[04:24] <pitti> Good morning
[06:15] <pitti> GrueMaster, skaet: hm, you used "Ubuntu ARM Preinstalled omap{3,4}" in the tracker? Isn't that what "Ubuntu Desktop armel+omap{,4}" is nowadays?
[06:16] <pitti> or yet another image?
[06:16] <GrueMaster> No, probably should be desktop.
[06:16] <pitti> ok, thanks
[06:16] <pitti> so "Ubutu ARM Preinstalled" is obsolete indeed
[06:17]  * pitti is currently trying to update publish-image-set.py accordingly
[06:19] <GrueMaster> I'm off to bed.  See you in ~8 hours.
[06:19] <pitti> see you!
[07:28] <pitti> jibel: bonojur
[07:28] <pitti> bonjour, rather
[07:31] <pitti> jibel: I have a question for you in bug 791159
[07:31] <ubot4> Launchpad bug 791159 in ubiquity (Ubuntu) "OEM Install: No launcher or desktop shortcut to prepare for shipping (affects: 1) (heat: 120)" [Medium,New] https://launchpad.net/bugs/791159
[07:33] <jibel> Guten Morgen pitti
[07:33] <jibel> it is fixed
[07:33] <pitti> jibel: nice, thanks for confirming
[07:34] <jibel> you're welcome
[07:40] <pitti> jibel: do you think bug 804655 is important enough to warrant a respin? it should properly fall back to 2d on these devices
[07:40] <ubot4> Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g (affects: 3) (heat: 16)" [High,Confirmed] https://launchpad.net/bugs/804655
[07:40] <pitti> but I'm not sure how much we want people to test the 3d live bits on ati
[07:40] <pitti> with the new gallium drivers
[08:06] <pitti> skaet: I updated https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview with the desktop news, and what I think are noteworthy bugs
[08:10] <jibel> pitti, I'm not sure how critical it is for a2. 2d fallback should work and isn't there a way to force r300g loading ?
[08:10] <pitti> I don't think it's critical
[08:10] <pitti> I don't know how to force r300g, RAOF would know
[08:11] <jibel> and that would require a respin of all the images. I don't think we have time for this.
[08:11] <pitti> *nod*
[08:12] <pitti> we used to respin on Wednesdays, but unlike previous times we actually have little reason to
[08:23] <pitti> back in ~ 30 mins
[08:23] <ogra_> pitti, so we have a chance of getting a new kernel for omap4 that could make the images work ... apw is just doing a testbuild for me
[08:35]  * cjwatson yawns
[08:36] <apw> ogra_: it seems the omap3 kernel already has the fix we are testing so should be unaffacted (assuming there are images for that even)
[08:36] <ogra_> yes, omap3 just segfaults
[08:37] <apw> quality
[08:37] <ogra_> USb is fine i suppose ... not that we were able to boot far enough to verify though
[09:02] <cjwatson> pitti: anything in particular I should be looking at?
[09:03] <apw> everyone happy for me to upload this fixed ti-omap4 (only) kernel, is tested by ogra_
[09:03] <ogra_> go ! :)
[09:03] <cjwatson> incidentally, I thought that bug 791883 was fixed now, I just hadn't closed the remaining task because I wanted to test it properly
[09:03] <ubot4> Launchpad bug 791883 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "ubi-console-setup.py:set_keyboard() gets error 141 (crashes) in Kubuntu (affects: 1) (heat: 125)" [High,Confirmed] https://launchpad.net/bugs/791883
[09:04] <pitti> hey cjwatson, good morning; how are you?
[09:04] <pitti> apw: please go ahead
[09:05] <cjwatson> not bad, thanks
[09:05] <apw> pitti: ogra_: on it thanks
[09:06] <ogra_> pitti, even though it wont fix the broken omap3 kernel, could you let u-boot out of new, will be at least one bug less on the images
[09:06] <pitti> cjwatson: some Kubuntu test installs went through without mentioning this, indeed; was that hard to reproduce, or did it happen every time?
[09:06] <ogra_> (so it ends up on the respin)
[09:07] <cjwatson> pitti: every time
[09:07] <cjwatson> it's probably dead now, I'll just double-check locally
[09:07] <pitti> cjwatson: other than that, I'm still waiting for the major disaster to happen
[09:08] <pitti> cjwatson: bug 782507 would be in your camp, although it's far from being a blocker
[09:08] <ubot4> Launchpad bug 782507 in partman-auto (Ubuntu) "Installation creates a new swap partition (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/782507
[09:08] <pitti> cjwatson: thanks
[09:08] <pitti> ogra_: that is u-boot-linaro?
[09:08] <ogra_> yep
[09:09] <ogra_> seems it adds one or two ne arches (so produces new binaries)
[09:09] <pitti> looks fine; I'll put them into universe for now, as most binaries are
[09:09] <cjwatson> 782507> also hardly new!  that's been the case since warty
[09:09] <ogra_> yeah
[09:10] <pitti> whee
[09:10] <ogra_> no need for main
[09:10] <pitti> ogra_: done
[09:10] <ogra_> thx :)
[09:10] <pitti> so I'll wait for the usb-enabled omap4 kernel, then we can at least release the omap4 bits
[09:12] <ogra_> right
[09:12] <pitti> cjwatson: ah, we only have kubuntu alternate results, the desktop ones are just for live session
[09:12] <ogra_> at least server would be good, if desktop has issues i'm happy to leave it out
[09:12] <pitti> cjwatson: but Kubuntu wants to skip a2 anyway
[09:13] <cjwatson> my Kubuntu desktop test install (image from last Friday, so not suitable for iso.qa reporting) is past the point of the previous crash
[09:13] <cjwatson> I'll close out that bug when rsync is done and I can restart firefox more easily
[09:13] <jibel> pitti, cjwatson , I can not reproduce 791883 anymore with latest images. It was 100% reproducible.
[09:14] <pitti> jibel: thanks for confirming
[09:14] <cjwatson> right.  I expected it to be fixed, so good.
[09:14] <cjwatson> as I say, will close shortly
[10:31] <jibel> pitti, I changed bug 781076 to critical. it affects i386 upgrades, I got it on wubi i386 and xubuntu i386 upgrades and it leaves the system in a very bad state.
[10:31] <ubot4> Launchpad bug 781076 in doc-base (Debian) (and 2 other projects) "package doc-base 0.9.5ubuntu2 failed to install/upgrade: Byte order is not compatible at ../../lib/Storable.pm (affects: 35) (dups: 37) (heat: 304)" [Unknown,Unknown] https://launchpad.net/bugs/781076
[10:31] <pitti> jibel: ok, thanks
[10:57] <jibel> bug 806349
[10:57] <ubot4> Launchpad bug 806349 in ubiquity (Ubuntu Oneiric) (and 1 other project) "OEM Install fails with - KeyError: "The cache has no package named 'python2.6-minimal'" - without network connection. (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/806349
[11:40] <stgraber> pitti, skaet: Edubuntu is completely tested and good to be released for alpha-2. We have quite a few critical bugs but nothing that'll be fixed in time for a respin.
[11:57] <cjwatson> jibel,pitti: 806349 fixed in bzr; does it justify a respin?
[12:13] <stgraber> cjwatson: Hi! Is it possible that the switch to live-build changed the content of sources.list in the livefs? One of the Edubuntu ubiquity plugins now fail because sources.list doesn't contain any deb-src entry
[12:16] <stgraber> cjwatson: bug 806428
[12:16] <cjwatson> I think I deliberately left that turned off
[12:16] <ubot4> Launchpad bug 806428 in edubuntu-live (Ubuntu Oneiric) (and 1 other project) "Missing detailed package selection step in Oneiric (affects: 1) (heat: 6)" [High,Triaged] https://launchpad.net/bugs/806428
[12:17] <pitti> re
[12:17] <cjwatson> (live-build completely rewrote the sources.list handling, and I decided not to re-enable that particular bit because it makes a fairly significant difference to CD size)
[12:18] <pitti> cjwatson: not from my POV; I don't think OEM install has a lot of actual value in alpha-2 (aside from testing that it works); WDYT?
[12:19] <pitti> documenting the workaround (install with network) seems sufficient to me
[12:19] <cjwatson> I'm OK with that, it's just not my milestone to drive :-)
[12:19] <stgraber> I'm not sure I actually need deb-src for what I want to do. As python-apt should be able to generate the list of binary packages generated from a given source package without needing Sources.
[12:19] <stgraber> mvo: ^
[12:21] <pitti> stgraber: would take some computation -- you'd need to iterate over all binary packages, get their source package, and build a map out of that
[12:21] <pitti> stgraber: it's not 100% correct during development releases due to NBS, and FTBFS, though
[12:22] <stgraber> pitti: indeed, though I guess in this case we'd prefer using a bit more CPU than re-introducing deb-src in the live environment
[12:22] <pitti> space wise, yes :)
[12:22] <cjwatson> stgraber: changing it would involve something like http://paste.ubuntu.com/638874/ with some suitable comment
[12:22] <cjwatson> but if you can avoid it, that would be good
[12:23] <cjwatson> (that's in livecd-rootfs)
[12:23] <stgraber> cjwatson: oh, now that I think of it :) Can you turn deb-src back on only for Edubuntu? :)
[12:23] <stgraber> I have around 2GB of free space on these images so I don't really care :)
[12:24] <cjwatson> well, that's what that diff does
[12:24] <stgraber> oh, that link was for edubuntu I guess?
[12:24] <cjwatson> yes
[12:24] <cjwatson> do you want to reassign that bug to livecd-rootfs, or do you want to keep it?
[12:25] <stgraber> that step is slow enough to load as it's, so I'll just re-assign to livecd-rootfs and ship Edubuntu with deb-src then
[12:25] <cjwatson> ok, committed
[12:26] <cjwatson> I'll upload now if you want
[12:26] <cjwatson> ?
[12:27] <stgraber> would be great. We're not going to respin for that but if for some reason we do get a respin it'd be nice to have.
[12:27] <cjwatson> done
[12:27] <pitti> stgraber: http://paste.ubuntu.com/638875/ takes 2 seconds here
[12:28] <pitti> stgraber: but I guess the live-build fix is still better, if you don't care about the size
[12:28] <cjwatson> I would do both fixes if it's feasible
[12:28] <cjwatson> more robust that way
[12:29] <stgraber> yep, I'll make a note to catch the exception from apt_pkg and use pitti's code in that case
[12:29] <pitti> stgraber: note that the map values are Package objects, not names; I just quickly threw this together to see how long the iteration takes
[12:30] <pitti> cjwatson: 806349 release-noted
[12:32] <pitti> cjwatson: do we actually want to publish the amd64+mac images? I thought so, I fixed published-image-set.py accordingly
[12:33] <cjwatson> yes please
[12:34] <cjwatson> (though not to releases.u.c, once we get far enough along to be doing that)
[13:26] <charlie-tca> ubuntustudio is failing for libc6; the images failed to build yesterday
[13:26] <charlie-tca> They probably need a respin; I am looking at the logs right now to see what happened
[13:28] <charlie-tca> E: Some index files failed to download, they have been ignored, or old ones used instead.
[13:28] <charlie-tca> make: *** [apt-update] Error 100
[13:29] <charlie-tca> server errors?
[13:29] <charlie-tca> W: Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/oneiric/main/binary-i386/Packages.bz2  Hash Sum mismatch
[13:29] <stgraber> that's for the cd build right? not livefs?
[13:29] <charlie-tca> The images are no good for alpha2, and need to be respun
[13:29] <pitti> charlie-tca: looks like it just needs a respin then; I've seen this happen several times
[13:29] <stgraber> if so, edubuntu had the same thing yesterday, a respin of just the cd would fix it
[13:29] <charlie-tca> That's the ubuntustudio images, they are live only
[13:29] <charlie-tca> rather, alternate only
[13:30] <pitti> charlie-tca: I added 20110704 to the tracker yesterday; that's not enough for a2?
[13:30] <charlie-tca> That image won't install
[13:31] <charlie-tca> That fails for the libc6 bug that got fixed
[13:31] <charlie-tca> They will need a re-spin to get an image that works
[13:31] <pitti> charlie-tca: you mean "live only" == "alternate only", right?
[13:31] <pitti> charlie-tca: running another build
[13:31] <charlie-tca> yeah, They have alternate images only
[13:31]  * pitti marks for rebuild in tracker
[13:31] <charlie-tca> Thanks, pitti
[14:01]  * skaet takes a sip of tea, and starts into the backscroll..
[14:02] <skaet> hiya pitti,   I see ubuntu studio is rebuilding.  Any others likely to need it?
[14:03] <pitti> charlie-tca: added to tracker, built now
[14:03] <pitti> hey skaet
[14:03] <pitti> skaet: yes, the omap4 images
[14:03] <charlie-tca> Thank you
[14:03] <pitti> skaet: they are waiting for https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1309.14/+build/2611421
[14:04] <pitti> skaet: they should take ~ 8 hours, plus another hour publisher, so the kernel should be published in about 5 or 6 hours
[14:04] <pitti> skaet: can you trigger the ubuntu desktop/server ARM images then?
[14:04] <skaet> pitti,  sure, can do,  as long as they give me the signal its ready.
[14:05] <pitti> skaet: was already tested from a PPA
[14:07] <skaet> pitti, good to know.   thanks.
[14:59] <doko> cjwatson, pitti: when do you expect the alpha2 tomorrow? asking I want to start the test rebuild before the unfreeze
[15:03]  * micahg has noticed that the soft freeze has almost seemed meaningless this time around
[15:05] <pitti> doko: still waiting for the new omap4 kernel, the other images seem fine to me
[15:05] <pitti> doko: so I expect that we'll have all a2 images in some 12 hours
[15:05] <pitti> skaet: ^ does that sound ok to you?
[15:06] <pitti> doko: how does that affect a test rebuild?
[15:06] <doko> would like to have something as consistent as possible
[15:06] <pitti> mythbuntu posted
[15:07] <pitti> doko: so better start it right now?
[15:12] <skaet> pitti,  doko,   Just to double check, are the test rebuilds replacing images in the archive, or just going to doko's sandbox?
[15:13] <doko> skaet: test rebuilds never reach the archive
[15:15] <skaet> doko,  coolio.  then since we're not hearing any requests for rebuilds, go ahead with i386/amd64.   Hold off on the arm ones until we get the next set of images posted though.
[15:29] <pitti> we can always reserve an arm buildd should another urgent upload come up
[15:55] <pitti> skaet: still need anything from me? I need to leave for Taekwondo in some 5 mins
[15:56] <skaet> pitti,   thanks.   Will keep an eye on those arm kernels.
[15:56] <pitti> thanks
[15:56] <pitti> so, see you tomorrow!
[15:59] <skaet> jdstrand,  since it looks like we'll need to respin images server image for arm,  does it make sense to upload those CVEs you were mentioning yesterday?
[15:59] <jdstrand> skaet: I'd be happy to upload the fixes for them, yes ;)
[15:59] <jdstrand> skaet: is now a good time?
[15:59] <skaet> jdstrand,  yup, nows a good time
[16:00]  * skaet has a couple more hours to wait for that kernel to emerge....
[16:02] <jdstrand> skaet: done (0.14.0+noroms-0ubuntu8)
[16:03] <skaet> jdstrand, thanks!
[16:03] <jdstrand> skaet: thank you for remembering me :)
[17:15] <cjwatson> wgrant: was there any progress with rolling out germinate-lubuntu?
[17:57] <skaet> arm kernel build done (took 8 hours, 21 minutes);  now waiting for publisher before kicking off those arm builds..
[17:58] <ogra_> yay
[17:58] <skaet> :)
[18:32] <smoser> slangasek, can you populate uec images iso testing results for 20110706 ?
[18:32] <smoser> http://uec-images.ubuntu.com/server/oneiric/20110706/
[18:57] <smoser> or anyone other than slangasek can do that also. i believe cjwatson has.
[19:04] <slangasek> smoser: having a look
[19:41] <pitti> so, mythbuntu is out, too
[19:42] <pitti> skaet: yay, omap4 kernel built
[19:43] <pitti> skaet: ah, you are already building the new armel images apparently?
[19:43] <skaet> pitti,  yup
[19:43] <pitti> cool
[19:44] <pitti> skaet: can you please add them as "Ubuntu Desktop armel+...", not "Ubuntu ARM ..."? the latter is deprecated, and the image release script now assumes the former
[19:44] <skaet> will do.
[20:02] <skaet> smoser,  I've set up the tester so results can be recorded, but the images still need to be populated.   Script is missing some info (where to put the northeast images)
[20:09]  * GrueMaster is standing by for new omap4 images.
[20:11]  * skaet is glad GrueMaster is standing by,  but they're still building.  Desktop should emerge first.
[20:14] <GrueMaster> ok
[20:44] <skaet> smoser,  was able to get the script to run,  can you confirm the right bits are in place?
[21:14] <slangasek> smoser: sorry, had a power outage here just as I started working on the AMI postings.  Looks like someone else has gotten to it?
[21:16] <skaet> slangasek,  took an attempt,  think its correct.  but would appreciate you or smoser confirming it.
[21:22] <slangasek> skaet: well, /something/ is posted, so provided you ran the script I trust that it's correct :)
[21:22] <slangasek> (I'm not going to try to compare a dozen AMI IDs by hand :-)
[21:22] <skaet> :)
[21:22] <skaet> script was run,
[21:37] <skaet> GrueMaster, Ubuntu Desktop armel+omap4 (20110706) posted
[21:37] <skaet> ogra_, ^
[21:38] <GrueMaster> ok
[21:42] <GrueMaster> skaet: Are you respinning armel server too?
[21:44] <skaet> yup, about to start
[21:46] <GrueMaster> Could you also trigger netboot to respin?  That will be the fastest and I need it for other testing as well.
[21:49] <skaet> GrueMaster, just started off the server while you were typing.   Will queue up netboot next then.
[21:49] <GrueMaster> ok.
[21:54] <charlie-tca> skaet: updates done on https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview
[21:54] <skaet> charlie-tca, thank you! :)
[22:52] <skaet> GrueMaster, ogra_ omap4 server image posted
[22:53] <GrueMaster> Thanks.  Hope it fairs better than desktop.
[22:53] <GrueMaster> I'm seeing massive ext3-fs errors during fs resize stage.
[23:05] <skaet> GrueMaster, ack.  :(
[23:05] <GrueMaster> Looks like jasper failed to resize.  It resized the filesystem, but not the underlying partition.
[23:07] <GrueMaster> I'll experiment a little before calling it a total loss.
[23:15] <skaet> GrueMaster, I'm going to break for dinner.   infinity has triggered a netboot rebuild,  so it should be emerging.
[23:15] <GrueMaster> yep.
[23:16] <GrueMaster> Have fun.  I will be breaking in a couple of hours.
[23:16] <skaet> I'll check back here after I get some food.   Let me know what you find (/me keeping fingers crossed).