[00:39] <hggdh> crap again. Second install of MAAS on amd64 seems to fail
[00:49] <hggdh> skaet, plars: http://launchpad.net/bugs/1066421 utter failure on MAAS install, AMD64, server
[00:49] <ubot2> Launchpad bug 1066421 in maas "fresh MAAS install from ISO fails when opening the MAAS URL" [Undecided,New]
[00:55] <slangasek> ScottK: mmh, cjwatson managed to extract the codename from him but we're apparently still waiting for the announcement
[00:55] <slangasek> stgraber: ok; it would be helpful if you could test the server install under SB since I'm not able to, but if you can't you can't
[00:55] <slangasek> stgraber: thanks for the bug report
[00:59] <slangasek> skaet, stgraber: so I've targeted the grub bug to quantal, because we should fix it for 12.10; the question is whether it should be post-release or not.  I'm having a look now at whether this impacts the installer's grub.cfg - it may well not
[01:03] <slangasek> stgraber, skaet, infinity: this bug doesn't affect the media, only the grub.cfg generated by update-grub; so I agree this is release-notable and have targeted to quantal-updates.  Will accept debian-installer now.
[01:09] <slangasek> skaet: I believe the grub2 -> debian-installer -> debian-cd dependencies related to boot mean that we should be respinning all our bootable images to make sure they're up-to-date.  Should we do that sooner rather than later?
[01:10] <skaet> slangasek, sooner rather than later would definitely be the preference.
[01:10] <slangasek> ok.  should I queue up the builds then?
[01:10]  * slangasek checks the pad for other targets of opportunity
[01:11] <skaet> slangasek, update the pad, and go ahead.    I'll update the tracker.
[01:17] <slangasek> skaet: pad updated, build triggers set
[01:19] <skaet> slangasek, iso tracker has everything except cloud images and wubi now marked for rebuilding.
[01:19] <slangasek> skaet: you targeted bug #1065686 to quantal-updates but it's still on the pad as an "opportunity target" - do we know where PS is with this?
[01:19] <ubot2> Launchpad bug 1065686 in unity-scope-video-remote "remote video scope doesn't full switch off traffic when privacy option switched on" [High,In progress] https://launchpad.net/bugs/1065686
[01:19] <skaet> go ahdead and start it off if you've got it up.
[01:19] <slangasek> skaet: wubi is being rebuilt.  core is not.
[01:19]  * skaet fixes core to indicate as such
[01:19] <slangasek> oh, let me think; maybe wubi doesn't need a rebuild either
[01:20] <skaet> slangasek, won't wubi need the rebuild once we get the certificates sorted
[01:20] <slangasek> yes
[01:20] <skaet> so, doesn't seem much point in spinning it now.
[01:20] <slangasek> but I need to see how it gets its bootloader and whether it's affected by this d-i change
[01:20] <skaet> ok
[01:21] <slangasek> hmmm, I don't think wubi is affected; dropping it from my respin pipeline
[01:21] <skaet> ok
[01:22] <skaet> re: PS,  they've got a fix, but its probably tied in with other ones which we don't really want to pick up.
[01:23] <skaet> go ahead without it,  but leave that one on the pad as an opportunity target if we can get a cherry picked update from them.
[01:23] <plars> skaet: I added https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376 - keyboard doesn't work to enter password with panda and encrypted partitions under the investigation section, I believe infinity is looking into it but it could be worked around with serial
[01:23] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
[01:23] <slangasek> skaet: well, unless we're specifically pressing them for a cherry-picked update, I don't imagine we'll see one
[01:23] <slangasek> anyway - pipelines are all queued up and I'm heading out for the evening
[01:24] <slangasek> skaet, infinity: if something comes up before the pipes kick off (in ~1h) and you need to cancel them, it's 'killall -9 wait-for-package' on nusakan
[01:24] <skaet> slangasek,  agreed.   kick'em off
[01:24] <skaet> why the delay?
[01:25]  * skaet figures PS is unlikely to be ready in next hour.
[01:25] <skaet> slangasek,  my understanding is that infinity is traveling now,  so won't be online for a while.
[01:31] <slangasek> oh, it is about that time, isn't it
[01:32] <slangasek> skaet: the delay is because we can't rebuild images for the updated d-i until the updated d-i is published...
[01:32] <skaet> slangasek,  gotcha.
[01:33] <skaet> plars, ok.  we'll release note it if necessary.
[02:02] <skaet> :)
[02:06] <len-dt> skaet, would it be possible to get a ubuntustudio respin?
[02:07] <len-dt> (after the above is approved..
[02:15] <skaet> len-dt
[02:15] <len-dt> ay
[02:15] <skaet> there's a respin queue'd up now.
[02:15] <skaet> I'll go in and review the ubuntustudio-meta,  and hopefully it will make it in time.
[02:15] <len-dt> ok, will the meta package above make it in?
[02:15] <micahg> skaet: respin is useless without the new meta
[02:16] <skaet> micahg,  slangasek already queued up the respin,  its started now
[02:16] <skaet> it may need another to pick up the ubuntustudio-meta though due to timing,  that's all
[02:17] <len-dt> OK.
[02:17] <skaet> len-dt, micahg - package looks ok.  it's approved
[02:18] <skaet> not sure if it will build in time or not for the respin.
[02:19] <skaet> if its not included in the next set of images, ping on this channel and one of the release team will kick off the respin to pick it up.
[02:19] <len-dt> will do, I'll test it tonight (PDT -700)
[02:19] <skaet> thanks
[02:19] <len-dt> NP
[05:23] <slangasek> hmm, why has the debian-installer publication not made it out to nusakan yet :P
[05:23] <slangasek> so the builds haven't started yet, because the trigger has thus far failed
[05:23] <slangasek> so good news for ubuntustudio, I guess
[05:24] <slangasek> because there was a stale lock file, sigh
[05:25] <slangasek> ok, image builds starting now
[05:37] <ScottK> I guess that answers the question about if I should stay up and wait for a fresh build to do more testing tonight.
[05:37] <slangasek> apparently
[05:37] <slangasek> sorry :/
[05:42] <ScottK> No problem.  Sleep is for the best anyway.
[08:10] <stgraber> slangasek: ok, I'll figure some way of doing a server install on that laptop later today or (more likely) tomorrow.
[08:19] <xnox> slangasek: maybe we do have a couple ubiquity bugs: bug 1066347 bug 1066302 bug 1065502
[08:19] <ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
[08:19] <ubot2> Launchpad bug 1066302 in ubiquity "'update this installer' link on the welcome page shows no response to a mouse click" [High,Confirmed] https://launchpad.net/bugs/1066302
[08:19] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[08:21] <xnox> the middle one is funny... as the update this installer shouldn't be shown at all, because we did not trigger 0day ubiquity update.
[08:33] <cjwatson> slangasek: keystatus and loadenv are simple and should be fine - adding those now.  I'm less sanguine about tftp; would rather do that at a bit more leisure.
[08:39] <cjwatson> ^- cloud fix + secure boot fix.  The former at least needs a quick regression-test on real BIOS as well
[08:46] <jibel> slangasek, there are 2 bugs that are important when installing over an existing installation bug 1065502 and bug 1066347
[08:46] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[08:46] <ubot2> Launchpad bug 1066347 in ubiquity ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [High,Confirmed] https://launchpad.net/bugs/1066347
[08:47] <jibel> first one hangs the installer, second breaks the 'reinstall' functionality
=== yofel_ is now known as yofel
[12:30] <xnox> cjwatson: doesn't loadenv -> reads & loads stuff from hard-drive & hence could be altered while machine is off leading to possibly doing something to bypass secure-boot or inject something?!
[12:35] <jibel> I reproduced bug 1066445 - fresh desktop installation with latest amd64 image
[12:35] <ubot2> Launchpad bug 1066445 in apt "Crashes doing update or upgrade operations" [Critical,Confirmed] https://launchpad.net/bugs/1066445
[12:53] <ScottK> The massif-visualizer uploadis mine, so I can't accept it.  Should be an easy one for someone to review.
=== doko_ is now known as doko
[14:53] <cjwatson> xnox: It reads environment variable settings, but that shouldn't let you execute arbitrary code before ExitBootServices.
[14:54] <cjwatson> doko: Your cairo-5c sync FTBFS ...
[14:56] <cjwatson> ScottK: Accepted.  You can close bug 935294, I think.
[14:56] <ubot2> Launchpad bug 935294 in massif-visualizer "massif-visualizer version 0.3-0ubuntu1 FTBFS on armhf in precise" [High,Confirmed] https://launchpad.net/bugs/935294
[15:00] <cjwatson> xnox: Also, note that "arbitrary code" in this context specifically excludes being able to run arbitrary GRUB commands; we already know you can do that and the system is structured so that that should not be a problem.  It would only be a problem if you could somehow arrange to run arbitrary code which is not already exposed as commands.
[15:00] <cjwatson> xnox: Remember that we *already* load /boot/grub/grub.cfg from the hard disk.
[15:19] <skaet> cjwatson,  would you mind turning off image erasing?   we're starting to stradle multiple days now and the historical ones may be useful.
[15:19] <skaet> (testing against at any rate)
[15:19] <cjwatson> done
[15:19] <hggdh> anyone confirmedhttps://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 ?
[15:19] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,New]
[15:19] <cjwatson> (not available for most of rest of today)
[15:21] <skaet> thanks cjwatson
[16:02] <ScottK> cjwatson: Thanks.  Forgot about the bug.
[16:03] <hggdh> why is 'ubuntu' considered a weak password for an user, and a fair password for disk encryption?
[16:27] <skaet> ScottK, stgraber, slangasek, infinity -  can one of you take a look at https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1066445?   we may need to revert that last apt upload.
[16:27] <ubot2> Launchpad bug 1066445 in apt "apt-get crashed with SIGSEGV in pkgCacheGenerator::ListParser::NewProvides()" [Critical,Confirmed]
[16:29] <hggdh> skaet: is https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480 important enough?
[16:29] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Undecided,Confirmed]
[16:32] <skaet> hggdh,  ugh.   not recognizing there's data there isn't good.  :P
[16:32] <hggdh> my thought also... adding to the pad
[16:33] <skaet> am marking it critical for now.   slangasek may modify that - but want it looked at as soon as possible.
[16:34] <hggdh> pad-added
[16:37] <hggdh> skaet: I cannot reproduce 1066445, and I do have main, universe, multiverse, partners in the source.list
[16:41] <skaet> hggdh,  interesting.    update from fresh install of precise?
[16:41] <skaet> what did you start from?
[16:54] <hggdh> skaet: I was already on quantal. I think this may be the difference
[16:55] <hggdh> I can try from precise
[17:00] <doko> cjwatson, known (as it was ftbfs before too), this was just for cleaning up the source package.
[17:04] <jibel> skaet, it is not reproducible on every system. I haven't found a pattern yet but got it on hardware and VM, fresh installation, all amd64
[17:04] <jibel> (re. 1066445)
[17:06] <hggdh> jibel: were you upgrading?
[17:10] <jibel> hggdh, no, right after a fresh installation
[17:14] <hggdh> ok so I am without a failure indeed
[17:20] <infinity> cjwatson: Accepted grub2, and uploaded a grub2-signed to go with it.
[17:20] <infinity> (If anyone else wants to let the -signed through...)
[17:21] <xnox> hggdh: actually both passwords use the same algo, so actually passwords should be reported as "the same strengthness"
[17:21] <hggdh> xnox: somehow they are still shown as fair and weak. So... bug on it
[17:22] <xnox> cjwatson: ok, thanks for explanation.
[17:25] <xnox> about bug 1066480. There is currently no UI to activate encrypted partitions (but partman can do it) but the other thing is that there is no ui nor partman functionality to de-activate encrypted partitions, which maybe desired for wipe & reinstall. Maybe we need to release note it.
[17:25] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480
[17:32] <hggdh> xnox: and, on a server install, both passwords are shown as 'weak'
[17:32] <xnox> hggdh: yes file bug. ubiquity != server cd. Ubiquity and debian-installer use different algorithms.
[17:33] <hggdh> ack
[17:33] <hggdh> will repeat to capture the data (original install is long gone)
[17:39] <phillw> infinity: could you take a look at bug 1066435 thanks
[17:39] <ubot2> Launchpad bug 1066435 in debian-installer "Debian-installer powerpc recursive fault" [Undecided,Confirmed] https://launchpad.net/bugs/1066435
[17:43] <skaet> infinity, accepted grub2-signed
[17:58] <skaet> lamont,  jibel saw the failure on hardware and VM,  fresh installation,  all amd64.  hggdh hasn't been able to see it though.   what are the specifics of the system you saw 1066445 on?
[18:01] <lamont> skaet: I'd have to dig a bit, but I'm pretty sure this was an install from this year, call it precise, amd64, real hw.  do-release-upgraded to quantal at beta(1?), and dist-upgraded pretty much daily since then.  has quantal{,-{security,updates}} {main,universe,multiverse} (I should add restricted...sigh), as well as a ppa or 2
[18:01] <lamont> and a local arhcive
[18:01] <lamont> the mirror I hit is synced from us.archive at :50 each hour
[18:02] <skaet> thanks lamont, can you add that to the bug, so we see if we can get the pattern figured out?
[18:02] <lamont> sure
[18:02] <skaet> hggdh - can you add the details of the configurations you've tried that work to it as well?   would like to get as much of the data summarized in one place as possible.
[18:02] <skaet> thanks lamont
[18:07] <lamont> posted, with spell checking, even
[18:12] <skaet> :)
[18:29] <hggdh> skaet: added. I do get it with main, universe enabled
[18:29] <skaet> thanks hggdh
[18:35] <slangasek> cjwatson: tftp> ack :)
[18:35] <slangasek> cjwatson: there's no hurry, I'm still trying to prove to myself that I can actually get a working system using tftp
[18:37] <lamont> slangasek: working how?
[18:37] <slangasek> xnox: I was asking specifically about the bug that jibel said was still present after you fixed it... was that bug #1065502?
[18:37] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[18:37] <slangasek> lamont: grub2 efi tftp
[18:37] <lamont> ah
[18:37] <lamont> that fails on my caring-scale
[18:37] <slangasek> lamont: with grub.cfg and kernel all loaded via tftp from grub, not bundled in a memdisk
[18:38] <lamont> at least for the moment
[18:38] <xnox> slangasek: it's a newly introduced bug, but has similar symptoms.
[18:38] <slangasek> xnox: hmm, ok
[18:38] <xnox> slangasek: the root cause is unclean unmounting of the /target resulting with "journal replay required" on first mount.
[18:39] <xnox> slangasek: which is cleared if you at least boot your system once, but not fine if you don't.
[18:39] <slangasek> xnox: ah; so this is only a problem for people who are serial installers?
[18:39] <xnox> it needs to be digged into why we are leaving the filesystem dirty at the end.
[18:39] <xnox> =)))))))
[18:39] <xnox> yes.
[18:40] <xnox> or force power-cycle shutdowners.
[18:40] <slangasek> xnox: then that shouldn't justify a respin on its own if that's the worst of the symptoms.  Unclean unmounting is obviously not good though, so please chase it up
[18:40] <xnox> ack. ok.
[18:47] <slangasek> skaet: the latest upload of apt only pulls in translation updates.  whatever this bug is, there's nothing to suggest it's tied to the latest upload (and therefore there's nothing to revert), nor evidence that it's widespread.
[18:48] <slangasek> skaet: well, modulo the fact that jibel and lamont both mention in scrollback that they're seeing it.
[18:49] <slangasek> skaet: anyway, the fact that a revert doesn't help still stands
[19:10] <jibel> slangasek, I have an easy test case for the apt bug: default install with free software enabled. Then all apps that depends on libapt will crash.
[19:10] <slangasek> jibel: except hggdh says he couldn't reproduce it?
[19:12] <jibel> slangasek, he said he did in comments 13 and 14
[19:12] <slangasek> ah, ok
[19:13] <slangasek> jibel: could you attach the sources.list (+sources.list.d) from this system?  may help to reproduce it more quickly
[19:13] <slangasek> also, the /var/cache/apt/pkgcache.bin that I asked for in the last comment
[19:20] <jibel> slangasek, it's uploading
=== Ursinha-afk is now known as Ursinha
=== rsalveti_ is now known as rsalveti
[19:23] <jibel> removing the cache files does just make apt crash later when it recreates them.
[19:31] <skaet> slangasek,   that was my understanding too, however the timing does seem a bit suspect.
[19:32] <skaet> however,  finding root cause is the key at this point.
[19:32] <jibel> slangasek, done uploading, it's enough to copy the sources.list file attached to the bug report to an existing system to reproduce the crash.
[19:58] <hggdh> skaet: bug 1066556 should be either looked at, or release-noted. Which one?
[19:58] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS install via d-i/tasksel fails whe opening the browser to /MAAS" [Undecided,New] https://launchpad.net/bugs/1066556
[20:38] <cjwatson> server team should look at that
[20:39] <cjwatson> skaet: if the timing of the apt upload is relevant, then since there are no source changes other than translations, it must be because *any* upload (and hence recompile) would have broken it; and therefore a revert won't help
[20:39] <cjwatson> but it could be something to do with the content of the Packages/Sources files
[20:41] <cjwatson> infinity: Thanks.  I was going to fiddle with grub2-signed to make sure it fetches binaries from -proposed - I suspect it might fail to build until grub2 hits release (which it probably shouldn't)
[20:41] <cjwatson> I'll sort that out tomorrow morning if nobody else has
[20:58] <cjwatson> Yeah, I can reproduce this with jibel's sources.list, though not with what I had in my sbuild chroots
[21:00] <skaet> cjwatson,  understand.
[21:01]  * cjwatson attempts a debug build
[21:15] <cjwatson> oh, for crying out loud, goes away when I try to debug it
[21:16] <cjwatson> I suppose that's to be expected for something introduced by a no-relevant-changes upload
[21:18] <cjwatson> oh, I forgot to put the relevant sources.list in place, whoops
[21:24] <cjwatson> OK, reproduced with a debug build now, which'll help
[21:28] <cjwatson> And under valgrind
[21:28] <cjwatson> (But not desperately helpfully)
[21:30] <cjwatson> God I hate C++
[21:38] <cjwatson> And it's all tied up in the cacheiterators stuff which I've never really understood at the best of times
[21:38] <cjwatson> Overly-clever Jason C++
[22:14] <cjwatson> Ah - well, it'll take me a bit longer to actually fix it, but I've tracked it down to excruciatingly unlucky timing of cache remapping in a function unequipped to handle it
[22:15] <cjwatson> So yeah, pretty sure reverting apt will make no difference worth mentioning
[22:16] <cjwatson> Unfortunately there may be a hard-to-resolve upgrade problem with old versions of apt; don't know what we can do about that short of (a) randomly permute size of cache by continuing normal development (b) SRU whatever fix we come up with
[22:16] <cjwatson> And possibly (c) release-note instructions for manually installing new apt
[22:33]  * cjwatson gets a feel for the pattern of working code now
[22:35] <skaet> cjwatson,  thanks for tracking that down.   Release noting is probably prudent based on the scenario you describe.
[22:37] <cjwatson> Fairly sure http://paste.ubuntu.com/1280162/ is the fix, or something very like it
[22:38] <cjwatson> The problem was that Prv->ProvideVersion was evaluated before the function assigning to it, which, in some very rare cases, changes Prv
[22:39] <cjwatson> skaet: would you mind setting up a release notes task on that bug?  I haven't kept track of the current method for doing that
[22:43] <skaet> cjwatson, will do.
[22:44] <cjwatson> thanks
[23:09] <skaet> cjwatson, release note task added, and have gone ahead and put bug and instructions on doing the manual update in the CommonInfrastructure  known issues section.
[23:10] <cjwatson> apt fix on its way to -proposed now - please review.  Sorry for the giant po/ diff but I believe it's all just trivial line number changes and other similar rearrangements.  The previous uploader mustn't have used 'bzr bd -S', I guess.
[23:11] <cjwatson> skaet: Yeah, that won't work :)
[23:11] <cjwatson> If 'apt-get install apt' worked this wouldn't be hard
[23:12] <skaet> cjwatson,  ah well, I hoped.   Adjust as needed.
[23:12] <cjwatson> reverted to an XXX comment for now
[23:13] <skaet> k
[23:16] <cjwatson> Oh, thinking about it, I bet fiddling with APT::Cache-Start would work around it
[23:16] <cjwatson> Too tired to write coherent release notes at the moment but let me quickly test that before bed while the problem is still reproducible
[23:26] <cjwatson> Right, yeah, that worked fine.  Workaround in the bug now.