[13:11] <jibel> skaet, on the tracker there is "Ubuntu Desktop Preinstalled armhf+mx5" shouldn't it be "Ubuntu Desktop armhf+mx5" instead ?
[13:13] <skaet> jibel,  I wasn't clear if it had been switched over to pre-installed or not yet.    Am assuming that when Adam switches it over he'll change the iso tracker,  but double checking is definitely in order.
[13:14] <skaet> infinity,  do yo have any updates on where we are with the oneiric kernel respin?     I'm not seeing many clues in the backscroll
[13:15] <jibel> skaet, well, on cdimages.u.c there are builds for mx5 live but no preinstalled.
[13:17] <skaet> jibel,  then yeah,  we probably need to change over the iso tracker.
[13:19] <skaet> infinity,   ogra - when any of the ARM images change from pre-installed,   please make sure to let jibel, stgraber or myself know so we can get the iso tracker back in synch.
[13:23] <ogra_> skaet, i was actually planning to add the omap4 arch to default server builds today and see what comes out
[13:23] <ogra_> without dropping the preinstalled build attempts, but they wont build until germinate is fixed
[13:24] <ogra_> not sure if that will also affect the normal alternate server builds though
[13:25] <ogra_> skaet, probably cjwatson has an idea for a quick-fix of germinate as interim solution
[13:25] <cjwatson> https://code.launchpad.net/~vorlon/germinate/lp.1025818/+merge/115429
[13:25] <cjwatson> I'm not going to merge something incomplete there
[13:25] <skaet> ogra_,  please double check that we won't be breaking the alternate server builds.
[13:25] <ogra_> cjwatson, yeah, thats clear from the comments
[13:26] <ogra_> skaet, we cant, if arm would fail that would only be arm
[13:26] <ogra_> our build system is clever enough to catch that
[13:27] <ogra_> and chances are better that the alternates will actually build, they dont run germinate on the target arch (as we do for the preinstalled-ship seed on preinstalled-server)
[13:28] <ogra_> so the older germinate on nusakan will be used
[13:28] <cjwatson> Indeed.
[13:29]  * ogra_ really doesnt get why unity-2d suddenly eats 370M according to htop ... that was 170M in precise 
[13:30] <ogra_> (for an idling desktop right after boto that is)
[13:30] <ogra_> *boot
[13:30] <cjwatson> I expect it'll be easy to review and merge once it has a test, but I'm not going to attempt something without that, given my experience of the fragility of this kind of change.  I expect Steve will finish it off once he's back from the plugfest.
[13:31] <ogra_> cjwatson, right, my target is to move to the same server builds as anyone else anyway i would pretty much love to put preinstalled to rest right now
[13:31] <ogra_> but seems QA needs them
[13:31] <jibel> skaet, added mx5 live with default ubuntu desktop armhf testcase, and also added a default testcase to omap live which had none.
[13:31] <skaet> thanks jibel
[13:32] <ogra_> we really need some mx5 boards in the company if we want to go on supporting that
[13:32] <ogra_> currently we fully rely on the one board that adam has on which he can only test if it has spare cycles and he has time
[13:37] <ogra_> cjwatson, does that look ok to you ? http://paste.ubuntu.com/1101810/
[13:37] <cjwatson> ogra_: I'd rather do those last two lines the other way round.
[13:37] <cjwatson> precise amd64 amd64+mac i386 powerpc
[13:38] <cjwatson> *       amd64 amd64+mac i386 powerpc armel+omap4
[13:38] <ogra_> ok
[13:38] <cjwatson> More conventional and easier to extend later
[13:39] <ogra_> done
[13:39] <ogra_> hmm, and i probably want armhf :P
[13:46]  * ogra_ fires off a testbuild of ubuntu-server for omap4 
[13:59] <ogra_> oh, that was pretty painless
[14:00]  * ogra_ wgets, lets see if it also boots 
[15:57] <ogra_> Generating the binary iso/jigdo images ...
[15:57] <ogra_> mkdosfs 3.0.7 (24 Dec 2009)
[15:57] <ogra_> Extracting bootloader from main archive
[15:57] <ogra_> cp: cannot stat `omap4/cdrom/vmlinuz': No such file or directory
[15:57] <ogra_> make: *** [bin-images] Error 1
[15:57]  * ogra_ curses
[15:57] <ogra_> i dont get why it does that
[15:58] <ogra_> ogra@nusakan:~$ ls -l /srv/cdimage.ubuntu.com/ftp/dists/quantal/main/installer-armhf/current/images/omap4/cdrom/vmlinuz
[15:58] <ogra_> -rw-rw-r-- 1 cdimage cdimage 4293816 2012-07-19 13:34 /srv/cdimage.ubuntu.com/ftp/dists/quantal/main/installer-armhf/current/images/omap4/cdrom/vmlinuz
[15:58] <ogra_> the file definitely exists ... its just as if DI_PATH isnt properly exported in debian-cd or so
[15:59] <cjwatson> set -x it.
[16:01] <ogra_> good idea ...
[16:01]  * ogra_ fires off a testbuild
[16:03] <bjf> infinity: my oneiric kernel packages are in the upload queue?
[16:10] <ogra_> oh, my, what a mess these omap4 debian-cd scripts are
[16:11] <ogra_> so yeah, i was looking at the wrong script ... having SUBARCH=omap in all these scripts surely cant work
[16:14] <ogra_> how embarrasing
[16:16] <cjwatson> Ah, yeah
[16:17] <ogra_> nobody noticed since we never built alternate for anything else than karmic omap
[16:40] <bjf> cjwatson, i have oneiric packages in the upload queue for yesterdays incident. can i trouble you to process them?
[16:42] <cjwatson> done
[16:43] <bjf> cjwatson: many thanks!
[16:43] <infinity> Heh, I was JUST doing that. ;)
[16:43] <infinity> Timing is everything.
[16:44] <cjwatson> Bah, I could have slacked.
[16:44] <infinity> Sure could have.
[16:46] <ScottK> cjwatson: That's almost always true.  The procrastinator's mantra is "If you wait long enough, it usually turns out you didn't need to do it anyway."
[16:47] <cjwatson> It's a careful balance between that and continuing to draw a paycheque, really.
[16:47] <ScottK> Absolutely.
[16:47] <skaet> infinity,  what's still needed before it goes to -updates?
[16:47] <cjwatson> Being published would be a start :-)
[16:48] <skaet> :)
[16:49] <skaet> was meaning is there further testing lined up or not?
[16:51] <infinity> skaet: From the bug log, I'm not sure it's even had basic smoketesting yet.
[16:51] <skaet> infinity,  from the IRC channel I had assumed so.
[16:51] <infinity> It doesn't need rigorous regression testing and other such involved pain, but it does need someone to boot it and make sure it's not just plain broken.
[16:52] <bjf> skaet: i'd like both utlemming and hggdh to test the kernel
[16:52] <skaet> bjf, infinity - what's the bug number that's being used to track this one?
[16:53] <infinity> 1026730
[16:53]  * skaet adding to the incident report
[16:53] <infinity> And 1026884
[16:53] <infinity> Though it looks like that one won't happen today, given the task status.
[16:54] <henrix> infinity: working on that one. hopefully, i'll have the lts pkg soon
[16:55] <dobey> what's the best way to go about pulling some pyqt bits onto the default install/image for quantal right now? having them in recommends/depends for things that are on the default install already?
[16:56] <infinity> dobey: If they're not required by the install, it seems a bit odd to artificially want to pull them in?
[16:57] <dobey> infinity: i want to get rid of ubuntuone-installer; and there is also no more ubuntu-sso-client-gtk with the new version i'm working on the upload for right now
[16:58] <dobey> so ubuntuone-control-panel-qt and ubuntu-sso-client-qt require some pyqt bits
[16:59] <infinity> Which they should depend on if they do?
[16:59] <infinity> I may be utterly failing to see what you're trying to do here. :P
[17:00] <ScottK> Then he immediately hits the brick wall of python-qt4 is frigging huge and you have to split the package.
[17:00] <ogra_> Jul 20 16:58:05 main-menu[292]: WARNING **: Configuring 'cdrom-detect' failed with error code 1
[17:00] <dobey> right. so what's the best way to get the -qt versions on the default install? just pull them in? i guess i'd need to add ubuntuone-control-panel-qt to ubuntu-meta though for ubuntu-desktop?
[17:00]  * ScottK dons his Debian maintainer hat and says, "patches welcome".
[17:00]  * ogra_ sighs deeply
[17:00] <dobey> ScottK: i guess thee's plenty of room now :)
[17:01] <ScottK> Oh, right.  Good point.
[17:01] <ScottK> Of course everyone else thinks that too, so move fast.
[17:01] <infinity> dobey: ubuntuone-control-panel-qt would have to be seeded, yes.  But its dependencies should just be, well, its dependencies.
[17:01] <dobey> infinity: right, and they are
[17:02] <dobey> infinity: should i propose a branch to seed it then?
[17:02] <infinity> Check, so it's not a question of getting pyqt on the CDs, but rather getting ubuntuone-control-panel-qt on them. :P
[17:02] <infinity> Is this all in the archive already?
[17:02]  * infinity just looks.
[17:02] <dobey> well there's nothing not in the archive that i'm trying to add to the image yet; so yes
[17:04] <dobey> there was only the one bin new i had this time 'round, as we haven't gotten anything else ported to python3 yet
[17:04] <infinity> Alright.  I'll just s/ubuntuone-installer/ubuntuone-control-panel-qt/ in the desktop seed and that should make you happy.
[17:06] <skaet> infinity,   looks like hggdh and utlemming are lining up for testing the oneiric kernel as soon as it comes out of the builders.   Will you be around later today to push it out,  if it tests ok?
[17:06] <infinity> skaet: It's already out of the builders...
[17:06] <infinity> skaet: But yes, I'm on top of it.
[17:06] <utlemming> infinity: do you have the URL for the new kerenl?
[17:06] <skaet> infinity,  ok,   please update the incident report as the status of things change.
[17:07] <infinity> utlemming: https://launchpad.net/ubuntu/+source/linux/3.0.0-23.39
[17:09]  * utlemming is testing new kernel
[17:10] <arosales> utlemming: thanks :-)
[17:11] <infinity> dobey: Hrm, do we still want ubuntuone-client-gnome too?  I'm a bit confused by the structure of this. :P
[17:11] <dobey> infinity: yes, ubuntuone-client-gnome is the nautilus and gnome-settings-daemon plug-ins
[17:12] <infinity> dobey: Okay, then this should do it: ubuntuone-client-gnome
[17:12] <infinity> Err.
[17:12] <infinity> http://paste.ubuntu.com/1102113/
[17:12] <infinity> That.
[17:12] <infinity> Multiple paste buffers strike again.
[17:12] <dobey> infinity: yeah, that should work
[17:12] <dobey> thanks
[17:14] <infinity> dobey: I'll update meta too, so we can see the results of this.
[17:16] <dobey> infinity: awesome. thanks much
[17:19] <infinity> dobey: And done.
[17:25] <utlemming> infinity: I've tested the new Oneiric kernel and confirmed it to work
[17:34] <skaet> thanks utlemming
[17:34] <infinity> utlemming: On both x86 arches, I'm guessing?
[17:35] <utlemming> infinity: on i386, verifying it amd64 now
[17:36] <infinity> utlemming: Anyhow, better to follow up to the tracking bug instead of me, so we can keep note of what's been done.
[17:36] <infinity> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1026730
[17:36] <ubot2> Ubuntu bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress]
[17:40] <utlemming> infinity: posted comments, and confirmed on amd64 too
[17:49] <henrix> infinity: oneiric packages ended up in the wrong component.  can you sort that out?
[17:49] <cjwatson> I can
[17:49] <cjwatson> I was meaning to check back on that anyway
[17:49]  * infinity blinks.
[17:49] <infinity> There was nothing NEW in them, how would that have happened?
[17:50] <cjwatson> Hm, not published yet
[17:50] <infinity> Oh, hahaha.
[17:50] <infinity> My removing the binaries would have killed it, of course. :P
[17:51] <infinity> Which is why only that one file is wrong.
[17:51] <infinity> Derp.
[17:51] <cjwatson> linux-image-3.0.0-23-virtual?
[17:51] <henrix> yep
[17:51]  * cjwatson fixes
[17:52] <henrix> cool, thanks
[17:54] <infinity> Will need the same manual override for lts-backport-oneiric's version later.  I'll keep that in mind when I accept it.
[17:54] <infinity> If it makes it today.
[17:55] <henrix> infinity: i hope it does... almost there!
[17:55] <infinity> Actually, wait.  Why would that be?  I only removed it on i386...
[17:55] <infinity> cjwatson: I thought soyuz was smart enough to copy overrides from another arch if the binary existed?
[17:56] <infinity> Maybe that breaks cross-pocket or something odd.
[17:57] <cjwatson> It looks like it *should*, but the ancestry logic in soyuz is very very wonky.
[17:58] <cjwatson> Sorry, the at least three different implementations of ancestry logic.
[17:58] <cjwatson> Fixing that is somewhere on my list :-/
[18:05] <hggdh> infinity, skaet, bjf: starting to test the kernel
[18:05] <bjf> hggdh: thanks
[18:05] <skaet> thanks hggdh
[18:16] <henrix> cjwatson: you did fix the oneiric pkg, right? because the 'promote-to-proposed' task is still 'incomplete' on the bug
[18:16] <cjwatson> I didn't do any bug paperwork
[18:16] <cjwatson> I ran change-override
[18:16] <cjwatson> linux-image-3.0.0-23-virtual 3.0.0-23.39 in oneiric i386: universe/admin/optional -> main
[18:17] <henrix> ah, ok. just wanted to confirm. i'll fix the bug task
[18:17] <henrix> thanks
[18:17] <infinity> henrix: Too late. ;)
[18:17] <henrix> infinity: :)
[19:30]  * skaet --> appt.   Online later
[19:35] <hggdh> utlemming: did your m1.small instance run OK? I lost contact with mine
[19:39] <hggdh> bjf: not really good: http://pastebin.ubuntu.com/1102330/
[19:41] <hggdh> jjohansen, bjf, infinity, skaet: tests still going on, but AWS m1.small failed
[19:42] <jjohansen> hggdh: this is the latest kernel correct? What of an older say -17 kernel?
[19:44] <hggdh> jjohansen: this is the current -proposed one. I just rebooted it, and will run the test again
[19:47] <henrix> hggdh: can you bring this to #ubuntu-kernel so that smb can help with this?
[19:49]  * hggdh moved over to -kernel
[19:50] <hggdh> jjohansen: as of yesterday, a -17 kernel also failed. But today I ended with a system down
[19:51] <jjohansen> hggdh: the -17 failure I saw yesterday was the QRT output not a dmesg oops, did the -17 also have an oops
[19:52] <hggdh> jjohansen: nope, it did not
[19:53] <jjohansen> hggdh: okay, so is this then a regression from previous kernel, failure of QRT test is a lot less serious than OOPs on test
[19:53] <hggdh> jjohansen: I did not repeat the OOPS, but I do get non-fatal GPFs now
[19:54] <jjohansen> hrmmm
[19:55] <jjohansen> hggdh: we need to know if we are getting those with previous kernels as well
[20:18] <balloons> is anyone about who can help me clean up the 'ubuntu core' testcases? I'd like to migrate them, but I want to make sure they make sense
[20:19] <infinity> balloons: Sure.
[20:19] <infinity> balloons: I'm not even sure what testcases it has, or how many it really needs. :P
[20:20] <infinity> balloons: Point me at something?
[20:20] <balloons> infinity, ok.. sure
[20:20] <balloons> there are three builds on the tracker
[20:20] <balloons> all point to this: http://testcases.qa.ubuntu.com/Install/ARM/Core
[20:21] <balloons> the builds are for amd64, armhf and i386
[20:21] <infinity> Yeah, I know, it's my product. ;)
[20:21] <infinity> And that testcase is fine.
[20:21] <infinity> It's really just testing that the chroot tarball itself didn't get hideously broken or corrupted in creation.
[20:21] <infinity> Since if the packages are broken, we'll find out elsewhere too.
[20:21] <infinity> (Everything in core is in every other image)
[20:22] <balloons> ok, right.. So I was going to say let's make sure we get proper links in the download links
[20:22] <balloons> but it looks like they are correct now
[20:22] <balloons> http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/18993/downloads
[20:22] <balloons> ok, so I'll strip that sentence out and add your little explanation to the top and convert them over
[20:23] <balloons> thanks infinity
[20:23] <infinity> NP.
[20:27] <balloons> does anyone know the status on this bug? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1009226. I just tried to run through the upgrade testing again, and this is a hard stop
[20:27] <ubot2> Ubuntu bug 1009226 in update-manager "Precise to Quantal: update-manager UI crashes: can't load DistUpgradeViewGtk (No module named vte)" [High,Confirmed]
[20:29] <balloons> actually, the bug I'm getting is very close, but not quite the same.. I'll go searching again to see if it's a dupe, but I know jibel was mentioning earlier upgrades are broken
[21:06] <hggdh> infinity, skaet: kernel approved on QA
[21:10] <infinity> hggdh: Shiny.
[21:12] <infinity> jjohansen: Were you doing the security sign-off for this oneiric update?
[21:12] <jjohansen> infinity: I am working on it
[21:13] <balloons> infinity, on those core images, where should bugs be reported? against what package?
[21:14] <infinity> balloons: If a package itself is broken, against that package.
[21:14] <infinity> balloons: If it's just that the image is broken somehow, ubuntu-cdimage
[21:15] <infinity> balloons: (Pretty much the same rules as any image, no?)
[21:15] <infinity> balloons: Well, except that sometimes the "cdimage" bug is in livecd-rootfs or live-build or something, but we don't expect users/testers to necessarily know that.
[21:16] <balloons> right, that works.. I'll get instructions added for bugs now
[21:20] <balloons> infinity, the core image does contain apport correct?
[21:21]  * stgraber wouldn't think os
[21:21] <stgraber> *so
[21:21] <stgraber> it's called core for a reason
[21:21]  * stgraber checks
[21:21] <stgraber> balloons: right, no apport
[21:22] <balloons> stgraber, thanks
[21:22]  * balloons adds to bug reporting instructions 
[23:41]  * skaet back
[23:44]  * skaet looks at the tracking bug,  sees all is shiny and smiles  :)