**** BEGIN LOGGING AT Wed Dec 08 02:59:57 2010
Dec 08 16:21:03 <apachelogger> rsalveti: so I installed the omap3 graphics foo and now the demo apps fall over http://paste.ubuntu.com/541043/ any clues
Dec 08 16:21:14 <apachelogger> (Qt also fails to find a EGL display for that matter)
Dec 08 16:48:18 <apachelogger> oh ah eh
Dec 08 16:48:36 <apachelogger> rsalveti: apparentlyt eh init script failed because we are currently running the n900 with the meego kernel
Dec 08 16:48:54 <apachelogger> commented out the ti_something modprobe, and the script worked *but* now it segfaults ^^
Dec 08 16:49:14 * apachelogger thinks that meego kernel and ubuntu sgx stuff does not go well together
Dec 08 17:55:23 <rsalveti> apachelogger: one thing is to make sure your user is also at the video group
Dec 08 17:55:39 <rsalveti> apachelogger: and yes, I don't think maemo's kernel will work nicely with these libraries
Dec 08 17:55:57 <rsalveti> if you're using it at the n900 you should just grab the meego's sgx libraries
Dec 08 17:56:13 <rsalveti> they are also available at meego's repository, just need to convert into deb packages
Dec 08 17:57:07 <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?
Dec 08 17:57:11 <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
Dec 08 17:57:12 <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
Dec 08 17:57:35 <GrueMaster> rsalveti: Given the current issues with the kernel team...no.
Dec 08 17:58:35 <GrueMaster> The issue is that they rely on a verification- tag, which encompasses the bug, not the package.
Dec 08 17:58:57 <rsalveti> GrueMaster: argh, true
Dec 08 17:59:09 <rsalveti> that was the reason for quite a lot of confusion lately
Dec 08 18:00:11 <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.
Dec 08 18:00:53 <rsalveti> GrueMaster: yeah, true
Dec 08 18:03:31 <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.
Dec 08 18:05:38 <rsalveti> janimo: so, it seems that the meego tree is our only choice for the natty cycle
Dec 08 18:05:53 <janimo> rsalveti: yes
Dec 08 18:06:02 <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
Dec 08 18:06:09 <rsalveti> such as rootstock
Dec 08 18:06:42 <rsalveti> just got another answer from peter saying that the omap 3 patches are on top of the priority list
Dec 08 18:07:20 <rsalveti> and giving the qemu release cycle, those patches are probably going to end upstream luckly for n+1
Dec 08 18:07:34 <rsalveti> and the worst case for n+2
Dec 08 18:08:04 <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
Dec 08 18:08:17 <janimo> I haven;t looked yet at qemu packaging internals
Dec 08 18:08:36 <rsalveti> janimo: we discussed that at uds, and it seems that it's easier just to create a different package for arm
Dec 08 18:08:47 <janimo> rsalveti: but we need an OMAP3 compatible QEMU soon right?
Dec 08 18:08:55 <rsalveti> because otherwise the server team is going to maintain all these patches in the package itself
Dec 08 18:08:57 <janimo> notjust by release
Dec 08 18:09:12 <rsalveti> janimo: we need a working qemu, omap 3 is just the most used atm
Dec 08 18:09:37 <rsalveti> there is another blueprint from the server side, let me find it
Dec 08 18:09:52 <janimo> rsalveti: shall I take this spec over or do you prefer working on it?
Dec 08 18:11:48 * janimo reads the new emails
Dec 08 18:12:15 <rsalveti> janimo: https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
Dec 08 18:12:35 <janimo> rsalveti: still maemo-qemu is a bit of a misnomer at this time
Dec 08 18:12:42 <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
Dec 08 18:12:52 <rsalveti> we're ok for uploading a different package for arm
Dec 08 18:13:09 <rsalveti> but if they prefer to apply and maintain all those patches, we're also fine
Dec 08 18:13:14 <janimo> rsalveti: ok, I'll read this spec
Dec 08 18:13:33 <janimo> so we'd only pick omap3 subset of the maemo tree?
Dec 08 18:13:47 <rsalveti> janimo: I'm ok for you taking up this spec, just ping me before closing the WI so I can see the progress :-)
Dec 08 18:13:55 <janimo> rsalveti: ok :)
Dec 08 18:14:09 <rsalveti> janimo: probably, and also the arm fixes that could be also not yet integrated
Dec 08 18:14:22 <rsalveti> janimo: so please add also new WI
Dec 08 18:14:42 <janimo> rsalveti: not sure what else is in the maemo tree besides those, I need to check
Dec 08 18:14:50 <janimo> to see what we do not carry over
Dec 08 18:14:57 <janimo> probably nokia device specifics
Dec 08 18:14:57 <rsalveti> - get the patch list of the differences from the upstream tree
Dec 08 18:15:24 <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
Dec 08 18:15:33 <rsalveti> janimo: yup
Dec 08 18:16:10 <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
Dec 08 18:16:28 <rsalveti>  janimo https://blueprints.launchpad.net/ubuntu/+spec/hardware-kernel-n-version-and-flavours
Dec 08 18:17:17 <janimo> should I add the last WI to this spec or to our spec?
Dec 08 18:17:20 <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
Dec 08 18:17:28 <rsalveti> janimo: to our
Dec 08 18:17:31 <janimo> ok
Dec 08 18:17:51 <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
Dec 08 18:17:55 <rsalveti> depending on our feedback
Dec 08 18:18:32 <janimo> so if omap3 works they drop versatile patches from qemu?
Dec 08 18:20:31 <rsalveti> janimo: they drop the versatile build from the ubuntu kernel
Dec 08 18:21:13 <rsalveti> at maverick, for example, the versatile build only exists because of the need from qemu
Dec 08 18:21:19 <rsalveti> as it's the only working target for arm
Dec 08 18:21:39 <janimo> rsalveti: I see
Dec 08 18:21:55 <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
Dec 08 18:26:40 <suihkulokki> well, there was discussion to make versatile the "virtualized" arm/qemu flavour
Dec 08 18:26:50 <suihkulokki> eg to get virtio and goodies
Dec 08 18:32:24 <rsalveti> yeah, but don't know much about the current state of it
Dec 08 18:32:57 <rsalveti> what we know is that we have already quite a lot of people using and testing the maemo tree nowadays
Dec 08 18:33:11 <rsalveti> and because of that it'd probably be the better choice for us
Dec 08 18:39:53 <prpplague> rsalveti: whats the git url for the ubuntu x-loader and u-boot?
Dec 08 18:40:12 <rsalveti> prpplague: http://gitorious.org/~rsalveti/pandaboard/rsalveti-x-loader/commits/omap4_panda_es2.1
Dec 08 18:40:15 <rsalveti> for x-loader
Dec 08 18:40:36 <rsalveti> prpplague: http://git.linaro.org/gitweb?p=ubuntu/u-boot-linaro-stable.git;a=summary
Dec 08 18:40:37 <rsalveti> u-boot
Dec 08 18:40:48 <prpplague> rsalveti: thanks
Dec 08 18:40:56 * prpplague makes a note so he doesn't have to ask again
Dec 08 18:41:15 <rsalveti> prpplague: np :-)
Dec 08 18:42:02 <rsalveti> prpplague: any news about the 200/400mhz memory issues?
Dec 08 18:42:19 <prpplague> rsalveti: none that i am aware of
Dec 08 18:42:36 <rsalveti> hm, ok :-(
Dec 08 18:42:41 <prpplague> rsalveti: i think we just had one or two people with boards populated incorrectly
Dec 08 18:42:47 <prpplague> iirc those are going to be swapped out
Dec 08 18:42:52 <rsalveti> prpplague: oh, ok
Dec 08 18:44:42 <GrueMaster> prpplague: Any changes to the panda we should be concerned about post ES2.1 A1?
Dec 08 18:45:13 <prpplague> GrueMaster: none
Dec 08 18:45:28 <prpplague> GrueMaster: the mounting holes will be bigger
Dec 08 18:45:29 <GrueMaster> My main concern is a hardware change that needs kernel updates and I have no way to test them.
Dec 08 18:45:31 <prpplague> GrueMaster: thats about it
Dec 08 18:45:36 <GrueMaster> Ok.
Dec 08 18:45:47 <GrueMaster> Can't test the new mounting holes.  Sorry.
Dec 08 18:45:52 <GrueMaster> :P
Dec 08 18:46:05 <ogra_ac> slacker !
Dec 08 18:46:47 <GrueMaster> ogra_ac: If you were watching what has been happening in the kernel realm, you wouldn't say that.
Dec 08 18:46:58 <ogra_ac> i have
Dec 08 18:47:07 <GrueMaster> Not the PM's.
Dec 08 18:47:50 <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
Dec 08 18:48:10 <ogra_ac> we need clearer rules for them, preferably done by a spec next UDS
Dec 08 18:48:22 <ogra_ac> s/the prob/one prob/
Dec 08 18:48:35 <GrueMaster> Unfortunately, I have not seen a single trend (other than dropped patches).
Dec 08 18:48:56 <ogra_ac> well, lets make up a spec for budapest and sort that one and for all
Dec 08 18:49:17 <ogra_ac> i agree that this is an unbearable situation
Dec 08 18:49:28 * GrueMaster feels like more weight will end up on his shoulders.
Dec 08 18:49:49 <ogra_ac> i doubt that
Dec 08 18:50:04 <ogra_ac> we just need clearly written down rules
Dec 08 18:50:18 <ogra_ac> and people to stick to them indeed ;)
Dec 08 18:50:54 <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.
Dec 08 18:51:27 <ogra_ac> well, thne lets define the rules in a way that human interaction is required for armel kernels ;)
Dec 08 18:51:51 <GrueMaster> With launchpad, if we have a bug that crosses multiple packages, we can't rely solely on a verification- tag.
Dec 08 18:52:09 <ogra_ac> then lets define additional verification tags
Dec 08 18:53:04 <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.
Dec 08 18:53: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.
Dec 08 18:54:03 <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
Dec 08 18:54:26 <GrueMaster> (hence the reason for the misfires on the MAC address bugs).
Dec 08 18:54:33 <ogra_ac> yeah
Dec 08 18:54:34 <GrueMaster> ok
Dec 08 18:59:08 <GrueMaster> ogra_ac: Why does it take so long for new packages to get published in armel?  Is it a manual process?
Dec 08 19:43:04 <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
Dec 08 21:36:37 <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
Dec 08 21:37:00 <rsalveti> oh, ok
Dec 08 23:24:36 <janimo> anyone tried 10.10 omap3 image in qemu? It does not completely boot for me
Dec 08 23:26:49 * janimo tries passing -mtd to qemu
Dec 08 23:39:54 <apachelogger> rsalveti: so, I tried again... it only works with their xorg fbdev driver and then X segfaults
Dec 09 01:39:39 <rsalveti> apachelogger: ouch
Dec 09 01:40:06 <apachelogger> rsalveti: do you happen to know where does our omap_rev_lt_3_0
Dec 09 01:40:21 * apachelogger is trying to get our dkms package build modules for the meego kernel, since he is out of other options
Dec 09 01:40:34 <apachelogger> currently fails to build with omap_rev_lt_3_0 being implictly defined
Dec 09 01:41:05 <rsalveti> apachelogger: what exactly are you trying to do, port ubuntu to n900?
Dec 09 01:41:37 <rsalveti> when I was trying that I basically ported the meego patches to the ubuntu tree, got it booting but didn't have time to test the sgx packages
Dec 09 01:41:50 <apachelogger> porting is a bit of a strong word, ScottK tells me someone is working on a kernel that will run on the n900
Dec 09 01:42:06 <apachelogger> meanwhile I am trying to work out what needs doing on the kubuntu side of things to give decent user experience
Dec 09 01:42:06 <rsalveti> I was doing that, then mpoirier also got some work on it
Dec 09 01:42:18 <rsalveti> ok
Dec 09 01:42:40 <rsalveti> so for now I'd recommend you to use at least the sgx kernel patch available for meego
Dec 09 01:43:00 <rsalveti> then try using their libraries and x driver, but that's what you said you did
Dec 09 01:43:09 <rsalveti> would be interesting to see your segfault
Dec 09 01:43:12 <apachelogger> yeah
Dec 09 01:43:30 <rsalveti> this weekend I'm planing to waste some time on that, now that I got my n900 back
Dec 09 01:43:43 <apachelogger> hooray
Dec 09 01:43:48 <rsalveti> at least to get a proper kernel tree that can be properly used by ubuntu's userspace
Dec 09 01:44:04 <apachelogger> having a working kernel makes things a lot more fixable for me ^^
Dec 09 01:44:42 <rsalveti> apachelogger: this was the latest tree that I did some work http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-master-n900
Dec 09 01:45:00 <apachelogger> ok
Dec 09 01:45:06 <rsalveti> got it booting until x11, and then used the efl interface
Dec 09 01:45:22 <rsalveti> but then I had to give my n900 to a friend of mine
Dec 09 01:45:27 <rsalveti> and I got it back this week
Dec 09 01:45:49 <rsalveti> while at uds I was debugging this with rbelem
Dec 09 01:49:45 <rcn-ee> apachelogger, which kernel?  give this a shot.. http://gitorious.org/angstrom/angstrom-linux/commit/38adc41c6f6d686156083ff0889d0b2dd71f2e14
Dec 09 01:50:02 <apachelogger> rcn-ee: 1.1
Dec 09 01:50:09 <apachelogger> we did dirty kernel copies ^^
Dec 09 01:50:24 <apachelogger> https://wiki.ubuntu.com/ARM/n900
Dec 09 01:51:21 <rcn-ee> ah, the meego kernel..
Dec 09 01:51:30 <apachelogger> aye
Dec 09 01:51:42 <rsalveti> rcn-ee: yeah, there are some other patches just to make n900 work properly
Dec 09 01:52:04 <apachelogger> DKMS: install Completed.
Dec 09 01:52:04 <apachelogger> omg
Dec 09 01:52:08 * apachelogger gets all jumpy
Dec 09 02:04:36 * rbelem o/
Dec 09 02:05:52 <apachelogger> QGLShader: could not create shader
Dec 09 02:05:52 <apachelogger> Warning: "" failed to compile!
Dec 09 02:05:54 * apachelogger sighs
Dec 09 02:06:24 <rbelem> apachelogger, which plasma-mobile are you running?
Dec 09 02:06:38 <apachelogger> whatever is in maverick
Dec 09 02:06:42 <apachelogger> oh
Dec 09 02:06:43 <apachelogger> omg
Dec 09 02:06:44 <apachelogger> uh
Dec 09 02:06:54 <apachelogger> OGLES2Coverflow works
Dec 09 02:07:02 * apachelogger got gles2 it seems \\o/
Dec 09 02:07:05 <rbelem> \o/
Dec 09 02:07:15 <rbelem> apachelogger, you rock!
Dec 09 02:07:17 <apachelogger> now if only plasma would like to work too
Dec 09 02:07:31 <rsalveti> apachelogger: cool
Dec 09 02:07:33 <apachelogger> rsalveti: would Qt need to be compiled against special sgx headers?
Dec 09 02:07:43 <apachelogger> currently it is built against mesa's gles
Dec 09 02:07:44 <rsalveti> just to be compiled with opengl
Dec 09 02:07:54 <rsalveti> apachelogger: nops, that should work
Dec 09 02:08:05 <apachelogger> strange
Dec 09 02:08:26 * rsalveti brb
Dec 09 02:09:14 <rbelem> apachelogger, do you know any tool that makes debian/copyright maintainance easy? :-)
Dec 09 02:09:50 <apachelogger> http://people.ubuntu.com/~apachelogger/scripts/
Dec 09 02:09:54 <apachelogger> copyright and license scripts
Dec 09 02:12:26 <apachelogger> http://paste.ubuntu.com/541253/
Dec 09 02:16:48 <rbelem> apachelogger, maybe martin has better clues about that
Dec 09 02:16:54 <apachelogger> http://comments.gmane.org/gmane.comp.lib.qt.qml/1749
Dec 09 02:17:02 <apachelogger> that does not sound very good
Dec 09 02:17:56 <rbelem> apachelogger, qt not compiled with gl es?
Dec 09 02:18:04 <apachelogger> no, it is
Dec 09 02:18:25 <apachelogger> but apparenlty it needs to be compiled against an appropriate version
Dec 09 02:19:02 <GrueMaster> I'd look at the problem in a deeper vein.  "The device itself is runs on a Atom Z520 processor".  That is Poulsbo video, which (when I worked on it) wasn't that great.
Dec 09 02:19:49 <rbelem> apachelogger, hum... martin said something about use mesa gl es libs to compile
Dec 09 02:19:59 <GrueMaster> And I don't know of any GMA500 (Poulsbo) support in Ubutnu since 8.04.
Dec 09 02:20:04 <apachelogger> rbelem: that is what I did
Dec 09 02:20:35 * apachelogger did not even know one needed proprietary blob until this week ^^
Dec 09 02:22:04 <rbelem> brb
Dec 09 02:24:53 <apachelogger> in the lands of meego the have sgx devel packages, making me think they build against it...
Dec 09 02:31:48 <apachelogger> rbelem: if you can find someone to give input on the problem, that would be great
Dec 09 02:32:02 * apachelogger needs to go to bed
Dec 09 02:32:33 <apachelogger> rbelem: also, fwiw, plasma-netbook does not manage to come up with *anything*
**** ENDING LOGGING AT Thu Dec 09 02:59:57 2010