[02:23] <micahg> that's me fiddling with backports
[02:26] <micahg> if someone has time to review ubuntustudio-default-settings/resping ubuntustudio after it builds, that would be rgeat
[02:31] <ScottK> micahg: Is that really an RC issue to respin for?
[02:32] <micahg> ScottK: the file is copied on install, so yes (I asked them to document the info in the bug)
[02:33] <ScottK> OK.  Based on the bug, I agree.  I'll accept it, but I can't do the respin.
[02:33] <micahg> ok
[02:34]  * micahg wishes there was a better way to handle these $HOME files, but that usually ends up in crazy migration scripts that are prone to error
[02:34] <ScottK> Right.
[02:34] <micahg> ScottK: thanks
[02:35]  * micahg disappears again
[02:35]  * micahg should probably add it to the pad first
[02:38] <micahg> pad updating, really gone now
[02:38] <micahg> *updated
[03:12] <slangasek> micahg, ScottK: ubuntustudio build queued pending ubuntustudio-default-settings_0.39 publication
[03:12] <ScottK> slangasek: Thanks.
[03:45] <slangasek> cjwatson, xnox: dunno if bug #1066653 rings any bells; doesn't smell RC to me, but maybe we want to release note it
[03:45] <ubot2> Launchpad bug 1066653 in ubiquity ""reinstall Ubuntu 12.10" on efi system fails when trying to mount /boot/efi" [Undecided,New] https://launchpad.net/bugs/1066653
[07:27] <stgraber> good morning
[07:27] <stgraber> I'm grabbing an up to date server image to do a secure boot test install for slangasek so I'll be off for 30min or so while it installs (only have one machine with me)
[08:09] <stgraber> slangasek: I checked and I'm indeed running efifb under d-i
[08:17] <infinity> stgraber: Of course, there's a new grub2 that will require another round of respins and testing.  But if the bugs fixed there don't affect you, all good.
[08:24] <xnox> slangasek: do you want to add UEFI hooks to the ubiquity apport collection? e.g. efibootmgr --verbose (if available)
[08:24] <xnox> ?
[08:40] <stgraber> cjwatson: is it expected that the server image doesn't have (or can't find) the intel wireless firmware (iwlwifi-6000-*.ucode)?
[08:50] <xnox> skaet: slangasek: I believe bug 1066480 is a dupe of bug 1046779 which has my comments there.
[08:50] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480
[08:50] <ubot2> Launchpad bug 1046779 in ubiquity "No option to resize full-disk encrypted installations" [Undecided,Won't fix] https://launchpad.net/bugs/1046779
[08:53] <stgraber> infinity: the current grub "works" for me (where "works" means I get a 30s delay every boot because of the missing two modules)
[08:53] <stgraber> infinity: I believe slangasek just wanted someone to confirm that one can boot, install and boot an ubuntu server image on a secureboot system
[08:54] <stgraber> of course, my install drive (an old phone) decided to die on me at the middle of the install, so I'm setting it up again (after spending 10min figuring out how to fix the efi boot entries so I could boot my main system again)
[08:55] <stgraber> (as d-i ran efibootmgr and changed my 'ubuntu' entry to point to the now dead usb key, requiring me to find another bootable media to chroot into my main system and fix the boot entries)
[08:56]  * stgraber starts to miss good old MBR...
[09:08] <stgraber> ok, done wiping the external SSSD and preparing another install media. I'll be out for the next 1.5h or so (install, test and lunch). Call my cell if you need me online (the +41 one)
[09:19] <cjwatson> stgraber: YA thing missing from nic-firmware-*.udeb, I guess
[09:20] <cjwatson> stgraber: 30s delay> I would say "try -proposed" except infinity screwed up the grub2-signed upload :)
[09:20] <infinity> cjwatson: I did?
[09:21] <xnox> cjwatson: you really know how to make someone's day go up and back down...
[09:21] <xnox> =)))))
[09:22] <infinity> xnox: To be fair, he just admitted in person that he screwed it up, and I just failed to notice and fix it. :P
[09:23]  * xnox ...
[09:27] <stgraber> cjwatson: well, we have another problem... I'm writting another boot image to debug and fix my laptop, but apparently ubuntu-server installs the signed grub but doesn't properly configure EFI to boot the shim (my current guess)
[09:27] <stgraber> so I end up with an access denied error at boot time and the machine getting stuck there
[09:28] <cjwatson> stgraber: OK, sigh, not a giant surprise I guess but ...
[09:28] <cjwatson> stgraber: if you can manage to get me installer logs that'd help
[09:31] <infinity> adam_g_: Have you done any testing on the nova build in quantal-proposed?
[09:36] <stgraber> cjwatson: ok, so the problem is that grub-efi-amd64-signed was installed but not the shim (no shim or shim-signed installed)
[09:36] <stgraber> cjwatson: I'll grab the install log now
[09:37] <stgraber> Oct 15 09:15:18 in-target: E: Unable to locate package shim-signed
[09:37] <stgraber> cjwatson: http://paste.ubuntu.com/1280795/ for the full log
[09:38] <stgraber> oh, one thing to note, as the installer couldn't find my wireless firmware and I don't have wired connectivity here, the install was done without internet access
[09:38] <cjwatson> So maybe shim-signed just isn't on the server CD
[09:38] <stgraber> yeah, looks like it, that's what I'm checking now
[09:38] <cjwatson> I thought Steve had seeded it though
[09:39] <cjwatson> But maybe not
[09:39] <stgraber> it's not in /pool/main/s
[09:42] <stgraber> cjwatson: hmm, so I guess we'll want shim-signed in the /pool of all images
[09:42] <cjwatson> Yeah
[09:43] <stgraber> good thing I tried a network-less install, would have been a bad surprise for anyone install on a secureboot system :)
[09:44] <cjwatson> So how is shim-signed in main?
[09:44]  * cjwatson checks germinate output
[09:45] <xnox> cjwatson: somebody promoted it, without seeding.
[09:45] <xnox> ?!
[09:45] <cjwatson> No
[09:45] <cjwatson> Oh, build-dep of d-i, of course
[09:45] <cjwatson> xnox: component-mismatches being empty is a fairly good clue that didn't happen
[09:46] <xnox> cjwatson: ok, thanks. makes sense. =)
[09:46] <stgraber> I'm a bit unclear on that part of the seeds, would adding it to platform/installer be enough to get it in *-ship? (I see a whole lot of udeb in that seed but they're not on the desktop images, so I'm wondering if there's more magic going on around that)
[09:48] <cjwatson> stgraber: already done
[09:48] <stgraber> ok :)
[09:48] <cjwatson> d-i-requirements + ship-live + (probably obsolete but I don't feel like reorganising now) usb-ship-live
[09:49] <stgraber> oh yeah, I should just have grepped for grub-efi-amd64-signed and added at the same places :)
[09:49] <cjwatson> yeah, exactly what I did
[09:53]  * stgraber grabs new grub2-signed from LP for a quick test
[09:54] <stgraber> and it works! no more error message or delay at boot
[09:55] <cjwatson> Yay
[09:55] <cjwatson> Hopefully I didn't break BIOS - apw is testing that
[09:58] <stgraber> I'll reboot again in a few minutes to go poke at the menu and command line a bit see if I can spot anything else that's failing outside of the standard boot path
[10:35] <cjwatson> So of the "under investigation" things, I'm still worried about bug 1066347
[10:35] <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
[10:38] <xnox> cjwatson: i have just finish reproducing it and peaking at the apt-clone tarball now.
[10:39] <xnox> cjwatson: lovely. so the apt-clone tarball generated from within the installer has temp mountpoint leaked into the tarball.
[10:39] <cjwatson> Aha
[10:39] <xnox> cjwatson: it's /tmp/tmp.AYhUtphW4V/etc/apt/sources.list instead of ./etc/apt/sources.list
[10:39] <cjwatson> That explains it, I was wondering
[10:40] <xnox> cjwatson: is that enough for you to fix it =))))?
[10:40] <cjwatson> If you could upload a fix for that ASAP, I think we should have it
[10:40] <cjwatson> You have it in front of you :P
[10:40] <xnox> ah.... =( sigh. ok.
[10:40]  * xnox haven't done anything with apt-clone before yet.
[10:41] <xnox> =)))
[10:41] <cjwatson> Nor I, really
[10:41] <cjwatson> Apart from monkey-see-monkey-do py3 porting
[10:41] <cjwatson> xnox: If you can grab mvo, he might be able to help
[10:42] <xnox> =)))) barry will like that phrase:"<cjwatson> Apart from monkey-see-monkey-do py3 porting"
[10:49] <mvo> xnox: I can help you after lunch just give me some details plase :)
[10:50] <cjwatson> mvo: bug 1066347 - respin-critical
[10:50] <ubot2> Launchpad bug 1066347 in apt-clone ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [Critical,Triaged] https://launchpad.net/bugs/1066347
[10:51] <xnox> mvo: see bug 1066347. It looks like we are generating restore tarball using: apt-clone clone --with-dpkg-repack --source "$mountpoint" "$working"
[10:52] <xnox> mvo: and it looks like the mountpoint is not stripped from the tarball for the /etc/apt/sources.list it ends up as $mountpoint/etc/apt/sources.list in the tarball.
[10:52] <mvo> xnox: uh, I will try to be back asap from lunch
[10:52] <xnox> mvo: no rush, we release on thursday =)
[10:53]  * stgraber quickly checks.
[10:53]  * xnox kind of wishes the manpage would actually document all options.
[10:53] <psivaa> xnox: if it would help bug 1066347 is similar to bug 1056815 where apt-clone-state tar file is attached
[10:53] <ubot2> Launchpad bug 1066347 in apt-clone ""Reinstall Ubuntu" failed - apt-clone crashes with: KeyError: "filename './etc/apt/sources.list' not found" line 1886 in getmember in tarfile.py" [Critical,Triaged] https://launchpad.net/bugs/1066347
[10:53] <ubot2> Launchpad bug 1056815 in ubiquity "'Could not restore packages from the previous install' error message when installed from live usb" [Low,Confirmed] https://launchpad.net/bugs/1056815
[10:53] <stgraber> I'm waiting for images to download and I've done some apt-clone patching in the past, will see if it's a trivial fix, otherwise will let mvo look at it when he's back
[10:53] <cjwatson> So, I see no other (potential) respin triggers that require a ubiquity upload, apart from the user-setup bug whose fix needs to be incorporated
[10:53] <cjwatson> Given that bug 1066480 seems to have been punted?
[10:53] <ubot2> Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480
[10:54] <stgraber> cjwatson: I can't remember, is apt-clone integrated in ubiquity or is it only in the dist-upgrader?
[10:54] <cjwatson> It's a dependency
[10:55] <xnox> cjwatson: well. I am punting it, but I want to hear a comment from $release-team to agree on punting it.
[10:55] <cjwatson> What I mean is actually, shall I upload ubiquity now with just this user-setup fix?
[10:55] <stgraber> good, so it's just ubuntu-release-upgrader that we should rebuild once we have apt-clone fixed (just to be safe)
[10:55] <cjwatson> xnox: I'm not hugely happy about it, because you can tell that it has a LUKS header and prompt for a decryption password; but it does seem too late to fix now, since it'll require new UI, I think
[10:56] <xnox> cjwatson: what about s/This system has nothing installed. What do you want to do?/This system has encrypted volume on it, what do you want to do?/
[10:56] <cjwatson> Way too late for string changes
[10:56]  * xnox thinks we have a template for "data" disk present ?!
[10:57] <cjwatson> ? is sufficient :-P
[10:57] <xnox> Or reuse the "other" option. Which maybe even more confusing
[10:57] <cjwatson> It does sound like it'll have to be a release note
[10:57] <xnox> i will not use capitalisation or punctuation any more because that will annoy cjwatson
[10:57] <xnox> cjwatson: true.
[10:57] <cjwatson> I only ask for normal punctuation :-)
[10:58] <Laney> Yeah, everyone knows it's ‽.
[10:58] <cjwatson> So, anyway, I tend to agree, but maybe worth confirming with QA whether they're prepared to consider it not stop-ship
[10:59] <cjwatson> I guess I should do a translation refresh if we need to upload ubiquity anyway
[11:03] <stgraber> mvo, cjwatson, xnox: I found the problem, figuring out what's the best fix now
[11:03] <cjwatson> Oh, great
[11:03] <xnox> apt_pkg?
[11:03] <stgraber> xnox: yeah, apt_pkg.config.find_file("Dir::Etc::sourcelist") returns an absolute path, so the code adding ./ in front of it doesn't really help
[11:04] <stgraber> I'll probably just go with stripping the source from that path as an easy workaround for that problem
[11:04] <cjwatson> Strip find_file("Dir") off the front, maybe
[11:04] <cjwatson> (Modulo details)
[11:05] <stgraber> cjwatson: oh, yeah, using find_file("Dir") would be better than my current hack :)
[11:05] <xnox> stgraber: but for all the other files, we manually pass the correct name with tar.add($var, arcname='./correct/name')
[11:05] <xnox> after find_file returns absolute paths.
[11:05] <stgraber> xnox: right, expect that for apt we don't have a fixed filename so can't go with just hardcoding it
[11:06] <xnox> stgraber: because of sources.list.d/*?
[11:06] <stgraber> right
[11:07] <stgraber> anyway, cjwatson's suggestion works fine, just cleaning up the code now, will have a diff in a minute
[11:08] <xnox> cool =)
[11:09] <mvo> stgraber: back and \o/
[11:11] <stgraber> mvo: http://paste.ubuntu.com/1280892/
[11:11] <stgraber> haven't tested the sources.list.d case yet though, I just assumed it'd also be affected, testing that now
[11:13] <stgraber> right, sources.list.d is indeed affected but my fix doesn't work for this one, updating
[11:15] <mvo> stgraber: maybe I'm a bit slow today, but I don't quite get why the prefix with "." does not work when its added as "arcname"
[11:16] <stgraber> mvo: because sources is /media/... instead of just /etc/apt/sources.list so you end up with ./media/...
[11:16] <mvo> stgraber: aha, that was the missing piece of info I needed :)
[11:17] <stgraber> mvo: my patch is completely wrong btw... it's trying to copy the files from outside the target with my change
[11:20] <stgraber> mvo: that one is good though: http://paste.ubuntu.com/1280901/
[11:21] <stgraber> there may be a better way of doing it, but that one is pretty short and obvious :)
[11:24] <stgraber> mvo: unless you scream in the next 5 minutes, I'll push that to ubuntu:apt-clone and upload (lp:apt-clone is confusing me quite a bit, so I'll let you merge the change ;))
[11:25] <xnox> it's funny how it's first set apt_pkg.config.set("Dir", sourcedir), and then later retrieved again.
[11:26] <xnox> surely sourcedir should become self.sourcedir. but not during freeze =)
[11:26] <xnox> stgraber: I'll test your patch.
[11:27] <mvo> stgraber: ok, I merge it in a bit, this needs a test too to ensure we don't regress on this  but I can look at this later too
[11:27] <stgraber> xnox: ok. I tested it locally with an install I had on a usb disk (under /media/...), worked fine here
[11:27] <mvo> xnox: +1 for making it self.sourcedir, once there is a test its trivial to refactor
[11:27] <xnox> stgraber: I'll test with ubiquity's reinstall =) which i have here open ready to accept patches.
[11:29] <stgraber> mvo: pushed and uploaded
[11:30] <xnox> stgraber: I don't think there is a need to test for arcname and do ifdefs, you could simply always pass it. Just make sure you set it always set to a correct name....
[11:30] <xnox> oh well =)
[11:30] <xnox> good enough.
[11:34] <infinity> Daviey: Do we know any more about bug #1066556?
[11:34] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS installed via d-i/tasksel: fails when opening the browser to /MAAS" [Critical,Confirmed] https://launchpad.net/bugs/1066556
[11:34] <stgraber> xnox: yeah, I know that the two places in the code using the function pass the arcname, but as the function had a pretty generic name I thought I might as well still support the "old way" :)
[11:36] <xnox> stgraber: yeah, only caveat I once hit was that such changes generally break mock.patched unit tests, if they patch that function. which is sad times =/
[11:36] <stgraber> ah, right. Which reminds me I probably should have ran the unit tests before uploading...
[11:36]  * stgraber does that quickly now
[11:39] <stgraber> xnox: well, I indeed broke a test in the process... for some reason the test suite isn't called at build time so I didn't notice...
[11:40] <stgraber> (rejected apt-clone, will fix the test and re-upload)
[11:40] <mvo> stgraber: its run as a pre-build hook in bzr-buildpackage
[11:41] <xnox> mvo: apt-clone testsuite needs to be ported to DEP-8 compatible one & maybe build time runable one. Many of us don't use/call bd pre-build hooks =/
[11:41] <stgraber> mvo: probably only in lp:apt-clone, not in ubuntu:apt-clone as I used bzr bd to test build and make the source package
[11:42] <mvo> stgraber: oh, that is possible, I don't know about the details of ubuntu:apt-clone
[11:42] <mvo> xnox: yeah, indeed
[11:47] <mvo> xnox: dep8 test env added to trunk now
[11:48] <xnox> cool =)
[11:49] <mvo> next is the patch merge…
[11:51] <xnox> stgraber: with your patch the install still fails.
[11:52] <stgraber> xnox: any idea why?
[11:52] <xnox> stgraber: now ubiquity is looking for precisely './etc/apt/sources.list' but the tar tf says the member is called "etc/apt/sources.list"
[11:53] <xnox> stgraber: maybe you really want to set arcname to the right one =) without ifdefs ;-)
[11:53] <xnox> it's actually error from apt-clone restore
[11:54] <stgraber> xnox: ok, so that matches my failure in the test suite, so that's already what I'm looking at now
[11:54] <infinity> Laney: Planning to fix handbrake's implicit pointer conversions?
[11:55] <Laney> infinity: I was just speaking to siretart about that
[11:55] <xnox> stgraber: http://paste.ubuntu.com/1280938/
[11:55] <stgraber> xnox: right, same thing I'm getting from the test
[11:56] <xnox> stgraber: so I suggest you explicetly set the acrname to ".(strip prefix)/" for all files.
[12:05] <xnox> stgraber: http://paste.ubuntu.com/1280948/
[12:05] <xnox> ?
[12:06] <xnox> horum... still fails...
[12:07] <mvo> stgraber, xnox: hrm, hrm, so there seems to be a testcase for this already in TestClone.test_save_state and its failing!
[12:08] <stgraber> mvo: yeah, it's just that whoever last uploaded didn't run it ;) or something changed in python-apt breaking it
[12:08] <mvo> stgraber: indeed
[12:08] <mvo> dep8 will rescue us in the future
[12:09] <xnox> also the fact that reinstall was not visible in the installer up until recently didn't help with manual testing of this feature either....
[12:10] <xnox> mvo: assert is looking for './etc/apt/sources.list' yet tarball has '/etc/apt/sources.list'
[12:11]  * xnox ponders if it's a change in tar...
[12:12] <mvo> xnox: it appears r101 is still working, at least the test unless that is a red-herring
[12:12] <stgraber> when running the tests, the assert is failing because sources.list is in tmp/tmp6qdubj/etc/apt/sources.list
[12:12] <mvo> stgraber: right, that seems to be the issue then
[12:13] <mvo> stgraber: r103 is breaking the test but that is unreleated, right?
[12:18] <mvo> xnox: stgraber: actualy I wonder if that change in r103 didn't break this as well, it  looks quite supicious to me, would be interessting if you could ru na version 0.2.3~ubuntu1 just for testing
[12:22] <stgraber> mvo: so, one obvious problem is that Dir doesn't match the source in the tests
[12:23] <stgraber> from my debug code:
[12:23] <stgraber> base_path = ./data/mock-system/
[12:23] <stgraber> going with: /tmp/tmpKIvPei/etc/apt/sources.list, /tmp/tmpKIvPei/etc/apt/sources.list
[12:23] <stgraber> if Dir was set to /tmp/tmpKIvPei/ then the test would pass
[12:25] <mvo> stgraber: could you please check http://paste.ubuntu.com/1280977/ ?
[12:26] <mvo> stgraber: I think we don't need to do anything complicated here, we know that sources.list needs to be in ./etc/apt/sources.list in the state file, so we I don't think we need to juggle paths
[12:29] <stgraber> mvo: test still fails with that code. sources.list is good but sources.list.d isn't
[12:29] <mvo> stgraber: hold on a sec
[12:30] <mvo> stgraber: http://paste.ubuntu.com/1280983/ <- bettter?
[12:31] <stgraber> hehe, I just did the same change locally ;) and the answer is no
[12:31] <mvo> stgraber: heh :) odd, that is much happier for me
[12:32] <stgraber> oh, actually nevermind, yours work...
[12:32] <mvo> stgraber: if its now also working in the realworld we may have a winner
[12:32] <mvo> stgraber: *fingerscrossed* :)
[12:32] <stgraber> I probably made a typo in mine or something like that (used "/%s" % source instead of + but result should have been the same...)
[12:33] <stgraber> mvo: hmm, there's still something wrong... I'm seeing duplicate entries now
[12:33] <stgraber> I'm not even sure how that's possible to start with... according to midnight commander I'm getting /etc/apt/sources.list.d/blah.list twice
[12:34] <stgraber> mvo: http://paste.ubuntu.com/1280992/
[12:36] <stgraber> mvo: oh, that's because you add the whole directory first
[12:36] <mvo> stgraber: ohhh
[12:37] <stgraber> right, confirmed that commenting the for loop works fine
[12:37] <mvo> stgraber: that would not scrub passwords fromthe sources.list.d files
[12:37] <mvo> stgraber: so that needs fxing, hold on a sec
[12:37] <stgraber> mvo: going with http://paste.ubuntu.com/1280999/ works here
[12:38] <stgraber> except that the scrubbing won't work
[12:40] <stgraber> mvo: http://paste.ubuntu.com/1281002/ that one works
[12:40] <mvo> stgraber: heh :) was just adding the same
[12:40] <mvo> stgraber: I will also update the test to ensure its not doing the double adding
[12:41] <mvo> stgraber: http://paste.ubuntu.com/1281005/ <- same as yours, just updates the test
[12:43] <xnox> mvo: self.assertTrue(len(sources_list_d) == set(sources_list_d))
[12:43] <xnox> ?
[12:43] <xnox> mvo: self.assertTrue(len(sources_list_d) == len(set(sources_list_d)))
[12:43] <xnox> :P
[12:44] <mvo> xnox: I'm confused
[12:44] <stgraber> xnox: self.assertTrue(len(set(members)) == len(members) ?
[12:44] <stgraber> +)
[12:44] <xnox> stgraber: yeah.
[12:45] <stgraber> xnox: though members is a list of tar objects so that won't work as they'll be different even if it's the same path
[12:45] <xnox> mvo: if you are testing that there are no duplicates you should check for how long is a unique set compared to the original list length.
[12:45] <stgraber> xnox: so you'd first need to extract them as strings, then use set()
[12:45] <xnox> also there is now a TarFile.getnames()
[12:45] <xnox> no need to do the [m.names for m...]
[12:45] <stgraber> xnox: oh, nevermind, the code already does that part :)
[12:46] <stgraber> right
[12:46] <xnox> meh. let me rerun ubiquity with this new one =)
[12:46] <mvo> yeah, getnames() is nicer nowdays -
[12:46] <mvo> xnox: well, len(sources_list_d) with recursive=True is "3" so the test served some purpose, but certainly testing for the actual names is prefereable
[12:47] <stgraber> testing with getnames() and the len(set()) thing
[12:47] <xnox> I see. =)
[12:48] <mvo> xnox: sorry, blind today now I get your suggestion about list/set compare
[12:49] <stgraber> mvo: so, I have a test using the list/set compare, except that we don't actually have anything in sources.list.d for the test so it's not spotting the bug if I regress the code :)
[12:50] <mvo> stgraber: hm? isn't there data/mock-system/etc/apt/sources.list.d/ubuntu-....list ?
[12:50] <stgraber> mvo: all lines are disabled, so it's ignored
[12:51] <mvo> stgraber: meeeh
[12:51] <mvo> stgraber: I think that is actually order dependant, the restorestatenewrelease is the problem
[12:51] <mvo> (I bet)
[12:52] <xnox> yeah.... we should be constructing to sorted lists and comparing them =/
[12:52] <xnox> well the real test is whether ubiquity will manage to reinstall itself =)
[12:54]  * xnox running it now....
[12:55] <xnox> yeay =) the tarball looks good... now waiting until the restore.
[13:04] <mvo> stgraber, xnox: finally! tests are happy with http://paste.ubuntu.com/1281041/ - I commit this to trunk now
[13:05] <skaet> :)
[13:05] <stgraber> mvo: good, I was starting to poke at the apt config but you're clearly faster than me when dealing with python-apt ;)
[13:06] <mvo> stgraber: yeah, the lack of apt_pkg.config.clear_all_damm_it() is a problem (that has a branch but is not merged yet). so this cheap workaround will have to do
[13:08] <stgraber> mvo: why did you remove accerciser?
[13:08] <mvo> stgraber: for me this now works, not sure what kind of artifact that is
[13:09] <stgraber> ok, because here it's failing when it's not there
[13:09] <mvo> stgraber: oh, please add it back then, I investigate now why
[13:09] <xnox> mvo: stgraber: confirming that http://paste.ubuntu.com/1281002/ works in ubiquity
[13:09] <xnox> mvo: comparing two sets will not catch duplicates, but silently discard them.
[13:10] <mvo> xnox: meh, yes
[13:10] <xnox> mvo: sort the list & compare it with sorted expected list.
[13:10] <xnox> mvo: that should catch everything.
[13:11] <mvo> xnox: thanks, fixed and updated
[13:13] <infinity> stgraber / mvo: What's the status of the whole apt-clone thing?
[13:13] <cjwatson> apt-clone is python3 only - you could just use assertCountEqual
[13:13] <stgraber> infinity: I'll upload in a few minutes
[13:13] <cjwatson> (>= 3.2)
[13:13] <xnox> cjwatson: cool =) we are settling on comparing two lists now to catch exact names & extra/missing items.
[13:13] <cjwatson> which is pretty much what assertCountEqual does
[13:14] <cjwatson> except less manual code :)
[13:14] <stgraber> infinity: re-applying that last change from mvo, then running a few more tests on it and pushing
[13:14] <xnox> cjwatson: ah, cool =)
[13:16] <skaet> infinity,  have you had a chance to talk to elmo and find out when we're going to get the certificate issue resolved for WUBI?
[13:18] <infinity> skaet: We don't seem to have an elmo here, but we'll chase it up.
[13:19] <skaet> infinity,  thanks.   also been looking at /etc/issue on quantal - it has "Ubuntu 12.10 \n \l" ,   is that "\n \l" appropriate?
[13:19] <stgraber> infinity: uploaded
[13:20] <stgraber> mvo: final debdiff (pushed to ubuntu:apt-clone) http://paste.ubuntu.com/1281067/
[13:20] <stgraber> mvo: I went with cjwatson's suggestion to simplify your test a little
[13:20] <infinity> skaet: Yes.
[13:20] <stgraber> tested locally with the test suite + my own system + an external system mounted in /media/
[13:21] <cjwatson> \n and \l are documented in getty(8)
[13:21] <cjwatson> under "ISSUE ESCAPES"
[13:21] <skaet> infinity,  cjwatson - am also a bit concerned that the MAAS issue may impact d-i,   can we make sure we get feedback on scope of impact before we respin?
[13:21] <skaet> thanks cjwatson.  :)
[13:22] <cjwatson> I don't know what's going on with the MAAS thing - we asked for feedback from Daviey earlier today and heard nothing
[13:22] <infinity> skaet: I've asked Daviey for feedback, not sure what's ha... What he said.
[13:23] <cjwatson> FWIW since wubi.exe isn't on the images any more, it's not an issue for the next round of respins - just needs to land in time for a test of just that before release
[13:23] <cjwatson> (obviously needs to happen, just trying to keep a handle on what are immediate issues)
[13:23] <skaet> cjwatson, infinity - Daviey's in california, with good chunk of server team,  so we're going to be at a time disadvantage communicating with them.
[13:23] <cjwatson> ah
[13:23] <infinity> Alright, well, they'll be up soonish.
[13:24] <cjwatson> Wonder if I can reproduce the MAAS thing in kvm
[13:24] <cjwatson> I obviously don't have a full setup
[13:24] <cjwatson> I guess it needs a server of some kind
[13:24] <xnox> cjwatson: is ubiquity in -proposed on purpose? cause then [35] trigger is not really "published and ready"
[13:24] <cjwatson> I don't really have enough context or details to be able to get anywhere
[13:24] <skaet> hggdh,  ^ can you help cjwatson with reproducing?
[13:25] <cjwatson> xnox: avoiding arch skew
[13:25] <xnox> ack.
[13:25] <cjwatson> I don't want even transient uninstallability at this point
[13:25] <cjwatson> I didn't say [35] was "published and ready", FWIW
[13:25] <cjwatson> anyway, it's copyable now, I'll do that
[13:25]  * xnox the pad does. whoever that is.
[13:25] <xnox> =)
[13:26] <skaet> my bad,  I saw it fix released, but didn't check the pocket it was in.
[13:26] <stgraber> what's the maas bug # again? I have a maas server somewhere for testing
[13:26] <xnox> bug 1066556
[13:26] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS installed via d-i/tasksel: fails when opening the browser to /MAAS" [Critical,Confirmed] https://launchpad.net/bugs/1066556
[13:26] <stgraber> thanks
[13:26] <skaet> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1066556
[13:26] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS installed via d-i/tasksel: fails when opening the browser to /MAAS" [Critical,Confirmed]
[13:26] <stgraber> btw, would be nice of someone could review apt-clone in the queue
[13:26] <cjwatson> I will
[13:27] <stgraber> looks easy to reproduce, I'll do that now
[13:29] <cjwatson> Looks OK to me
[13:30] <stgraber> the new livefs server install is really impressive! Installing a maas VM here took 3 minutes including answering all the d-i questions ;)
[13:30] <cjwatson> stgraber: excellent, tell the server team that so that they get off my back about performance
[13:30] <stgraber> :)
[13:33] <cjwatson> jamespage: what happens to old iSCSI installs here?  Do they end up with two conflicting initiator names?  (Where did GenerateName store the generated name/)
[13:33] <cjwatson> ?
[13:34] <hggdh> cjwatson: how can I help you?
[13:34] <stgraber> maas bug reproduced
[13:35] <cjwatson> hggdh: no need now, I think
[13:35] <cjwatson> jamespage: I guess that the initiator name used to go into /etc/iscsi/initiatorname.iscsi, so that this was previously violating policy by editing a conffile in maintainer scripts?
[13:36] <cjwatson> (and in fact still will, if I understand this correctly, just now front-and-centre in the postinst)
[13:36] <stgraber> rbasak: answer to your question in bug 1066556 is yes. Running dpkg-reconfigure and not changing anything fixes it.
[13:36] <ubot2> Launchpad bug 1066556 in debian-installer "MAAS installed via d-i/tasksel: fails when opening the browser to /MAAS" [Critical,Confirmed] https://launchpad.net/bugs/1066556
[13:36] <cjwatson> (I mean "still will [go into that file]")
[13:37]  * stgraber reinstalls maas to diff the pre/post dpkg-reconfigure and see exactly what's wrong
[13:38] <cjwatson> stgraber: in the allegedly-dup bug, roaksoax says that it's because the rabbitmq user is not created during CD install - so dpkg-reconfigure after reboot won't be a good guide
[13:38] <cjwatson> I think perhaps it's rather because the rabbitmq service is not started
[13:38] <cjwatson> (which is intentional and I recall telling the server team this - we don't start services during installation)
[13:39] <stgraber> maas is broken post-install (after reboot) until you run dpkg-reconfigure
[13:39] <infinity> seb128: Is there a cherry-pick one could do for bug #1060171?
[13:39] <ubot2> Launchpad bug 1060171 in compiz-core "gtk-window-decorator crashed with SIGSEGV in g_hash_table_lookup_node() from g_hash_table_remove_internal() from event_filter_func() from gdk_event_apply_filters()" [High,Fix committed] https://launchpad.net/bugs/1060171
[13:39] <cjwatson> stgraber: Indeed, but that matches roaksoax's analysis
[13:39] <barry> xnox, cjwatson love it!
[13:39] <seb128> didrocks, popey, ^
[13:39] <cjwatson> After reboot, rabbitmq will be running when you run dpkg-reconfigure
[13:39] <cjwatson> Which is the important bit - running dpkg-reconfigure during installation wouldn't help, if that analysis is right
[13:39] <stgraber> ah, yeah, that makes sense
[13:39] <seb128> infinity, do you think it's worth trying to get on the iso rather than SRU0?
[13:40] <didrocks> infinity: you mean for finale?
[13:40] <stgraber> so one fix would be to move that logic into the maas upstart job which I assume properly depends on rabbitmq running
[13:40] <cjwatson> So in that case, I don't see anything that might reasonably be changed in d-i - maas has to handle this the first time it's run
[13:40] <infinity> seb128: Well, given that a fix was available for a week, I'm a bit surprised no one mentioned the possibility.  But it's not critical, if it can be 0-dayish.
[13:40] <didrocks> infinity: it's already on the SRU0 list, popey's team is supposed to have something ready to upload for tomorrow
[13:41] <infinity> didrocks: Alright.  We'll see how that pans out, then.
[13:41] <didrocks> infinity: well, the crash didn't get that much to ask for a cherry-pick in finale
[13:41] <infinity> didrocks: Still, if there *is* a simple/auditable/testable cherry-pick for it, I wouldn't actually say no to having it on the ISO (or at least to having it build in proposed and consider it for a respin, if there's one)
[13:42] <infinity> didrocks: Oh, it's not that common?  There was a claim it was a "top crasher".
[13:42] <skaet> didrocks, infinity - cherry picked to get rid of it (if fix was available today) would be nice.    Tomorrow's heading towards too late territory and best leave it for SRU.
[13:42] <didrocks> infinity: 30 on errors.ubuntu.com, we cherry-picked way worse lenses fix :)
[13:43] <xnox> cjwatson: about bug 1066302 how come ubuntu-studio does not have release_notes_url? =)
[13:43] <ubot2> Launchpad bug 1066302 in ubiquity "/cdrom/.disk/release_notes_url missing in ubuntu-studio, resulting in ubiquity triggering installer update" [High,Confirmed] https://launchpad.net/bugs/1066302
[13:43] <didrocks> skaet: when i'm telling tomorrow, it's tomorrow for -proposed :)
[13:43] <xnox> cjwatson: it's currently being release noted that "the update link is shown and does nothing" but I think this can be fixed in studio cdimage build.
[13:43] <didrocks> infinity: the fix is easy, if you have a respin plan, I don't object to backport it
[13:43] <skaet> didrocks,  why not today for -proposed?
[13:43]  * xnox wonders who is ubuntu studio contact.
[13:43] <infinity> didrocks: Please upload then, yeah.
[13:43] <didrocks> skaet: because we don't cherry-pick only that one
[13:44] <infinity> didrocks: If that had happened days ago, it would have gone into a respin by now. :/
[13:44] <didrocks> infinity: ok, let me do some testing first
[13:44] <cjwatson> xnox: 'cos debian-cd only doesthat for a given list of products
[13:44] <cjwatson> I can fix that if that's what the studio folks want
[13:44] <didrocks> infinity: well, we get tons of small issues, we don't want to make the project less stable due to a late fix
[13:44] <stgraber> scott-work: ^
[13:44] <skaet> didrocks, only want a cherry pick of that one.   Want to limit scope of change at this point.
[13:44] <didrocks> otherwise I can push for you a fix everyday if you one :)
[13:44] <cjwatson> Actually I suspect studio didn't have it because it never used to be live
[13:44] <cjwatson> So I'm going to JFDI
[13:44] <didrocks> skaet: we agree :)
[13:45] <didrocks> skaet: infinity: look at what is planned for SRU0 for instance: https://launchpad.net/compiz/+milestone/0.9.8.6
[13:45] <cjwatson> xnox: Still a ubiquity bug though
[13:45] <didrocks> (you can see there are other crashes)
[13:45] <cjwatson> Should be showing different text if release_notes_url is  unset
[13:45] <infinity> didrocks: Looking.
[13:46] <xnox> cjwatson: true. But if you fix studio, we don't need to release not it (1066302 that is) (highlighting skaet)
[13:46] <didrocks> and unity itself: https://launchpad.net/unity/+milestone/6.10.0
[13:46] <skaet> ack xnox
[13:46] <cjwatson> xnox: Sure
[13:46] <infinity> didrocks: Actually, yeah.  Nevermind the single cherry-pick.  You're right, just concentrate on the SRU0 stuff, and make sure it's solid.
[13:46] <cjwatson> xnox: I just want to make sure it's still open
[13:46] <xnox> cjwatson: ack.
[13:47] <infinity> didrocks: Not sure why this one bug was deemed more interesting than the rest.
[13:47] <Laney> because of its place on e.u.c
[13:47] <skaet> errors.ubuntu.com statistics on it.
[13:47] <infinity> skaet: Yes, I meant I wasn't sure why, other than statistics. :P
[13:47] <cjwatson> xnox: done
[13:47] <infinity> Frequency != Impact.
[13:48] <seb128> well, it's still a metric
[13:48] <didrocks> infinity: who told you it was interesting? :)
[13:48] <seb128> we want to fix the most common issues
[13:48] <infinity> If it's guaranteed to explode right after install, and one can't upgrade, that would be critical.
[13:48] <infinity> didrocks: Whoever noted it in the pad. :P
[13:48]  * didrocks opens the pad :p
[13:48] <infinity> seb128: Sure, and it's being fixed.  I don't disagree with fixing it. :)
[13:49]  * Laney gets blinded by the colours on the pad
[13:49] <skaet> infinity,  it was put on the pad to make sure we had this discussion,  after seeing it was top on errors.ubuntu.com over the weekend.     Discussion has happened.   Process working.
[13:49] <didrocks> infinity: TBH, I would prefer that we have it in a strongly tested SRU. I know compiz/gtk-w-d too much to know we can have regression on "simple fixes" like that
[13:50] <skaet> didrocks,  I'd also prefer a strongly tested SRU
[13:51] <didrocks> I have some debs if you want, still not fan of risking a heart attack :-)
[13:52] <cjwatson> doko: Hmm, do you understand why kamailio/amd64 failed?
[13:52] <cjwatson> doko: Seems weird that you have CFLAGS=... in the configure parameters twice now, rather than causing dpdkg-buildflags --export=configure to DTRT
[13:52] <cjwatson> *dpkg-buildflags
[13:53] <doko> well, I add something in the second line
[13:53] <doko> I have to look at it. it could be that some -f flag which was set upstream, is now overwritten again
[13:53] <doko> like the -fsigned-char which I noticed on arm
[13:54] <cjwatson> You add something, yes, it just seems odd and semi-not-clearly-defined to have it there twice
[13:54] <cjwatson> Rather than using DEB_MAINT_CFLAGS_APPEND say
[13:57] <doko> the _APPEND macros should never be used in the rules files itself. they are meant to overwrite things
[13:57] <doko> like in a test rebuild
[13:59] <cjwatson> doko: Err, not true!
[14:00] <cjwatson> doko: DEB_CFLAGS_APPEND is for the user - but DEB_CFLAGS_MAINT_APPEND is explicitly for use in debian/rules
[14:00] <cjwatson> Even documented as such in dpkg-buildflags(1)
[14:00] <doko> ahh, ok
[14:00] <cjwatson> (Sorry, I got the name wrogn earlier)
[14:09] <smartboyhw> Is the Studio image respinning now?
[14:10] <skaet> smartboyhw, it will be include in the next set of respins we'll be coming out later
[14:10] <smartboyhw> skaet, yeah!
[14:16] <plars> cjwatson:  https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1066883 is the X issue on amd64+mac psivaa just filed that I mentioned a bit ago
[14:16] <ubot2> Launchpad bug 1066883 in xorg "Fatal server error: Can not run in framebuffer mode on reboot" [Undecided,New]
[14:21] <skaet> thanks plars
[14:23] <smartboyhw> skaet, I think we need to change the release notes for Ubuntu Studio 12.10....
[14:23] <skaet> smartboyhw,  please edit in any changes you think are necessary.    They are under version control.
[14:24] <smartboyhw> :D
[14:24] <skaet> scott-work, will be revieweing/improving this week as well,  I believe.
[14:24] <cjwatson> *blink* 1066883 looks like Intel graphics, so why is that exploding ...
[14:24] <smartboyhw> skaet, so I just edit it in the wiki?
[14:26] <scott-work> skaet: sorry i haven't been very responsive today, between sick and work...ugh
[14:26] <smartboyhw> scott-work, hey I was just going to find you:D
[14:26] <scott-work> it appears that we are respinning our image, i think that is good
[14:26] <scott-work> and i shall be reviewing the release notes as well
[14:27] <scott-work> hi smartboyhw
[14:30]  * cjwatson wonders if there are any X people in a sensible timezone to look at 1066883 - this is opaque to me
[14:30] <cjwatson> plars: ^- FWIW
[14:30] <Laney> there is mlankhorst who is not in this channel
[14:31] <plars> cjwatson: psivaa was trying to track someone down earlier, did you have any luck with that psivaa ?
[14:31] <cjwatson> This is mostly me disclaiming ability to make any sense of it
[14:33] <psivaa> plars: i could not find anyone to reproduce that
[14:39] <balloons> Daviey, have you seen this? https://launchpad.net/bugs/1018542
[14:39] <ubot2> Launchpad bug 1018542 in debian-installer "JEOS install oversized" [Undecided,New]
[14:40] <balloons> there's concern the current RC images are also overlimit
[14:43] <cjwatson> balloons: I thought the plan was to update the docs for that
[14:44] <balloons> yes -- I was just thinking for some reason that jeos had a specific requirement for some reason
[14:44] <balloons> k -- if not then :-)
[14:46] <balloons> cjwatson, ahh probably this line that had me thinking this way: "This change does not affect Ubuntu Server, which remains a traditional CD sized image.  "
[14:46] <balloons> that's from Kate's email annouce
[14:46] <smartboyhw> balloons, yes
[14:47] <cjwatson> balloons: yeah, that's image size not installed size
[14:48]  * balloons rattles head
[14:53] <skaet> cjwatson,  infinity - just talked to roaksoax in california.   fix is still being figured out but it will be localized to the maas package.    So we can go ahead and respin the images after the last bits publish.
[14:53] <cjwatson> maas is on the server images
[14:53] <skaet> yes
[14:54] <skaet> we may need to respin that one again after a fix is found,  but we may as well pick up the other pieces now.
[14:54] <cjwatson> So should we respin server anyway?
[14:54] <cjwatson> (Now, I mean)
[14:54] <skaet> yes,  there's no eta on the fix at this point.
[14:56] <skaet> plars, hggdh ^ FYI.
[14:56] <hggdh> skaet: ack
[15:04] <phillw> skaet: is anyone looking at the debian-installer fail for PPC (Affects server and Alternate for PPC)?
[15:04] <skaet> infinity, ^ ??
[15:04] <skaet> phillw, bug number?
[15:04] <phillw> bug 1066435
[15:04] <ubot2> Launchpad bug 1066435 in debian-installer "Debian-installer powerpc recursive fault" [Undecided,Confirmed] https://launchpad.net/bugs/1066435
[15:04] <xnox> infinity: is probably away from his physical ppc box, i think...
[15:04] <cjwatson> iz kernel bug
[15:05] <xnox> =))))
[15:05] <cjwatson> kernel/exit.c
[15:05] <jibel> balloons, the minimal installation size has been increased to 668000B for 32bit and 668000B + 93250B for 64bit as agreed with the server team. See with Daviey or jamespage for details.
[15:05] <cjwatson> (well, probably ... have reassigned as at least a temporary measure anyway)
[15:05] <balloons> jibel, ty.. that's what I was trying to confirm
[15:06] <phillw> cjwatson: thanks, they're trying to get some meaningful logs up, but not easy with the fail so early on.
[15:07] <phillw> but, we do know the spin that broke it, so that may help a bit (he says, more in hope...) :)
[15:08] <phillw> the desktop is unaffected, which is why it was not initally flagged as kernel bug.
[15:09] <jamespage> cjwatson, not ignoring you - power was out....
[15:09]  * jamespage reads backscroll
[15:11] <jamespage> cjwatson, I've actually just restored the postinst bits which where lost during the last merge that generated the initiator name on install
[15:12] <jamespage> (and yes its not policy compliant - it should be using ucf)
[15:14] <jamespage> cjwatson, initiator name still ends up in the same place - its done by the init script in the latest Debian revisions
[15:14] <jamespage> cjwatson, upgrades should be OK
[15:19] <skaet> cjwatson, infinity - when kicking off the respins,  please bias towards getting arm desktop, arm server out early so we can get some testing in today before Europe goes offline.
[15:27] <skaet> cjwatson,  anything left to land?  or can the respins be started?
[15:30] <infinity> cjwatson: Waiting on the d-i I just uploaded, at least.
[15:32] <plars> infinity: did you have any additional thoughts on https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1066376
[15:32] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New]
[15:34] <skaet> infinity,  what d-i change?
[15:34] <infinity> plars: Oh, yeah, I'll follow up.  It's almost certainly always been broken, even in many x86 cases, and we'll have to fix it in another release.
[15:34] <cjwatson> jamespage: it's policy-compliant *now* :)
[15:34] <infinity> skaet: d-i needed rebuilding to pick up the latest grub2 (again)
[15:34] <skaet> ahh..
[15:34] <skaet> thanks infinity
[15:34] <cjwatson> (Well, ish)
[15:34] <cjwatson> I wonder if we should get this open-iscsi in for server ...
[15:34] <jamespage> yes please
[15:34] <jamespage> and thanks
[15:36] <plars> infinity, skaet: thanks, I couldn't reproduce it on my x86 machine at least, but it could be more isolated than the clear case on arm. I added it to the pad for investigation on friday but it seems to have fallen off at some point.  I think at the very least it should go in release notes
[15:36] <slangasek> xnox: efibootmgr ubiquity apport hook> I don't think so, I don't imagine that's going to be all that relevant after the current crop of efi bug reports are sorted
[15:37] <xnox> slangasek: ok.
[15:42] <doko> cjwatson, still no clue on the kamailio ftbfs. replaced gcc with gcc-4.6, binutils with 2.22, restored the upstream CFLAGS ...
[15:42] <cjwatson> doko: Does the previous version FTBFS now?
[15:42] <doko> yes
[15:42] <infinity> Oh, special.
[15:50] <kenvandine> i see my updated telepathy-indicator made it on the last iso spin earlier
[15:50] <kenvandine> it had an annoying bug, fixed in -proposed now
[15:50] <kenvandine> any chance of getting it in the next respin?
[15:50] <infinity> kenvandine: Yeah, I'm pulling it in.
[15:51] <kenvandine> thanks!
[16:16] <xnox> cjwatson: have you seen bug 1066173 ? (now installing on to external drive sdb, grub is installed on to internal drive sda)
[16:16] <ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [High,Confirmed] https://launchpad.net/bugs/1066173
[16:23] <cjwatson> xnox: sigh :-/
[16:23] <cjwatson> apw ran a bunch of USB tests this morning and didn't run into that, and there are supposed to be automatic tests for this ...
[16:24] <cjwatson> Can't look today, will queue up for tomorrow morning
[16:24] <xnox> ok.
[16:29] <apw> xnox, i am redoing a test to confirm
[16:30] <infinity> Alright, respinning the world after this publisher run, if no one has objections.
[16:32] <xnox> apw: thanks. as far as I can see "boot of cdrom, check that sda is internal & sdb is external, install onto external" check logs where grub got installed.
[16:33] <jibel> I think I still have the logs on the external drive I used for the test
[16:34] <skaet> infinity,  make it so..  please get the arm server/desktop images out from the respin early.
[16:35] <skaet> if you could paste the build sets as you kick them off,  it would help us follow along with the sequence and stop needing to ping.
[16:37] <slangasek> infinity: maybe now's the time for you to implement that work item to support disabling builds on the ISO tracker when a respin is started ;)
[16:37]  * skaet +1's that
[16:40] <infinity> skaet: Paste sets as I kick them off?
[16:41] <skaet> infinity - paste each of the commands lines you'll be hitting enter with on nusakan in the channel here, so we all know the sequence of operating.
[16:42] <skaet> I'm assuming you'll be using the pad set, but with possible order modifications.
[16:42] <skaet> just want it explicit, when it happens so we know order things come out next
[16:44] <infinity> skaet: The only way to guarantee the order they come out is to build each one individually and wait.
[16:44] <infinity> skaet: Probably better to just let queuebot let you know when they pop out.
[16:45] <slangasek> infinity: please post the commands being run; people here can work out from there what to expect
[16:48] <infinity> slangasek: I just used the default pipelines, as that satisfies the request to get ARM desktop/server out first.
[16:49] <infinity> (Yes, lubuntu alternate comes before the server build, but it's only a few minutes, and ubuntu-desktop is building then anyway)
[16:50] <infinity> Oh, for fuck's sake.
[16:51] <infinity> Arguing about this made me lose track of when the publisher was done (and it wasn't), and I kicked off all the builds early.
[16:51] <infinity> *sigh*
[16:53] <xnox> adding http://pad.lv/1057690 as opportunity target
[16:56] <slangasek> infinity: wait-for-package is nice
[16:57] <slangasek> (if I do say so myself)
[16:58] <infinity> slangasek: Yeah, it is, but tailing a logfile was working fine too.
[16:58] <slangasek> that's less fire and forget though ;)
[17:05] <highvoltage> infinity: hey there. I got a message that a build triggered by you failed, is there something I should look at?
[17:05] <stgraber> highvoltage: no, just ignore those
[17:05] <infinity> highvoltage: Ignore it, I mangled the world a bit.
[17:10] <highvoltage> infinity: ok
[17:20] <roaksoax> skaet: marked the bug in question as dup of bug #1065763 and i already have a fix for it, just needs testing
[17:20] <ubot2> Launchpad bug 1065763 in maas "UI URL displays "200 Error" page after CD install" [Critical,In progress] https://launchpad.net/bugs/1065763
[17:20] <roaksoax> skaet: it shold land later today
[17:24] <skaet> thanks roaksoax
[17:25] <skaet> once its tested, and landed,  we'll respin the server image to pick it up.
[17:28] <scott-work> the ubuntu studio mailing list just received a image build failure email from nusakan. is this concerning to anyone?
[17:29] <xnox> scott-work: inifinity cancelled a build. do not panic.
[17:29] <scott-work> groovy
[17:29] <infinity> scott-work: All being resolved now, sorry about the noise.
[17:29] <scott-work> i have my towel and not panicing
[17:29] <skaet> :)
[17:29] <scott-work> panicking
[17:29] <xnox> ;-)
[17:30] <scott-work> no problem, infinity, i knew a respin was expected but wanted to make sure it wasn't something else going on
[18:28]  * skaet breaking for lunch for a bit
[19:07] <slangasek> infinity: still around?
[19:09] <maxb> Hi. I've done a precise->quantal upgrade and ended up without a functional bootloader, because quantal's grub2 apparently cannot fit LVM support into the classic 62 sector gap between MBR and partitions, but precise's could.  Since release is ominously close, how should I be reporting this?
[19:10] <slangasek> maxb: bug report against ubiquity and drop the bug number here
[19:10] <slangasek> er, no
[19:10] <slangasek> not ubiquity, of course
[19:10] <slangasek> maxb: is this the same as bug #1066324?
[19:10] <ubot2> Launchpad bug 1066324 in grub2 "core.img too large for embedding with msdos partition style" [Critical,Confirmed] https://launchpad.net/bugs/1066324
[19:10] <maxb> Ah, probably
[19:11] <slangasek> maxb: also, does this mean you have no separate /boot partition outside of the LVM?
[19:11] <balloons> so, are we just going to ship with the colord-sane issue, or am I the only one still getting it on new installs?
[19:11] <maxb> OK, yes, that is exactly my issue - should I add a release notes task to that bug?
[19:11] <slangasek> balloons: bug #, please?
[19:12] <maxb> And no, I have no non-LVM partitions
[19:12] <slangasek> maxb: yes please
[19:12] <slangasek> maxb: right - so I guess it's a little late to tell you "Don't do that then"
[19:12] <slangasek> I always put /boot outside the LVM
[19:12] <maxb> slangasek: It works fine except for this :-)
[19:12] <slangasek> and I thought the installer handheld users to do that
[19:13] <maxb> I forget when I installed this, but I imagine I went for manual partitioning on the alternate CD
[19:14] <slangasek> xnox: ^^ when ubiquity installs LVM guided, does it make sure to put /boot outside?
[19:16] <slangasek> xnox: nevermind, I guess I already know that the answer is yes :)
[19:20] <balloons> slangasek, no bug report.. I'm trying to find the old perputual colord-sane bug report from this cycle.. I can't file a new one, because apport says, it's not an offical package
[19:20] <balloons> Crash is here: http://paste.ubuntu.com/1281769/
[19:21] <balloons> ahh found it: https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1043990
[19:21] <ubot2> Launchpad bug 1043990 in colord "colord-sane crashed with SIGSEGV in __opendirat()" [Medium,Confirmed]
[19:26] <hggdh> balloons: they do not look the same. How did you get it?
[19:26] <plars> Should English (and a few others) langauge support be complete on the isos? I could swear I'd seen a bug for this already but I'm not locating it at the moment, but perhaps there was and it's actually known/expected.  After installing without network, in english, it says I have incomplete language support and prompts to download
[19:28] <plars> The dialog that comes up makes it seem more like it doesn't have information about the "available languages yet" rather than incomplete support for english
[19:28] <plars> "No language information available" "The system does not have information about the available languages yet.  Do you want to perform a network update to get them now?"
[19:30] <balloons> plars, yes I've gotten that for some time
[19:30] <balloons> even installing in english.. there's some dicts that are not on the cd
[19:31] <plars> actually, after updating that, it seems there are some things missing
[19:31] <balloons> hggdh, I got it by doing an amd64 install
[19:31] <plars> wbritish, myspell-{en-au, en-gb,en-za}, openoffice.org-hyphenation, hyphen-en-us, mythes-en-us, thunderbird-locale-en, thunderbird-locale-en-us
[19:32] <hggdh> balloons: just that? Did you change colour settings? I just finished a desktop amd64, and I do not see the crash
[19:32] <plars> balloons: regarding the colord-sane crash, I'm not seeing that anymore
[19:32] <balloons> hggdh, no I did nothing else
[19:32] <balloons> the weird piece is the 'this is not a ubuntu package'
[19:32] <plars> balloons: so do you know if this is known and expected, or if it's something really missing?
[19:32] <plars> skaet: sound familiar to you?
[19:33] <balloons> hggdh, this is the exact case
[19:33] <slangasek> balloons: ok; this colord crash doesn't even rank on errors.ubuntu.com, and no fix is reported to be available, so no, it's not a priority for fixing before release
[19:33] <balloons> http://iso.qa.ubuntu.com/qatracker/milestones/240/builds/25954/testcases/1451/results/
[19:33] <slangasek> balloons: if you can work with the desktop team to get a fix, we can take it as an SRU
[19:33] <balloons> slangasek, k, just wondering.. I've had some form of color-sane errors for most of the cycle
[19:34] <slangasek> balloons: understood, but errors.u.c suggests that your experience is not representative
[19:34] <balloons> they stopped recently, but it seems they are cropping up again
[19:34] <skaet> plars,  don't remember seeing any bugs similar in my searches,  so please go ahead and open one.
[19:34] <roaksoax> skaet: uploaded
[19:34] <skaet> thanks roaksoax
[19:34] <balloons> slangasek, that's good :-)
[19:34] <roaksoax> :)
[19:34] <skaet> roaksoax, can you give a bit of overview of the testing done so far on it?
[19:34]  * skaet figures may as well ask now.
[19:37] <slangasek> cjwatson, infinity: trying to follow through on the pad to make sure everything that needs respinning is done, and I'm having a hard time verifying from the logs what version of grub2-signed is included in the d-i build. :/  Perhaps I should make that more verbose at build-time?  grabbing version and cat'ing it or something?
[19:40] <skaet> slangasek, thanks for looking into that,  I was a bit worried.   from a timing perspective it should be good,  but double checking properly is much appreciated.
[19:40] <slangasek> yes, it's much better to check proactively than to wait for someone to report that the bugs are still there ;P
[19:41]  * skaet nods emphatically :)
[19:42]  * skaet looking for roaksoax's upload and not seeing it.... 
[19:43] <roaksoax_> skaet: ok, so I tested this by manually installing this packages after having a broken installation to see if it worked as expected, and it did
[19:43] <roaksoax_> skaet: then in the installer itself, I made the necessary changes and confirmed that after reboot, MAAS is available
[19:45] <plars> skaet: bug #1067040
[19:45] <ubot2> Launchpad bug 1067040 in language-selector "Incomplete language support after networkless install" [Undecided,New] https://launchpad.net/bugs/1067040
[19:47] <hggdh> plars: it is not only for networkless install, I got the prompt on a networked install; it does not happen if installing en_GB
[19:47] <skaet> thanks roaksoax_
[19:48] <skaet> I'm not seeing the upload yet,  am I just being impatient?  ;)
[19:48] <skaet> ah yes
[19:48] <skaet> indeed I am
[19:48] <skaet> seeing it now
[19:53] <plars> hggdh: really? I did an install with network just a bit ago and didn't get that
[19:53] <plars> and I was definitely *not* installing with en_GB
[19:53] <slangasek> plars, hggdh: what are the packages it tries to install when it says language support is incomplete?
[19:54] <hggdh> plars: I did -- and still do. I just ass-umed it was expected to be prompted
[19:54] <slangasek> so I'm not sure we have a hard rule about putting all the language support packages on the image
[19:54] <slangasek> I know this has been brought up for the Chinese images in particular and so we've tried to get everything on there
[19:54] <hggdh> slangasek: I will have to re-install for en_US (or wait for armhf-omap4 install to end
[19:55] <slangasek> understood
[19:56] <plars> slangasek: there's a list in the bug I posted above
[19:57] <slangasek> ok, thanks
[19:57] <plars> odd, it's prompting me again after I let it install them all and rebooted
[19:57] <plars> update-notifier I guess it is, is telling me to do it again, but when it takes me to language-selector it doesn't prompt me to do anything
[19:58] <jibel> slangasek, cjwatson apt crash is not fixed. It now crashes during installation with free software enabled.
[19:58] <jibel> reproduced on kvm, now trying on hardware
[19:59] <slangasek> jibel: "during installation"?  the crash cjwatson fixed should only happen during an apt-get update
[20:01] <jibel> slangasek, I know, there is a segfault of libapt-pkg during the execution of plugininstall.py
[20:02] <slangasek> jibel: ok, so sounds like something that should be treated as a separate bug.  Can you open a report with backtrace?
[20:05] <slangasek> cjwatson, infinity: to answer my own question, yes, we should spit out the grub2 version in the log; change committed, in case we happen to respin d-i for any reason
[20:08] <jibel> I filed bug 1067056 as a placeholder with ubiquity logs, I'll try to generate a stack trace
[20:08] <ubot2> Launchpad bug 1067056 in ubiquity "libapt-pkg.so segfaults during execution of plugininstall.py" [Undecided,New] https://launchpad.net/bugs/1067056
[20:09] <plars> jibel: psivaa hit this also and filed it here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1067035
[20:09] <ubot2> Launchpad bug 1067035 in ubiquity "Installer crashed when free software installed with manual partitioning" [Undecided,Confirmed]
[20:09] <plars> jibel: I just confirmed it on amd64, but on i386 I don't hit this
[20:10] <jibel> plars, ok thanks, marking as dupe
[20:11] <jibel> balloons, I have a colord-sane crash in the live session
[20:14] <slangasek> plars, hggdh: I've confirmed that it's expected behavior that these english language support packages are not on the image and that they are available for download only once you have a network connection
[20:15] <plars> slangasek: fair enough, just thought I remembered it once being the case that some languages were expected to be complete at install time regardless of connectivity
[20:16] <plars> it's a fairly trivial thing though
[20:16] <plars> this install crash is a bit more troublesome
[20:16] <slangasek> plars: yeah, I don't recall that ever being a rule, and these packages certainly were not on the CD in previous releases either
[20:17] <balloons> plars, slangasek yes I agree.. this is a no change
[20:18] <slangasek> plars: note that if you do have a network connection during install, I would expect these packages to be automatically downloaded at that point; but even if that's not happening I think this is probably not respin-worthy for 12.10
[20:18] <plars> slangasek: hggdh says that he's seeing an issue even with network connected, however I'm not able to reproduce that here
[20:20] <slangasek> hggdh: ^^ if that's reproducible, I think that's definitely a bug in language-selector (unlike plars's bug, which is a debatable seed question)
[20:20] <hggdh> slangasek, plars: I am trying to repeat now
[20:22] <hggdh> I wonder if this has some influence from the system I am using, a Dell (the same one that lies about the disks)
[20:23] <plars> hggdh: any chance you lost network at some point during the install?
[20:24] <hggdh> plars: not to my knowledge; but this system takes a while to get a connection (not only it lies about disks, but it also does not recognise the NIC on BIOS/early boot)
[20:25] <hggdh> sigh. Well, at least it was a cheap system.
[20:29] <jibel> so apt bug is very close from yesterdays issue, not to say it's the same. apt crashes if sources.list is configured so that main and universe use the same mirror and are the only components on that mirror
[20:33] <slangasek> skaet: was it you that accepted the cups package into quantal-proposed?  I would expect this to go via the SRU process, which hasn't been followed here
[20:35] <skaet> slangasek, good point.
[20:36] <hggdh> plars: cannot reproduce anymore. But, looking at the installer syslog, I see ubiquity downloading language files
[20:36] <plars> hggdh: yeah, I'm thinking maybe you lost network for a bit
[20:37] <hggdh> plars: think so, or it is just this crappy Dell acting up. But since I see about the same set of files being downloaded as you noted in your bug, then at least we know these files are *NOT* there.
[20:38] <hggdh> plars: so, if it is networkless, you will not have full language support
[20:38]  * skaet has to head out to appt now, back on later.
[20:40] <jibel> cjwatson, slangasek same bug, but other method. This time it's in PkgCacheGenerator::NewVersion() instead of PkgCacheGenerator::List::NewProvides()
[20:40] <slangasek> hmm, ok
[20:40] <jibel> I'll attach the back trace
[20:44] <hggdh> plars: I confirmed the language support bug
[20:44] <plars> hggdh: I think it's invalid - expected behavior as slangasek mentions above
[20:45] <plars> or at least, unspecified behavior to be more precise
[20:45] <hggdh> it may be indeed.
[20:46] <hggdh> plars: have you tried a panda install? Mine hangs on preparing the system (hard hang)
[20:46] <plars> hggdh: not yet
[21:29] <infinity> slangasek: d-i was definitely respun for the latest grub2 and published before any images were spun, but yes, I agree that better verbosity in the logs would be nice.
[21:33]  * slangasek nods
[21:37] <slangasek> plars: we have some freshly signed wubi binaries; are you in a position to do some testing today?
[21:37] <slangasek> plars: quantal http://people.canonical.com/~dlawson/wubi-r273-signed.exe , precise http://people.canonical.com/~dlawson/wubi-r269-signed.exe
[21:42] <plars> slangasek: will take a look as soon as I can
[21:43] <slangasek> cheers
[21:49] <plars> slangasek: looks like we bought 2 more years :)
[21:49] <plars> slangasek: valid from 10/3/2012 to 10/6/2014
[21:50] <slangasek> yeah, I assume they only come in 2-year increments :/
[21:51] <slangasek> plars: so does it check out in terms of running without warnings?
[21:51] <plars> slangasek: yes
[21:51] <slangasek> plars: cool - did you test both of 'em?
[21:51] <plars> slangasek: I'm running the install from it now, but it no longer complains that it can't be verified
[21:51] <plars> slangasek: no, just the quantal one so far
[21:51] <slangasek> ok
[21:51] <slangasek> will wait for full results before I publish
[21:52] <TheLordOfTime> how do package versions change, from debian-sync to first ubuntu-only changes?
[21:52] <TheLordOfTime> for SRUs
[21:52] <plars> slangasek: by full, do you just want a run to make sure they don't complain? or installs from both?
[21:52] <slangasek> plars: if it's not too much effort, a full install from each to make sure you *actually* get the release you were expecting would be nice
[21:53] <slangasek> plars: otherwise, I can always try to binary diff them against the existing ones to see if they're the same binary, and call it good :)
[21:53] <plars> slangasek: it will take me some time, I've started the install with the quantal one, but need to go do some stuff. I'll be back on this evening for sure though
[21:54] <ScottK> TheLordOfTime: That's a better question for #ubuntu-devel or #ubuntu-motu.
[21:54] <TheLordOfTime> ScottK:  ah, well once someone in -motu answers, i'll know
[21:54] <TheLordOfTime> since they havent answered ;p
[21:55] <TheLordOfTime> ScottK:  trying to push a fix for an nginx segfault through, hence my asking multiple people to get an answer quickly
[21:55] <TheLordOfTime> (segfault bugs are evil)
[21:55]  * TheLordOfTime disappears to -motu
[21:56] <slangasek> TheLordOfTime: please don't treat #ubuntu-release as an escalation channel for questions you're not finding answers to in the regular channels; while people here probably know the answers, we're also here because we're busily trying to coordinate the release
[21:56] <TheLordOfTime> slangasek:  understood.
[21:59] <bdrung> bug #1067064 is a (late) FFe for vlc 2.0.4
[21:59] <ubot2> Launchpad bug 1067064 in vlc "FFe New upstream release 2.0.4" [Undecided,New] https://launchpad.net/bugs/1067064
[22:01] <ScottK> vlc is only seeded in mythbuntu and they aren't participating this time around, so it's possible.
[22:03] <ScottK> bdrung: What bout the libdvdnav comment?
[22:04] <slangasek> skaet: "translations" are still listed as an opportunity target with a question mark; seems to be getting rather late in the day for that.  Did the check with dpm/pitti happen?  Should this be removed from the pad?
[22:04] <bdrung> ScottK: the window release ships with a newer libdvdnav library and therefore fixes some bugs caused by the library. we build against the system libdvdnav and therefore take care to update the library.
[22:04] <hggdh> slangasek: on maas again
[22:05] <slangasek> hggdh: eta on refreshed server images is soon-ish
[22:05] <hggdh> k
[22:06] <slangasek> huh, sorry, thought I commented here about those already, but scrollback tells me I was lying to myself
[22:06] <slangasek> anyway, the livefs spins are all done so the images should be along shortly
[22:08]  * stgraber is done for the day, will do the heavy testing tomorrow morning, now that we have builds
[22:09] <stgraber> slangasek, cjwatson: I'm assuming you'll want me to start with ubuntu server amd64 on secureboot right (to make sure the shim installs fine and that the rest then boots)?
[22:09] <slangasek> stgraber: that would certainly be helpful, yes
[22:11] <ScottK> bdrung: What testing have you done on Quantal?
[22:11] <doko> cjwatson, I wouldn't care if kamailio is completely removed. it's only in sid, not wheezy
[22:23] <xnox> slangasek: partman checks for separate /boot in both d-i & ubiquity. More over you have to preseed or drop the promts level to be asked "do you really really wanna wanna no separate /boot"
[22:24] <slangasek> xnox: ah, really?  I wonder if that's what maxb did
[22:28] <skaet> slangasek,  yeah its too late in the day for them.   Should have happened earlier.    Remove from pad
[22:29] <slangasek> skaet: removed
[22:29] <slangasek> so the only thing I'm currently aware of that's a potential respin trigger is the apt issue when using Free Software Only mode
[22:30] <slangasek> I hope I can work out today how to fix that, by referencing Colin's fix for the previous instance
[22:30] <phillw> slangasek: and if we get ppc to work in alternate and server..... pretty please?
[22:31] <slangasek> phillw: bug #?
[22:31] <phillw> it got broke during RC respins, which is a pain!
[22:31] <xnox> slangasek: yeah. finished scrollback.
[22:31] <phillw> bug 1066435
[22:31] <ubot2> Launchpad bug 1066435 in linux "Debian-installer powerpc recursive fault" [High,Confirmed] https://launchpad.net/bugs/1066435
[22:32] <phillw> slangasek: and we are REALLY against the clock on this one, as it was a proposed route for the video card bug affecting nVidia graphics cards.
[22:32] <xnox> slangasek: does the 2-year increment means that wubi-precise is signed with now expired cert? Given that a release is supported for 18 months that R, S and T will become "unverified" ever so quickly?
[22:35] <skaet> hggdh, ^ new server images with MAAS
[22:36] <xnox> slangasek: there is a 3-year certificate
[22:36] <slangasek> phillw: as this is a kernel issue, it's highly unlikely that there's any room for a fix.  Furthermore, your analysis on the bug is inaccurate: you've concluded that this was a regression between 20121012 and 20121012.2 on the basis that one person said 20121012 worked for him and a different person said 20121012.2 failed for him, with no analysis of whether they're using the same hardware.
[22:37] <xnox> slangasek: about `apt-get update` bugs, ubiquity does run apt-get update, to get up to date sources & when installing langpacks, hw-packs, updates & third-party stuff.
[22:37] <phillw> slangasek: they are, as we speak, trying to get logs pulled together, but with a fail at such an early stage, this is not an easy task.
[22:38] <slangasek> phillw: as there were no powerpc-related changes to the kernel between those two builds, there's not much for a developer to go on here - which makes it a very low priority for anyone on the Canonical kernel team to work on, above and beyond the fact that powerpc is a community flavor that Canonical has no mandate to do this kind of work for
[22:38] <slangasek> phillw: people who want Ubuntu working on powerpc are going to have to be a bit more self-service
[22:39] <slangasek> phillw: I don't know what you mean by "early stage" - the bug reports that a crash happens at the *end* of install, which isn't early at all
[22:39] <phillw> slangasek: my apologies, I mis read the bug!
[22:40] <slangasek> xnox: well, it's not like we really care about users trying to install the release from a year ago via wubi, except in the case of an LTS
[22:41] <slangasek> xnox: so a 3-year cert might in theory be better, but at this point the 2-year cert has been purchased and I don't know if it makes sense for IS to try to go through the process again to get it extended (if that's even an option)
[22:42] <xnox> slangasek: ok. shall I open the bug for T-series to renew it with a 3-year option before T LTS is released, because this one will expire within ~2 months after T LTS is released =)
[22:43] <xnox> slangasek: actually 2-year cert just before LTS release is the best option for us.
[22:43] <xnox> 3-year one will get out of sync every other 3 years.
[22:43] <slangasek> xnox: sounds like a good idea, thanks
[22:45] <xnox> slangasek: 6.06 is/was the reason for june ssl cert?!
[22:46] <slangasek> xnox: don't ask me :)
[22:46] <slangasek> I wasn't here in 6
[22:46]  * xnox ponders who was... cjwatson ? doko ?
[22:47] <slangasek> true, true
[22:48] <slangasek> cjwatson, infinity: ok, I want to run 'remove-package -s quantal-proposed -m "Moved to -release" -e 2.12.12 ubiquity' to clean out -proposed, but the output unhelpfully includes no confirmation that this command is acting on quantal-proposed instead of quantal-release.  Can either of you confirm that this command is safe to run?
[22:51] <ScottK> slangasek: It generally includes such an unhelpful output and is generally safe to run.
[22:51] <slangasek> ScottK: thanks :)
[22:53] <bdrung> ScottK: i tested installation, music (flac, mp3) and video (mpeg) playback
[22:54] <ScottK> bdrung: On quantal?
[22:54] <bdrung> ScottK: yes, on quantal
[22:54] <bdrung> ScottK: i did test on precise too (mkv video playback) (for the upcoming SRU)
[22:54] <ScottK> bdrung: OK.  FFe approved.  Upload it ASAP (like the next few hours).  I'll mark it such in the bug.
[22:55] <bdrung> s/test/tests/
[22:55] <bdrung> ScottK: thanks
[22:55] <plars> slangasek, skaet: wubi quantal installer just worked for 64 bit, comes up ok after install for me
[22:55] <slangasek> plars: huzzah
[22:56] <skaet> thanks plars
[22:56] <plars> hggdh: arm install worked ok for me it seems, rebooting now
[22:56] <hggdh> plars: mine is working until reboot -- then nothing
[22:56] <plars> for desktop guided/full that is
[22:56] <hggdh> yes
[22:56] <plars> known issues with lvm+crypt
[22:57] <hggdh> no crypt install
[22:57] <plars> hggdh: seems to be working fine after reboot too
[22:58] <hggdh> hell
[22:58] <doko> skaet, there is this gcc-4.7 upload in the ubuntu-toolchain-r ppa (which was not uploaded to -propsed). should this go directly to quantal, or quantal-proposed? The one thing I'd like to make sure is that kernel uploads do use the new compiler version (which were already tested using the new compiler version)
[22:58] <hggdh> plars: OK. I will try changing the USB stick
[22:59] <bdrung> ScottK: uploaded
[22:59] <skaet> doko,  it needs to go through the SRU process as does any new kernel.  Can you help me understand the background on this change?
[23:01] <bdrung> ^ why mozilla? the vlc source does not ship the mozilla plugin any more.
[23:02] <doko> skaet, it's one c++ regression, plus aarch relevant changes. so I assume the correct procedure it to copy gcc-4.7 to -proposed, and once it is published, to accept the kernel source
[23:02] <ScottK> bdrung: Thanks.
[23:02] <ScottK> slangasek: I fixed remove-package to be more helpful.
[23:02] <slangasek> ScottK: ta
[23:02] <bdrung> ScottK: thanks for accepting the FFe :)
[23:04] <ScottK> bdrung: Accepted.  Talk to Colin (after the release) about the packageset question.
[23:19] <hggdh> plars: I was able to boot & login on my panda after editing preEnv.txt and taking out 'quiet splash'
[23:27] <skaet> doko,  what's the bug #s you and the kernel team are trying to fix with this compiler update?
[23:27] <xnox> now catched up on my mail.... wubi-precise also got re-signed \0/
[23:35] <cjwatson> slangasek: shouldn't matter whether the installer puts /boot outside LVM or not, because it also ensures that the first partition is aligned to 1MiB, allowing ample space for boot loader code.  Problems with fitting LVM booting into 62 sectors only affect those who originally installed before 10.04, or those who manually partitioned with non-default tools.
[23:35] <slangasek> cjwatson: ok
[23:36] <slangasek> cjwatson: I assume it's non-trivial for us to fix any of this on upgrade, and release noting is the only real option?
[23:40] <cjwatson> doko: definitely not the release pocket at this point, I'd say
[23:41] <cjwatson> slangasek: A real fix involves trying to shrink the grub code back down, when there's no single smoking gun, just general drift
[23:41] <slangasek> right
[23:41] <slangasek> and I'm skeptical that this constitutes a "real fix" vs. a temporary workaround
[23:42] <cjwatson> slangasek: The only things we could do on upgrade are to refuse the upgrade altogether, to warn that there may be a problem, or to store up an upgrade/boot problem for later
[23:42] <cjwatson> slangasek: Well, upstream would generally like not to cause scenarios to not fit in 62 sectors when they previously did ...
[23:43] <cjwatson> But this competes against bug-fixes
[23:43]  * slangasek nods
[23:43] <slangasek> cjwatson: oh, incidentally.. is it possible that keystatus doesn't actually work under EFI? ;)
[23:43] <cjwatson> EFI doesn't provide modifier key status
[23:43] <slangasek> heh
[23:43] <cjwatson> Not in any terribly useful way
[23:44] <cjwatson> So providing the module is basically just to shut up warnings
[23:44] <slangasek> so putting that module into the efi image was kinda pointless I guess
[23:44] <slangasek> right
[23:44] <cjwatson> We ought to undo the zero timeout on EFI, really, since it's impractical there
[23:45] <cjwatson> Due to spec limitations
[23:45] <slangasek> is that something we should push to have addressed in a future version of the spec?
[23:45] <cjwatson> Well, disclaimer: I last checked this several spec revisions ago, and it's possible there's been an extension since then
[23:46] <cjwatson> Can't check right now
[23:46] <cjwatson> If it isn't in 2.3.1, probably
[23:46] <slangasek> ok
[23:46] <slangasek> so in place of a zero timeout, what do we want?
[23:53] <cjwatson> So it's actually slightly possible that EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL.ReadKeyStrokeEx() does this now; it's not clear that if shift is depressed upon entry to grub, we'll get Key == 0 and KeyState = { <shift pressed> }
[23:53] <cjwatson> vs. EFI_NOT_READY
[23:54] <cjwatson> But I actually thought that if keystatus couldn't do anything useful, it degraded to a mumble-second timeout
[23:54] <slangasek> happy to test some code at leisure if you want to do up a patch
[23:54] <slangasek> but I think we probably both have bigger fish to fry at the moment
[23:54] <slangasek> (for instance, I have an actual install test to run, which is why I'm trying to interrupt my boot in the first place)
[23:55] <cjwatson> That's what the 'if keystatus; then ...' bit is supposed to be for
[23:56] <slangasek> so if it's not working, it's not supported?
[23:56] <cjwatson> Indeed
[23:56] <cjwatson> I suppose it's possible that you're getting the usb_keyboard input terminal on EFI rather than term/efi/console.c
[23:57] <cjwatson> But if so then you'd expect it to actually work ...