**** BEGIN LOGGING AT Thu Feb 10 02:59:57 2011 Feb 10 04:16:43 working sgx driver for natty published at https://launchpad.net/~tiomap-dev/+archive/omap-trunk Feb 10 04:17:02 same version as currently used at maverick, but ported to make it work with natty's xorg Feb 10 09:49:12 rsalveti: cool Feb 10 10:02:23 rsalveti: thanks for pushing the DDK update for natty! Feb 10 10:13:27 ogra, in the natty platform seed I see dove, is that still needed there? Feb 10 10:14:13 also what is the difference between platform.natty and ubuntu.natty seeds? I saw no overview of the relationship between various ubuntu.seed branches Feb 10 10:18:47 janimo, in the seeds we can keep it in case a platform comes back you dont need to redo the whole seeding Feb 10 10:19:13 we dont build images for such platforms so it shouldnt do any harm apart from a bit bit-rotting Feb 10 10:19:22 janimo, also forget about seeds Feb 10 10:19:30 ogra, right but I was hoping version control software was a better fit for keeping such legacy bits around Feb 10 10:19:46 I find almost all the scripts in the area of image building have a lot of unnecessarey baggage Feb 10 10:20:00 making them harder to understand Feb 10 10:20:07 janimo, i had a chat with lool yesterday, they use the same low level seed and have a policy that no bootloader should be installed, we would break it for them Feb 10 10:20:09 ogra, so no bootloaders in the seeds? Feb 10 10:20:26 ok, I'll add them in livecd-rootfs then Feb 10 10:20:30 no Feb 10 10:21:04 just have a line in the upgrade script that apt-get installs them ... we dont need them seeded, you need the latest version from the archive anyway Feb 10 10:21:58 one check of the script should be that -updates is enabled, then get the last versions from there and drop the binaries in place Feb 10 10:22:02 ogra, yes but they will not be upgraded ifg they are not in the image initally Feb 10 10:22:17 the version we would seed would be the original one installed anyway Feb 10 10:22:35 ogra right, but then updates would be automatic Feb 10 10:22:54 why do we need automated updates here ? Feb 10 10:23:10 ogra, if the script needs to bring them the user cannot be notified when an update is there Feb 10 10:23:18 automated fetch not install Feb 10 10:23:57 we dont want to actually encourage users to upgrade their bootloader, we just need a tool for the case where we tell them to upgrade Feb 10 10:23:59 well suppose we have a bugfix, how to propagete to users so they stop complaining about it? I think it shold be like a regular bugfix via apt Feb 10 10:24:05 ogra, ok Feb 10 10:24:06 i.e. we dont need notification here Feb 10 10:25:13 ogra, in this case apt-get installing it just to put it on the 1st partition is strange. Feb 10 10:25:29 anyway I'll do wahtever t tajkes to have some script working for omap3/4 Feb 10 10:25:41 without too much fanciness :) Feb 10 10:26:07 well, if you prefer to pull the deb and extract it, i wouldnt object Feb 10 10:28:02 and if you have a convincing reason to have it on the image in advance, feel free to convince me, i was on that page before my discussion yesterday ;) Feb 10 10:28:16 yay, my new mobile just arrived Feb 10 10:28:43 ogra, well for easy of install and not bothering with extra step, plus to notufy users automatically. And if it can be done from livecd-rootfs withoiut touching the seeds what is the drawback? Feb 10 10:29:03 ogra: Well, it's not a policy that no bootloader should be installed :-) Feb 10 10:29:26 ah, i thought it was turned into some kind of policy Feb 10 10:29:29 it's just that we decided that the bootloader did not have to be part of the rootfs, even more so if it's not upgraded automatically (which we certainly don't want) Feb 10 10:29:52 janimo, what i see as a compelling reason to have it installed is that you easily can find out the version Feb 10 10:29:55 lool, we also decided that updates would not be automatic, but up to the user Feb 10 10:30:06 however this is not implemented, and I believe that current images still install a bootloader .deb, this is a limitation of our image writing tools which will be fixed once we implement what we call hwpack v2 Feb 10 10:30:19 https://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV2 Feb 10 10:31:44 I personally recommend *not* shipping the bootloader with apt/deb if you can avoid it because "updates" of this file wont make any sense (wont actually get the bootloader update, and might result in the rootfs hosting a bootloader which might not work when put to use) Feb 10 10:33:14 lool, yes, but you still get an easy way to check the version, might be helpful for i.e. apport reports of a kernel crash Feb 10 10:34:22 i know its doesnt necessarily show the running version Feb 10 10:35:06 It doesn't represent the real version Feb 10 10:35:11 it's just a random piece of data Feb 10 10:36:31 BTW the point I was making yesterday was about network-dependency Feb 10 10:37:15 Since you're going to want a fresher version of the bootloader to install because yours is borken, then you necessarily have access to an archive (since you can apt-get update to it), so why not instead apt-get install it when needed, and not install it by default in the first place? Feb 10 10:37:47 I didn't read the spec, so I don't understand how you'd actually boot your board which has a broken bootloader to upgrade it though Feb 10 10:38:41 lool, no provision for fixing that. So even if update is made easy, one still needs some technical skill to restore Feb 10 10:40:11 Perhaps one way this would work is from your x86 laptop, putting your rootfs SD card into it and updating the bootloader; if you really need to run ARM code, you could use qemu-arm-static, but I think you could avoid it Feb 10 10:40:33 thats a different scenario Feb 10 10:40:45 This would also allow the "download image from ubuntu.com, write to SD, update bootloader on SD, boot on recent hardware" use case Feb 10 10:41:00 the point is to be able to apply fixes, not tro make unbootable systems boot Feb 10 10:41:10 What kind of fix? Feb 10 10:41:44 initialization errors of single bits of the hw that the bootloader has by release time for example Feb 10 10:42:02 Why can't this be done in linux? Feb 10 10:42:26 because it might be a more ugly patch or it might not be possible to do it after boot Feb 10 10:42:46 the omap4 display issue we had would not have been solvable in the kernel for example Feb 10 10:43:15 So how would you do it with another bootloader? Feb 10 10:43:23 e.g. in production, with a lightweight bootloader Feb 10 10:43:36 it was an x-loader fix that initialized the HW Feb 10 10:43:41 I might not know the specific of this bug, it just seems odd that hardware state would belong into u-boot Feb 10 10:43:58 it wasnt u-boot but x-loader Feb 10 10:44:03 If x-loader/u-boot work enough to start a kernel, then it seems to be the kernel could fixup stuff Feb 10 10:44:24 if you set a voltage wrong and the kernel cant adjust it, you cant fix it differently Feb 10 10:44:33 Why wouldn't the kernel be able to adjust? Feb 10 10:44:44 (I am really ignorant here) Feb 10 10:44:45 because there is no interface to do so Feb 10 10:45:24 * ogra needs to vanish for a moment Feb 10 12:02:29 morning Feb 10 12:07:46 lool: ideally the kernel should handle everything, and the x-loader/u-boot would just bring up the board Feb 10 12:07:49 but is not the case atm Feb 10 12:08:06 x-loader is still important, and still setting things that the kernel expects to be ready once it boots Feb 10 12:08:28 that's why in the last cycle we needed a x-loader update to have a feature working fine Feb 10 12:08:34 Yup Feb 10 12:08:42 so the system is working, is booting Feb 10 12:08:58 but not properly working regarding some feature Feb 10 12:09:10 that x-loader, for example, initialize, then we need a way to update it Feb 10 12:09:27 as we can easily brick the board with automatic updates, we decided to provide a tool for the user Feb 10 12:09:33 and notify him once we have new updates Feb 10 12:09:44 so he can run this tool, and update the core boot files Feb 10 12:10:03 having both installed at the images can make the work a lot easier Feb 10 12:10:10 Hmm the notification part is harder Feb 10 12:10:11 at least to identify the version, and also to notify the user Feb 10 12:10:30 Do we expect this to happen frequently? It would make sense to invest in having the init done by linux instead of x-loader Feb 10 12:10:51 well, it happened frequently with maverick Feb 10 12:11:37 It sounds a bit like a BIOS update, but you can't even check which version of the BIOS you're using! Feb 10 12:11:39 and because of the short time frame to have a working 2.6.38, I'd not expect to have the kernel properly setting up everything Feb 10 12:12:00 you can only check by the binaries, or by the package metadata, if it's installed at the system Feb 10 12:12:33 This is very indirect Feb 10 12:12:59 true Feb 10 12:12:59 binaries > if you mean the ones on the boot partition, that's ok, but the one in the rootfs that would sound bad Feb 10 12:13:15 the ones at the boot partition Feb 10 12:13:26 I'm not up-to-date on flash-kernel stuff ATM; is the boot partition always mounted, or mounted when needed? Feb 10 12:13:46 mounted when needed Feb 10 12:14:25 You're going to want some kind of permanently installed package to raise the notification; perhaps a sensible one would be jockey Feb 10 12:14:44 jockey could mount this partition ro when starting (ouch, but eh) and check MLO for a specific version Feb 10 12:15:43 then you decide that an update is needed; jockey does the x-loader package download if needed and run a x-loader flashing wrapper; question is whether x-loader package stays installed o rnot Feb 10 12:15:47 *or not Feb 10 12:16:46 we don't want to run the update automatically Feb 10 12:16:52 Jockey prompts you Feb 10 12:16:55 we want the user to run the flashing tool Feb 10 12:16:58 that can work Feb 10 12:17:41 it probably needs some adaptations to deal with this, but that would seem to give a good starting platform; maybe pitti would have more comments there Feb 10 12:17:51 janimo: ^ Feb 10 12:18:10 We might not have a text UI for jockey Feb 10 12:18:17 only Gtk+ and Qt based ones Feb 10 12:19:00 hm, we would need to run this procedure in text mode too Feb 10 12:19:05 as we'll have the minimal image Feb 10 12:19:07 the actual flashing script should probably be implemented in flash-kernel, but with special care to advertize this as extremely dangerous brick-your-device feature Feb 10 12:19:20 You could have documentation for text mode Feb 10 12:19:31 run flash-kernel --flash-bootloader Feb 10 12:20:07 guess that's ok Feb 10 12:20:21 Technically, you could use package upgrades to trigger flashing, but it's not really a direction that seems reasonnable :-. Feb 10 12:20:25 :-/ Feb 10 12:20:34 lool, I was also thinking of adding it to flash-kernle as it makes packagihng and coding easier. I am not sure if this does not take it further away from debian and the original intention of the package Feb 10 12:21:05 but, yes I would rather have it in flash-kernel that a separate source package for one script Feb 10 12:21:12 janimo: Currently flash-kernel has knowledge of where your bootloader lives (SD vs flash); that's the only non-installer place which has this, so it seems sensible Feb 10 12:21:40 lool, actually for OMAP flash-kernel needs to be told the partition in a config file ia UBOOT_PART Feb 10 12:21:44 In general, I think flash-kernel needs to be modernized substantially, but it's a lot of work Feb 10 12:21:46 so it's not like it autotdetecta anything Feb 10 12:22:05 lool, otherwise it assumes NAND Feb 10 12:22:12 janimo: I know, but it has code to parse flash-kernel.conf and stuff, doesn't it? Feb 10 12:22:24 but the conf is there by default already Feb 10 12:22:35 if the user installed by using our image Feb 10 12:22:48 not completely safe, but ok Feb 10 12:22:50 You wouldn't want to have another tool reading this kind of data; it's very Ubuntu specific and I'd like to keep it flash-kernel-specific; if it spreads to other packages we're bound to lots of pain Feb 10 12:22:51 lool, sure, I am for using flash-kernel, just pointing out that the code in case was not some complex piece Feb 10 12:22:57 lool, true Feb 10 12:23:26 It's really not about complexity, it's rather that I find this dirty enough :-) Feb 10 12:23:45 this whole flash-kernel.conf was quickly thrown together some years ago, and never architectured, sent to Debian or anything Feb 10 12:23:55 I could easily take the blame for this though Feb 10 12:23:55 lool, actually flash-bootloader may not be enough. I think we;d want to update xloader and uboot independently. Feb 10 12:24:13 so maybe have flash-bootfile /path/to/opaquefile Feb 10 12:24:22 or flash-uboot, flash-xloader options Feb 10 12:24:27 flash-bootloader should be fine Feb 10 12:24:29 however this make it very omap specific Feb 10 12:24:32 you can check both before updating Feb 10 12:24:36 and updating what needs to be updated Feb 10 12:24:50 x-loader is omap specific Feb 10 12:24:53 rsalveti, makes sense, but maybe the user would only want to update one Feb 10 12:24:56 and also part of the booting procedure Feb 10 12:25:36 the normal user would not update it independently Feb 10 12:25:41 so no GUI, agreed? Feb 10 12:25:45 I think it's best if you know what you're doing; flash-kernel --install-to-boot /usr/lib/x-loader:MLO && flash-kernel --install-to-boot /usr/lib/u-boot:u-boot.bin sounds much uglier than flash-kernel --spl --tpl or flash-kernel --bootloaders=spl,u-boot Feb 10 12:25:47 probably doesn't not even know about x-loader/u-boot Feb 10 12:26:05 You basically don't want to leave any room for hacks or abuses with this kind of stuff Feb 10 12:26:16 yup Feb 10 12:26:23 otherwise someone is going to suggest flash-kernel --install-to-boot boot.scr in some documentation Feb 10 12:26:25 both of these contradicotry approaches make sense Feb 10 12:26:33 depends who are we targeting and which is more useful in general Feb 10 12:26:34 janimo: gui just to warn the user Feb 10 12:26:39 aobut the update Feb 10 12:26:59 and then the seas will rise, cities will collapse, mountains will fall Feb 10 12:27:08 rsalveti, I think we still need to decide whether these belong to the preinstalled image or not, at least ogra seems to have doubts about the latter Feb 10 12:27:08 janimo: Why no GUI? :-) Feb 10 12:27:10 :-) Feb 10 12:27:43 I mean, perhaps I'm thinking it wrong, but to me you're trying to distribute an user-friendly Ubuntu for OMAP4 which does the right thing Feb 10 12:27:43 lool, no extra GUI I mean. If it cannot be part of update-manager or some other apt-related I'd rather us not have a special gui for this Feb 10 12:27:54 janimo: why not part of jockey? Feb 10 12:28:32 jockey will popup and tell you that you bought a proprietary graphics card and that you can't get any boingboing effects without clicking "Install these binary stuff" Feb 10 12:28:52 lool, no experience with jockey, but party because I;d like to first figure out somethig that works and then see if it can be imporved, before touching too many different packages initially Feb 10 12:28:58 gnome-power-manager will tell you "This battery has been recalled, contact your manufacturer" Feb 10 12:29:25 lool, yes but that is already running and does this as an extra. We'd not run a dameon specifically to watch for updates Feb 10 12:29:32 that's wha update-manager does Feb 10 12:29:32 janimo: Sure; these are kind of orthogonal, but in general user experience is better designed top-down (apple) than bottom-up (linux :-) Feb 10 12:29:57 lool, true as well, but we are talking about a rpocedure which requires running a cmdline app Feb 10 12:29:59 You can implement the flash-kernel plumbing first obviously Feb 10 12:30:15 which if goes wrong needs expert intervention anyway -VFAT formatting, copying of blobs etc Feb 10 12:30:32 lool, right, the core operation first and see how it can be improved Feb 10 12:30:44 update-manager delivers package updates, or recommends dist upgrades; don't think it deals with special general-purpose hooks like jockey kind of does; I don't know where you'd put the data Feb 10 12:31:23 * lool thinks jockey could also be used to install the powervr stuff Feb 10 12:31:28 lool, that is why the solution (until yesterday that is) involved having the packages installed so dpkg post install hooks can be used for this purpose Feb 10 12:31:40 * janimo does not know about the powervr use case Feb 10 12:32:10 it's technically feasible to decide to do upgrades from package hooks, but I would find that disturbing and risky Feb 10 12:32:37 lool: jockey could work fine with pvr, I believe Feb 10 12:32:45 at least would make sense Feb 10 12:33:08 (because you'd have to protect the action by some debconf prompt which are considered evil and would have to fail by default, and because it would create a perception that you have x-loader 1.2.4 when in fact you have some random other version and it doesn't necessarily get installed) Feb 10 12:33:39 the jockey case also makes it more obviously optin than upgrade your system and it might not boot Feb 10 12:34:18 lool, well technically it is just as risky as upgrading kernel/initrd no? If update gets broken it does not boot. And we would not push broken boot loaders to the archive Feb 10 12:35:03 janimo: well, kind of Feb 10 12:35:04 sure if jockey is better suited for this it can be used, I just have no experience with it Feb 10 12:35:14 the user can still try something at the u-boot prompt Feb 10 12:35:23 if we break x-loader, nothing will show at the uard Feb 10 12:35:26 *uart Feb 10 12:35:35 and the user will cry and screen Feb 10 12:37:13 rsalveti, but if a user can work with uboot prompt via serial he can surely copy two files on the MMC VFAT partition? Feb 10 12:37:41 janimo: probably not Feb 10 12:37:52 we have cases that the user only uses uart to see what's happening Feb 10 12:37:57 and log-in into the system Feb 10 12:38:00 I see this spec as a convenience use-case not one that makes regular users do expert things because of a wrapper Feb 10 12:38:34 but don't have proper technical background for other stuff Feb 10 12:39:20 yup, we should focus on the simple user, that just want his system to be fixed Feb 10 12:39:25 janimo: I tend to agree that it would be best if we had a way to offer booting older kernel / initrd, or passing cmdline options; not visible by default, but to be able to maintain multiple kernels on a system Feb 10 12:39:57 but the difference is that we know the kernel is going to see some security updates, while the bootloader shouldn't ever need an upgrade if we don't really need it Feb 10 12:40:10 it should basically get out of the way; think of it as firmware Feb 10 12:40:51 I have devices where in theory I have source of the bootloader, but I didn't build it myself and I doubt I'd be able to replace a broken bootloader; in fact, if I flash a broken bootloader there is zero way to recover Feb 10 12:41:19 it might not be true on SD, but because the solution will involve flash-kernel etc. it would be best to have safety nets in place and not do it unless really needed Feb 10 12:41:40 For instance, you might want to decide to only upgrade the bootloader if people are running a specific board Feb 10 12:42:29 lool, you mean variants of beagle or rather beagle vs panda? Feb 10 12:43:05 both Feb 10 12:43:11 right now I guess all variant will get a new package being in the same source package even if only one gets a fix Feb 10 12:43:34 so you're upgrading the bootloader even when not strictly needed? sounds bad Feb 10 12:44:23 lool, no, the opposite, was just needing calrification Feb 10 13:02:21 lool: not even jtag Feb 10 15:35:13 ogra, yo ... seems that the linaro qemu images have hit the archive. this ought to mean we can emulate omap3 correctly now, which might mean that versatile kernels are no longer needed for arm as they are used for qemu only ... what are your thoughts? Feb 10 15:35:32 ogra, i am a little concerned about the interaction between a lucid host and this though Feb 10 15:36:29 apw: well, at least with rootstock (that uses versatile) I'll test with omap 3 and see how it goes Feb 10 15:36:49 but it should work fine, as linaro is already using qemu with the omap 3 kernel Feb 10 15:36:49 rsalveti, that sounds good ... Feb 10 15:36:57 don't know if we have any other use for versatile Feb 10 15:37:02 maybe ogra knows Feb 10 15:37:13 rsalveti, there is a bug open which might make sense to report the outcome of any testing Feb 10 15:37:18 bug #715113 Feb 10 15:37:19 Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/715113 Feb 10 15:37:23 apw: sure, will do Feb 10 15:37:43 apw, we were just discussing it in the meeting :) Feb 10 15:38:26 And in -kernel Feb 10 15:38:55 heh and here, and ... yeah i am suggesting the bug for any position statements or testing :) Feb 10 15:41:53 apw, the bug I filed is part of a spec of the arm team, so they are at least partly aware of the situation :) Feb 10 15:42:22 apw, there are some bugs still with various corner cases but the linaro devs are on them and fix qemu relatively fast Feb 10 15:44:23 yup Feb 10 15:44:31 so we should be safe with the qemu-linaro and omap 3 Feb 10 15:45:26 Concern is for folks running a complex environment: for example lucid amd64 hosts running natty/arm buildds under qemu Feb 10 15:46:48 ppa should be enough for that Feb 10 15:48:01 I'd prefer a proper backport to a PPA: I know lots of folks who don't trust PPAs, for a number of fairly well-argued reasons. Feb 10 15:50:49 persia, sure but those special cases should not block removing versatile from natty right Feb 10 15:50:49 ? Feb 10 15:51:45 I don't see any special reason to block the removal. Feb 10 15:52:03 That said, it's probably worth filing a backports bug for qemu-linaro once it's known good. Feb 10 16:01:28 NCommander, bug 708661 and bug 708659 Feb 10 16:01:31 Launchpad bug 708661 in libqtgconf "[MIR] please include libqtgconf in natty main" [High,Incomplete] https://launchpad.net/bugs/708661 Feb 10 16:01:33 Launchpad bug 708659 in libqtbamf "[MIR] please include libqtbamf in natty main" [High,Incomplete] https://launchpad.net/bugs/708659 Feb 10 16:01:44 see the last comments Feb 10 21:10:47 btw, anyone aware of ppa w/ firefox-4.0 for arm? Feb 10 21:10:53 ppa:ubuntu-mozilla-daily/ppa doesn't seem to build for arm.. Feb 10 22:29:36 micahg, Hey. firefox-4.0 in the mozillateam PPA doesn't build for ARM. Are there any backports available, or other ways to get it for maverick? Feb 10 22:30:06 persia: we might be able to throw it in maverick-backports Feb 10 22:30:27 Is there a good version suitable for -backports? Feb 10 22:30:40 natty looks like beta11 Feb 10 22:30:52 robclark, Was there a specific version you wanted/needed? Feb 10 22:32:23 well, actually, the problem with throwing it in -backports is I don't want to replace the current version in Maverick yet Feb 10 22:33:08 I'll have to see, maybe I can get a native PPA for firefox Feb 10 22:33:56 or maybe an ARM enabled PPA Feb 10 22:35:02 also, is there a specific timeframe (i.e. you need a version now, or just want Firefox 4 on maverick at some point) Feb 10 22:35:04 Without the completion of https://launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster ARM PPAs are tricky :( Feb 10 22:35:29 I'm just asking you as the most knowledgeable person I know because robclark asked earlier. Feb 10 22:35:45 I don't know the detailed requirements. Feb 10 22:36:06 ok, it would be nice to know what the use case is, that might help how it's implemented Feb 10 22:40:08 persia, just something recent 4.0 beta Feb 10 22:40:20 micahg, ^^ Feb 10 22:40:27 supposedly there should be some performance improvements.. Feb 10 22:40:34 robclark: can I ask what the use case is? Feb 10 22:40:40 we just want to do some benchmarking w/ our xorg driver Feb 10 22:40:51 browsing the web ;-) Feb 10 22:41:01 scrolling performance and stuff like that Feb 10 22:41:01 robclark: I'm wondering maverick vs natty Feb 10 22:41:16 ahh, maverick preferrably.. Feb 10 22:41:29 I'm running mostly maverick right now Feb 10 22:42:17 robclark: do you specifically need a PPA, or is this just for you? I could build debs for you on ARM Feb 10 22:47:24 robclark: chrisccoulson suggested just grabbing the natty debs Feb 10 22:48:32 Do they install cleanly on maverick? I thought there've been a few ABI transitions. Feb 10 22:48:48 i can't think of any reason it wouldn't work Feb 10 22:49:01 persia: we use mostly internal libs for Firefox, so there shouldn't be an issue Feb 10 22:49:06 remember, firefox uses bundled copies of pretty much everything except gtk and libc Feb 10 22:49:18 and those don't break ;) Feb 10 22:49:29 i might be wrong, but it *should* work on maverick Feb 10 22:49:48 micahg, doesn't need to be a PPA.. Feb 10 22:50:00 oh, are there natty debs Feb 10 22:50:43 * persia grumbles about internal libraries, grumbles more about firefox security, and finds a hole in the sand in which to insert head. Feb 10 22:51:20 persia - it's not really a problem for firefox, it gets frequent security updates anyway (more frequently than any of our system libraries) Feb 10 22:52:07 No moving the sand away from my eyes: I don't want to know :) Feb 10 22:52:16 heh Feb 10 22:52:30 in addition to that, there are other benefits to using bundled libraries Feb 10 22:52:34 out of shampoo ? Feb 10 22:52:41 one of them being that we can submit crash reports directly to mozilla Feb 10 22:52:59 so they have visibility of linux crashes, which is a very important part of their QA Feb 10 22:53:00 * ogra heard of birds that prefer sand, i didnt know it was polular in japan Feb 10 22:55:12 * persia is emulating an ostrich Feb 10 22:55:48 japanese ostrich ? Feb 10 22:57:47 Sure. Any ostrich. If I can't see the problem, it doesn't exist, and won't eat me. Feb 10 22:58:58 hmm, wget + dpkg -i http://launchpadlibrarian.net/62913574/firefox_4.0~b10%2Bbuild1%2Bnobinonly-0ubuntu2_armel.deb didn't seem to result in anything workable.. Feb 10 22:59:08 although I guess there are probably some other deb's I need to install? Feb 10 22:59:22 one 10mb .deb file seems a bit small for firefox Feb 10 23:04:00 rsalveti: After resolving a few local issues, I finally got around to getting the latest beaglexm image up. Seeing a kernel oops on kswapd. System runs, but this is not a good thing to have. Filing a bug now. Feb 10 23:04:29 GrueMaster: ok Feb 10 23:07:12 robclark, What sort of error did you get trying to install? Feb 10 23:07:43 persia, it installed fine.. but just crashes on startup.. Feb 10 23:08:02 heh. Feb 10 23:08:07 but I guess there are probably other deb's I need to install, so maybe I ended up with some 3.6/4.0 hybrid.. Feb 10 23:08:33 The dependencies should have prevented that. Feb 10 23:08:52 chrisccoulson, micahg: maybe you could fix the dependencies, or build a maverick backport? Feb 10 23:09:59 i really need arm hardware to test this stuff on ;) Feb 10 23:10:10 yeah, it's going to need a backport as the depends are versioned based on natty Feb 10 23:10:20 i've been debugging an arm build failure with upstream today, but i've got absolutely no way of testing this Feb 10 23:10:29 ahh Feb 10 23:10:44 well, I have the setup to test deb's on maverick if that helps at all ;-) Feb 10 23:10:45 i just press the button and hope people say if it doesn't work ;) Feb 10 23:11:25 i can test builds ok on the porter boxes, but they don't have an X display ;) Feb 10 23:11:27 chrisccoulson, You might ask if anyone else in mozillateam has ARM hardware :) Feb 10 23:11:59 chrisccoulson: I can test stuff on ARM Feb 10 23:12:23 that doesn't really solve my problem though (having no way of testing it myself) ;) Feb 10 23:12:37 chrisccoulson: I might be able to set up the machine so you can test Feb 10 23:13:38 * persia imagines a video camera and robotic key-presser. Feb 10 23:13:59 * micahg is thinking more along the lines of VNC ;) Feb 10 23:14:06 heh :) Feb 10 23:15:11 persia: Hey there; did you build an efikamx .deb as of late? Feb 10 23:15:32 persia: I checked the linaro-mx51 one, and it has efikamx enabled in the config, but I bet it misses tons of patches Feb 10 23:17:26 lool, I'm working on one. I have a current tree, but kernel packaging is *hard* Feb 10 23:17:41 (it's sascha + rtp + ubuntu sauce) Feb 10 23:18:15 persia: Ok; jcrigby has a script to generate linaro-foo sources from a common git tree, not sure if that helps Feb 10 23:18:40 I've looked at that, and it doesn't quite do what I want. I care about d-i integration, etc. Feb 10 23:18:53 debian.linaro/scripts/mkflavourbranches in git.l.o:ubuntu/linux-linaro-natty.git Feb 10 23:19:16 persia: Ok; what do you do instead? Feb 10 23:19:58 I've been working off the variations abogani used for the -lowlatency kernel to get an idea how to package it. Feb 10 23:20:29 Ok Feb 10 23:20:34 Basically, creating debian.foo and fiddling the scripts to pull the right bits together. Feb 10 23:20:46 udebs should in theory be possible with linaro kernels, but I'd expect them to be disabled by default Feb 10 23:21:03 That said, I'd much prefer to use a linaro-imx51 kernel, if you guys are happy to produce one with all the d-i bits and Ubuntu sauce. Feb 10 23:21:57 Last time I looked at the Linaro kernel packages, they were disabled by default: looked mostly like replacement kernels to test stuff, targeting folk who were capable of initialising their own bootloader, rather than the "Insert card, hold key, reboot" crowd. Feb 10 23:21:59 persia: apparently our mx51 kernel spits udebs out Feb 10 23:22:02 https://launchpad.net/ubuntu/+source/linux-linaro-mx51/2.6.37-1002.5/+buildjob/2183588 Feb 10 23:22:17 persia: efikamx is definitely enabled in the config I'm looking at Feb 10 23:22:24 Oh, heh. I was looking at the linaro wiki, and I should have looked at LP :) Feb 10 23:22:25 CONFIG_MACH_MX51_EFIKAMX=y Feb 10 23:22:32 but not sb, not in upstream yet Feb 10 23:22:44 Has anyone tested it? Feb 10 23:23:03 No; I have that in mind since beginning of this week Feb 10 23:23:13 persia: u-boot-linaro just gained efikamx as well Feb 10 23:23:14 I have patches for SB, but I'm honestly much more interested in MX. Feb 10 23:23:15 from upstream Feb 10 23:23:29 Oh, excellent. Then I'll stop fiddling with a kernel: no point :) Feb 10 23:23:31 rsalveti: Bug 716761 Feb 10 23:23:31 still in NEW though Feb 10 23:23:33 Launchpad bug 716761 in linux-meta "Page allocation failures during system boot on beagleXM" [Undecided,New] https://launchpad.net/bugs/716761 Feb 10 23:23:40 persia: Well, I don't have it yet :-) Feb 10 23:23:44 Are you moving to 2.6.38 soon? Feb 10 23:23:45 persia: did you care about efikamx or sb? Feb 10 23:23:51 persia: dunno Feb 10 23:24:05 I mostly care about MX. SB would be nice, but most of the folk I know have MX rather than SB. Feb 10 23:24:09 persia: patches > basically our gatekeeper is npitre and I guess he will take stuff which is going upstream Feb 10 23:24:37 I'm a bit lazily waiting for u-boot-linaro-efikamx to be published to propose a hwpack Feb 10 23:25:02 lool, By "going upstream" do you mean for-linus, for-rmk, or for-sascha? Feb 10 23:25:11 eventually going upstream :-) Feb 10 23:25:33 Ah, so for-sascha patches are acceptable? That's not so bad then. Feb 10 23:25:35 I don't think there's a set limit; it's basically good enough quality and eventually ending in mainline via variou trees Feb 10 23:25:55 What timezone is npitre? Feb 10 23:26:08 I would think patches from Sacha's tree would be acceptable, and hope that for-sascha patches stand a chance :-) Feb 10 23:26:16 Eastern Canada IIRC Feb 10 23:26:31 persia: best is email rather than IRC Feb 10 23:26:42 Ah. That makes it tricky :) Feb 10 23:26:47 pull request is ideal, preferably based of a linux tree Feb 10 23:27:00 well it's his EOD now, he might be around still Feb 10 23:27:25 I'd need to find somewhere to put a git tree :) Most of the interesting stuff I have is quilt. Feb 10 23:27:52 But I'll try to merge the quilt stuff against linaro-imx51, and make either a tree or a sequence of mail-formatted patches available, and send to npitre. Feb 10 23:28:18 That'll be *heaps* easier than me pretending to be a kernel developer. Feb 10 23:44:41 persia: You can send him a patch series or you can host the patches as regular files Feb 10 23:44:47 persia: he has access to canonical hosts too Feb 10 23:47:27 The hard part is trying to sort which patches are interesting, really. Feb 10 23:52:41 yeah Feb 11 00:07:06 GrueMaster: can you also try to update to the latest kernel? Feb 11 00:07:20 the rc4 based one should be available already Feb 11 00:08:42 I didn't see it in the pool yet, but I'll check launchpad. Feb 11 00:09:39 https://launchpad.net/ubuntu/+source/linux/2.6.38-3.30/+buildjob/2252836 Feb 11 00:11:30 Yea, finished 16 minutes ago. That's why. Feb 11 00:11:33 Heh. Feb 11 00:11:44 hehe Feb 11 00:12:04 Hrm? Says finished 7 hours ago for me. Feb 11 00:12:45 https://launchpad.net/ubuntu/+source/linux-meta/2.6.38.3.17/+buildjob/2255077 Feb 11 00:13:14 That's what is currently published (or in the que). Feb 11 00:13:20 Ah. That's probably still stuck in the publisher. Feb 11 00:13:38 But it finished enough before the hour that it ought be in this run, rather than waiting until the next run. Feb 11 00:14:23 Right, but last I was told, the publishing run starts at ~:05 and finishes at :40. Feb 11 00:14:36 * npitre sees a pending interrupt for himself here Feb 11 00:14:46 So I only have to wait another 30 minutes. Feb 11 00:15:36 npitre, I've been trying to package an imx51 kernel tree with sascha's tree + patches from rtp + ubuntu sauce. lool advised me you were the gatekeeper for linux-linaro-imx51, and I should send you patches and use your package. Feb 11 00:16:15 npitre, Since the last upload is 2.6.37, I'll try to sort out what patches I have that are relevant to the efika boards, and prepare a tree for your review. Feb 11 00:16:41 persia: no problem Feb 11 00:16:57 npitre, For reference, rtp's work is a quilt patchset at git://git.rtp-net.org/efika.git Feb 11 00:17:38 persia: what is rtp? Feb 11 00:18:01 npitre, Arnaud Patard Feb 11 00:18:04 persia: fyi, the linaro tree should move to 2.6.38-rc5 once released Feb 11 00:19:01 npitre, Excellent. If your 2.6.37 boots on the hardware, I'll postpone sending you patches until after the move. If not, I may send you a few in advance. Feb 11 00:20:53 persia: OK, as lool hinted I'm not that good at tracking irc so feel free to send me an email if you have something you want included in the linaro kernel Feb 11 00:21:23 npitre, Absolutely :) I'm not that good at tracking email: thanks for having the initial discussion with me here. Feb 11 00:22:28 persia: you may try to ping me on irc, but sometimes this might take hours before I notice Feb 11 00:23:17 npitre, I'll send you email once I have something substantive. For now, I'm waiting on a test report for the Efika MX with your kernel. Feb 11 00:23:44 persia: OK Feb 11 01:09:04 cooloney: hey, are you back already? Feb 11 01:12:21 rsalveti: yeah, man Feb 11 01:12:26 rsalveti: how's going? Feb 11 01:12:39 cooloney: good, and you? Feb 11 01:12:41 refreshed? Feb 11 01:13:17 rsalveti: heh, actually a little bit tired Feb 11 01:13:29 rsalveti: any news? Feb 11 01:13:30 cooloney: well, weekend ahead :-) Feb 11 01:13:39 cooloney: well, some :-) Feb 11 01:13:45 we got a ti-omap4-dev branch Feb 11 01:13:50 as you probably know already Feb 11 01:14:15 cooloney: one thing I'd like to ask you is if you can test and merge the DVI patches for panda Feb 11 01:14:19 for 2.6.38 Feb 11 01:14:26 so we can have a working display with this kernel Feb 11 01:14:42 as my panda has a broken dvi, can't test atm Feb 11 01:14:52 look at l-o for [PATCH] OMAP4: PandaBoard: Adding DVI support Feb 11 01:15:13 rsalveti: sure, i will do it today Feb 11 01:15:27 i got that HDMI-DVI cable Feb 11 01:16:09 cooloney: cool Feb 11 01:16:17 rsalveti: is this one? Feb 11 01:16:18 but even the hdmi cable should work Feb 11 01:16:18 [PATCH] OMAP4: PandaBoard: Adding DVI support Feb 11 01:16:22 cooloney: yup Feb 11 01:16:30 rcn-ee said it worked fine for him Feb 11 01:16:32 so it should just work Feb 11 01:16:42 if it's the case, try sending it to this branch Feb 11 01:16:46 it's from Raghuveer Murthy Feb 11 01:16:48 ti-omap4-dev Feb 11 01:16:55 cooloney: yup, that's the one Feb 11 01:17:01 OK, i got it Feb 11 01:17:29 so will we get .38 patches soon? Feb 11 01:18:55 cooloney: not directly from serbjan, probably from linaro Feb 11 01:18:58 or something like that Feb 11 01:19:31 rsalveti: right, i know Andy Green is working with sebjan on that Feb 11 01:19:45 yeah Feb 11 01:20:18 rsalveti: thx a lot for this info. Feb 11 01:20:52 i will test that DVI patch and try to push to ti-omap4-dev Feb 11 01:22:01 * cooloney just update his machine, needs reboot, brb Feb 11 02:19:15 rsalveti: does our ti-omap-dev branch kernel supports graphic, since i wanna test that DVI patch. Feb 11 02:19:28 It should. Feb 11 02:19:42 cooloney: probably Feb 11 02:20:00 cooloney: you just need to check if you have all the dependencies, like described at the patch Feb 11 02:20:23 rsalveti: i think it is based on 2.6.38-rc kernel which miss some graphic support. Feb 11 02:20:42 but as we're basically using the same one as master (rc4), and rcn-ee said it worked fine for him, I expect this patch to be enough to get the display working Feb 11 02:21:02 rsalveti: OK, I will try it soon **** ENDING LOGGING AT Fri Feb 11 02:59:57 2011