[04:15] <rsalveti> working sgx driver for natty published at https://launchpad.net/~tiomap-dev/+archive/omap-trunk
[04:16] <rsalveti> same version as currently used at maverick, but ported to make it work with natty's xorg
[09:48] <lool> rsalveti: cool
[10:01] <ndec> rsalveti: thanks for pushing the DDK update for natty!
[10:12] <janimo> ogra, in the natty platform seed  I see dove, is that still needed there?
[10:13] <janimo> also what is the difference between platform.natty and ubuntu.natty seeds? I saw no overview of the relationship between various ubuntu.seed branches
[10:17] <ogra> janimo, in the seeds we can keep it in case a platform comes back you dont need to redo the whole seeding
[10:18] <ogra> we dont build images for such platforms so it shouldnt do any harm apart from a bit bit-rotting
[10:18] <ogra> janimo, also forget about seeds
[10:18] <janimo> ogra, right but I was hoping version control software was a better fit for keeping such legacy bits around
[10:18] <janimo> I find almost all the scripts in the area of image building have a lot of unnecessarey baggage
[10:19] <janimo> making them harder to understand
[10:19] <ogra> 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
[10:19] <janimo> ogra, so no bootloaders in the seeds?
[10:19] <janimo> ok, I'll add them in livecd-rootfs then
[10:19] <ogra> no
[10:20] <ogra> 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
[10:21] <ogra> one check of the script should be that -updates is enabled, then get the last versions from there and drop the binaries in place
[10:21] <janimo> ogra, yes but they will not be upgraded ifg they are not in the image initally
[10:21] <ogra> the version we would seed would be the original one installed anyway
[10:21] <janimo> ogra right, but then updates would be automatic
[10:22] <ogra> why do we need automated updates here ?
[10:22] <janimo> ogra, if the script needs to bring them the user cannot be notified when an update is there
[10:22] <janimo> automated fetch not install
[10:23] <ogra> 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
[10:23] <janimo> 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
[10:23] <janimo> ogra, ok
[10:23] <ogra> i.e. we dont need notification here
[10:24] <janimo> ogra, in this case apt-get installing it just to put it on the 1st partition is strange.
[10:24] <janimo> anyway I'll do wahtever t tajkes to have some script working for omap3/4
[10:24] <janimo> without too much fanciness :)
[10:25] <ogra> well, if you prefer to pull the deb and extract it, i wouldnt object
[10:27] <ogra> 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 ;)
[10:27] <ogra> yay, my new mobile just arrived
[10:27] <janimo> 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?
[10:28] <lool> ogra: Well, it's not a policy that no bootloader should be installed  :-)
[10:28] <ogra> ah, i thought it was turned into some kind of policy
[10:28] <lool> 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)
[10:28] <ogra> janimo, what i see as a compelling reason to have it installed is that you easily can find out the version
[10:29] <janimo> lool, we also decided that updates would not be automatic, but up to the user
[10:29] <lool> 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
[10:29] <lool> https://wiki.linaro.org/Platform/Specs/11.05/HardwarePacksV2
[10:30] <lool> 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)
[10:32] <ogra> 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
[10:33] <ogra> i know its doesnt necessarily show the running version
[10:34] <lool> It doesn't represent the real version
[10:34] <lool> it's just a random piece of data
[10:35] <lool> BTW the point I was making yesterday was about network-dependency
[10:36] <lool> 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?
[10:36] <lool> 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
[10:37] <janimo> lool, no provision for fixing that. So even if update is made easy, one still needs some technical skill to restore
[10:39] <lool> 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
[10:39] <ogra> thats a different scenario
[10:39] <lool> This would also allow the "download image from ubuntu.com, write to SD, update bootloader on SD, boot on recent hardware" use case
[10:40] <ogra> the point is to be able to apply fixes, not tro make unbootable systems boot
[10:40] <lool> What kind of fix?
[10:40] <ogra> initialization errors of single bits of the hw that the bootloader has by release time for example
[10:41] <lool> Why can't this be done in linux?
[10:41] <ogra> because it might be a more ugly patch or it might not be possible to do it after boot
[10:41] <ogra> the omap4 display issue we had would not have been solvable in the kernel for example
[10:42] <lool> So how would you do it with another bootloader?
[10:42] <lool> e.g. in production, with a lightweight bootloader
[10:42] <ogra> it was an x-loader fix that initialized the HW
[10:42] <lool> I might not know the specific of this bug, it just seems odd that hardware state would belong into u-boot
[10:43] <ogra> it wasnt u-boot but x-loader
[10:43] <lool> If x-loader/u-boot work enough to start a kernel, then it seems to be the kernel could fixup stuff
[10:43] <ogra> if you set a voltage wrong and the kernel cant adjust it, you cant fix it differently
[10:43] <lool> Why wouldn't the kernel be able to adjust?
[10:43] <lool> (I am really ignorant here)
[10:43] <ogra> because there is no interface to do so
[10:44]  * ogra needs to vanish for a moment
[12:01] <rsalveti> morning
[12:06] <rsalveti> lool: ideally the kernel should handle everything, and the x-loader/u-boot would just bring up the board
[12:06] <rsalveti> but is not the case atm
[12:07] <rsalveti> x-loader is still important, and still setting things that the kernel expects to be ready once it boots
[12:07] <rsalveti> that's why in the last cycle we needed a x-loader update to have a feature working fine
[12:07] <lool> Yup
[12:07] <rsalveti> so the system is working, is booting
[12:08] <rsalveti> but not properly working regarding some feature
[12:08] <rsalveti> that x-loader, for example, initialize, then we need a way to update it
[12:08] <rsalveti> as we can easily brick the board with automatic updates, we decided to provide a tool for the user
[12:08] <rsalveti> and notify him once we have new updates
[12:08] <rsalveti> so he can run this tool, and update the core boot files
[12:09] <rsalveti> having both installed at the images can make the work a lot easier
[12:09] <lool> Hmm the notification part is harder
[12:09] <rsalveti> at least to identify the version, and also to notify the user
[12:09] <lool> Do we expect this to happen frequently?  It would make sense to invest in having the init done by linux instead of x-loader
[12:09] <rsalveti> well, it happened frequently with maverick
[12:10] <lool> It sounds a bit like a BIOS update, but you can't even check which version of the BIOS you're using!
[12:10] <rsalveti> 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
[12:11] <rsalveti> you can only check by the binaries, or by the package metadata, if it's installed at the system
[12:11] <lool> This is very indirect
[12:12] <rsalveti> true
[12:12] <lool> binaries > if you mean the ones on the boot partition, that's ok, but the one in the rootfs that would sound bad
[12:12] <rsalveti> the ones at the boot partition
[12:12] <lool> I'm not up-to-date on flash-kernel stuff ATM; is the boot partition always mounted, or mounted when needed?
[12:12] <rsalveti> mounted when needed
[12:13] <lool> You're going to want some kind of permanently installed package to raise the notification; perhaps a sensible one would be jockey
[12:13] <lool> jockey could mount this partition ro when starting (ouch, but eh) and check MLO for a specific version
[12:14] <lool> then <insert here some magic> 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
[12:14] <lool> *or not
[12:15] <rsalveti> we don't want to run the update automatically
[12:15] <lool> Jockey prompts you
[12:16] <rsalveti> we want the user to run the flashing tool
[12:16] <rsalveti> that can work
[12:16] <lool> 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
[12:16] <rsalveti> janimo: ^
[12:17] <lool> We might not have a text UI for jockey
[12:17] <lool> only Gtk+ and Qt based ones
[12:18] <rsalveti> hm, we would need to run this procedure in text mode too
[12:18] <rsalveti> as we'll have the minimal image
[12:18] <lool> 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
[12:18] <lool> You could have documentation for text mode
[12:18] <lool> run flash-kernel --flash-bootloader
[12:19] <rsalveti> guess that's ok
[12:19] <lool> Technically, you could use package upgrades to trigger flashing, but it's not really a direction that seems reasonnable  :-.
[12:19] <lool> :-/
[12:19] <janimo> 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
[12:20] <janimo> but, yes I would rather have it in flash-kernel that a separate source package for one script
[12:20] <lool> 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
[12:20] <janimo> lool, actually for OMAP flash-kernel needs to be told the partition in a config file ia UBOOT_PART
[12:20] <lool> In general, I think flash-kernel needs to be modernized substantially, but it's a lot of work
[12:20] <janimo> so it's not like it autotdetecta anything
[12:21] <janimo> lool, otherwise it assumes NAND
[12:21] <lool> janimo: I know, but it has code to parse flash-kernel.conf and stuff, doesn't it?
[12:21] <rsalveti> but the conf is there by default already
[12:21] <rsalveti> if the user installed by using our image
[12:21] <rsalveti> not completely safe, but ok
[12:21] <lool> 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
[12:21] <janimo> lool, sure, I am for using flash-kernel, just pointing out that the code in case was not some complex piece
[12:22] <janimo> lool, true
[12:22] <lool> It's really not about complexity, it's rather that I find this dirty enough  :-)
[12:22] <lool> this whole flash-kernel.conf was quickly thrown together some years ago, and never architectured, sent to Debian or anything
[12:23] <lool> I could easily take the blame for this though
[12:23] <janimo> lool, actually flash-bootloader may not be enough. I think we;d want to update xloader and uboot independently.
[12:23] <janimo> so maybe have flash-bootfile  /path/to/opaquefile
[12:23] <janimo> or flash-uboot, flash-xloader options
[12:23] <rsalveti> flash-bootloader should be fine
[12:23] <janimo> however this make it very omap specific
[12:23] <rsalveti> you can check both before updating
[12:23] <rsalveti> and updating what needs to be updated
[12:23] <rsalveti> x-loader is omap specific
[12:23] <janimo> rsalveti, makes sense, but maybe the user would only want to update one
[12:24] <rsalveti> and also part of the booting procedure
[12:24] <rsalveti> the normal user would not update it independently
[12:24] <janimo> so no GUI, agreed?
[12:24] <lool> 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
[12:24] <rsalveti> probably doesn't not even know about x-loader/u-boot
[12:25] <lool> You basically don't want to leave any room for hacks or abuses with this kind of stuff
[12:25] <rsalveti> yup
[12:25] <lool> otherwise someone is going to suggest flash-kernel --install-to-boot boot.scr in some documentation
[12:25] <janimo> both of these contradicotry approaches make sense
[12:25] <janimo> depends who are we targeting and which is more useful in general
[12:25] <rsalveti> janimo: gui just to warn the user
[12:25] <rsalveti> aobut the update
[12:26] <lool> and then the seas will rise, cities will collapse, mountains will fall
[12:26] <janimo> 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
[12:26] <lool> janimo: Why no GUI?  :-)
[12:26] <rsalveti> :-)
[12:26] <lool> 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
[12:26] <janimo> 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
[12:27] <lool> janimo: why not part of jockey?
[12:27] <lool> 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"
[12:27] <janimo> 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
[12:28] <lool> gnome-power-manager will tell you "This battery has been recalled, contact your manufacturer"
[12:28] <janimo> lool, yes but that is already running and does this as an extra. We'd not run a dameon specifically to watch for updates
[12:28] <janimo> that's wha update-manager does
[12:28] <lool> janimo: Sure; these are kind of orthogonal, but in general user experience is better designed top-down (apple) than bottom-up (linux :-)
[12:29] <janimo> lool, true as well, but we are talking about a rpocedure which requires running a cmdline app
[12:29] <lool> You can implement the flash-kernel plumbing first obviously
[12:29] <janimo> which if goes wrong needs expert intervention anyway -VFAT formatting, copying of blobs etc
[12:29] <janimo> lool, right, the core operation first and see how it can be improved
[12:29] <lool> 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
[12:30]  * lool thinks jockey could also be used to install the powervr stuff
[12:30] <janimo> 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
[12:30]  * janimo does not know about the powervr use case
[12:31] <lool> it's technically feasible to decide to do upgrades from package hooks, but I would find that disturbing and risky
[12:31] <rsalveti> lool: jockey could work fine with pvr, I believe
[12:31] <rsalveti> at least would make sense
[12:32] <lool> (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)
[12:32] <lool> the jockey case also makes it more obviously optin than upgrade your system and it might not boot
[12:33] <janimo> 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
[12:34] <rsalveti> janimo: well, kind of
[12:34] <janimo> sure if jockey is better suited for this it can be used, I just have no experience with it
[12:34] <rsalveti> the user can still try something at the u-boot prompt
[12:34] <rsalveti> if we break x-loader, nothing will show at the uard
[12:34] <rsalveti> *uart
[12:34] <rsalveti> and the user will cry and screen
[12:36] <janimo> rsalveti, but if a user can work with uboot prompt via serial he can surely copy two files on the MMC VFAT partition?
[12:36] <rsalveti> janimo: probably not
[12:36] <rsalveti> we have cases that the user only uses uart to see what's happening
[12:37] <rsalveti> and log-in into the system
[12:37] <janimo> I see this spec as a convenience use-case not one that makes regular users do expert things because of a wrapper
[12:37] <rsalveti> but don't have proper technical background for other stuff
[12:38] <rsalveti> yup, we should focus on the simple user, that just want his system to be fixed
[12:38] <lool> 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
[12:39] <lool> 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
[12:39] <lool> it should basically get out of the way; think of it as firmware
[12:39] <lool> 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
[12:40] <lool> 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
[12:40] <lool> For instance, you might want to decide to only upgrade the bootloader if people are running a specific board
[12:41] <janimo> lool, you mean variants of beagle or rather beagle vs panda?
[12:42] <lool> both
[12:42] <janimo> right now I guess all variant will get a new package being in the same source package even if only one gets a fix
[12:42] <lool> so you're upgrading the bootloader even when not strictly needed?  sounds bad
[12:43] <janimo> lool, no, the opposite, was just needing calrification
[13:01] <lilstevie> lool: not even jtag
[15:34] <apw> 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?
[15:34] <apw> ogra, i am a little concerned about the interaction between a lucid host and this though
[15:35] <rsalveti> apw: well, at least with rootstock (that uses versatile) I'll test with omap 3 and see how it goes
[15:35] <rsalveti> but it should work fine, as linaro is already using qemu with the omap 3 kernel
[15:35] <apw> rsalveti, that sounds good ...
[15:36] <rsalveti> don't know if we have any other use for versatile
[15:36] <rsalveti> maybe ogra knows
[15:36] <apw> rsalveti, there is a bug open which might make sense to report the outcome of any testing
[15:36] <apw> bug #715113
[15:36] <ubot2> Launchpad bug 715113 in linux "Drop versatile support" [Undecided,New] https://launchpad.net/bugs/715113
[15:36] <rsalveti> apw: sure, will do
[15:36] <ogra> apw, we were just discussing it in the meeting :)
[15:37] <persia> And in -kernel
[15:38] <apw> heh and here, and ... yeah i am suggesting the bug for any position statements or testing :)
[15:40] <janimo> apw, the bug I filed is part of a spec of the arm team, so they are at least partly aware of the situation :)
[15:41] <janimo> apw, there are some bugs still with various corner cases but the linaro devs are on them and fix qemu relatively fast
[15:43] <rsalveti> yup
[15:43] <rsalveti> so we should be safe with the qemu-linaro and omap 3
[15:44] <persia> Concern is for folks running a complex environment: for example lucid amd64 hosts running natty/arm buildds under qemu
[15:45] <rsalveti> ppa should be enough for that
[15:47] <persia> 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.
[15:49] <janimo> persia, sure but those special cases should not block removing versatile from natty right
[15:49] <janimo> ?
[15:50] <persia> I don't see any special reason to block the removal.
[15:51] <persia> That said, it's probably worth filing a backports bug for qemu-linaro once it's known good.
[16:00] <ogra> NCommander, bug 708661 and bug 708659
[16:00] <ubot2> Launchpad bug 708661 in libqtgconf "[MIR] please include libqtgconf in natty main" [High,Incomplete] https://launchpad.net/bugs/708661
[16:00] <ubot2> Launchpad bug 708659 in libqtbamf "[MIR] please include libqtbamf in natty main" [High,Incomplete] https://launchpad.net/bugs/708659
[16:00] <ogra> see the last comments
[21:09] <robclark> btw, anyone aware of ppa w/ firefox-4.0 for arm?
[21:09] <robclark> ppa:ubuntu-mozilla-daily/ppa doesn't seem to build for arm..
[22:28] <persia> 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?
[22:29] <micahg> persia: we might be able to throw it in maverick-backports
[22:29] <persia> Is there a good version suitable for -backports?
[22:29] <persia> natty looks like beta11
[22:29] <persia> robclark, Was there a specific version you wanted/needed?
[22:31] <micahg> well, actually, the problem with throwing it in -backports is I don't want to replace the current version in Maverick yet
[22:32] <micahg> I'll have to see, maybe I can get a native PPA for firefox
[22:33] <micahg> or maybe an ARM enabled PPA
[22:34] <micahg> also, is there a specific timeframe (i.e. you need a version now, or just want Firefox 4 on maverick at some point)
[22:34] <persia> Without the completion of https://launchpad.net/ubuntu/+spec/other-arm-n-public-panda-ppa-build-cluster ARM PPAs are tricky :(
[22:34] <persia> I'm just asking you as the most knowledgeable person I know because robclark asked earlier.
[22:34] <persia> I don't know the detailed requirements.
[22:35] <micahg> ok, it would be nice to know what the use case is, that might help how it's implemented
[22:39] <robclark> persia, just something recent 4.0 beta
[22:39] <persia> micahg, ^^
[22:39] <robclark> supposedly there should be some performance improvements..
[22:39] <micahg> robclark: can I ask what the use case is?
[22:39] <robclark> we just want to do some benchmarking w/ our xorg driver
[22:39] <robclark> browsing the web ;-)
[22:40] <robclark> scrolling performance and stuff like that
[22:40] <micahg> robclark: I'm wondering maverick vs natty
[22:40] <robclark> ahh, maverick preferrably..
[22:40] <robclark> I'm running mostly maverick right now
[22:41] <micahg> robclark: do you specifically need a PPA, or is this just for you?  I could build debs for you on ARM
[22:46] <micahg> robclark: chrisccoulson suggested just grabbing the natty debs
[22:47] <persia> Do they install cleanly on maverick?  I thought there've been a few ABI transitions.
[22:47] <chrisccoulson> i can't think of any reason it wouldn't work
[22:48] <micahg> persia: we use mostly internal libs for Firefox, so there shouldn't be an issue
[22:48] <chrisccoulson> remember, firefox uses bundled copies of pretty much everything except gtk and libc
[22:48] <chrisccoulson> and those don't break ;)
[22:48] <chrisccoulson> i might be wrong, but it *should* work on maverick
[22:48] <robclark> micahg, doesn't need to be a PPA..
[22:49] <robclark> oh, are there natty debs
[22:49]  * persia grumbles about internal libraries, grumbles more about firefox security, and finds a hole in the sand in which to insert head.
[22:50] <chrisccoulson> persia - it's not really a problem for firefox, it gets frequent security updates anyway (more frequently than any of our system libraries)
[22:51] <persia> No moving the sand away from my eyes: I don't want to know :)
[22:51] <chrisccoulson> heh
[22:51] <chrisccoulson> in addition to that, there are other benefits to using bundled libraries
[22:51] <ogra> out of shampoo ?
[22:51] <chrisccoulson> one of them being that we can submit crash reports directly to mozilla
[22:52] <chrisccoulson> so they have visibility of linux crashes, which is a very important part of their QA
[22:52]  * ogra heard of birds that prefer sand, i didnt know it was polular in japan
[22:54]  * persia is emulating an ostrich
[22:54] <ogra> japanese ostrich ?
[22:56] <persia> Sure.  Any ostrich.  If I can't see the problem, it doesn't exist, and won't eat me.
[22:58] <robclark> 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..
[22:58] <robclark> although I guess there are probably some other deb's I need to install?
[22:58] <robclark> one 10mb .deb file seems a bit small for firefox
[23:03] <GrueMaster> 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.
[23:03] <rsalveti> GrueMaster: ok
[23:06] <persia> robclark, What sort of error did you get trying to install?
[23:06] <robclark> persia, it installed fine.. but just crashes on startup..
[23:07] <persia> heh.
[23:07] <robclark> 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..
[23:07] <persia> The dependencies should have prevented that.
[23:07] <persia> chrisccoulson, micahg: maybe you could fix the dependencies, or build a maverick backport?
[23:09] <chrisccoulson> i really need arm hardware to test this stuff on ;)
[23:09] <micahg> yeah, it's going to need a backport as the depends are versioned based on natty
[23:09] <chrisccoulson> i've been debugging an arm build failure with upstream today, but i've got absolutely no way of testing this
[23:09] <robclark> ahh
[23:09] <robclark> well, I have the setup to test deb's on maverick if that helps at all ;-)
[23:09] <chrisccoulson> i just press the button and hope people say if it doesn't work ;)
[23:10] <chrisccoulson> i can test builds ok on the porter boxes, but they don't have an X display ;)
[23:10] <persia> chrisccoulson, You might ask if anyone else in mozillateam has ARM hardware :)
[23:11] <micahg> chrisccoulson: I can test stuff on ARM
[23:11] <chrisccoulson> that doesn't really solve my problem though (having no way of testing it myself) ;)
[23:11] <micahg> chrisccoulson: I might be able to set up the machine so you can test
[23:12]  * persia imagines a video camera and robotic key-presser.
[23:13]  * micahg is thinking more along the lines of VNC ;)
[23:13] <chrisccoulson> heh :)
[23:14] <lool> persia: Hey there; did you build an efikamx .deb as of late?
[23:14] <lool> persia: I checked the linaro-mx51 one, and it has efikamx enabled in the config, but I bet it misses tons of patches
[23:16] <persia> lool, I'm working on one.  I have a current tree, but kernel packaging is *hard*
[23:16] <persia> (it's sascha + rtp + ubuntu sauce)
[23:17] <lool> persia: Ok; jcrigby has a script to generate linaro-foo sources from a common git tree, not sure if that helps
[23:17] <persia> I've looked at that, and it doesn't quite do what I want.  I care about d-i integration, etc.
[23:17] <lool> debian.linaro/scripts/mkflavourbranches in git.l.o:ubuntu/linux-linaro-natty.git
[23:18] <lool> persia: Ok; what do you do instead?
[23:19] <persia> I've been working off the variations abogani used for the -lowlatency kernel to get an idea how to package it.
[23:19] <lool> Ok
[23:19] <persia> Basically, creating debian.foo and fiddling the scripts to pull the right bits together.
[23:19] <lool> udebs should in theory be possible with linaro kernels, but I'd expect them to be disabled by default
[23:20] <persia> 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.
[23:21] <persia> 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.
[23:21] <lool> persia: apparently our mx51 kernel spits udebs out
[23:21] <lool> https://launchpad.net/ubuntu/+source/linux-linaro-mx51/2.6.37-1002.5/+buildjob/2183588
[23:21] <lool> persia: efikamx is definitely enabled in the config I'm looking at
[23:21] <persia> Oh, heh.  I was looking at the linaro wiki, and I should have looked at LP :)
[23:21] <lool> CONFIG_MACH_MX51_EFIKAMX=y
[23:21] <lool> but not sb, not in upstream yet
[23:21] <persia> Has anyone tested it?
[23:22] <lool> No; I have that in mind since beginning of this week
[23:22] <lool> persia: u-boot-linaro just gained efikamx as well
[23:22] <persia> I have patches for SB, but I'm honestly much more interested in MX.
[23:22] <lool> from upstream
[23:22] <persia> Oh, excellent.  Then I'll stop fiddling with a kernel: no point :)
[23:22] <GrueMaster> rsalveti: Bug 716761
[23:22] <lool> still in NEW though
[23:22] <ubot2> Launchpad bug 716761 in linux-meta "Page allocation failures during system boot on beagleXM" [Undecided,New] https://launchpad.net/bugs/716761
[23:22] <lool> persia: Well, I don't have it yet  :-)
[23:22] <persia> Are you moving to 2.6.38 soon?
[23:22] <lool> persia: did you care about efikamx or sb?
[23:22] <lool> persia: dunno
[23:23] <persia> I mostly care about MX.  SB would be nice, but most of the folk I know have MX rather than SB.
[23:23] <lool> persia: patches > basically our gatekeeper is npitre and I guess he will take stuff which is going upstream
[23:23] <lool> I'm a bit lazily waiting for u-boot-linaro-efikamx to be published to propose a hwpack
[23:24] <persia> lool, By "going upstream" do you mean for-linus, for-rmk, or for-sascha?
[23:24] <lool> eventually going upstream  :-)
[23:24] <persia> Ah, so for-sascha patches are acceptable?  That's not so bad then.
[23:24] <lool> I don't think there's a set limit; it's basically good enough quality and eventually ending in mainline via variou trees
[23:24] <persia> What timezone is npitre?
[23:25] <lool> I would think patches from Sacha's tree would be acceptable, and hope that for-sascha patches stand a chance  :-)
[23:25] <lool> Eastern Canada IIRC
[23:25] <lool> persia: best is email rather than IRC
[23:25] <persia> Ah.  That makes it tricky :)
[23:25] <lool> pull request is ideal, preferably based of a linux tree
[23:26] <lool> well it's his EOD now, he might be around still
[23:26] <persia> I'd need to find somewhere to put a git tree :)  Most of the interesting stuff I have is quilt.
[23:26] <persia> 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.
[23:27] <persia> That'll be *heaps* easier than me pretending to be a kernel developer.
[23:43] <lool> persia: You can send him a patch series or you can host the patches as regular files
[23:43] <lool> persia: he has access to canonical hosts too
[23:46] <persia> The hard part is trying to sort which patches are interesting, really.
[23:51] <lool> yeah