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