[00:55] <infinity> slangasek: I need to do a new d-i upload for omap anyway, apparently, so we'll get the new kernel with that.
[00:55] <slangasek> ok
[01:01] <infinity> slangasek: Uploaded.
[01:02] <slangasek> cheers
[01:03] <infinity> Oh wait... Bah.
[01:03] <infinity> Were the new kernels still pending?
[01:03] <infinity> Silly trigger-happy me.
[01:03] <slangasek> evidently
[01:03] <slangasek> only armhf has published
[01:04] <infinity> There, removed from the upload queue.
[01:04] <infinity> I'll re-upload later.
[01:05] <infinity> La la la.  Pay no attention to the shell account behind the curtain.
[01:11] <infinity> slangasek: If history is anything to go by, those kernels will be done in 6-7 hours, so I'll do my d-i upload just before bed tonight.
[01:11] <slangasek> alright
[01:11] <infinity> cjwatson: Don't worry about d-i respins, I'm doing an upload to fix omap after all the kernels are built.
[02:00] <skaet> slangasek, re: step 3 on day-2 - I did it earlier (and just added it).  Basically want to make sure the cloud images stay in synch with our rebuilds (or its an explicit decision to not rebuild)
[02:01] <slangasek> skaet: oh, I meant step 4, apparently you added a new 3 when I wasn't looking ;)
[02:02] <skaet> :)  step 4 was an artifact from before,  and given the iso tester mails out to those subscribed to tests, am wondering if its worth doing.   Didn't do it earlier since we knew the images were bad - does the current set look like possible keepers?
[02:02] <slangasek> no, the current set are still only smoke-testers
[02:02] <slangasek> the kernel is still building
[02:11] <skaet> still building... urk
[02:11] <skaet> ok, maybe cjwatson and pitti can do the mail out once the next set get posted then.
[02:11] <skaet> s/and/or/
[02:12] <skaet> slangasek, when did they actually start building?
[02:25] <skaet> slangasek, any updates to the pad.ubuntu.com?
[03:23] <slangasek> skaet: the kernels started building as soon as uploaded, 6-ish hours ago; all archs are built now except for armel.  As for pad.ubuntu.com, infinity has updated it to allow outputting arm images faster so that we don't have to wait for all subarchs before testing can be done
[03:24] <skaet> slangasek,  re: kernel - ok,  seems a bit longer than before though, but I'll check my records before commenting further.
[03:27] <skaet> re. pad.ubuntu.com - you comment doesn't quite make sense to me,  pad is just to record what's happening.  Comments there were the ones I put up before I had to go to the meeting (indicating things building, etc.  not current status).   I see adam's changes on the arm images - but the status at the top isn't accurate at the moment.
[03:27] <skaet> hence my questions on IRC :)
[04:06] <slangasek> skaet: oh, sorry - I mean that there was a tweak to the build pipeline, my comment didn't make sense because I misunderstood the question :)
[04:07] <slangasek> skaet: I hadn't looked at the top there.  What's the "LTSP" item?
[04:08] <slangasek> skaet: in any event, no new issues have been raised since those
[04:20] <TheYsNoi> hi there..1st time boot here...finally..
[04:30] <pitti> skaet: mail out> sorry, what mail?
[04:30] <pitti> (and good morning)
[06:38]  * infinity glares at the armel kernel build to see if that will make it finish faster.
[07:41] <infinity> Kernel finally published; new debian-installer uploaded.
[08:05] <TheYsNoi_> hi there...new boot here..
[08:05] <TheYsNoi_> anybody?
[10:18]  * cjwatson uploads casper to fix the autotests (bug 924535)
[10:18] <ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,In progress] https://launchpad.net/bugs/924535
[10:19] <cjwatson> added to the pad
[11:35] <Riddell> "Preseeded installation stops at user setup" remind me again what that is?
[11:35] <cjwatson> bug 924535
[11:35] <ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/924535
[11:35] <cjwatson> unless I'm misunderstanding your question
[11:35] <Riddell> needs a preseed file pointed too at the start of the install
[11:35] <cjwatson> sure, the automatic tests do that
[11:36] <Riddell> that'll be it, that's why I haven't come across it
[11:36] <cjwatson> if you aren't preseeding then that bug doesn't show up, indeed
[11:36] <cjwatson> but it makes a pretty big difference for qa/hwcert
[11:36] <Riddell> that makes sense
[11:37] <Riddell> do they care about kubuntu?  if not it doesn't seem to be alpha critical for us
[11:37] <cjwatson> do you have jenkins tests?
[11:37] <Riddell> nope
[11:38] <cjwatson> well, it's possible for other folks to do preseeding as well, but true, probably not milestone-critical for Kubuntu in itself
[11:39] <Riddell> I am coming cross network-manager not successfully telling plymouth that it has started which causes plymouth to wait for ages on first boot
[11:39] <Riddell> I don't see that in the iso tracker yet
[11:47] <jibel> Riddell, I got this issue, but not enough information to file a bug. there's a 2 minutes timeout on first boot.
[11:48] <Riddell> I filed bug 924836
[11:48] <ubot4> Launchpad bug 924836 in network-manager (Ubuntu) "network-manager does not tell plymouth it has started (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924836
[11:54]  * ogra_ wonders why the ac100.bootimg files on cdimage have the wrong md5 
[11:54] <cjwatson> URL?
[11:55] <ogra_> http://cdimage.ubuntu.com/daily-preinstalled/20120201.1/precise-preinstalled-desktop-armel+ac100.bootimg
[11:55] <cjwatson> hm
[11:55] <ogra_> 552f7b49d76bf0df93a71223dec9ff06 is what i get locally
[11:55] <ogra_> 47dcdb59b8dbacc2c0462135c38b864c is what it says it should be in the MD5SUM file
[11:56] <ogra_> aha, which is the MD5 of the last build
[11:56] <cjwatson> looking into it
[11:56] <ogra_> seems the publisher doesnt properly replace that file or so
[11:56] <cjwatson> looking into it :)
[11:56] <ogra_> yep
[12:01] <cjwatson> combination of problems I think
[12:06] <ogra_> hmm
[12:07] <ogra_> armhf seems to have the same issue, sad
[12:07] <cjwatson> fixed the core problems (pending deployment) but this really isn't helped by there being an entirely different preinstalled output directory from debian-cd for no obvious reason
[12:08] <ogra_> "different preinstalled output directory " ?
[12:08] <cjwatson> ./CONF.sh:244:export PREINSTALLEDIMAGES=$CDIMAGE_ROOT/scratch/$PROJECT/$IMAGE_TYPE/preinstalled
[12:08] <ogra_> all preinstalleds go into the same target dir, no ?
[12:08] <ogra_> oh, the scratch dir
[12:08] <cjwatson> which is unhelpful, it should just use OUT
[12:08] <cjwatson> then this would have worked
[12:08] <cjwatson> (then again we'd never have noticed the underlying bugs, but)
[12:08]  * ogra_ wonders where that line comes from, i cant remember adding that
[12:09] <ogra_> (and i wouldnt know why i would mangle the default dir)
[12:11] <cjwatson> should be fixed on cdimage now at least
[12:11] <ogra_> thanks
[12:12] <cjwatson> oh, I suppose PREINSTALLEDIMAGES might be more like LIVEIMAGES, that makes sense
[12:12] <cjwatson> so the bug is just that ac100 bootimg files are written to PREINSTALLEDIMAGES (which is meant to be an intermediate directory) rather than OUT (which is meant to have all the output files)
[12:13] <ogra_> aha
[12:14]  * cjwatson goes to fix that
[12:20] <cjwatson> actually I'm still very confused.  maybe I don't need to deal with this right now.
[12:22] <cjwatson> for future reference, I think my statement above is wrong - maybe it's a problem with the imagesums target not checksumming .bootimg files
[12:22] <ogra_> cjwatson, ugh, that bashism is in all arm boot scripts btw
[12:22] <cjwatson> anyway, it shouldn't cause a practical problem no
[12:22] <cjwatson> w
[12:22] <cjwatson> ogra_: that was just drive-by nitpicking, not a real problem, seeing as it's #!/bin/bash :)
[12:22]  * ogra_ will fix that after milestone, since its ugly
[12:23] <ogra_> sure, still ugly :)
[12:23] <ogra_> thats what you get basing all scripts on the same initial version :)
[13:18] <ogra_> hmm, is it normal that i get a wlan network dialog in ubiquity but the password field is greyed out ?
[13:18] <ogra_> i get a separate popup to input the WEP key, but it seems that should already be possible from the main dialog
[13:21] <ogra_> hmm, and shouldnt i see a slideshow ? or isnt that ready yet
[13:32] <ogra_> gah, i'm stuck with english kbd ... and i cant remember having a kbd selection dialog .... do i get an english keyboard based on the language selection nowadays ?
[13:37] <ogra_> bah, and dpkg-reconfigure keyboard-configuration only regenerates my initrd, how do i tell debconf to use a different keyboard ?
[13:38] <cjwatson> you should get console selection
[13:39] <ogra_> i dont
[13:39] <cjwatson> setxkbmap may help for the time being
[13:39] <ogra_> reconfiguring console-setup gets me keymap selection etc
[13:39] <cjwatson> sorry, I'm deep in the innards of apt, no attention to spare
[13:39] <ogra_> but keyboard-configuration doesnt get me any debconf prompts
[13:40] <ogra_> well, editing /etc/default/keyboard helps for the moment
[13:40] <cjwatson> it's possible the keyboard configuration bit is after wireless selection
[13:40]  * ogra_ tries a german install this time, lets see
[13:41] <cjwatson> we can't really fix the ordering there until we can move keyboard handling to an indicator
[13:41] <ogra_> k
[13:42] <cjwatson> which is bug 800561
[13:42] <ubot4> Launchpad bug 800561 in ubiquity (Ubuntu Precise) (and 5 other projects) "No way to add other keymap than english on Live CD (affects: 4) (dups: 1) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/800561
[13:42] <ogra_> ah, ok, if its filed i wont dig deeper
[13:42] <cjwatson> also bug 653057 sounds like what you're describing
[13:42] <ubot4> Launchpad bug 653057 in ubiquity (Ubuntu) "[Maverick] can't connect to wi-fi during installation because keyboard isn't set up yep (affects: 1)" [Undecided,New] https://launchpad.net/bugs/653057
[13:43] <ogra_> well, i had no prob connecting to wifi, its just that in the ubiquity dialog there is a password field thats greyed out
[13:43] <ogra_> clicking the wlan i want gets me the std network manager WEP dialog though
[13:44] <ogra_> (i dont htink the kbd stuff and the wlan issue are related at all)
[13:53] <ogra_> hmm, intresting, so if i dont select the network in this dialog but the device the pw field isnt greyed out
[13:54] <ogra_> and i definitely dont get any kbd seletion at all ...
[13:55] <ogra_> (in ubiquity that is)
[14:02] <ogra_> hmpf and even in a german install i end up with us kbd
[14:17] <ogra_> beyond that keyboard issue all looks fine on armhf and armel ac100
[14:17] <ogra_> :)
[14:17]  * ogra_ moves on to omap4
[14:42] <lamont> who's the victim of the day?
[14:43] <lamont> I'm going to nuke the oneiric x86 livecd rootfs images on cardamom, for disk space, figured I'd check first
[14:43] <lamont> cjwatson: ??
[14:43] <cjwatson> I think that's OK although is there anything else that could be nuked first?
[14:43] <lamont> 13722   public_html/LiveCD/lucid
[14:43] <lamont> 10763   public_html/LiveCD/oneiric
[14:43] <lamont> 66511   public_html/LiveCD/precise
[14:44] <lamont> that's du -smx
[14:44] <lamont> the precise number is a *boggle* I'll discuss with infinity later
[14:46] <lamont> cjwatson: and I assume you'd prefer nuking oneiric to nuking lucid ?
[14:46] <lamont> all it really means is that you'd need to regen before you could respin, but you're highly likely to need to do so anyway
[14:47] <cjwatson> nuking lucid would be bad
[14:47] <cjwatson> we're about to do a point release
[14:47] <cjwatson> nuking oneiric is OK given that it's not too horrible to regenerate
[14:47] <lamont> that was my thinking, with out the "about to do" part
[14:47] <cjwatson> but yeah, clean up precise :)
[14:47] <cjwatson> er in the reduce rather than remove sense
[14:48] <lamont> right
[14:48] <lamont> base edubuntu-dvd kubuntu kubuntu-dvd kubuntu-mobile lubuntu mythbuntu ubuntu ubuntu-core ubuntu-dvd ubuntustudio-dvd ubuntu-wubi ubuntu-zh_CN xubuntu
[14:49] <lamont> edubuntu-dvd is the clear winner at 10700MB, everyone else is 2-6GB, or base/ubuntu-core at 200-700 MB
[14:49] <lamont> y'all keep adding images
[14:50] <stgraber> skaet: bug 924897 is caused by the switch to PAE on the i386 images. LTSP explicitly depends on the non-PAE kernel as a good part of the existing thin clients don't support PAE.
[14:50] <ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/924897
[14:52] <stgraber> skaet: I realise asking to have a second kernel on the CD just for LTSP is a bit too much to ask, so I'll probably relax the dependecy to "linux-image-generic | linux-image-generic-pae" keeping non-pae as the default (for these manually running ltsp-build-client post-install) while using the PAE kernel for these installing from alternate
[14:52] <stgraber> I'll need to release note it though as people will need manual action post-installs to switch to the non-pae kernel if they have any thin clients requiring that (mostly thinking of VIA and Pentium M)
[15:07] <stgraber> skaet: ok, I have a fix for bug 924897. Should I upload that? (it's not tested in the exact environment as it's not really easy to do for something running in the middle of d-i. I tested the change manually on another Precise machine)
[15:07] <ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/924897
[15:20] <skaet> stgraber, looking into it.
[15:22] <cjwatson> of the set listed at the top of the pad, the only one that isn't built is cgroup-lite
[15:22] <cjwatson> the pad claims that it was uploaded, but I see no evidence of that
[15:27] <cjwatson> Riddell: Kubuntu supports Wubi, doesn't it?  Bug 924899 points out that (I think) bug 924535 breaks Wubi
[15:27] <ubot4> Launchpad bug 924899 in wubi "Had to enter new account name and password both in wubi.exe and in the second phase Xubuntu installer (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924899
[15:27] <ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Fix released] https://launchpad.net/bugs/924535
[15:28] <cjwatson> well, FSVO "breaks", I suppose it's release-notable if we must
[15:30] <skaet> stgraber,  looks like we'll need to rebuild all the alternates (including server), edubuntu dvd, kubuntu dvd - have I missed some?
[15:31] <astraljava> skaet: What about Studio? What's the reason for this?
[15:32] <astraljava> Ahh... wubi, I presume.
[15:33] <stgraber> skaet: the LTSP fix would only required alternate to be rebuilt, well, technically only i386 but well...
[15:34] <stgraber> skaet: the bug is in ltsp-build-client running in d-i when we don't have linux-image-generic on the media
[15:37] <skaet> astraljava, ubuntustudio switching to dvd has me unsure of the implications on it.  But if that was the trigger,  then  yup,  guess so.
[15:37] <skaet> stgraber,  I'm seeing reference to ltsp-client in the kubuntu dvd
[15:38] <Riddell> cjwatson: more like Wubi supports Kubuntu, I think I'm happy not having wubi working for alpha 2
[15:38] <cjwatson> Riddell: *nod*
[15:38] <cjwatson> astraljava: not sure Wubi supports Ubuntu Studio
[15:39] <astraljava> cjwatson: I am not familiar with wubi support at all, so I'll trust your word on the matter.
[15:39] <cjwatson> but the ath9k fix perhaps?
[15:40] <jibel> wubi doesn't support ubuntu studio
[15:41] <stgraber> skaet: do they have linux-image-generic on the media (on i386)? if not, it'll need a rebuild indeed
[15:42] <Riddell> skaet: are you testing kubuntu dvds?
[15:43] <skaet> Riddell,  no - was looking through manifests to scope implications of the fix and spotted that the ltsp-client was on it.
[15:44] <Riddell> oh right
[15:44] <Riddell> skaet: I'd also be fine having broken ltsp on our dvds
[15:44] <jibel> stgraber, linux-image-generic is on kubuntu i386 DVD.
[15:44] <Riddell> for alpha 2
[15:45] <skaet> stgraber,  linux-generic-pae	3.2.0.12.12
[15:45] <skaet> linux-image-3.2.0-12-generic-pae	3.2.0-12.20
[15:45] <skaet> linux-image-generic-pae	3.2.0.12.12
[15:45] <skaet> is on the kubuntu DVD
[15:45] <skaet> hmm... what Riddell said
[15:45] <skaet> :)
[15:46] <stgraber> ok, so not affected then
[15:46] <stgraber> skaet: so looks like it's just alternate then. Should I upload the fix?
[15:47] <skaet> stgraber,  yes go ahead and upload
[15:48] <skaet> cjwatson,  so the casper fix is going to require all the live cd/dvds to be rebuilt?
[15:49]  * GrueMaster hears "rebuild", twitches.
[15:49]  * charlie-tca thinks "time" when he sees "rebuild"
[15:50]  * ScottK LOLs at GrueMaster when he hears rebuild.
[15:51] <cjwatson> skaet: anything that cares about (a) automatic testing (b) wubi
[15:51] <cjwatson> other images can probably get away without; Riddell has already decided that Kubuntu can skip it
[15:54] <ogra_> GrueMaster, we dont use casper luckily ... :)
[15:55] <ogra_> no need to rebuild any of arm for this ...
[15:57] <skaet> thanks ogra_
[15:59] <stgraber> skaet: uploaded
[16:00] <stgraber> skaet: I'll run the test myself on i386 as soon as it's built so we know if the fix worked ASAP
[16:01] <skaet> thanks stgraber,   I'll do that one first then.
[16:01] <skaet> or slangasek will ;)
[16:03] <doko_> set the i386 and amd64 to manual to get a build on a fast buildd. please ping me if you need something urgent
[16:04] <skaet> doko_,  don't know the runes for that,  so looks like someone else will need to step in and help out here.
[16:04] <cjwatson> I think he's saying he already did it
[16:05] <doko_> good to have interpreters on this channel ;-)
[16:05] <skaet> ahh... s/set/have set/
[16:05] <skaet> thanks cjwatson, doko_  :)
[16:06] <cjwatson> set is set in the simple past tense too ;-)
[16:06] <GrueMaster> iso.qa needs to be updated with the latest netboot (20101020ubuntu103).
[16:07] <skaet> stgraber, jibel - ^ can one of you help with getting netboot updated on the tracker.
[16:07] <skaet> ?
[16:09] <jibel> skaet, GrueMaster done
[16:09] <GrueMaster> Thanks.
[16:10] <skaet> stgraber,  do you want respins of Edubuntu for the casper fix?
[16:12] <stgraber> skaet: it's not critical for us but might as well do it yes, I haven't tested Edubuntu yet and was planning on testing later this afternoon anyway
[16:13] <skaet> stgraber, ack
[16:19] <skaet> cjwatson,  can you do a review of the pad.ubuntu.com and confirm I've got the state captured accurately of what needs to be rebuilt and why?
[16:20] <cjwatson> skaet: I think Xubuntu desktop may want [8]
[16:21] <cjwatson> not sure about Mythbuntu and Lubuntu; may be less of an issue there, but I did get a bug report from a user trying to install Xubuntu using Wubi who was bitten by that
[16:25] <skaet> cjwatson,  ok,  will plan on Xubuntu desktop then, unless one of the Xubuntu crowd says otherwise.   Not seeing gilir or superm1 in the channel to ask - will see if I can hunt them down later (will leave it as ? then for those)
[16:26] <skaet> Thanks!
[16:37] <charlie-tca> I will go with cjwatson's recommendations for Xubuntu
[16:37]  * charlie-tca highly respects cjwatson when he makes a suggestion
[16:42] <skaet> :)
[16:59] <slangasek> cjwatson: the most recent builds I did should already have the ath9k fix landed on any livefses, if I didn't screw it up - so perhaps that means ubuntustudio doesn't care about respinning?
[17:00] <cjwatson> ah, could be
[17:01] <slangasek> ogasawara: are you still maintaining the code behind http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html?  (Is that going to remain the url for this, and should we be talking to QA about getting someone else to maintain it?)
[17:01] <cjwatson> the pad didn't capture that in a way I understood :)
[17:01] <astraljava> slangasek: I was sort of waiting for ScottL to tell us whether he wants the lightdm-greeter fix in before it or not, but it's still not settled.
[17:01] <ogasawara> slangasek: technically I still look after it, although I haven't really touched it aside from s/oneiric/precise/
[17:02] <slangasek> cjwatson: right, sorry, I haven't usefully updated the pad, I don't really have the feel for how that works
[17:02] <ogasawara> slangasek: I don't mind maintaining it for now as it's not much work involved and I'm happy to make tweaks.  Any major re-work I'd probably rather hand over to QA.
[17:02] <skaet> slangasek, astraljava - ltsp-client - https://launchpad.net/bugs/924897 needed for Ubuntu Studio ?
[17:02] <ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released]
[17:03] <skaet> slangasek,  want to get on the phone and I'll walk you through how we've been using the pad?
[17:03] <slangasek> ogasawara: so the main thing right now is that we should probably have manifest tracking for the arm preinstall images
[17:03] <cjwatson> skaet: ltsp> no
[17:03] <astraljava> skaet: It's not needed for us, but we would be interested in the ath9k fix, as some of the milestone testers have hw that need that driver.
[17:03] <astraljava> s/need/use/
[17:03] <slangasek> skaet: well, I did get the briefing earlier when you started using it, I just don't have the *feel* for it yet :)
[17:04] <skaet> I'm not seeing the ath9k fix on the pad - so it probably should be added explicitly.
[17:04] <cjwatson> astraljava: you've got it already - sorry for being confusing
[17:04] <slangasek> skaet: that's [3]
[17:04] <cjwatson> skaet: no need
[17:04] <skaet> slangasek, cjwatson - ok.  :)
[17:05] <ogasawara> slangasek: that should be easy enough to add, I'll ping you when it's available
[17:05] <slangasek> ogasawara: thanks :)
[17:05] <slangasek> strange smattering of package uploads overnight that hit the alternates, I see... libraw? http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport/iso_pkg_diffs/ubuntu-i386-alt.html
[17:05] <astraljava> cjwatson: Ok, thanks!
[17:05] <skaet> slangasek,  to confirm [2],[3],[4],[5] - are now in the images we've got up on the tracker and in testing?
[17:06] <slangasek> skaet: 2 definitely, 3 may be missing yet from some of the arm images (that's why I'd like the weather report updated to be able to tell me), 4 and 5 are definitely both done
[17:07] <skaet> slangasek, gotcha. :)
[17:08] <GrueMaster> slangasek: I don't think we care about 3 so much.  None of our "supported" image systems use ath9k (only AC100 and it has a community kernel).
[17:09] <hallyn> libvirt fix being queued up - shall I wait to push it?  (it's not urgent)
[17:10] <slangasek> GrueMaster: ok, thanks
[17:11] <slangasek> skaet: so according to the weather report, kubuntu alternate is actually still missing the ath9k fix in its d-i builds
[17:12] <slangasek> that's a quick'n'easy respin that I can do right now
[17:12] <slangasek> Riddell: ^^
[17:13] <skaet> slangasek, should bug 924752 be on the pad for triggering rebuilds?   just the wubi affected?
[17:13] <ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
[17:13] <slangasek> btw, in light of the discussions above about disk space, I've also nuked the stale ubuntustudio daily/ directory in favor of the new dvds
[17:13] <GrueMaster> slangasek: Looking at the bug, I assume only the main kernel was fixed?  That only covers omap3, which none of the supported systems have wifi built in.  Could possibly affect usb wifi, but I think the affected user base will be extremely low.
[17:13] <skaet> slangasek,  wait on that alternate rebuild until [9] is built I think,  its marked down for rebuilds when that's done as well.
[17:14] <cjwatson> cdimage doesn't have especially meaningful disk space constraints these days
[17:14] <slangasek> cjwatson, jibel: does bug #924752 need fixed on the CDs, or just in the standalone wubi?
[17:14] <ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
[17:14] <cjwatson> lamont was talking about the livefs builders
[17:14] <slangasek> cjwatson: ah, ok
[17:14] <cjwatson> still, nuking that directory probably made sense
[17:14] <cjwatson> slangasek: it *should* be able to copy from the CD rather than downloading
[17:14] <cjwatson> I think
[17:14] <slangasek> cjwatson: well, it also leads to the weather report claiming that 682 packages are out of date on an image we no longer care about ;)
[17:14] <cjwatson> slangasek: any rebuild will pick it up anyway ...
[17:14] <cjwatson> slangasek: heh, yeah
[17:14] <slangasek> skaet: so no, we don't need to track 924752 for respins
[17:15] <slangasek> GrueMaster: yes, it's the main kernel
[17:16] <slangasek> skaet: ack, holding off on respin
[17:16] <ogra_> ac100 doesnt have ath9k anyway
[17:16] <ogasawara> slangasek: hrm, is there an arm specific Packages.gz file so that I can compare what's in the archive to what's in the manifest?
[17:16] <ogra_> so no issues here
[17:17] <skaet> slangasek, re; 924752 ok, have updated pad to reflect its not a respin trigger (so I don't end up asking again)
[17:20] <ogasawara> slangasek: nm, found it
[17:20] <skaet> slangasek,  looks like ltsp-client is published now,  so go ahead with those rebuilds.
[17:21] <skaet> https://launchpad.net/ubuntu/+source/ltsp/5.2.16-0ubuntu13
[17:21] <highvoltage> ltsp-client? rebuilds? does that affect edubuntu too?
[17:23] <slangasek> highvoltage: it wasn't marked as such; the bug impacts LTSP client installs from an image that doesn't include linux-image-generic
[17:24] <slangasek> highvoltage: which seems not to apply to edubuntu, so no need for a respin unless you want it to give the other code path testing
[17:24] <skaet> highvoltage - edubuntu has linux-image-generic in its manifest, so its not affected.
[17:25] <skaet> however edubuntu needs respin for [8]
[17:25] <stgraber> highvoltage: Edubuntu won't get rebuilt for this but will for some other packages (casper being one). I'll do the testing this afternoon with the new build.
[17:25]  * skaet notes [8] is casper fix.... 
[17:26] <slangasek> alternate respins going
[17:26] <stgraber> slangasek: cool. Will test for the LTSP fix when I'm back with something to eat (should be right around the time where they'll be ready)
[17:26] <charlie-tca> What is the cutoff for getting the images tested now for alpha2?
[17:28] <slangasek> infinity: we're building both daily and daily-preinstalled for ubuntu-server on armel?
[17:28] <skaet> charlie-tca 1400 GMT on Feb 2.
[17:28] <highvoltage> stgraber: ok
[17:29] <skaet> slangasek,  any reason not to start the casper rebuilds as well?
[17:29] <charlie-tca> Ok, upgrade testing may have to be skipped for Xubuntu
[17:29] <ogra_> slangasek, hmm, we shouldnt build daily (only netinst)
[17:30] <slangasek> stgraber: iso tracker bug: if I try to disable all alternates at once, I get an error about an invalid selection
[17:30] <slangasek> stgraber: not sure I can reproduce it however
[17:30] <stgraber> slangasek: could it be something published since you last refreshed the page?
[17:30] <ogra_> slangasek, daily will happen once we have the marvell kernel which isnt the case yet
[17:31] <cjwatson> slangasek: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview?action=diff&rev2=36&rev1=35 - can you review?
[17:31] <slangasek> ogra_: er, considering the daily-preinstalled (which is not a netinst) has a crontab entry all its own, I'm not inclined to disable that.  I'm only asking about the duplication between daily and daily-preinstalled
[17:31] <ogra_> slangasek, yes, i was referring to that, we should not build daily yet
[17:31]  * GrueMaster didn't even know a daily existed.
[17:31] <cjwatson> there's no such thing as a netinst for Ubuntu to the best of my knowledge - do you mean netboot?
[17:31] <ogra_> only daily-preinst
[17:31] <GrueMaster> cjwatson: yes, netboot.
[17:32] <ogra_> cjwatson, well, a mangled netboot image that pretends to be a mini iso :)
[17:32] <cjwatson> netinst is a term of art related to Debian installer images
[17:32] <slangasek> skaet: looks good to me for the casper respinning; I'll launch that here shortly
[17:32] <stgraber> slangasek: hmm, actually got a trace in the logs, so indeed a bug. Will investigate.
[17:32] <slangasek> stgraber: shouldn't have been due to anything being published, I had refreshed the page this morning
[17:32] <cjwatson> it refers specifically to an image which contains all the installer udebs plus the base system but is configured to install everything else from the network
[17:32] <cjwatson> we don't have those
[17:32] <ogra_> right
[17:33] <slangasek> ogra_: so you don't need server daily *now*, but you *will* soon?
[17:33] <slangasek> for a disjoint set of subarchs?
[17:33] <cjwatson> so I'm picky about the terms in case somebody invents one for Ubuntu and then I get confused :)
[17:33] <ogra_> slangasek, yes, as soon as the marvell kernel exists we will roll normal d-i daily server images with it
[17:34] <ogra_> cjwatson, we just call it (falsely) like that because the install pulls all packages from the network, no debian relation at all :)
[17:47] <slangasek> cjwatson: release note LGTM
[17:48] <cjwatson> thanks
[17:48] <slangasek> skaet: bug #924281 was fixed with an upload of lxc, not of cgroup-lite; fixing the bug state & pad
[17:48] <ubot4> Launchpad bug 924281 in cgroup-lite (Ubuntu) "cgroup-lite not installable inside 'lxc create -t ubuntu' container (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/924281
[17:49] <skaet> slangasek,  :)  thanks for solving that mystery.
[17:57] <slangasek> stgraber: no really, bug #924836 has nothing to do with network-manager - /etc/init/failsafe.conf doesn't care about network devices that aren't listed in /e/n/i
[17:57] <ubot4> Launchpad bug 924836 in network-manager (Ubuntu Precise) (and 3 other projects) "network-manager does not tell plymouth it has started (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/924836
[18:01] <ogasawara> slangasek: arm manifests added, all showing to be up to date
[18:02] <slangasek> ogasawara: sweet, thanks!
[18:02] <stgraber> slangasek: oh, right, misread the script ... I'll eventually get a clear picture of all that in my head :) right. when lo is brought up, the ifupdown hook should emit static-network-up as all the interfaces are ready
[18:03] <stgraber> slangasek: so the question is why it didn't happen or what make the script think there was something else to bring up
[18:03] <slangasek> yep
[18:05] <stgraber> slangasek: asked for details. My guess is that one of the other if-up hooks failed making ifupdown stop there and never called the upstart one. That's easy to check with upstart job logging.
[18:05] <slangasek> right
[18:09] <GrueMaster> ogasawara: Not all arm images are listed.  Missing Kubuntu-desktop (omap, omap4), and Ubuntu-Server (omap, omap4).  Both are daily-preinstalled.
[18:09] <ogasawara> GrueMaster: ah thanks, will add those
[18:10] <GrueMaster> Also, Ubuntu Netbook Remix and Kubuntu Netbook are no longer built.
[18:10] <GrueMaster> (both were rolled into desktop).
[18:10] <stgraber> skaet: same LTSP issue says jibel ... apparently my fix didn't work. I'm grabbing the image here to investigate, ETA around 30min till I have an idea of what's broken (and that wasn't fixed by my fix)
[18:11] <skaet> stgraber, ack.
[18:12] <slangasek> skaet: do the question marks mean we're waiting for feedback on mythbuntu and lubuntu before deciding te respin?
[18:12] <hallyn> skaet: is now a good time to push a new libvirt with bugfix?
[18:12] <skaet> slangasek,  yes - default is probably going to be release note, but want them to have the option.
[18:13] <skaet> hallyn,   is it a blocker for A2 or can it be release noted?
[18:14] <hallyn> skaet: it blocks pxeboot of vms, but can be worked around - release noted is probably fine
[18:14] <hallyn> Daviey here?
[18:15] <skaet> hallyn,  if it can be worked around, then lets just release note it for now.
[18:16] <Daviey> hallyn: always
[18:16] <hallyn> skaet: ok, will do.  no idea where to release not it, btw
[18:16] <hallyn> release note, that is
[18:16] <stgraber> skaet: just noticed my auto upgrade tester just pushed the results for today (flavours). Edubuntu and Kubuntu are all good (better than yesterday) but Xubuntu and Mythbuntu both fail because of a unity-greeter crash (affects i386 and amd64)
[18:16] <hallyn> Daviey: just wanted your assessment of the bug importance - i don't know if there are projects blocked by it (bc of automated installs breaking)
[18:17] <Daviey> hallyn: Can you quote the bug number, and reference a patch?
[18:17] <charlie-tca> I wonder if that is because we don't use unity-greeter?
[18:17] <Daviey> hallyn: i think we are too early in the cycle to be blocked on something not working :)
[18:17] <stgraber> charlie-tca: well, if it crashes, that's because it's installed for some reason :)
[18:17] <hallyn> iDaviey: cool, thx
[18:18] <skaet> stgraber,  re: unity-greeter - is it a known issue already or a new one?  (bug number?)
[18:19] <stgraber> skaet: no idea, all I see is a .crash in the upgrade tester and apport won't let me use the .crash files from the auto upgrade...
[18:19] <stgraber> skaet: someone would need to manually run the upgrade to figure out exactly what's happening and be able to report the crash with apport
[18:19] <skaet> stgraber,  ack.
[18:20] <slangasek> skaet: are we not worrying about oversizedness right now?
[18:20] <skaet> charlie-tca, not sure.   Can you see if you can help figure it out?
[18:21] <skaet> slangasek,  yes, we'll document our oversizedness as part of the release notes for A2
[18:21] <slangasek> ok
[18:21] <charlie-tca> Yes, I can try an upgrade, but it will take about 4-6 hours here
[18:21] <charlie-tca> wait, which one am I haelping with?
[18:22] <charlie-tca> the oversized for xubuntu doesn't matter yet. We adjust it around beta1
[18:23] <skaet> charlie-tca, the upgrade crash is the one I'm wondering about.   However if you're comfortable release noting it (ie. don't do it), that might be an option.
[18:24] <Daviey> hallyn: have the bug and patch?
[18:24] <charlie-tca> I don't see much of an option but to release note it. It will take me at least 12 hours to run both upgrades
[18:25] <charlie-tca> if I don't do anything else while they are running
[18:25] <charlie-tca> I ran them for alpha1, and they worked, but the new tracker has always shown them failing
[18:26] <charlie-tca> skaet: my choice is to run all tests except upgrades, or run the upgrade tests
[18:27] <stgraber> charlie-tca: I'm trying to boot one of the auto upgrade images manually, see if I can extract something
[18:28] <stgraber> charlie-tca: hmm, you don't seem to have a login screen at this stage, all I see is a black screen with a white bar at the top
[18:29] <charlie-tca> How can that be?
[18:29] <charlie-tca> because it installed unity-greeter
[18:29] <stgraber> charlie-tca: well, AFAICT it's using unity-greeter. greeter-session=unity-greeter in /etc/lightdm/lightdm.conf
[18:30] <charlie-tca> that has to be removed, and xubuntu-greeter installed
[18:30] <charlie-tca> Xubuntu willl not work with unity greeter
[18:30] <stgraber> charlie-tca: right, no xubuntu-greeter installed
[18:34] <stgraber> charlie-tca: unity-greeter is getting installed because lightdm recommends it
[18:34] <charlie-tca> but it won't work
[18:34] <stgraber> charlie-tca: and sets itself as the default in its postinst
[18:34] <charlie-tca> which makes xubuntu fail because it won't login
[18:35] <charlie-tca> so, the user must then manually switch to a tty, install xubuntu-greeter, remove unity-greeter, and do what ever else he needs to be able to login
[18:36] <charlie-tca> We had that fixed in 11.10, but apparently it will take fixing for each release
[18:36] <stgraber> charlie-tca: what's the actual name for xubuntu-greeter? there isn't a xubuntu-greeter package in the archive
[18:36] <skaet> charlie-tca,  release note it is.
[18:36] <micahg> umm, the resolver shouldn't be adding unity-greeter to xubuntu as both lightdm and lightdm-gtk-greeter are recommends
[18:36] <micahg> s/recommends/depends/
[18:37] <charlie-tca> micahg: what's the name we use?
[18:37] <micahg> we're using lightdm-gtk-greeter which provides lightdm-greeter
[18:37] <stgraber> micahg: well, there's nothing wrong (at least for apt) with installing lightdm-gtk-greeter and unity-greeter
[18:37] <micahg> stgraber: yes, there is when it's seeded like that :)
[18:38] <micahg> unity-greeter is not on the xubuntu live image
[18:38] <stgraber> micahg: hmm, indeed, that's weird (just looked at the exact recommends/provides)
[18:38] <charlie-tca> Thanks, micahg
[18:38] <micahg> at least amd64 from 2 days ago
[18:38] <charlie-tca> and won't allow the login to work, for whatever reason
[18:39] <stgraber> micahg: when was that introduced?
[18:39] <micahg> stgraber: which?
[18:39] <stgraber> micahg: lightdm-gtk-greeter providing lightdm-greeter and lightdm recommending unity-greeter | lightdm-greeter
[18:39] <micahg> oneiric IIRC
[18:40] <micahg> lightdm (0.9.3-0ubuntu3) oneiric; urgency=low
[18:40] <stgraber> k, so it's not a case where lightdm would be upgraded before lightdm-gtk-greeter pulling unity-greeter as the provides isn't part of lightdm-gtk-greeter yet, then
[18:42] <stgraber> micahg: oh, hmm, wait, are you telling me you actually depend on unity-greeter not being on the media for your stuff to work?
[18:42] <micahg> stgraber: idk about depend, but I think so, it certainly shouldn't be on the xubuntu media
[18:43] <stgraber> if so, that's the problem, because auto-upgrade-tester doesn't use a media, it uses the archive and so unity-greeter is available
[18:43] <stgraber> just like it'd be if you did a Netboot install (which very well may be failing for you at the moment)
[18:43] <micahg> the two greeters will overwrite the configuration for each other depending on which is configured last
[18:43] <ScottK> That sounds like a clear bug.
[18:43] <micahg> not really, you can only have one greeter working at a time
[18:44] <micahg> although, idk why unity-greeter wouldn't work with xubuntu
[18:44] <charlie-tca> I think because it doesn't start the right file, it tries to run the wrong session
[18:44] <stgraber> the fix here is that some xubuntu package should probably depend on lightdm-gtk-greeter explicitly and conflict with unity-greeter
[18:44] <micahg> I'm certainly using it with xubuntu on one machine, but idk about the live media
[18:44] <stgraber> otherwise you depend on what's on the media and that's just wrong
[18:44] <micahg> I think we have a hack somewhere that specifies the lightdm-gtk-greeter for xubuntu
[18:45] <charlie-tca> It's the way lightdm is coded to use unity and unity session
[18:45] <micahg> stgraber: well, xubuntu-desktop depends on lightdm-gtk-greeter, but it shouldn't conflict with unity-greeter
[18:46] <stgraber> micahg: well "something" should ensure you can't get two greeters are once and that the default is lightdm-gtk-greeter in your case (even if unity-greeter is available for installation)
[18:46] <micahg> oh wait, I don't have unity-greeter on that other machine anymore
[18:47] <micahg> stgraber: that's what the seed is supposed to do
[18:47] <micahg> xubuntu-desktop depending on lightdm and lightdm-gtk-greeter should insure that
[18:48] <micahg> do we have apt debug output for this use case?
[18:48] <micahg> 2 greeters at once isn't an issue on an installed system
[18:49] <stgraber> micahg: what I see is the release upgrader installing "xubuntu-desktop" on a minimal ubuntu system and both lightdm-gtk-greeter and unity-greeter in the list
[18:49]  * micahg tries in a chroot
[18:50] <micahg> yeah, I see that too which is wrong, let's see what's pulling it in
[18:51] <stgraber> charlie-tca: good news, only a very limited subset of people will get the issue, actually these would likely have a broken Oneiric system too, bad news, auto upgrade testing is kind of pointless for you until that's solved (and will need solving as an SRU in Oneiric for it to work)
[18:52] <ScottK> micahg: One package overwriting the configuration for another is a bug.  It doesn't matter if only one can run at a time (think about sendmail overwriting postfix config files).
[18:52] <micahg> gah, no debug output
[18:52] <charlie-tca> stgraber: thanks for pushing through to this point on it.
[18:53] <micahg> ScottK: it's not overwriting the configuration, just setting itself as the current greeter akin to setting the dm before like gdm, kdm, xdm
[18:53] <stgraber> ScottK: they both use some lightdm command to set themselves as default, AFAIK they never touch the config directly.
[18:53] <stgraber> micahg was faster ;)
[18:53] <ScottK> Oh.  I see.
[18:53] <ScottK> thanks.
[18:54] <stgraber> skaet: found the bug in my fix, should have thought of it ... my check (apt-cache show) is running outside the LTSP chroot which isn't guaranteed to have the same apt sources as the chroot (and in this case, doesn't)
[18:55] <stgraber> skaet: I'll have a fix ready for upload in a few minutes (just checking out another LTSP weirdness on Edubuntu first)
[18:55] <skaet> stgraber, goodness.   :)
[18:56] <micahg> stgraber: I still think it's a resolver issue, but I can't get any debug output
[18:56] <stgraber> skaet: too many levels of chroot going on ;) installer => target => ltsp chroot each with potentially different apt sources ...
[19:02] <Riddell> skaet: I need to go out for a few hours
[19:02] <Riddell> skaet: when is release expected?
[19:03] <slangasek> tomorrow? :)
[19:03] <skaet> Riddell,  we'll be doing the release tomorrow - once we've gotten the test results and release notes updated.
[19:03] <Riddell> I need to test the new kubuntu alternates slangasek has made, otherwise I'm happy with the kubuntu images for an alpha
[19:03] <Riddell> I can do more tests if the release is not early tomorrow
[19:04] <Riddell> virtualbox actually works on precise which is a big help
[19:07] <slangasek> ubuntu desktop respin posted
[19:07] <slangasek> only xubuntu, edubuntu, ubuntu-dvd outstanding
[19:09] <Riddell> I can't do arm tests yet, I need a power supply for my pandaboard so those won't be in kubuntu alpha 2 I expect
[19:09] <ScottK> Unless GrueMaster has some time for them ...
[19:09] <GrueMaster> Sigh....
[19:10] <GrueMaster> I'll add them to my list, but they will be last.
[19:11] <GrueMaster> Riddell: You can always power it from the microusb to your PC if you have a USB Y cable (like for external drives).
[19:11] <skaet> Riddell,  ok.   I'll have the draft of the techoverview ready for review later today.
[19:11] <Riddell> GrueMaster: so a phone charger should do it?
[19:12] <skaet> Riddell,  please add any Kubuntu notes when you're back.
[19:12] <Riddell> will do
[19:15] <GrueMaster> Build versions of arm desktop need to be bumped on iso.qa.  (20120201.1)
[19:18] <slangasek> infinity: ^^ are those from your respin?
[19:19] <stgraber> skaet: I have fixes for both the Edubuntu issues (caused by the "inotify doesn't quite work with overlayfs" kernel bug) and the Ubuntu Alternate issue. Testing both now
[19:20] <stgraber> skaet: if you want these fixes, Ubuntu Alternate and Edubuntu will need rebuilding
[19:20] <slangasek> GrueMaster: updated
[19:20] <skaet> thanks stgraber,  ok,  will mark them for rebuild.
[19:28] <infinity> slangasek: I did no respin.
[19:29] <slangasek> infinity: didn't you do a build last night after d-i rebuilt?
[19:29] <infinity> slangasek: No, I just uploaded d-i and went to sleep. :P
[19:29] <slangasek> hmm
[19:30] <slangasek> infinity: oh, that's because we built in two batches so they had different serial numbers
[19:30] <infinity> Ahh, yes, that makes more sense.
[19:30] <infinity> And an irksome side effect of that change.
[19:30] <infinity> Oh well.
[19:36] <stgraber> skaet: uploaded
[19:36] <slangasek> infinity: yeah, not a big deal, we just have to remember that :)
[19:37] <gilir> skaet, is it possible to respin lubuntu desktop images when the last lubuntu-meta upload will be built ?
[19:38] <skaet> gilir,  should be possible.   when has lubuntu-meta been uploaded?
[19:38] <gilir> skaet, just a minute ago :)
[19:39] <stgraber> skaet: Edubuntu would like bug 882147 to be released targeted and its importance bumped. It's the ultimate cause of all these ltsp-live bugs and the reason why I had to add a bunch of upstart and NM hacks in ltsp-live (as in, force them to rescan/restart their config to workaround inotify not working)
[19:39] <ubot4> Launchpad bug 882147 in linux (Ubuntu) "overlayfs does not implement inotify interfaces correctly (affects: 4) (dups: 3) (heat: 42)" [Medium,Triaged] https://launchpad.net/bugs/882147
[19:39] <stgraber> *release targeted
[19:40] <skaet> gilir, okie,  please post an explicit warning in the channel during soft freeze  :)   which bug number?
[19:40] <stgraber> skaet: this is also annoying when doing things like "tail -f /var/log/syslog" in a livecd and it just doesn't work because of that bug
[19:42] <slangasek> hah, right, tail supports inotify these days
[19:43] <skaet> stgraber,  I've up'd the priority and marked it targetted to precise.
[19:44] <gilir> skaet, ok, will do it next time, there is no specific bug number, the seed was very outdated
[19:45] <skaet> gilir,  thanks.  ok,  putting it on the pad as such.
[19:45] <gilir> skaet, but it's not risky for lubuntu desktpop iso, there are currently badly broken, and I'm not even sure this upload will improve the situation :/
[19:46] <stgraber> skaet: thanks
[19:46] <slangasek> gilir: so you want desktop respin only, not alternates?
[19:47] <stgraber> slangasek: yeah, we discovered that at the release sprint when doing tail -f /var/log/syslog and wondering why syslog wasn't working in the live environment ;) when in fact it was "simply" inotify not working with overlayfs
[19:48]  * slangasek nods
[19:48] <gilir> slangasek, I'm checking the alternate right now, to see if it's necessary also
[19:48] <slangasek> stgraber: what was the upload just now to work around this?
[19:49] <stgraber> slangasek: ltsp for ltsp-live. A super-ugly hack ... after installing the packages needed for LTSP, I run "initctl reload-configuration" to have upstart manually scan /etc/init and for Network Manager, well ... I restart it completely ...
[19:50] <skaet> gilir,  ack.  The rebuild will be picking up [8] by the way.   Hopefully that will help to.o
[19:50] <gilir> skaet, thanks
[19:59] <skaet> stgraber,  can you confirm ltsp .2.16-0ubuntu14 should also fix bug 924897.  (I think so, but double checking...)
[19:59] <ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/924897
[20:01] <stgraber> skaet: yes, the second changelog entry is for that one. I looked at the bug list on LP and couldn't find it (as it was fix released) so didn't put the LP: # entry in changelog
[20:01] <skaet> slangasek, ^ This was [9] on the tracker.
[20:02] <skaet> stgraber,  probably should have the status changed back to Fix Committed - since it isn't really fixed.
[20:02] <skaet> yet. :)
[20:04] <stgraber> :)
[20:06] <skaet> slangasek, ^ same set we did for [9] will need to be redone for [12]  - at least these are nice and speedy.  ;)
[20:07] <slangasek> skaet: well, if it's ltsp-live, isn't it only edubuntu that's actually affected by the bug?
[20:08] <slangasek> we can respin to ensure the images are up to date of course, but it doesn't seem to impact on the releasability
[20:08]  * skaet going to check the backscroll - but thought it was wider impact... 
[20:08]  * skaet could be wrong though :)
[20:10] <slangasek> bug #924897 was already fixed in a previous upload and alternates already respun for it
[20:10] <ubot4> Launchpad bug 924897 in ltsp (Ubuntu Precise) (and 1 other project) "ltsp-build-client initial setup failed on i386 : Unable to locate package linux-image-generic (affects: 1) (heat: 6)" [High,Fix released] https://launchpad.net/bugs/924897
[20:10] <slangasek> stgraber: was the fix in -0ubuntu13 incomplete?
[20:10] <stgraber> slangasek: yes
[20:10] <skaet> slangasek, yes.  bug is in ltsp-build-client running in d-i when we don't have linux-image-generic on the media.
[20:11]  * skaet found what she wanted in the back scroll
[20:11] <slangasek> ok
[20:11] <slangasek> skaet: right, I hadn't seen that you'd stuck another bug # on [12] :)
[20:11] <stgraber> slangasek: the new LTSP requires Ubuntu Alternate and Edubuntu to be respin (nothing else as ltsp-live is Edubuntu specific and the non-PAE issue only affects Ubuntu Alternate, everything else has the kernel on the media)
[20:12] <slangasek> stgraber: does server have -generic on it?
[20:12] <stgraber> slangasek: I don't think so, but they don't have LTSP (LTSP requires a full desktop install)
[20:13] <skaet> slangasek,  :)  you'd removed [9] so seemed easier to add it there, since the fix for [12] referenced it.
[20:13]  * skaet wants time machine option on this pad... 
[20:13] <slangasek> stgraber: so the ltsp-client-builder package on the ubuntu-server CDs is... unrelated?  superfluous?
[20:15] <slangasek> stgraber: none of [kxl]ubuntu alternate have linux-image-generic on the i386 CD, and they do all have at least ltsp-client-builder
[20:15] <slangasek> are they not affected because they do the LTSP install via the network only?
[20:17] <skaet> slangasek,  issue is recovering from the fact that they don't have linux-image-generic on the image.  :)
[20:17] <skaet> those images that have it don't need the fix
[20:17] <skaet> (ie. dvd's were ok)
[20:17] <stgraber> slangasek: hmm, server having ltsp-client-builder sounds like a bug, there's no way that'd work (ltsp-client-builder forces ltsp-build-client to use the install media as source)
[20:17] <slangasek> yes, I understand
[20:18] <slangasek> stgraber: ok, so scratching ubuntu-server off the rebuild list.  How about the other?
[20:18] <slangasek> others
[20:18] <stgraber> slangasek: [kxl]ubuntu might be affected, I didn't know they actually had LTSP on them (I only test Ubuntu and Edubuntu). Would be worth checking if the LTSP option is visible in gfxboot for these, if not, the presence of ltsp-client-builder is a bug
[20:19] <slangasek> stgraber: I'll exclude them from the respins for now, then
[20:19] <stgraber> slangasek: ok. I have a local copy of all of them, I'll have a quick look in gfxboot to see which actually offer ltsp as an option
[20:20] <charlie-tca> Xubuntu can release note that the fix will be available in the daily image tomorrow
[20:20] <slangasek> charlie-tca: does an ltsp install work at all from Xubuntu CDs?
[20:20] <charlie-tca> not sure, I thought it was only desktop images
[20:21] <slangasek> I suspect then that there's no need to release something you're not QAing anyway
[20:21] <charlie-tca> slangasek: it is not something we actually test, but every once in a while a user does an ltsp install. That's when we find out if it is broken
[20:22] <stgraber> slangasek: kubuntu => not in gfxboot, xubuntu => in gfxboot, lubuntu => not in gfxboot
[20:22] <stgraber> slangasek: I also confirmed that it's not in gfxboot for ubuntu server
[20:23] <slangasek> stgraber: ok, thanks
[20:23] <slangasek> charlie-tca: so I won't respin xubuntu alternate for ltsp unless you insist :)
[20:23] <charlie-tca> Thank you. I would prefer we do NOT do it
[20:23] <stgraber> slangasek: so it looks like only Ubuntu and Xubuntu offer LTSP in their alternate install and Edubuntu is the only one offering it in a live install (it costs an extra 400MB so we're the only one who can afford it space wise ;))
[20:24] <slangasek> oh wait
[20:24] <slangasek> I misparsed!
[20:24] <slangasek> charlie-tca: so xubuntu *is* affected, but it's still release-notable if you prefer
[20:24] <charlie-tca> I think I told the last person trying that to go to server and ask how
[20:24] <charlie-tca> slangasek: we will release note it. Thanks
[20:25] <charlie-tca> If everything else works, we will be happy
[20:26] <stgraber> charlie-tca: Xubuntu should have someone who actively wants LTSP to work and can test/fix it and coordinate with upstream (#ltsp) or it should be dropped, I don't really have time to spend on testing/fixing it in Xubuntu and I doubt someone else in LTSP upstream does.
[20:27] <charlie-tca> I will bring that up to the powers that be, then. I don't care either way about LTSP, myself.
[20:27] <stgraber> charlie-tca: thanks
[20:27] <charlie-tca> stgraber: thank you for bringing it to my attention
[20:29] <stgraber> skaet: just so you know, I'm looking at bug 924836 which seems to affect any current system during first boot, making first boot time 90s slower, potential reason for a mass respin (I tested on Ubuntu but Kubuntu at least is also affected).
[20:29] <ubot4> Launchpad bug 924836 in network-manager (Ubuntu Precise) (and 3 other projects) "network-manager does not tell plymouth it has started (affects: 1) (heat: 8)" [High,Invalid] https://launchpad.net/bugs/924836
[20:30] <stgraber> slangasek: confirmed, it's /etc/network/if-up.d/000resolvconf failing to find /run/resolvconf/interface and blocking the other if-up.d scripts
[20:31] <slangasek> oh good, if it's only resolvconf then :P
[20:32] <slangasek> stgraber: will you follow through?
[20:32] <slangasek> hmm, why would that be only on first boot?
[20:32] <stgraber> slangasek: yeah, I'm continuing to investigate the exact source, /run/resolvconf doesn't exist at all on first boot ...
[20:32] <slangasek> hmm
[20:33] <stgraber> slangasek: and /var/lib/resolvconf/convert exists, so that means the upstart job never started (or failed pretty early)
[20:33]  * slangasek nods
[20:33] <stgraber> slangasek: right, resolvconf is "stop/waiting" and I don't have any log for it in /var/log/upstart
[20:34] <slangasek> odd
[20:35] <slangasek> is there something on first-boot that prevents mountall from running normally?
[20:35] <stgraber> slangasek: I don't get why it didn't start though, it's "start on mounted MOUNTPOINT=/run" that should definitely work
[20:35]  * slangasek nods
[20:35] <stgraber> slangasek: apparently yes "mountall: Event failed"
[20:35] <stgraber> slangasek: in /var/log/boot.log
[20:35] <slangasek> fun
[20:41] <stgraber> slangasek: I can also confirm that the second boot works fine
[20:42] <stgraber> actually, fine-ish, I still have the mountall "Event failed" in boot.log, but the boot no longer hangs
[20:42] <cjwatson> interaction with ureadahead profiling somehow, maybe?
[20:43] <stgraber> cjwatson: oh, good idea, yeah, it's "start on starting mountall", so a failure would be pretty bad. I'll try to flush the profile and see what happens
[20:45] <stgraber> hmm, doesn't seem to be it. I certainly regret not making a snapshot of the VM post install. Re-installing now to have that snapshot ...
[20:46] <stgraber> running a full diff of post-install / post-first-boot should explain what's going on
[20:53] <skaet> stgraber,  slangasek,  since the fallback mode (while slower) still works,  am thinking it might be best to look at this one opportunistically - ie. go ahead and upload, but we won't mandate a massive rebuild for A2, since thing seem to work in recovery mode.     Document it in release notes, and know the dailies will have it.
[20:54] <stgraber> skaet: well, apparently it's not just a matter of taking 90s to boot instead of 5s, a bunch of upstart jobs don't start, including resolvconf, so I'm not too sure you'd be able to resolv anything post-boot
[20:54] <stgraber> will know more once I found the source of the issue though
[20:55] <stgraber> (we could still release note that it'll take 90s to boot and you'll then need to reboot to have it working though)
[20:55] <skaet> stgraber,  ok,  standing by
[21:12] <slangasek> ubuntu alternate, edubuntu respin for ltsp going
[21:13]  * stgraber wonders why Ubiquity is "Importing documents and settings" and "Restoring previously installed packages" on a perfectly blank disk image ;)
[21:13] <slangasek> and lubuntu also going
[21:15] <jibel> verification failed for bug 924535
[21:15] <ubot4> Launchpad bug 924535 in casper (Ubuntu Precise) (and 1 other project) "desktop preseeded installation stops at user setup since build 20120131 (affects: 2) (dups: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/924535
[21:16] <slangasek> :/
[21:16] <slangasek> cjwatson: ^^ bug #924535 is still an issue, if you're still around
[21:16] <stgraber> doh, that boot hanging issue seems to be a racy ...
[21:19] <stgraber> ok, at least it showed up on the second boot try ;)
[21:27] <stgraber> Can someone with access to nusakan fix Ubuntu Studio mapping with the tracker?
[21:27] <stgraber> No iso.qa.ubuntu.com product found for ubuntustudio/dvd/precise-dvd-amd64; skipping.
[21:27] <stgraber> No iso.qa.ubuntu.com product found for ubuntustudio/dvd/precise-dvd-i386; skipping.
[21:27] <slangasek> stgraber: where is the mapping?
[21:29] <stgraber> slangasek: no idea, I don't have access to that part of the magic. It's whatever ends up calling post-images-to-iso-tracker.py
[21:31] <jibel> verification of bug 924752 failed
[21:31] <ubot4> Launchpad bug 924752 in wubi "wubi r255 - Ubuntu Desktop failed to install from disk image - wrong download url (affects: 1) (heat: 6)" [Critical,Fix released] https://launchpad.net/bugs/924752
[21:33] <slangasek> jibel: same error as before or not?
[21:33] <stgraber> slangasek: hmm, nothing interesting that I can find in the diff ... only difference in /etc are resolv.conf (simple change in content as NM starte), mtab and udev's 70-persistent-cd.rules...
[21:34] <slangasek> stgraber: why would you expect it to be a diff in /etc, though?\
[21:35] <jibel> slangasek, double-checking, the downloader returns a 403 but the url is correct and the file exists on the server
[21:37] <stgraber> slangasek: well, I was expecting "something" to show up in the diff between post-install and after the first boot... /var isn't particularly more interesting. A new entry in /var/cache/cups, the dbus UUID, a dhcp lease, NM's interface status, update-manager and update-notifier info on release and updates and the lightdm session files
[21:39] <slangasek> jibel: which url is it using?
[21:39] <slangasek> jibel: it's possibly a case of bad timing, since the wubi tarball was just updated on cdimage
[21:40] <slangasek> stgraber: well, but there would be /var/cache changes for ureadahead, too
[21:40] <slangasek> stgraber: but what about logs?
[21:41] <jibel> slangasek, false alarm. I used the wrong version of wubi. removing all wubi.exe from the drive and trying again.
[21:41] <jibel> 12.04 is downloading
[21:42] <slangasek> jibel: ok :)
[21:49] <stgraber> slangasek: definitely is a race ... got 10 good boots in a row (every time going back to the post-install disk), then started stressing my SSD with some I/Os (copying disk images around) and got the hang
[21:50] <slangasek> stgraber: that's 10 good first-boots from the snapshot?
[21:51] <stgraber> slangasek: yeah
[21:51]  * slangasek nods
[21:51] <slangasek> fwiw, I've just done a precise install test here... on the first boot I hit the "waiting for network" problem, and then on the second boot I see that NM has taken over /etc/resolv.conf.
[21:52] <slangasek> ah, no
[21:52] <slangasek> it's that /var/lib/resolvconf/convert is still present
[21:52] <slangasek> interesting
[21:53] <stgraber> oh, so resolvconf still hasn't started for you on the second boot ...
[21:53] <slangasek> correct
[21:53] <stgraber> slangasek: can you confirm the "mountall: Event failed" in /var/log/boot.log?
[21:53] <slangasek> yes
[21:54] <stgraber> I confirmed that manually doing "initctl emit mounted MOUNTPOINT=/run" works and fixes /etc/resolv.conf, now to understand why it doesn't do it at boot time...
[21:55] <stgraber> hmm, actually, stupid question, are we supposed to get that event when mountall itself doesn't actually mount it?
[21:56] <slangasek> oh, I really hope so :P
[21:57] <stgraber> ok, time for mountall --debug I guess
[21:57] <cjwatson> slangasek: argh, I tested that :(
[21:59] <stgraber> slangasek: if it doesn't emit mounted MOUNTPOINT for already mounted mount points, that "may" be my fault (with the code to ensure mountall doesn't hide an existing mount point)
[22:00] <cjwatson> slangasek: I'll be around in a bit to have a look
[22:00] <slangasek> cjwatson: ok, thanks
[22:03] <cjwatson> jibel: if you're still here, it would be helpful to know what debconf question you're using to preseed the password
[22:04] <cjwatson> jibel: I thought you were using passwd/user-password-crypted or however it's spelled, but it's just occurred to me that you might be using the non-crypted version
[22:04] <cjwatson> which is overwritten as a side-effect of user-setup-apply ...
[22:04] <jibel> cjwatson, d-i passwd/user-password and d-i passwd/user-password-again
[22:05] <cjwatson> damn, I should have asked
[22:05] <slangasek> stgraber: mountall definitely emits events for all filesystems, even those it didn't mount
[22:05] <slangasek> (all filesystems listed in /etc/fstab or /lib/init/fstab, that is)
[22:05] <cjwatson> ok, that's an easy fix in casper, just add those to the debconf_backup and debconf_restore calls
[22:06] <stgraber> slangasek: good, so I didn't break it, still doesn't explain what's going on ... resolvconf should start or fail but either way I should have a log file for it ...
[22:10] <slangasek> stgraber: oh blast
[22:10] <slangasek> stgraber: /run is always mounted BEFORE / IS WRITABLE
[22:10]  * slangasek facepalms
[22:11] <stgraber> slangasek: oh, yeah, that would be a problem indeed ;)
[22:12] <jibel> cjwatson, I can change to -crypted and release note it for a2
[22:13] <jibel> I asked the cert team to verify it works with their tests
[22:15] <stgraber> slangasek: so just changing resolvconf to "start on mounted MOUNTPOINT=/ and mounted MOUNTPOINT=/run" should do the trick
[22:15] <slangasek> no
[22:15] <slangasek> not at all
[22:15] <stgraber> oh right, because mountall will emit mounted for / even though it's ro ...
[22:15] <slangasek> the whole idea of using a stamp file for /etc/resolv.conf linking needs to be scrapped
[22:15] <slangasek> no
[22:15] <cjwatson> jibel: I guess that depends - if we're going to have to rebuild for this resolvconf thing anyway (which I've only peripherally been following so may be talking out my hat) then casper is an easy ride-along
[22:16] <slangasek> the problem is that we need to *block the boot* while getting /etc/resolv.conf in place
[22:16] <cjwatson> backing up / restoring a couple extra questions isn't going to make it worse
[22:16] <slangasek> so since we can't do that reliably if we have to write to /, we instead need to ensure /etc/resolv.conf linkage is done at package install time, not at boot time
[22:18] <stgraber> which gets us back to how to do that without breaking chroots
[22:18] <stgraber> oh, actually there's a way I didn't consider that should fix chroots ... simply move /etc/resolv.conf to /run/resolvconf/resolv.conf, then make the symlink
[22:19] <stgraber> on a regular system, it'll be wiped (as it's on tmpfs) and generated by resolvconf, but for chroots, /run is just a directory like any other, so it'll stay there and work just like a regular /etc/resolv.conf
[22:21] <stgraber> slangasek: does that make sense or did I forget something (sounds too easy)?
[22:25] <slangasek> stgraber: were chroots the justification for this change?  I was just working on understanding that
[22:26] <slangasek> bug #922578
[22:26] <ubot4> Launchpad bug 922578 in resolvconf (Ubuntu) "please remove 'resolvconf' from ubuntu-minimal Depends (affects: 1) (heat: 6)" [High,Opinion] https://launchpad.net/bugs/922578
[22:26] <slangasek> oh, with the descriptive bug title, right :P
[22:27] <stgraber> slangasek: right, that was the reason for the change, that bug and report from apw and tgardner that schroot was no longer working for a similar reason
[22:27] <slangasek> stgraber: I thought the chroot problems were that, if /etc/resolv.conf was a symlink at all inside the chroot, things fail because they want to do a cp
[22:28] <stgraber> slangasek: hmm, the bit with the cp is schroot and indeed it'll fail if we make it a symlink ... unless we make it a relative symlink
[22:28] <slangasek> heh
[22:28] <stgraber> otherwise schroot's cp will try to override the /run/resolvconf/resolv.conf outside of the container
[22:28] <stgraber> which will work in some cases (but not do what we want) and fail in others
[22:28] <slangasek> technically a policy violation, but if either /etc or /run is itself a symlink, thbbt
[22:30] <slangasek> stgraber: I want to think on this some more; I don't think this is anything we should try to change for alpha-2, the risk is too high
[22:30] <slangasek> but a relative symlink might be ok
[22:30] <stgraber> having postinst, copy /etc/resolv.conf to /run/resolvconf/resolv.conf and make /etc/resolv.conf a relative symlink to ../run/resolvconf/resolv.conf sounds like it'd do what we want (except for respecting policy)
[22:32] <stgraber> slangasek: yeah, I agree it's risky. How would we release note it? "run 'sudo start resolvconf' after first boot, then reboot"?
[22:33] <slangasek> that sounds good to me
[22:33] <cjwatson> so should I hold off on the casper change too?
[22:34] <cjwatson> if I'm not going to get to ride along with something else
[22:35] <slangasek> cjwatson: I thought the casper change was a blocker for actually doing the milestone validation?
[22:35] <cjwatson> there exists a workaround by using the keys that contain pre-crypted passwords
[22:36] <cjwatson> which is unnecessary in an insecure environment like this, but would work around this bug
[22:36] <cjwatson> the fix is almost certainly http://paste.ubuntu.com/825741/ FWIW
[22:36] <slangasek> ah, right, got that from scrollback now
[22:36] <slangasek> cjwatson: I think I'd like to have the casper upload anyway, so that any other respins that come up benefit from it
[22:37] <cjwatson> OK, I'm just testing it
[22:38] <cjwatson> ... and once again I'm tempted to shove nano in the initramfs
[22:38] <cjwatson> cp -a /scripts/casper-bottom/25adduser /root/tmp/ && chroot /root vi /tmp/25adduser && cp -a /root/tmp/25adduser /scripts/casper-bottom/ # sigh
[22:39] <stgraber> slangasek: actually resolvconf's postinst already does the cp to /run/resolvconf/resolv.conf. So the only problem was that the symlink wasn't relative.
[22:39] <slangasek> stgraber: well, that and the problem that the symlinking has been moved out of the postinst to a bit of upstart job that never runs ;)
[22:39] <stgraber> cjwatson: IIRC you can call /root/usr/bin/vim.tiny without a chroot call, so without doing the cp magic (it complains but still mostly works)
[22:39] <cjwatson> stgraber: mm, yeah, sometimes I remember that
[22:40] <cjwatson> but still it's annoying :)
[22:40] <cjwatson> I think it might need LD_LIBRARY_PATH ...
[22:40] <cjwatson> (at least in principle)
[22:40] <stgraber> slangasek: yeah, the new postinst needs to check for /var/lib/resolvconf/convert, remove it and reset the debconf key
[22:41] <slangasek> yes to the first two parts; are we already resetting the debconf key right now?
[22:42] <slangasek> stgraber: btw, I don't find any mention of post-images-to-iso-tracker.py in cdimage
[22:43] <cjwatson> slangasek: debconf key> is that directed to me or stgraber?
[22:43] <slangasek> cjwatson: stgraber
[22:43] <cjwatson> slangasek: bin/post-qa - might only be in the deployment branch
[22:43] <cjwatson> also s/images/image/
[22:43] <slangasek> aha
[22:43] <cjwatson> you wanted an ubuntustudio thing fixed?  I can do that now
[22:43] <slangasek> hence my grep fail :)
[22:43] <slangasek> cjwatson: yes please
[22:43] <cjwatson> it was my oversight anyway
[22:44] <cjwatson> what's the product name?
[22:44] <cjwatson> "Ubuntu Studio DVD {amd64,i386}"?
[22:44] <stgraber> slangasek: http://paste.ubuntu.com/825747/
[22:45] <stgraber> cjwatson: yes
[22:46] <cjwatson> stgraber,slangasek: post-qa fixed - I haven't posted anything current though, not up to date on the state of the tracker
[22:47] <slangasek> cjwatson: I think stgraber already updated the tracker
[22:47] <cjwatson> slangasek: casper 1.304 uploaded
[22:47] <slangasek> ta
[22:47] <cjwatson> ok
[22:49] <slangasek> stgraber: I would've just done if [ "$RET" = "true" ] || [ -e /var/lib/resolvconf/convert ]; then
[22:49] <stgraber> slangasek: http://paste.ubuntu.com/825753/ is the delta from ubuntu4 (last version with the link being created in the postinst)
[22:50] <slangasek> stgraber: then there's no additional messing with debconf, and we just need to rm -f /var/lib/resolvconf/convert
[22:50] <slangasek> but either way works
[22:50] <stgraber> slangasek: indeed, then wipe the directory (as it no longer exists in the new package)
[22:50] <slangasek> yes, that looks sane
[22:50]  * slangasek nods
[22:50] <slangasek> rm -rf /var/lib/resolvconf, in that case
[22:54] <stgraber> slangasek: http://paste.ubuntu.com/825759/ (still from ubuntu4)
[22:56] <slangasek> stgraber: lgtm - possibly also add a note that this transitional code can be dropped after, say, beta-2?
[22:56] <slangasek> or maybe just after precise release
[22:56] <slangasek> stgraber: also, please double-check that /etc/resolvconf/update.d/libc's readlink works with the new target
[23:03] <stgraber> slangasek: http://paste.ubuntu.com/825766/
[23:03] <stgraber> (went with readlink -m)
[23:22] <GrueMaster> Can someone verify the md5sums at  http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20120201
[23:23] <slangasek> stgraber: right, lgtm then
[23:24] <slangasek> 2f73545a5bc65f3d2fd5cbf1c9ba4444  kubuntu/daily-preinstalled/20120201/precise-preinstalled-desktop-armel+omap4.img.gz
[23:24] <slangasek> 0911bead4e5721a04d59cddb4bab3e50  kubuntu/daily-preinstalled/20120201/precise-preinstalled-desktop-armel+omap.img.gz
[23:24] <slangasek> GrueMaster: ^^
[23:25] <stgraber> slangasek: good, I'll keep it around and upload tomorrow then
[23:25] <GrueMaster> Yea, I get the same when running md5sum on the images.  the MD5SUMS file must be old.
[23:25] <slangasek> GrueMaster: yeah, I think cjwatson was addressing this earlier, but the scripts haven't been run since
[23:25] <slangasek> stgraber: can you push that change to bzr today?  I might wind up poking at a few other things
[23:25] <slangasek> and I'd rather this be committed first
[23:26] <GrueMaster> ok.  I won't worry then and will test these images when I return (have to step out for a bit).  Almost all other images have now been tested on arm.
[23:26] <GrueMaster> barring an arm respin (shudder).
[23:26] <stgraber> slangasek: sure
[23:28] <cjwatson> I didn't notice a problem with .img.gz files
[23:28] <cjwatson> let me check
[23:28] <stgraber> slangasek: pushed
[23:29] <slangasek> cjwatson: ah, that as just bootimg before, right
[23:29] <cjwatson> yeah
[23:29] <slangasek> stgraber: tah
[23:29] <slangasek> ta
[23:29] <GrueMaster> cjwatson: The images seem ok, just no way to ensure they are the right images.
[23:29] <cjwatson> sure
[23:29] <cjwatson> I understand the need for checksums :-)
[23:34] <cjwatson> GrueMaster: I think that's fixed now.  Thanks for the report.  If this recurs I definitely want to know about it because that means my previous fix was busted.
[23:34] <cjwatson> (Or incomplete.)
[23:35] <GrueMaster> Ok.  I can't make any promises, as I don't normally check the kubuntu images.
[23:36] <GrueMaster> But I'll check next week when the dailies are turned back on.
[23:36] <cjwatson> Yeah, I won't hold you to auditing our checksums ...
[23:51] <cjwatson> stgraber: why doesn't isotracker_xmlrpc understand the "Precise Alpha 2" milestone?
[23:51] <cjwatson> I've tried fiddling around with various parameters to isotracker.drupal.qatracker.milestones.get_list and can't make it return it
[23:52] <cjwatson> >>> [m["title"] for m in isotracker.drupal.qatracker.milestones.get_list(range(1000)) if "Precise" in m["title"]]
[23:52] <cjwatson> ['Precise Alpha 1', 'Precise Daily']
[23:54] <cjwatson> stgraber: ah, never mind, ~/.isotracker.conf on my laptop is still configured to your old testing tracker :)
[23:54] <stgraber> cjwatson: I was just about to suggest that ;)
[23:54] <cjwatson> much better now