[00:16] <rcn-ee> Sp0tter, it'll run ubuntu's userspace, you'll have to figure out the kernel stuff yourself..
[00:39] <Sp0tter> hmm
[00:39] <Sp0tter> drats i was hoping to just benifit from someone elses previous hard work :)
[00:40] <Sp0tter> archos 32 is too new and not popular enough yet though to have much of a following, so maybe i'll look into it
[01:54] <rcn-ee> Sp0tter, it might be as easy as copying their kernel and modules into an ubuntu rootfs..
[02:23] <Sp0tter> define "their"
[02:23] <Sp0tter> it runs android
[16:20] <apachelogger> rsalveti: so I installed the omap3 graphics foo and now the demo apps fall over http://paste.ubuntu.com/541043/ any clues
[16:21] <apachelogger> (Qt also fails to find a EGL display for that matter)
[16:48] <apachelogger> oh ah eh
[16:48] <apachelogger> rsalveti: apparentlyt eh init script failed because we are currently running the n900 with the meego kernel
[16:48] <apachelogger> commented out the ti_something modprobe, and the script worked *but* now it segfaults ^^
[16:49]  * apachelogger thinks that meego kernel and ubuntu sgx stuff does not go well together
[17:55] <rsalveti> apachelogger: one thing is to make sure your user is also at the video group
[17:55] <rsalveti> apachelogger: and yes, I don't think maemo's kernel will work nicely with these libraries
[17:55] <rsalveti> if you're using it at the n900 you should just grab the meego's sgx libraries
[17:56] <rsalveti> they are also available at meego's repository, just need to convert into deb packages
[17:56] <rsalveti> GrueMaster: why did you create bug 687396? isn't it easier to just change bug 673509 saying that also affects the linaro's kernel?
[17:57] <ubot2> Launchpad bug 687396 in linux-linaro (Ubuntu) "Beagleboard-XM chooses a new IP address everytime the interface is brought up (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/687396
[17:57] <ubot2> Launchpad bug 673509 in linux (Ubuntu Maverick) (and 1 other project) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 12)" [Undecided,Fix committed] https://launchpad.net/bugs/673509
[17:57] <GrueMaster> rsalveti: Given the current issues with the kernel team...no.
[17:58] <GrueMaster> The issue is that they rely on a verification- tag, which encompasses the bug, not the package.
[17:58] <rsalveti> GrueMaster: argh, true
[17:58] <rsalveti> that was the reason for quite a lot of confusion lately
[18:00] <GrueMaster> This is also partly why the go around for the panda fix.  The patch listed both bug reports in the commit, so both bug reports get updated when only one kernel gets patched.
[18:00] <rsalveti> GrueMaster: yeah, true
[18:03] <GrueMaster> There are several flaws in the current system.  I think I found 5-6 bugs tagged with verification-needed for kernel updates that I was never informed of.  Mainly for babbage & dove.
[18:05] <rsalveti> janimo: so, it seems that the meego tree is our only choice for the natty cycle
[18:05] <janimo> rsalveti: yes
[18:05] <rsalveti> I know linaro's testing the omap 3 kernel on it, but it'd be good to make sure it works fine with our tools
[18:05] <rsalveti> such as rootstock
[18:06] <rsalveti> just got another answer from peter saying that the omap 3 patches are on top of the priority list
[18:07] <rsalveti> and giving the qemu release cycle, those patches are probably going to end upstream luckly for n+1
[18:07] <rsalveti> and the worst case for n+2
[18:07] <janimo> rsalveti: right, so for natty we package maemo stuff. I wonder if we need a new source package or is it reasonable easy to patch existing qemu
[18:08] <janimo> I haven;t looked yet at qemu packaging internals
[18:08] <rsalveti> janimo: we discussed that at uds, and it seems that it's easier just to create a different package for arm
[18:08] <janimo> rsalveti: but we need an OMAP3 compatible QEMU soon right?
[18:08] <rsalveti> because otherwise the server team is going to maintain all these patches in the package itself
[18:08] <janimo> notjust by release
[18:09] <rsalveti> janimo: we need a working qemu, omap 3 is just the most used atm
[18:09] <rsalveti> there is another blueprint from the server side, let me find it
[18:09] <janimo> rsalveti: shall I take this spec over or do you prefer working on it?
[18:11]  * janimo reads the new emails
[18:12] <rsalveti> janimo: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
[18:12] <janimo> rsalveti: still maemo-qemu is a bit of a misnomer at this time
[18:12] <rsalveti> janimo: it'd be good to get the patch set, see how many they are and ask the server team what they think about it
[18:12] <rsalveti> we're ok for uploading a different package for arm
[18:12] <rsalveti> but if they prefer to apply and maintain all those patches, we're also fine
[18:13] <janimo> rsalveti: ok, I'll read this spec
[18:13] <janimo> so we'd only pick omap3 subset of the maemo tree?
[18:13] <rsalveti> janimo: I'm ok for you taking up this spec, just ping me before closing the WI so I can see the progress :-)
[18:13] <janimo> rsalveti: ok :)
[18:13] <rsalveti> janimo: probably, and also the arm fixes that could be also not yet integrated
[18:14] <rsalveti> janimo: so please add also new WI
[18:14] <janimo> rsalveti: not sure what else is in the maemo tree besides those, I need to check
[18:14] <janimo> to see what we do not carry over
[18:14] <janimo> probably nokia device specifics
[18:14] <rsalveti> - get the patch list of the differences from the upstream tree
[18:15] <rsalveti> - talk with the server team to see what they think about maintaining the patches or simply pushing a new qemu-maemo package at the archive
[18:15] <rsalveti> janimo: yup
[18:15] <rsalveti> janimo: - test current linaro's omap 3 kernel with qemu and report back to the server team if it's enough for us, so they can drop versatile
[18:16] <rsalveti>  janimo https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
[18:17] <janimo> should I add the last WI to this spec or to our spec?
[18:17] <rsalveti> after changing our tools to use it, test to see if we get at least the same behavior of the main qemu-kvm package
[18:17] <rsalveti> janimo: to our
[18:17] <janimo> ok
[18:17] <rsalveti> janimo: I'm just pointing this spec, as it's the one that they put a WI to see if they should drop versatile or not
[18:17] <rsalveti> depending on our feedback
[18:18] <janimo> so if omap3 works they drop versatile patches from qemu?
[18:20] <rsalveti> janimo: they drop the versatile build from the ubuntu kernel
[18:21] <rsalveti> at maverick, for example, the versatile build only exists because of the need from qemu
[18:21] <rsalveti> as it's the only working target for arm
[18:21] <janimo> rsalveti: I see
[18:21] <rsalveti> as we already need an omap 3 build (now maintained by linaro), if we can get qemu working with it there's no need to keep versatile
[18:26] <suihkulokki> well, there was discussion to make versatile the "virtualized" arm/qemu flavour
[18:26] <suihkulokki> eg to get virtio and goodies
[18:32] <rsalveti> yeah, but don't know much about the current state of it
[18:32] <rsalveti> what we know is that we have already quite a lot of people using and testing the maemo tree nowadays
[18:33] <rsalveti> and because of that it'd probably be the better choice for us
[18:39] <prpplague> rsalveti: whats the git url for the ubuntu x-loader and u-boot?
[18:40] <rsalveti> prpplague: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
[18:40] <rsalveti> for x-loader
[18:40] <rsalveti> prpplague: http://git.linaro.org/gitweb?p=ubuntu/u-boot-linaro-stable.git;a=summary
[18:40] <rsalveti> u-boot
[18:40] <prpplague> rsalveti: thanks
[18:40]  * prpplague makes a note so he doesn't have to ask again
[18:41] <rsalveti> prpplague: np :-)
[18:41] <rsalveti> prpplague: any news about the 200/400mhz memory issues?
[18:42] <prpplague> rsalveti: none that i am aware of
[18:42] <rsalveti> hm, ok :-(
[18:42] <prpplague> rsalveti: i think we just had one or two people with boards populated incorrectly
[18:42] <prpplague> iirc those are going to be swapped out
[18:42] <rsalveti> prpplague: oh, ok
[18:44] <GrueMaster> prpplague: Any changes to the panda we should be concerned about post ES2.1 A1?
[18:45] <prpplague> GrueMaster: none
[18:45] <prpplague> GrueMaster: the mounting holes will be bigger
[18:45] <GrueMaster> My main concern is a hardware change that needs kernel updates and I have no way to test them.
[18:45] <prpplague> GrueMaster: thats about it
[18:45] <GrueMaster> Ok.
[18:45] <GrueMaster> Can't test the new mounting holes.  Sorry.
[18:45] <GrueMaster> :P
[18:45] <ogra_ac> slacker !
[18:46] <GrueMaster> ogra_ac: If you were watching what has been happening in the kernel realm, you wouldn't say that.
[18:46] <ogra_ac> i have
[18:46] <GrueMaster> Not the PM's.
[18:47] <ogra_ac> i think the prob is that the kernel team rotates every cycle so one habit yu have established with someone working on SRUs is lost if the next one comes up
[18:47] <ogra_ac> we need clearer rules for them, preferably done by a spec next UDS
[18:48] <ogra_ac> s/the prob/one prob/
[18:48] <GrueMaster> Unfortunately, I have not seen a single trend (other than dropped patches).
[18:48] <ogra_ac> well, lets make up a spec for budapest and sort that one and for all
[18:49] <ogra_ac> i agree that this is an unbearable situation
[18:49]  * GrueMaster feels like more weight will end up on his shoulders.
[18:49] <ogra_ac> i doubt that
[18:49] <ogra_ac> we just need clearly written down rules
[18:50] <ogra_ac> and people to stick to them indeed ;)
[18:50] <GrueMaster> I don't think it is just a set of rules.  We have broken tools.  Launchpad is part of the problem, the scripts that everyone runs in automation is another.
[18:51] <ogra_ac> well, thne lets define the rules in a way that human interaction is required for armel kernels ;)
[18:51] <GrueMaster> With launchpad, if we have a bug that crosses multiple packages, we can't rely solely on a verification- tag.
[18:51] <ogra_ac> then lets define additional verification tags
[18:52] <GrueMaster> That won't work.  The verification needs to be on a per-package basis and shouldn't be a tag.  This was discussed in the QA CoP.
[18:53] <GrueMaster> The only way to make it work currently is by having separate bugs per package, but then scripts fail when a commit is made that tags multiple bugs.
[18:53] <ogra_ac> well, nothing i want to discuss now, but i'm sure if we sit down all together at UDS with the right people we will find a solution
[18:54] <GrueMaster> (hence the reason for the misfires on the MAC address bugs).
[18:54] <ogra_ac> yeah
[18:54] <GrueMaster> ok
[18:58] <GrueMaster> ogra_ac: Why does it take so long for new packages to get published in armel?  Is it a manual process?
[19:42] <ogra_ac> GrueMaster, depends on the package, the kernel chsanges it binary package name with every upload, so it ends up on binary-NEW and needs an archive admin to let it out
[21:36] <apachelogger> rsalveti: tried that, didn't get me far, then again I fear my image was a bit broken yesterday, I'll try again with a new image
[21:36] <rsalveti> oh, ok
[23:24] <janimo> anyone tried 10.10 omap3 image in qemu? It does not completely boot for me
[23:26]  * janimo tries passing -mtd to qemu
[23:39] <apachelogger> rsalveti: so, I tried again... it only works with their xorg fbdev driver and then X segfaults