[04:44] <straszheim> have a docs bug
[04:45] <straszheim> this page -> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[04:45] <straszheim> On Beagleboard xM rev A3 and B, the wgets are to the wrong directories
[04:45] <straszheim> they're right, but reversed
[05:09] <persia> straszheim, Would you mind correcting that?
[05:13] <straszheim> np
[05:16] <persia> Thanks!
[05:27] <straszheim> after a solid week of trying to get things built for a gumstix I have to say that install was pretty awesome.
[05:29] <persia> I heard of someone running on a gumstix before.  Did you have to do anything special to the image, or did it mostly just work?
[05:30] <straszheim> ah, no, i mean the omap3/maverick install was awesome because it worked and took a few hours.  gumstix is unplugged, major fail
[05:31] <persia> Which gumstix do you have?
[05:31] <straszheim> verdex pro
[05:31] <straszheim> armv5te iirrc
[05:32] <persia> Indeed.  Debian ought be not too hard to get running on that.
[05:33] <persia> I think the omap3 images work on the Overos, but I haven't seen enough confirmation to be sure: none of the regulars on this channel seems to use one with Ubuntu.
[05:37] <straszheim> is there a recommended way to strip the gui stuff out of this install?  This thing is intended to run headless.  I'm considering just removing x11-common.
[05:37] <straszheim> that'll take a ton of stuff with it
[05:40] <jhobbs> check out tasksel
[05:40] <straszheim> ah nice
[05:40] <straszheim> thx
[05:41] <persia> I'd recommend making sure ubuntu-standard and ubuntu-minimal are installed, and then removing ubuntu-netbook and all it's dependencies (avoiding removing -standard and -minimal)
[05:41] <persia> From there you can build up again.
[05:42] <straszheim> sounds good
[09:15] <rsalveti> straszheim: I'm reverting your change
[09:15] <rsalveti> the first sd card partition should have the uImage, not vmlinuz
[14:45] <ogra> http://projects.goldelico.com/p/ombeagle/
[14:56] <rsalveti> ogra: cool!
[14:57] <ogra> yep
[14:57] <ogra> waiting for the panda version :)
[15:11] <janimo> rsalveti,  wrt https://blueprints.launchpad.net/ubuntu/+spec/other-arm-n-handle-core-boot-files-update
[15:11] <janimo> is that tool suipposed to do what flash-kernel currently does but for uboot binaries ?
[15:11] <rsalveti> janimo: moving it for you
[15:11] <rsalveti> kind of
[15:12] <rsalveti> because u-boot and x-loader is not updated
[15:12] <rsalveti> just the kernel
[15:12]  * janimo wonders if code can be reused from flash-kernel at all
[15:13] <rsalveti> janimo: yup, that's why you need to talk with NCommander later, to check the flash kernel and the sub arch detect code
[15:13] <rsalveti> to see what can be shared
[15:14] <janimo> ok
[15:19] <ogra> rsalveti, we should just seed them and make sure they are on the image worst case ... then people can at least manually update
[15:20] <rsalveti> ogra: but the idea is to have a tool to manually update the core boot files
[15:20] <rsalveti> shouldn't be that hard
[15:20] <ogra> indeed
[15:20] <ogra> but if we dont manage, seeding should at least get us a step forward
[15:20] <rsalveti> yup, true
[15:54] <janimo> ogra, seeding all? For instance for omap3 image seed all the omap3 based xloader/uboot binaries?
[15:55] <ogra> janimo, well, we cant be that distinctive in the seeds (seeds dont support subarches)
[15:55] <ogra> so we would need to seed all
[15:56] <janimo> ok
[15:56] <ogra> the point is that apt-get update will get you the latest binaries on disk
[15:56] <ogra> so even without the desired script we would have them available for manual tinkering
[15:56] <janimo> I am thinking having them on the disk and then adding a post install hook like flash-kernel would solve this
[15:56] <ogra> right
[15:57] <ogra> that was the initial plan
[15:57] <ogra> but if we dont have time for the flash-kernel bit, at least seeding should be done
[15:57] <rsalveti> janimo: we don't want a post install hook
[15:58] <rsalveti> we want the user to manually update the files
[15:58] <rsalveti> avoid problems
[15:58] <ogra> right
[15:58] <rsalveti> and a lot easier to implement
[15:58] <ogra> just a script
[16:02] <janimo> rsalveti, so not the same ease and transparency s grub is installed with?
[16:02] <janimo> ok
[16:03] <rsalveti> yeah, we want a script that the user can trigger by hand
[16:03] <janimo> or rather ease, but not automatic
[16:03] <rsalveti> and we also want to notify the user about such update
[16:03] <janimo> ack
[16:03] <ogra> we dont update grub stage 1
[16:03] <ogra> there is no such ease ;)
[16:23] <lool> rsalveti: Hey, would you know whether USB storage is fully stable on xm now?
[16:23] <ogra> lool, given that the buildds use it ...
[16:23] <lool> We use xms as buildds now?
[16:23] <ogra> you should know it :)
[16:23] <ogra> they come from linaro afaik
[16:24] <ogra> see https://launchpad.net/builders
[16:24] <lool> ogra: how do I know they are xms?
[16:24] <ogra> lamont
[16:24] <lool> Ok, so https://launchpad.net/builders doesn't help much I guess
[16:25] <ogra> the arm team helped him to bring them up
[16:25] <ogra> well, it shows that there are 15 instead of 8 now
[16:25] <ogra> indeed it doesnt show the arch
[16:26] <GrueMaster> The *ceae systems are the new ones.
[16:26] <ogra> right
[16:26] <ogra> i was just looking for the naming convention
[16:26] <ogra> had noted it somewhere
[16:27] <ndec> ogra: lool: I didn't know the builders moved to XM!
[16:27] <ogra> ndec, on *the builders*
[16:28] <ogra> s/on/not
[16:28] <lool> Well /builders is confusing
[16:28] <ogra> ndec, linaro added 6 XM builders to the queue so their rebuilds dont impact the distro
[16:28] <lool> ogra: they are shared though, right?
[16:28] <ogra> ndec, we are still waiting for the panda cluster
[16:28] <ogra> lool, yep
[16:28] <ndec> lool: i was about that too.
[16:28] <lool> ndec: we have two types of buildds
[16:29] <ogra> lool, but can be used dedicated as i understood
[16:29] <lool> ndec: some for packages and some for images
[16:29] <lool> we can actually share them, but we usually don't
[16:29] <lool> and offspring/linaro don't use these for image builds, but another separate pool -- let's call them offspring builders
[16:29] <ogra> lool, so during archive rebuild tests they wont be shared
[16:29] <ndec> lool: ok, and the one for the packages are split between archive and PPA?
[16:29] <lool> ndec: Yes
[16:29] <lool> ndec: That's only on ARM because these are non-virtual
[16:30] <lool> on other arches, they are actually separate
[16:30] <ogra> ndec, though your PPA builders are the two at the very bottom of the /builders page
[16:30] <ogra> they are not in the normal builder pool
[16:30] <GrueMaster> Actually, there are two dedicated ppa buildds, according to the link above.
[16:30] <ndec> ogra: did they moved to XM too?
[16:30] <ogra> ndec, nope
[16:31] <GrueMaster> wait, nevermind.
[16:31] <GrueMaster> eyes are blurry.  need more coffee.
[16:32] <ogra> GrueMaster, the two are for private PPAs
[16:33] <GrueMaster> Ah, there they are, at the bottom.  I had sorted by arch and thought I saw two, but then they disappeared.  Thought my eyes were bugging out.
[16:34] <ogra> heh
[16:37] <ogra> ndec, they will likely move to pandas once we have them
[17:01] <lool> ndec: Sorry, I was confused, we're using separate PPA builders nowadays it seems
[17:03] <ogra> lool, depends on the PPA
[17:04] <lool> ogra: How so?
[17:05] <ogra> see PM
[17:27] <rsalveti> lool: it should be, the only issue atm is that the driver is allocating a lot of memory when you stress the ethernet or usb
[17:27] <rsalveti> and some times you can see the traces, but not something that breaks
[17:28] <rsalveti> same problem we have with panda, as it's the same driver
[17:28] <lool> Ok thanks
[17:29] <rsalveti> lool: but I'd say beagle in general is a lot more stable than panda
[17:29] <rsalveti> and I think we didn't face any major issues with the builders
[17:33] <rsalveti> I'm impressed by the amount of bug reports for unity-2d since it was released
[17:33] <rsalveti> seems people are really using it
[17:56] <slangasek> ogra: hey there, another question on historic qemu packaging.  You have another sysctl here for 'vm.vdso_enabled = 0' with the reason "else chroot execution fails" - how did it fail, how can I verify if this is still needed?
[17:56] <ogra> slangasek, hmm, did i actually add that ?
[17:57] <slangasek> ogra: in karmic, yes
[17:57] <ogra> hmm, i think i had that from the maemo ML somewhere
[17:57] <ogra> let me dig
[17:58] <slangasek> ogra: thanks
[17:59] <ogra> http://maemo.org/development/sdks/maemo5_alpha_installation/#sboxissue
[18:00] <ogra> http://bugs.maemo.org/show_bug.cgi?id=3479
[18:00] <ubot2> bugs.maemo.org bug 3479 in SDK "SDK does not work on Debian lenny system" [Major,Resolved: fixed]
[18:00] <ogra> might not be needed anymore
[18:01] <ogra> since it refers to intrepid
[18:04] <ogra> slangasek, ^^^
[18:05] <slangasek> ogra: so is this specific to scratchbox in some way?
[18:06] <ogra> i had the same error in rootstock/qemu back then, else i wouldnt have added it
[18:06] <slangasek> ok
[18:06] <ogra> i would suggest a test on amd64
[18:06] <ogra> i'm not sure its still valid
[18:07] <slangasek> well, testing how?
[18:07] <slangasek> and on amd64 we don't set this at all, the key doesn't exist in /proc/sys on amd64
[18:07] <ogra> seems related to the glibc in side the VM
[18:07] <slangasek> VM?
[18:07] <slangasek> should be a chroot not a VM, yes?
[18:07] <ogra> err, yes, sorry
[18:09] <ogra> the bug seems to also rather suggest to set it to 2 instead of 0
[18:09] <ogra> looking at the last comment
[18:10] <ogra> i would actually drop it and look out for related bugs
[18:10] <ogra> its natty after all ;)