[02:23] that's me fiddling with backports [02:26] if someone has time to review ubuntustudio-default-settings/resping ubuntustudio after it builds, that would be rgeat [02:31] micahg: Is that really an RC issue to respin for? [02:32] ScottK: the file is copied on install, so yes (I asked them to document the info in the bug) [02:33] OK. Based on the bug, I agree. I'll accept it, but I can't do the respin. [02:33] 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] Right. [02:34] ScottK: thanks [02:35] * micahg disappears again [02:35] * micahg should probably add it to the pad first [02:38] pad updating, really gone now [02:38] *updated [03:12] micahg, ScottK: ubuntustudio build queued pending ubuntustudio-default-settings_0.39 publication [03:12] slangasek: Thanks. [03:45] 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] 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] good morning [07:27] 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] slangasek: I checked and I'm indeed running efifb under d-i === henrix_ is now known as henrix [08:17] 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] slangasek: do you want to add UEFI hooks to the ubiquity apport collection? e.g. efibootmgr --verbose (if available) [08:24] ? === henrix is now known as henrix_ [08:40] cjwatson: is it expected that the server image doesn't have (or can't find) the intel wireless firmware (iwlwifi-6000-*.ucode)? === henrix_ is now known as henrix [08:50] skaet: slangasek: I believe bug 1066480 is a dupe of bug 1046779 which has my comments there. [08:50] Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480 [08:50] Launchpad bug 1046779 in ubiquity "No option to resize full-disk encrypted installations" [Undecided,Won't fix] https://launchpad.net/bugs/1046779 [08:53] 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] 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] 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] (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] 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) === doko_ is now known as doko [09:19] stgraber: YA thing missing from nic-firmware-*.udeb, I guess [09:20] stgraber: 30s delay> I would say "try -proposed" except infinity screwed up the grub2-signed upload :) [09:20] cjwatson: I did? [09:21] cjwatson: you really know how to make someone's day go up and back down... [09:21] =))))) [09:22] 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 ... === balloons is now known as Guest98741 [09:27] 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] so I end up with an access denied error at boot time and the machine getting stuck there === mmrazik is now known as mmrazik|afk [09:28] stgraber: OK, sigh, not a giant surprise I guess but ... [09:28] stgraber: if you can manage to get me installer logs that'd help [09:31] adam_g_: Have you done any testing on the nova build in quantal-proposed? [09:36] 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] cjwatson: I'll grab the install log now [09:37] Oct 15 09:15:18 in-target: E: Unable to locate package shim-signed [09:37] cjwatson: http://paste.ubuntu.com/1280795/ for the full log [09:38] 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] So maybe shim-signed just isn't on the server CD [09:38] yeah, looks like it, that's what I'm checking now [09:38] I thought Steve had seeded it though [09:39] But maybe not [09:39] it's not in /pool/main/s [09:42] cjwatson: hmm, so I guess we'll want shim-signed in the /pool of all images [09:42] Yeah [09:43] good thing I tried a network-less install, would have been a bad surprise for anyone install on a secureboot system :) [09:44] So how is shim-signed in main? [09:44] * cjwatson checks germinate output [09:45] cjwatson: somebody promoted it, without seeding. [09:45] ?! [09:45] No [09:45] Oh, build-dep of d-i, of course [09:45] xnox: component-mismatches being empty is a fairly good clue that didn't happen [09:46] cjwatson: ok, thanks. makes sense. =) [09:46] 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] stgraber: already done [09:48] ok :) [09:48] d-i-requirements + ship-live + (probably obsolete but I don't feel like reorganising now) usb-ship-live [09:49] oh yeah, I should just have grepped for grub-efi-amd64-signed and added at the same places :) [09:49] yeah, exactly what I did [09:53] * stgraber grabs new grub2-signed from LP for a quick test [09:54] and it works! no more error message or delay at boot [09:55] Yay [09:55] Hopefully I didn't break BIOS - apw is testing that [09:58] 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] So of the "under investigation" things, I'm still worried about bug 1066347 [10:35] 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] cjwatson: i have just finish reproducing it and peaking at the apt-clone tarball now. [10:39] cjwatson: lovely. so the apt-clone tarball generated from within the installer has temp mountpoint leaked into the tarball. [10:39] Aha [10:39] cjwatson: it's /tmp/tmp.AYhUtphW4V/etc/apt/sources.list instead of ./etc/apt/sources.list [10:39] That explains it, I was wondering [10:40] cjwatson: is that enough for you to fix it =))))? [10:40] If you could upload a fix for that ASAP, I think we should have it [10:40] You have it in front of you :P [10:40] ah.... =( sigh. ok. [10:40] * xnox haven't done anything with apt-clone before yet. [10:41] =))) [10:41] Nor I, really [10:41] Apart from monkey-see-monkey-do py3 porting [10:41] xnox: If you can grab mvo, he might be able to help [10:42] =)))) barry will like that phrase:" Apart from monkey-see-monkey-do py3 porting" [10:49] xnox: I can help you after lunch just give me some details plase :) [10:50] mvo: bug 1066347 - respin-critical [10:50] 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] mvo: see bug 1066347. It looks like we are generating restore tarball using: apt-clone clone --with-dpkg-repack --source "$mountpoint" "$working" [10:52] 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] xnox: uh, I will try to be back asap from lunch [10:52] 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] xnox: if it would help bug 1066347 is similar to bug 1056815 where apt-clone-state tar file is attached [10:53] 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] 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] 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] 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] Given that bug 1066480 seems to have been punted? [10:53] Launchpad bug 1066480 in ubiquity "12.10 installer don't show encrypted partitions" [Critical,Confirmed] https://launchpad.net/bugs/1066480 [10:54] cjwatson: I can't remember, is apt-clone integrated in ubiquity or is it only in the dist-upgrader? [10:54] It's a dependency [10:55] cjwatson: well. I am punting it, but I want to hear a comment from $release-team to agree on punting it. [10:55] What I mean is actually, shall I upload ubiquity now with just this user-setup fix? [10:55] good, so it's just ubuntu-release-upgrader that we should rebuild once we have apt-clone fixed (just to be safe) [10:55] 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] 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] Way too late for string changes [10:56] * xnox thinks we have a template for "data" disk present ?! [10:57] ? is sufficient :-P [10:57] Or reuse the "other" option. Which maybe even more confusing [10:57] It does sound like it'll have to be a release note [10:57] i will not use capitalisation or punctuation any more because that will annoy cjwatson [10:57] cjwatson: true. [10:57] I only ask for normal punctuation :-) [10:58] Yeah, everyone knows it's ‽. [10:58] So, anyway, I tend to agree, but maybe worth confirming with QA whether they're prepared to consider it not stop-ship [10:59] I guess I should do a translation refresh if we need to upload ubiquity anyway [11:03] mvo, cjwatson, xnox: I found the problem, figuring out what's the best fix now [11:03] Oh, great [11:03] apt_pkg? [11:03] 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] I'll probably just go with stripping the source from that path as an easy workaround for that problem [11:04] Strip find_file("Dir") off the front, maybe [11:04] (Modulo details) [11:05] cjwatson: oh, yeah, using find_file("Dir") would be better than my current hack :) [11:05] stgraber: but for all the other files, we manually pass the correct name with tar.add($var, arcname='./correct/name') [11:05] after find_file returns absolute paths. [11:05] xnox: right, expect that for apt we don't have a fixed filename so can't go with just hardcoding it [11:06] stgraber: because of sources.list.d/*? [11:06] right [11:07] anyway, cjwatson's suggestion works fine, just cleaning up the code now, will have a diff in a minute [11:08] cool =) [11:09] stgraber: back and \o/ [11:11] mvo: http://paste.ubuntu.com/1280892/ [11:11] haven't tested the sources.list.d case yet though, I just assumed it'd also be affected, testing that now [11:13] right, sources.list.d is indeed affected but my fix doesn't work for this one, updating [11:15] 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" === mmrazik|afk is now known as mmrazik [11:16] mvo: because sources is /media/... instead of just /etc/apt/sources.list so you end up with ./media/... [11:16] stgraber: aha, that was the missing piece of info I needed :) [11:17] mvo: my patch is completely wrong btw... it's trying to copy the files from outside the target with my change [11:20] mvo: that one is good though: http://paste.ubuntu.com/1280901/ [11:21] there may be a better way of doing it, but that one is pretty short and obvious :) [11:24] 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] it's funny how it's first set apt_pkg.config.set("Dir", sourcedir), and then later retrieved again. [11:26] surely sourcedir should become self.sourcedir. but not during freeze =) [11:26] stgraber: I'll test your patch. [11:27] 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] xnox: ok. I tested it locally with an install I had on a usb disk (under /media/...), worked fine here [11:27] xnox: +1 for making it self.sourcedir, once there is a test its trivial to refactor [11:27] stgraber: I'll test with ubiquity's reinstall =) which i have here open ready to accept patches. [11:29] mvo: pushed and uploaded [11:30] 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] oh well =) [11:30] good enough. [11:34] Daviey: Do we know any more about bug #1066556? [11:34] 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] 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] 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] ah, right. Which reminds me I probably should have ran the unit tests before uploading... [11:36] * stgraber does that quickly now [11:39] 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] (rejected apt-clone, will fix the test and re-upload) [11:40] stgraber: its run as a pre-build hook in bzr-buildpackage [11:41] 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] 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] stgraber: oh, that is possible, I don't know about the details of ubuntu:apt-clone [11:42] xnox: yeah, indeed [11:47] xnox: dep8 test env added to trunk now [11:48] cool =) [11:49] next is the patch merge… [11:51] stgraber: with your patch the install still fails. [11:52] xnox: any idea why? [11:52] 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] stgraber: maybe you really want to set arcname to the right one =) without ifdefs ;-) [11:53] it's actually error from apt-clone restore [11:54] xnox: ok, so that matches my failure in the test suite, so that's already what I'm looking at now [11:54] Laney: Planning to fix handbrake's implicit pointer conversions? [11:55] infinity: I was just speaking to siretart about that [11:55] stgraber: http://paste.ubuntu.com/1280938/ [11:55] xnox: right, same thing I'm getting from the test [11:56] stgraber: so I suggest you explicetly set the acrname to ".(strip prefix)/" for all files. [12:05] stgraber: http://paste.ubuntu.com/1280948/ [12:05] ? [12:06] horum... still fails... [12:07] stgraber, xnox: hrm, hrm, so there seems to be a testcase for this already in TestClone.test_save_state and its failing! [12:08] mvo: yeah, it's just that whoever last uploaded didn't run it ;) or something changed in python-apt breaking it [12:08] stgraber: indeed [12:08] dep8 will rescue us in the future [12:09] 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] 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] xnox: it appears r101 is still working, at least the test unless that is a red-herring [12:12] when running the tests, the assert is failing because sources.list is in tmp/tmp6qdubj/etc/apt/sources.list [12:12] stgraber: right, that seems to be the issue then [12:13] stgraber: r103 is breaking the test but that is unreleated, right? [12:18] 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] mvo: so, one obvious problem is that Dir doesn't match the source in the tests [12:23] from my debug code: [12:23] base_path = ./data/mock-system/ [12:23] going with: /tmp/tmpKIvPei/etc/apt/sources.list, /tmp/tmpKIvPei/etc/apt/sources.list [12:23] if Dir was set to /tmp/tmpKIvPei/ then the test would pass [12:25] stgraber: could you please check http://paste.ubuntu.com/1280977/ ? [12:26] 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] mvo: test still fails with that code. sources.list is good but sources.list.d isn't [12:29] stgraber: hold on a sec [12:30] stgraber: http://paste.ubuntu.com/1280983/ <- bettter? [12:31] hehe, I just did the same change locally ;) and the answer is no [12:31] stgraber: heh :) odd, that is much happier for me [12:32] oh, actually nevermind, yours work... [12:32] stgraber: if its now also working in the realworld we may have a winner [12:32] stgraber: *fingerscrossed* :) [12:32] 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] mvo: hmm, there's still something wrong... I'm seeing duplicate entries now [12:33] 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] mvo: http://paste.ubuntu.com/1280992/ [12:36] mvo: oh, that's because you add the whole directory first [12:36] stgraber: ohhh [12:37] right, confirmed that commenting the for loop works fine [12:37] stgraber: that would not scrub passwords fromthe sources.list.d files [12:37] stgraber: so that needs fxing, hold on a sec [12:37] mvo: going with http://paste.ubuntu.com/1280999/ works here [12:38] except that the scrubbing won't work [12:40] mvo: http://paste.ubuntu.com/1281002/ that one works [12:40] stgraber: heh :) was just adding the same [12:40] stgraber: I will also update the test to ensure its not doing the double adding [12:41] stgraber: http://paste.ubuntu.com/1281005/ <- same as yours, just updates the test [12:43] mvo: self.assertTrue(len(sources_list_d) == set(sources_list_d)) [12:43] ? [12:43] mvo: self.assertTrue(len(sources_list_d) == len(set(sources_list_d))) [12:43] :P [12:44] xnox: I'm confused [12:44] xnox: self.assertTrue(len(set(members)) == len(members) ? [12:44] +) [12:44] stgraber: yeah. [12:45] 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] 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] xnox: so you'd first need to extract them as strings, then use set() [12:45] also there is now a TarFile.getnames() [12:45] no need to do the [m.names for m...] [12:45] xnox: oh, nevermind, the code already does that part :) [12:46] right [12:46] meh. let me rerun ubiquity with this new one =) [12:46] yeah, getnames() is nicer nowdays - [12:46] 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] testing with getnames() and the len(set()) thing [12:47] I see. =) [12:48] xnox: sorry, blind today now I get your suggestion about list/set compare [12:49] 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] stgraber: hm? isn't there data/mock-system/etc/apt/sources.list.d/ubuntu-....list ? [12:50] mvo: all lines are disabled, so it's ignored [12:51] stgraber: meeeh [12:51] stgraber: I think that is actually order dependant, the restorestatenewrelease is the problem [12:51] (I bet) [12:52] yeah.... we should be constructing to sorted lists and comparing them =/ [12:52] well the real test is whether ubiquity will manage to reinstall itself =) [12:54] * xnox running it now.... [12:55] yeay =) the tarball looks good... now waiting until the restore. [13:04] stgraber, xnox: finally! tests are happy with http://paste.ubuntu.com/1281041/ - I commit this to trunk now [13:05] :) [13:05] mvo: good, I was starting to poke at the apt config but you're clearly faster than me when dealing with python-apt ;) === Ursinha-afk is now known as Ursinha [13:06] 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] mvo: why did you remove accerciser? [13:08] stgraber: for me this now works, not sure what kind of artifact that is [13:09] ok, because here it's failing when it's not there [13:09] stgraber: oh, please add it back then, I investigate now why [13:09] mvo: stgraber: confirming that http://paste.ubuntu.com/1281002/ works in ubiquity [13:09] mvo: comparing two sets will not catch duplicates, but silently discard them. [13:10] xnox: meh, yes [13:10] mvo: sort the list & compare it with sorted expected list. [13:10] mvo: that should catch everything. [13:11] xnox: thanks, fixed and updated [13:13] stgraber / mvo: What's the status of the whole apt-clone thing? [13:13] apt-clone is python3 only - you could just use assertCountEqual [13:13] infinity: I'll upload in a few minutes [13:13] (>= 3.2) [13:13] cjwatson: cool =) we are settling on comparing two lists now to catch exact names & extra/missing items. [13:13] which is pretty much what assertCountEqual does [13:14] except less manual code :) [13:14] infinity: re-applying that last change from mvo, then running a few more tests on it and pushing [13:14] cjwatson: ah, cool =) [13:16] 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] skaet: We don't seem to have an elmo here, but we'll chase it up. [13:19] infinity, thanks. also been looking at /etc/issue on quantal - it has "Ubuntu 12.10 \n \l" , is that "\n \l" appropriate? [13:19] infinity: uploaded [13:20] mvo: final debdiff (pushed to ubuntu:apt-clone) http://paste.ubuntu.com/1281067/ [13:20] mvo: I went with cjwatson's suggestion to simplify your test a little [13:20] skaet: Yes. [13:20] tested locally with the test suite + my own system + an external system mounted in /media/ [13:21] \n and \l are documented in getty(8) [13:21] under "ISSUE ESCAPES" [13:21] 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] thanks cjwatson. :) [13:22] 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] skaet: I've asked Daviey for feedback, not sure what's ha... What he said. [13:23] 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] (obviously needs to happen, just trying to keep a handle on what are immediate issues) [13:23] 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] ah [13:23] Alright, well, they'll be up soonish. [13:24] Wonder if I can reproduce the MAAS thing in kvm [13:24] I obviously don't have a full setup [13:24] I guess it needs a server of some kind [13:24] cjwatson: is ubiquity in -proposed on purpose? cause then [35] trigger is not really "published and ready" [13:24] I don't really have enough context or details to be able to get anywhere [13:24] hggdh, ^ can you help cjwatson with reproducing? [13:25] xnox: avoiding arch skew [13:25] ack. [13:25] I don't want even transient uninstallability at this point [13:25] I didn't say [35] was "published and ready", FWIW [13:25] anyway, it's copyable now, I'll do that [13:25] * xnox the pad does. whoever that is. [13:25] =) [13:26] my bad, I saw it fix released, but didn't check the pocket it was in. [13:26] what's the maas bug # again? I have a maas server somewhere for testing [13:26] bug 1066556 [13:26] 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] thanks [13:26] https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1066556 [13:26] Launchpad bug 1066556 in debian-installer "MAAS installed via d-i/tasksel: fails when opening the browser to /MAAS" [Critical,Confirmed] [13:26] btw, would be nice of someone could review apt-clone in the queue [13:26] I will [13:27] looks easy to reproduce, I'll do that now [13:29] Looks OK to me [13:30] 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] stgraber: excellent, tell the server team that so that they get off my back about performance [13:30] :) [13:33] 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] ? [13:34] cjwatson: how can I help you? [13:34] maas bug reproduced [13:35] hggdh: no need now, I think [13:35] 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] (and in fact still will, if I understand this correctly, just now front-and-centre in the postinst) [13:36] rbasak: answer to your question in bug 1066556 is yes. Running dpkg-reconfigure and not changing anything fixes it. [13:36] 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] (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] 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] I think perhaps it's rather because the rabbitmq service is not started [13:38] (which is intentional and I recall telling the server team this - we don't start services during installation) [13:39] maas is broken post-install (after reboot) until you run dpkg-reconfigure [13:39] seb128: Is there a cherry-pick one could do for bug #1060171? [13:39] 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] stgraber: Indeed, but that matches roaksoax's analysis [13:39] xnox, cjwatson love it! [13:39] didrocks, popey, ^ [13:39] After reboot, rabbitmq will be running when you run dpkg-reconfigure [13:39] Which is the important bit - running dpkg-reconfigure during installation wouldn't help, if that analysis is right [13:39] ah, yeah, that makes sense [13:39] infinity, do you think it's worth trying to get on the iso rather than SRU0? [13:40] infinity: you mean for finale? [13:40] so one fix would be to move that logic into the maas upstart job which I assume properly depends on rabbitmq running [13:40] 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] 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] infinity: it's already on the SRU0 list, popey's team is supposed to have something ready to upload for tomorrow [13:41] didrocks: Alright. We'll see how that pans out, then. [13:41] infinity: well, the crash didn't get that much to ask for a cherry-pick in finale [13:41] 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] didrocks: Oh, it's not that common? There was a claim it was a "top crasher". [13:42] 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] infinity: 30 on errors.ubuntu.com, we cherry-picked way worse lenses fix :) [13:43] cjwatson: about bug 1066302 how come ubuntu-studio does not have release_notes_url? =) [13:43] 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] skaet: when i'm telling tomorrow, it's tomorrow for -proposed :) [13:43] 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] infinity: the fix is easy, if you have a respin plan, I don't object to backport it [13:43] didrocks, why not today for -proposed? [13:43] * xnox wonders who is ubuntu studio contact. [13:43] didrocks: Please upload then, yeah. [13:43] skaet: because we don't cherry-pick only that one [13:44] didrocks: If that had happened days ago, it would have gone into a respin by now. :/ [13:44] infinity: ok, let me do some testing first [13:44] xnox: 'cos debian-cd only doesthat for a given list of products [13:44] I can fix that if that's what the studio folks want [13:44] 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] scott-work: ^ [13:44] didrocks, only want a cherry pick of that one. Want to limit scope of change at this point. [13:44] otherwise I can push for you a fix everyday if you one :) [13:44] Actually I suspect studio didn't have it because it never used to be live [13:44] So I'm going to JFDI [13:44] skaet: we agree :) [13:45] skaet: infinity: look at what is planned for SRU0 for instance: https://launchpad.net/compiz/+milestone/0.9.8.6 [13:45] xnox: Still a ubiquity bug though [13:45] (you can see there are other crashes) [13:45] Should be showing different text if release_notes_url is unset [13:45] didrocks: Looking. [13:46] cjwatson: true. But if you fix studio, we don't need to release not it (1066302 that is) (highlighting skaet) [13:46] and unity itself: https://launchpad.net/unity/+milestone/6.10.0 [13:46] ack xnox [13:46] xnox: Sure [13:46] 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] xnox: I just want to make sure it's still open [13:46] cjwatson: ack. [13:47] didrocks: Not sure why this one bug was deemed more interesting than the rest. [13:47] because of its place on e.u.c [13:47] errors.ubuntu.com statistics on it. [13:47] skaet: Yes, I meant I wasn't sure why, other than statistics. :P [13:47] xnox: done [13:47] Frequency != Impact. [13:48] well, it's still a metric [13:48] infinity: who told you it was interesting? :) [13:48] we want to fix the most common issues [13:48] If it's guaranteed to explode right after install, and one can't upgrade, that would be critical. [13:48] didrocks: Whoever noted it in the pad. :P [13:48] * didrocks opens the pad :p [13:48] 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 === Guest98741 is now known as balloons === balloons is now known as Guest27823 [13:49]