[00:04] <cjwatson> slangasek: hmm, that crash in pkgCacheGenerator::NewVersion should have been fixed by the patch I pulled in from David
[00:04] <slangasek> well hmm
[00:06] <infinity> plars / hggdh: Either of you around?
[00:08] <skaet> infinity, plars is family time right now.   what's up?
[00:09] <infinity> skaet: Was just looking for someone who had a system with bug 1066376, but I'll just poke him in the morning.
[00:09] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New] https://launchpad.net/bugs/1066376
[00:09] <cjwatson> slangasek: So, I dunno.  I can look at it first thing tomorrow if you / somebody else haven't worked it out by then, although I also ought to look at bug 1066173.
[00:09] <ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [High,Confirmed] https://launchpad.net/bugs/1066173
[00:09] <skaet> infinity,  ok.    ogra_ may be online earlier, but I can't remember if his was showing it or not.
[00:10] <slangasek> cjwatson: well, I still have some time today that I'm hoping to spend looking at it (apt); hopefully that'll leave you free to worry about grub-installer
[00:10] <cjwatson> xnox's latest comment suggests it's actually ubiquity, but yeah
[00:11] <slangasek> cjwatson: btw, not sure if you saw my comment the other day about /boot/efi being a problem for the "reinstall Ubuntu" path?  I don't think that's a blocker bug in itself, but I'm wondering if it suggests a deeper problem with the mount handling somewhere (os-prober?) that could have a more widespread effect
[00:11] <cjwatson> slangasek: I don't think I did see that comment, no
[00:12]  * infinity is somewhat tempted to just replace the manual list of HID drivers with a copy_modules_dir call instead.
[00:12] <infinity> Unless someone can give me a fancy way of sorting out if a module in that directory is or isn't a keyboard driver.
[00:13] <cjwatson> slangasek: FWIW my technique for tracking the previous apt bug down involved building a chroot with suitable sources.list, a debug build of apt, and gdb installed, bisecting to find the number of iterations of the affected function that ran before the segfault, and then observing pointer values on stepping through the crashing iteration
[00:13] <cjwatson> Perhaps the Dynamic trick isn't working due to that being a & parameter or something
[00:14] <cjwatson> I checked for any other instances of the same bug I fixed, so this is a qualitatively different one
[00:15] <cjwatson> Although it certainly feels similar
[00:15] <slangasek> cjwatson: the /boot/efi thing was bug #1066653
[00:15] <ubot2> Launchpad bug 1066653 in ubiquity ""reinstall Ubuntu 12.10" on efi system fails when trying to mount /boot/efi" [Medium,New] https://launchpad.net/bugs/1066653
[00:15] <slangasek> cjwatson: thanks for the debug hints
[00:15] <cjwatson> OK, will have to look tomorrow ...
[00:15] <slangasek> ok
[00:15]  * cjwatson crashes, just like apt
[00:16]  * infinity too.
[00:37] <skaet> slangasek,  confirm that WUBI i386 using the new signed image works.
[00:45] <hggdh> infinity: I am here
[00:49] <slangasek> hggdh: he said he was looking for help on bug #1066376, but he's EOD now
[00:49] <ubot2> Launchpad bug 1066376 in initramfs-tools "keyboard doesn't work to enter password with panda and encrypted partitions" [Undecided,New] https://launchpad.net/bugs/1066376
[00:50] <hggdh> slangasek: I will have to leave for the airport (picking up my wife) in a few, but I will try
[00:51] <slangasek> hggdh: well, I don't think there's anything to try because he didn't actually say what he wanted help with beyond giving the bug #: )
[00:51] <hggdh> slangasek: I know what was the issue -- keyboard unavailable for entering the disk encryption passphrase on arm, so I can try it
[00:52] <slangasek> hggdh: I don't think he's asking for a reproduction test
[00:52] <slangasek> hggdh: so really, don't worry about it
[00:53] <hggdh> slangasek: ack. I think he wanted us to check the new arm image
[00:53]  * hggdh misplaces yet another USB memory stick
[00:54] <slangasek> hggdh: there haven't been any changes accepted into quantal for this bug
[00:54] <slangasek> so there's really no new image to check :)
[00:54] <hggdh> slangasek: oh. /me disregards it, then until tomorrow
[00:56] <skaet> slangasek, https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1067134
[00:56] <ubot2> Launchpad bug 1067134 in grub2 "when booting fresh install on i386 system, screen output shows evidence of buffer overwrites" [High,New]
[01:26] <skaet> slangasek,  apport-collect info gatherered and added to bug.   anything else you want for it before I EOD?
[01:32]  * skaet will leave system up,  but time for dinner now
[02:15] <micahg> can someone please process Bug #1033325 before it gets too late?
[02:15] <ubot2> Launchpad bug 1033325 in vala-0.10 "Please remove vala and vala-0.10 source packages from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1033325
[02:15] <infinity> micahg: Sure.
[02:16] <slangasek> infinity: sleep
[02:16] <micahg> isn't deleting stuff from the archive what everyone aspires to do at 3AM?
[02:17] <infinity> slangasek: I slept.  For, like, 3 hours.
[02:17] <micahg> and dynamips above is an FTBFS fix
[02:17] <slangasek> grr, why are there no longer any working instances of checkrdepends
[02:18] <micahg> slangasek: reverse-depends if you need something without setup
[02:18] <slangasek> I don't know what reverse-depends is, how do I know I can trust it? :)
[02:19]  * micahg introduces slangasek to tumbleweed
[02:19] <slangasek> tumbleweed is not an archive admin, his tool may not do what I want
[02:19] <slangasek> indeed, it does not
[02:19] <micahg> slangasek: I can paste you output of reverse-depends
[02:19] <micahg> oops
[02:19] <micahg> I meant checkrdepends
[02:19] <infinity> slangasek: 'reverse-depends src:vala-0.10 ; reverse-depends -b src:vala-0.10' is probably what you wantr.
[02:20] <infinity> s/wantr/want/
[02:20] <infinity> Anyhow, I'll try to get more sleep.
[02:20] <infinity> Oh, but first.
[02:21] <slangasek> two commands! fie
[02:21] <infinity> hggdh: If you still have a panda with crypted root that can only be unlocked via serial, can you jump on the #1066376 bandwagon and give me an lsmod of the booted system?
[02:23] <infinity> hggdh: And if it happens that it also wants hid_logitech_dj, can you patch /usr/share/initramfs-tools/hook-functions by hand to add "hid-logitech-dj" in the same block as you find "hid-generic", run "sudo update-initramfs -u", and reboot and see if that's all you need to make it go?
[02:23] <infinity> And this should all be in the bug.
[02:23]  * infinity copies and pastes.
[02:24] <slangasek> yeah, check-rdepends doesn't do what I want; I don't want a list of 50 interdependencies between awn-extras and avant-window-navigator and have to hand-inspect each one to make sure it's what it appears
[02:26] <slangasek> s/check-rdepends/reverse-depends/
[02:28] <micahg> oh, I didn't know checkrdepends accepts multiple pacakges
[02:28] <micahg> that's a cool feature :)
[02:28] <slangasek> ;)
[02:29] <micahg> slangasek: I can give you the output of checkrdepends from a packages mirror from Friday if you like
[02:30] <slangasek> micahg: I've got it now, thanks
[02:30] <plars> infinity: back
[02:31] <slangasek> plars: I believe infinity's request for you is the same as what he just asked hggdh for 10 minutes ago in scrollback
[02:31] <slangasek> micahg: bug #1033325 dispatched
[02:31] <ubot2> Launchpad bug 1033325 in vala-0.10 "Please remove vala and vala-0.10 source packages from Ubuntu" [Undecided,Fix released] https://launchpad.net/bugs/1033325
[02:32] <micahg> slangasek: thanks
[02:33] <plars> infinity: I included an lsmod in the bug report since yesterday when I opened it
[02:35] <infinity> plars: Yeah, I wanted to know if his was the same keyboard.
[02:36] <infinity> plars: But I'm betting it is.
[02:36] <plars> infinity: I have at least two different keyboards here I can try it with, it does it on both
[02:36] <plars> infinity: I'll need to reinstall before I can really try anything though
[02:37] <infinity> And this is totally just the fault of our static module list being longer/different than Debian's, and thus me failing to merge this one change (it's the only module they include that we don't).
[02:37] <infinity> I'm just going to upload with that one change.
[02:37] <infinity> plars: My bet is that they both use the logitech-dj driver.
[02:37] <plars> infinity: one does, the other is a dell generic usb keyboard and likely does not
[02:38] <infinity> Dell doesn't manufacture hardware.
[02:38] <infinity> It's probably a logitech. :P
[02:40] <bjf> infinity, my usb keyboard: http://pastebin.ubuntu.com/1282357/
[02:40] <infinity> bjf: And what driver does it use?
[02:41] <infinity> (Anyhow, I'm confident the 1-line change I'm about to upload is what we want/need anyway, for other reasons)
[02:41] <infinity> And, furthermore, this needs to be SRUed.
[02:42] <plars> infinity: right, but when I plug this "dell" (yeah, I realize they didn't make it) into my laptop, I don't see any logitech driver. However, when I plug in the logitech one, I do
[02:42] <infinity> plars: Fair enough.  Does the Dell one also fail to love the Panda?
[02:42] <plars> infinity: with the dell one, I just get usbhid
[02:42] <plars> infinity: yes, they both do
[02:42] <bjf> infinity, hid_logitech_dj
[02:42] <infinity> plars: And, if so, an lsusb on that would also be nice (when it's booted and working).
[02:43] <infinity> bjf: That's kinda what I expected.
[02:43] <bjf> infinity, yup
[02:43] <infinity> plars: Err, and lsmod, I mean.
[02:44] <plars> infinity: they had both been plugged in with the one I provided yesterday, but I'll limit it to just the generic usb keyboard this time
[02:45] <plars> I had tried swapping them to make sure it wasn't keyboard specific
[02:52] <infinity> Alright, I'm going to bed again.
[02:53] <infinity> slangasek: That initramfs-tools should fix people's logitech keyboards.  For bonus points, there's also an upload in precise-proposed that brings the hid module list in line.
[03:39] <plars> infinity: updated the bug
[04:24] <slangasek> infinity: hid from initramfs, only on ARM, hardware-specific> this seems to me like something we can take as a target of opportunity rather than something that warrants a respin on its own
[04:24] <slangasek> infinity: so I'm going to leave it in the queue and mark it on the pad, for now
[07:25] <stgraber> good morning
[07:28] <cjwatson> slangasek: checkrdepends is still usable as ubuntu-archive@lillypilly
[07:35] <infinity> slangasek: It's not ARM-specific, but yes, it's not worth a respin all by itself.
[07:38] <cjwatson> OTOH looks like we still have those open apt and ubiquity issues ...
[07:40]  * infinity -> office.
[07:49] <tumbleweed> micahg: reverse-depends is more of a QA tool then an AA one (it coalesces alternative dependencies). Patches / suggestions welcome, of course :)
[07:52]  * stgraber -> out for the next 15min or so, testing secureboot on server amd64
[08:07] <stgraber> slangasek: so, we're getting closer but still not there...
[08:08] <stgraber> cjwatson: Install media boots fine, install succeeds, shim-signed gets installed and grub shows up post-install
[08:08] <stgraber> cjwatson: but then grub won't let me boot an unsigned kernel so I'm getting stuck when booting the installed system
[08:09] <stgraber> cjwatson: the same grub detected my existing system (with a signed kernel) and booting that entry works fine, it's really just the new server system with an unsigned kernel that won't boot
[08:10] <stgraber> cjwatson: I ran with debug=all and am getting the same thing I pasted the other day (bunch of efidisk read while loading the kernel, then "Locating shim protocol" and stuck there)
[08:19] <cjwatson> stgraber: well, independently of whether unsigned kernels should be bootable (they should, but that may be a system-specific problem), there's then the question of why a signed kernel wasn't installed
[08:19] <cjwatson> stgraber: Any way to get installer logs?
[08:19] <stgraber> cjwatson: sure
[08:21] <stgraber> cjwatson: http://paste.ubuntu.com/1282678/
[08:22] <stgraber> cjwatson: would it be useful for me to try installing the desktop image see if we get the same problem with ubiquity?
[08:23] <cjwatson> Sure, but I bet you won't since I see where this problem is
[08:23] <stgraber> good :)
[08:23] <cjwatson> base-installer bug
[08:23] <cjwatson> (If you could file one ...)
[08:23] <stgraber> sure
[08:25] <stgraber> cjwatson: bug 1067250
[08:25] <ubot2> Launchpad bug 1067250 in base-installer "Installing quantal server amd64 on secureboot, shim-signed is installed but linux-signed isn't" [Undecided,New] https://launchpad.net/bugs/1067250
[08:25] <cjwatson> Thanks.  I should look at this apt bug first, though.
[08:27] <cjwatson> Since it doesn't look like Steve managed to sort it overnight
[08:40] <stgraber> cjwatson: hmm, just spotted another problem, looks like Edubuntu (at least) doesn't ship the signed kernel
[08:42] <cjwatson> Yeah, we haven't in general had a chance to ensure that all the flavours have secure boot bits sorted out properly
[08:42] <cjwatson> Because this all landed so late
[08:42] <cjwatson> If you want to tweak your seeds, feel free
[08:42] <infinity> I thought we'd put it in a common seed?
[08:42] <stgraber> yeah, I'll have to figure out exactly what happened there as in general edubuntu inherits everything from ubuntu and just adds a bunch of packages on top
[08:43] <infinity> Oh, not for ship.
[08:43] <cjwatson> infinity: exactly
[08:47] <stgraber> oh right, and the live seed is the only thing we don't include as a whole from ubuntu in edubuntu... we just use live-common. Will do some copy/pasting and do a quick respin of Edubuntu to ensure it's good (no test results at the moment and it's a reasonably quick build nowadays)
[08:48] <cjwatson> Pretty sure we have some more respin-everythings coming up :-/
[08:48] <infinity> apt's good for that.
[08:48] <cjwatson> (bug 1067056, bug 1066173)
[08:48] <ubot2> Launchpad bug 1067056 in apt "apt-get crashed with SIGSEGV during installation in pkgCacheGenerator::NewVersion ()" [Critical,Confirmed] https://launchpad.net/bugs/1067056
[08:48] <ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [High,Confirmed] https://launchpad.net/bugs/1066173
[08:49] <stgraber> yeah, it's just that I want to get that secureboot stuff done with ASAP so I can use my machine for VM testing and stop having to reboot and reconfigure EFI every 10 minutes ;)
[08:50] <cjwatson> Heh
[08:50] <cjwatson> Fair enough
[08:50] <cjwatson> Won't be ready with base-installer for a while - still not really awake :-/
[08:50] <stgraber> seed updated, started a rebuild of edubuntu i386/amd64 now. Shouldn't take much more than 30min so should finish way before the next respin
[08:51]  * stgraber updates the pad
[08:54] <infinity> cjwatson: I don't recommend waking up.
[08:54] <infinity> cjwatson: It's not working out well for me.
[08:59] <cjwatson> jibel: Hmm, I can't reproduce bug 1067056 with the directions given
[08:59] <ubot2> Launchpad bug 1067056 in apt "apt-get crashed with SIGSEGV during installation in pkgCacheGenerator::NewVersion ()" [Critical,Confirmed] https://launchpad.net/bugs/1067056
[09:00] <cjwatson> jibel: Any way I could get the contents of /etc/apt/ at the point of the crash?
[09:01] <jibel> cjwatson, of course, I'll attach it to the report
[09:01] <cjwatson> Thanks
[09:02] <jibel> cjwatson, https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1067056/+attachment/3399940/+files/_etc_apt.tgz
[09:02] <ubot2> Launchpad bug 1067056 in apt "apt-get crashed with SIGSEGV during installation in pkgCacheGenerator::NewVersion ()" [Critical,Confirmed]
[09:02] <jibel> I'll try to recreate the crash again
[09:03] <cjwatson> Huh, ddebs were present in sources.list during installation?
[09:03] <cjwatson> sources.list.d/ddebs.list anyway
[09:05] <jibel> no, I added after the crash to generate the back trace
[09:07] <cjwatson> Ah
[09:18] <stgraber> xnox: hey, do we have any weird/critical partman/ubiquity bug at the moment? I'm trying to figure out why my VM seems to always get stuck loading partman (hangs after clicking Continue on the prepare step)
[09:19] <stgraber> xnox: manually wiping the partition table and rebooting seems to fix it, though starting ubiquity again after the system is installed gets me the same thing again (so it's not a temporarily messed up partition table)
[09:19] <xnox> stgraber: well, we do have a bug with VirtualBox which I cannot reproduce yet.
[09:19] <jibel> cjwatson, I can't reproduce the apt crash this morning with the same image than yesterday, free software only i.e main and universe only.
[09:20] <stgraber> xnox: I'm running in kvm here
[09:20] <xnox> stgraber: http://pad.lv/1065502  ?
[09:20] <xnox> similar?
[09:20] <xnox> oh and there is something funny about mounting efi partitions ?!
[09:20] <stgraber> xnox: certainly looks like it
[09:21] <xnox> https://launchpad.net/bugs/1066653
[09:21] <ubot2> Launchpad bug 1066653 in ubiquity ""reinstall Ubuntu 12.10" on efi system fails when trying to mount /boot/efi" [Medium,New]
[09:21] <xnox> bug 1065502
[09:21] <ubot2> Launchpad bug 1065502 in ubiquity "[VirtualBox] Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[09:21] <stgraber> xnox: it's not an EFI system. It's a standard kvm VM so good old BIOS
[09:23] <stgraber> xnox: looking at the process tree, it looks stuck on /lib/partman/automatically_partition/25replace/choices
[09:24] <xnox> stgraber: ooh reproducer of bug 1065502. I didn't manage to reproduce it with kvm.
[09:24] <ubot2> Launchpad bug 1065502 in ubiquity "[VirtualBox] Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[09:24] <xnox> stgraber: can you paste ps tree?
[09:24] <cjwatson> jibel: Yeah, I can't do it with that /etc/apt/ either, although I hadn't yet got round to plugging in apt-cdrom configuration
[09:24] <stgraber> xnox: I'm trying to reproduce it from a full ubuntu session so I can give you VNC access to the VM
[09:25] <cjwatson> jibel: I suspect this has been avoided by essentially arbitrary changes to archive indexes, and we won't be able to debug it until it happens again
[09:25] <cjwatson> (And we also don't need to consider it RC unless it comes back)
[09:25] <cjwatson> jibel: FWIW, if it happens again, immediately take a tarball of /etc/apt/ and /var/lib/apt/
[09:26] <cjwatson> jibel: That will then let us debug it regardless of archive changes
[09:26] <jibel> cjwatson, I still have a snapshot of the previous VM in a broken state, you want the indexes ?
[09:27] <jibel> and bug  1067244 is a recent duplicate with the restricted and multiverse enabled
[09:27] <ubot2> Launchpad bug 1067244 in ubiquity "installation crashes (dup-of: 1067056)" [Undecided,Confirmed] https://launchpad.net/bugs/1067244
[09:27] <ubot2> Launchpad bug 1067056 in apt "apt-get crashed with SIGSEGV during installation in pkgCacheGenerator::NewVersion ()" [Critical,Confirmed] https://launchpad.net/bugs/1067056
[09:28] <cjwatson> jibel: Oh, yes, definitely
[09:28] <cjwatson> I'm certainly up for debugging this if at all possible
[09:32]  * smartboyhw thinks stgraber can update the pad again since the build has finished:D
[09:33] <stgraber> smartboyhw: I'm grabbing them now to check that I have the right kernel on them, otherwise I'll need to tweak the seed again and respin
[09:33] <smartboyhw> stgraber, ah:P
[09:34] <cjwatson> stgraber: Do you think I should upload this base-installer fix to quantal-proposed or quantal?
[09:34] <cjwatson> infinity: ^-
[09:35] <stgraber> cjwatson: well, the plan is to respin with it and it's not one of those potential skew packages, so quantal should be fine
[09:35] <infinity> cjwatson: quantal it up.
[09:35] <infinity> cjwatson: And while you're at it, accept my initramfs-tools, now that we have something else we need to respin for.
[09:40] <cjwatson> Right
[09:40] <stgraber> cjwatson, infinity, skaet: added bug 1065502 as "UNDER INVESTIGATION FOR REBUILD TRIGGERS". We've seen multiple occurences of it now and it's not limited to a single VM type, xnox is looking at it (he has access to my VM)
[09:40] <ubot2> Launchpad bug 1065502 in ubiquity "[VirtualBox] Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[09:40] <smartboyhw> Hmm I don't get THAT bug....
[09:40] <smartboyhw> Is there actually a package name for the signed linux kernel?
[09:41] <cjwatson> Yes
[09:41] <smartboyhw> cjwatson, er what is the name?
[09:41] <cjwatson> apt-cache search linux-signed
[09:41] <cjwatson> (That's the source package name, but that command will show the binary package names)
[09:42] <jibel> cjwatson, https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1067056/+attachment/3399977/+files/_var_lib_apt.tgz
[09:42] <ubot2> Launchpad bug 1067056 in apt "apt-get crashed with SIGSEGV during installation in pkgCacheGenerator::NewVersion ()" [Critical,Confirmed]
[09:42] <smartboyhw> cjwatson, thx. stgraber then I don't think the signed kernel is in the new build , I can't see them in the manifest....Or am I wrong?
[09:42] <cjwatson> New build of what?
[09:42] <jibel> I also have var/cache/apt if there is some value, but that's another 40MB upload
[09:43] <cjwatson> jibel: I don't think I need that, but I'll let you know
[09:43] <smartboyhw> cjwatson, edubuntu
[09:43] <stgraber> smartboyhw: you're right, I'm looking into that now
[09:43] <smartboyhw> stgraber, :D
[09:45] <cjwatson> stgraber: dvd-live is a task-generating seed; I suspect you didn't wait for enough publisher runs
[09:45] <cjwatson> Indeed, given that quantal's frozen and that there were no accepts for some hours, there may not have been a relevant publisher run until the one that's starting in ~18 minutes
[09:46] <stgraber> cjwatson: yeah, that sounds like it. I'll wait until the next run is done and check that the Task field is properly updated
[09:50] <xnox> stgraber: naturally adding `set -x` to the replace/choices and re-running ubiquity makes the bug disappear....
[09:55] <cjwatson> jibel: Thanks, that's enough to reproduce it in a chroot with 'apt-cache gencaches'
[09:56] <stgraber> xnox: wouldn't be fun otherwise :)
[09:57] <infinity> Does someone want to have an opinion about the apport upload in the queue?
[09:57] <xnox> stgraber: may I reboot it?
[10:00] <stgraber> xnox: sure
[10:01] <stgraber> xnox: there you go. (It ejected the cd-rom so I had to kill it and restart it)
[10:02] <xnox> stgraber: thanks.
[10:06] <xnox> stgraber: it was a "serial installer" habbit? installed and didn't boot into the installed system & try to install again?
[10:06] <stgraber> xnox: could have been
[10:07] <stgraber> xnox: actually, yeah, the previous install was done and never booted as I was trying to reproduce the non-free bug jibel mentioned earlier
[10:12] <jibel> xnox, despite being a serial installer, I always reboot the system I installed. But I noticed that disks are often not cleanly unmounted in vbox.
[10:12] <xnox> s/often/always/
[10:12] <apw> cjwatson, i have had a little bit of a poke at this "install from usb to usb with a disk present" install.  from what i can see dispite knowing that target is on sdc, it decides to install to 'the default boot disk' as long as that is not the 'cd'.  grub-mkdevicemap is used to get the disks which returns the internal drive first
[10:14] <cjwatson> xnox's analysis suggested that it might be because we're not setting the boot device debconf question in all partitioning scenarios
[10:16] <cjwatson> I haven't had a chance to poke yet ...
[10:18] <apw> cjwatson, i can see how that might do it, if its not set we'll use the value i am aluding to, which is indeed wrong and what we used.
[10:21] <stgraber> apw, cjwatson: I can take a look at that bug if you want. Should be easy to replicate in a VM.
[10:21] <cjwatson> Please
[10:21] <stgraber> apw: got a bug #?
[10:21] <cjwatson> Slightly overextended at the momt
[10:21] <cjwatson> moment
[10:22] <cjwatson> stgraber: bug 1066173
[10:22] <ubot2> Launchpad bug 1066173 in ubiquity "whole disk install puts grub in wrong place" [High,Confirmed] https://launchpad.net/bugs/1066173
[10:22] <cjwatson> Of course it's possible this is misdesign - it used to be that hd0 was a good default because that was likely to be where the system booted from
[10:22] <stgraber> hehe, yeah I figured and xnox is probably busy trying to reproduce and debug bug 1065502
[10:22] <ubot2> Launchpad bug 1065502 in ubiquity "Ubiquity failed to proceed to partman, fails at replace recipe now..." [High,Confirmed] https://launchpad.net/bugs/1065502
[10:23] <cjwatson> We might need to add yet another special case, namely the case where you're installing to removable media which is a good indication you don't want the boot loader on a fixed disk
[10:23] <cjwatson> If you do that then be careful to change the corresponding code in both grub-installer and ubiquity (sorry)
[10:23] <cjwatson> At least the one in ubiquity has test cases
[10:23] <cjwatson> I had a reason for duplicating it but I forget what it was; possibly to be able to set the default value in the drop-down long before grub-installer starts
[10:24] <cjwatson> In future perhaps a good partial-simplification rule would be that the default boot loader location should be constrained to be of the same type (fixed or removable) as /boot
[10:25]  * cjwatson develops a nasty suspicion about apt
[10:25] <cjwatson> I think David got it wrong
[10:25] <cjwatson> IOW if I'd just left well alone and not backported his patch, it would have been fine
[10:30] <cjwatson> ... and he's already reverted it in trunk
[10:31] <cjwatson> Fortunately I didn't backport that patch in my SRU
[10:32] <infinity> cjwatson: I eagerly await your revert. :)
[10:33] <cjwatson> Yeah, just testing
[10:35] <cjwatson> That fixes it - partial revert on its way
[10:41]  * infinity is trying to sort out why that apport has a patch in debian/patches.
[10:49] <stgraber> cjwatson: managed to reproduce the bug with a VM using two virtio disks and a cdrom drive. When installing to whatever is /dev/vda it works fine, when installing to /dev/vdb it fails as /dev/vda is perfectly blank (no partition table) and grub-install fails when run against it ("unable to identifiy a filesystem in hostdisk/dev/vda: safety check can't be performed"
[10:50] <stgraber> at least it lets me select another drive in that case
[10:50] <cjwatson> Almost a different bug, although similar - the removable vs. not case is more immediate, isn't it?
[10:51] <stgraber> yeah, the problem here is that kvm is terribly slow when running with usb disks (I gave up after 10min trying to boot the installer) so I can't actually test with removal usb disks...
[10:51] <xnox> usb 1.0 only emulation =/
[10:51] <cjwatson> While I think some of this suggests that in future maybe we should just always install to the disk containing /boot, I'm wary about doing this across the board two days before release; it's a bigger code change, and I'm worried that it will produce a different set of complaints
[10:52] <cjwatson> Of the form "I installed Ubuntu to my second hard disk and it doesn't boot by default"
[10:52] <cjwatson> I don't know, maybe attempting to fix that was misguided
[10:52] <xnox> my worry is that rarely boot options on a machine list USB before internal HDD by default =(
[10:52] <cjwatson> Sure, I absolutely think we should fix the USB vs. not case
[10:53] <cjwatson> But I'm wary about changing the first HDD vs. second HDD case right at the moment
[10:53] <cjwatson> Even if perhaps we ought to change it in the future
[10:53] <xnox> ack.
[10:53] <cjwatson> USB vs. not is what's going to get us the lion's share of bugs, I think
[10:53] <stgraber> I'll figure out the required code change to make my VM work, then will put that under a check for the removable flag on the disk, that should let me test it easily and then do what we actually want
[10:53] <infinity> bdmurray: Your apport upload is rather goofy.
[10:54] <infinity> bdmurray: You have a populated .pc in your diff.
[10:54] <xnox> also ubiquity does rw mount to check for wubi.... totally should be ported to grub-mount, partman detection, or maybe both.
[10:54] <stgraber> (and poke apw so he test whatever change I come up with)
[10:55] <apw> stgraber, have the machine sitting here indeed
[11:15] <stgraber> apw: so, looking at the code, the logic seems right... ubiquity should only be looking at (hd0) in the device map if the drive containing /boot isn't removable
[11:18] <apw> stgraber, and how does it decide that
[11:18] <stgraber> at least I managed to get usb2 running in kvm so I should be able to debug the removable handling code
[11:18] <stgraber> apw: it queries using udev
[11:19] <stgraber> apw: can you paste: udevadm info -q property -n /dev/sdX ?
[11:19] <apw> stgraber, presumably from the 'installer' boot ... will do
[11:20] <xnox> "imuxsock begins to drop messages from pid 4274 due to rate-limiting" *sigh*
[11:20] <stgraber> apw: the content of /sys/class/block/sdX/removable would also be useful
[11:20] <apw> stgraber, ack
[11:31] <apw> stgraber, http://paste.ubuntu.com/1282881/ and /removable is 1
[11:32] <stgraber> apw: can you get the same against the first partition of that disk?
[11:37] <apw> stgraber, http://paste.ubuntu.com/1282880/ and /removable is not there
[11:43] <stgraber> apw: can you try to run http://paste.ubuntu.com/1282898/ with /dev/sdX and /dev/sdX1 as argument?
[11:43] <infinity> stgraber: Bin that with debian, so he can download it without logging in? :P
[11:44] <stgraber> http://paste.debian.net/201016/
[11:46] <apw> stgraber, http://paste.ubuntu.com/1282905
[11:46] <apw> stgraber, http://paste.ubuntu.com/1282906
[11:46] <apw> sdc == 05, sdc1 == 06
[11:46] <stgraber> ok, so that part of the code works fine
[11:52] <stgraber> apw: can you replace /usr/lib/ubiquity/ubiquity/misc.py with http://paste.debian.net/201017/, run and install and don't reboot at the end (stay in the live environment)?
[11:53] <apw> stgraber, will do
[11:54] <stgraber> apw: I'm going to want /var/log/syslog /var/log/installer/* /var/cache/debconf/* and maybe even /target/var/cache/debconf/* once that install is over
[11:54] <apw> ack
[11:54] <stgraber> that should let me grab all the debug statements I added, check what grub-install ran against and what's stored in debconf
[11:56] <apw> stgraber, ok
[11:58] <cjwatson> infinity: Can you reproduce the spandsp/amd64 build failure?
[12:03] <infinity> cjwatson: Not sure, was looking at gmap/ppc.  Let me spin up a testbuild ot spandsp.
[12:03] <cjwatson> I'm trying in a (virt) PPA now, but it won't fail locally
[12:04] <infinity> cjwatson: I blame the uploader.
[12:06] <cjwatson> Well, quite
[12:07] <cjwatson> Could revert to older tiff and see if that helps, I guess, except: it has rdepends; I don't understand why it only breaks on amd64; and it would be nice to be able to reproduce the build failure in case the old source just FTBFS now
[12:07] <infinity> cjwatson: Didn't fail locally here either.  Hrm.
[12:08] <infinity> That error doesn't look like the sort of thing that should be reliant on environment.
[12:12] <cjwatson> Worked in my PPA
[12:12] <cjwatson> infinity: Do you think you could try copying the source into a devirt PPA and see what happens?
[12:12] <infinity> cjwatson: Sure.
[12:12] <cjwatson> I wondered if it might depend on -j or something
[12:14] <infinity> It was -j4 here.
[12:14] <cjwatson> -j8 on the buildd
[12:17] <infinity> I can see no reason why it would work in a devirt but not the archive, but it's building now, so we'll see.
[12:20] <infinity> cjwatson: Entertainingly, it failed on i386 in my PPA.
[12:20] <infinity> cjwatson: With different, but related errors.
[12:21] <infinity> cjwatson: I suppose it could be a concurrency/dependency issue.
[12:21] <cjwatson> Succeeeded across the board on mine.
[12:21] <infinity> hahahaha.
[12:21] <cjwatson> Maybe this is another "retry until it sticks" thing?
[12:21] <infinity> Failed on i386, built on amd64.
[12:21] <infinity> So, yeah, retrying until it sticks would likely "work".
[12:22] <cjwatson> Not that I like it but we're out of time.
[12:22] <cjwatson> Found an upstream patch for spatialite/powerpc
[12:22] <cjwatson> It's a bit giant
[12:22] <infinity> Removing the --parallel from debian/rules might magically fix it, if it's a concurrency issue.
[12:22] <cjwatson> But without evidence ...
[12:22] <cjwatson> I'll retry this and see what happens
[12:23] <infinity> Well, evidence would come in looking at the logs and trying to sort out if we're getting deps out of order.
[12:23] <infinity> But retrying should work, eventually, based on my PPA's results.
[12:23] <infinity> We could force it to komainu, which is where it worked for me, but that's likely just a fluke.
[12:24] <infinity> I'll do that if your retry on allspice fails.
[12:25] <infinity> kamailio looks all good now, at least.
[12:26] <skaet> stgraber,  Edubuntu image on the iso tracker,  does 20121016 have [41] in it?
[12:26] <cjwatson> infinity: allspice built it
[12:26] <stgraber> skaet: no
[12:26] <infinity> cjwatson: Cute.
[12:27] <infinity> cjwatson: Also, "whatever".
[12:27] <skaet> stgraber, is it rebuilding for that right now, or something else?
[12:28] <stgraber> skaet: no, it'll be included with the next mass rebuild
[12:32] <skaet> k
[12:37] <stgraber> apw: how's that install going?
[12:40] <skaet> stgraber,  can't tell from the pad about that seed change for Edubuntu.   Is it ready to go, or something pending?
[12:40] <stgraber> skaet: the change was made, we were waiting for the publisher to run but that's be done a while ago, so it's just going to get fixed whenever we respin
[12:40]  * ogra_ notes that omap4 desktop and server as well as omap server work fine here
[12:40] <skaet> ok,  marking as such.
[12:41] <ogra_> ac100 next :)
[12:41] <skaet> thanks ogra_ :)
[12:41] <ogra_> havent noted them on the tracker yet
[12:52] <skaet> infinity,   looks like we've got positive testing results on the signed WUBI,   can you copy it over to nusakan so we don't forget about it later?
[12:54] <stgraber> cjwatson, infinity: opinion on aptdaemon? it's fixing bug 1066457 which in itself should appear until post-install but I think it'd be worth including if we're going to respin the world anyway
[12:54] <ubot2> Launchpad bug 1066457 in aptdaemon "Missing dpkg-dev dependency results in false bad quality warnings when installing local packages" [Critical,In progress] https://launchpad.net/bugs/1066457
[12:55] <cjwatson> Doesn't that pull in a pile of stuff onto images?
[12:56] <stgraber> no
[12:56] <stgraber> diff is: http://paste.ubuntu.com/1283012/
[12:56] <cjwatson> Oh, I see
[12:56] <cjwatson> Should be done using lsb_release, really
[12:56] <stgraber> yeah
[12:56] <cjwatson> But yeah, that patch is fine
[12:57] <stgraber> accepted into -proposed. skaet added it to the pad so we'll need to remember to pocket copy
[13:03] <cjwatson> quantal_outdate_all almost fits in one browser page for me now ...
[13:11] <apw> stgraber, chinstrap:~apw/X.tgz ... machine awaiting any further poking
[13:11] <stgraber> apw: yay, thanks
[13:11] <skaet> infinity, cjwatson - what's still critical to land from your perspectives before the respin gets kicked off?  (beyond the aptdaemon?)
[13:12] <stgraber> apw: oh, fun, so it never actually reaches the is_removable code :)
[13:12] <cjwatson> skaet: stgraber's ubiquity fix (plus the other bits queued in bzr there)
[13:13] <cjwatson> Which appears to be still under investigation
[13:13] <stgraber> xnox: any progress on the VM bug?
[13:14] <stgraber> xnox: s/VM/partman freaking out when running on possibly not clean disks/
[13:14] <cjwatson> Oh, yes, that too
[13:14] <xnox> stgraber: some I can reproduce it, but neither set -x nor strace are useful. Unless i'm reading it wrong...
[13:14] <cjwatson> spatialite above is a giant diff basically because it's GIS software and has loads of autogenerated code
[13:15] <cjwatson> But it's straight from upstream (with just a bit of adjustment to apply to what we had) and I've test-built it on amd64/i386/powerpc
[13:15] <stgraber> ok, so apw's problem is that boot_device returns None. That can either be because parted doesn't return anything or because it stacktraces and we hit the except statement
[13:15]  * stgraber gets back to looking at the logs
[13:15]  * xnox smae
[13:16] <infinity> cjwatson: Having a look.
[13:23] <balloons> skaet, do we see this as being release noted at this point, or is a fix still being worked on? https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1055949
[13:23] <ubot2> Launchpad bug 1055949 in unity "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard)" [Medium,Confirmed]
[13:24] <skaet> balloons,  release noted,  feel free to add it to ReleaseNotes/UbuntuDesktop page if its not there already ;)
[13:24]  * skaet suspects it will likely be in SRU, but will let seb128, popey comment on that. 
[13:25] <infinity> I'm not sure why that needs a release note, to be honest.
[13:25] <seb128> skaet, right, I don't think we want to respin for cosmetic issues
[13:25] <seb128> doesn't seem really release note worthy either...
[13:26] <infinity> Release notes shouldn't contain every bug we know about, just things that affect people negatively.
[13:26] <infinity> (Plus interesting new changes)
[13:27] <skaet> infinity, seb128 - key reason would be we don't want people filing more bug reports against it, as it is visible.   But since its localized to ARM,  suspect you're right and it doesn't really need a note.    balloons, chime in if you disagree.
[13:28] <popey> skaet / seb128 +1
[13:28] <balloons> skaet, I brought it up because it's the 'out of the box' experience on ARM. It is purely cosmetic, but it will also universally affect those users
[13:29] <balloons> that said I've no reason to disagree with the decision to release note or not. Thanks for the info :-)
[13:30] <apw> balloons, as they can boot successfully and update successfully and indeed file a bug successfully it does not seem critical to note
[13:34] <stgraber> cjwatson, xnox: so, after adding a ton of debug, I see that misc.boot_device() is properly iterating through the disks and indeed lists a single partition on the disk I'm using, but I'm suspecting some kind of race as it's marked as "free" and doesn't list a mountpoint...
[13:35] <xnox> stgraber: hmm... is it cached and determined only once (at start of partman caching) and never actually re-iterated on partman confirm as to what we want to do?
[13:36]  * xnox needs to look at misc.py
[13:37] <stgraber> xnox: I'm adding some more debug to check that the output of p.partitions() makes sense
[13:39] <infinity> jamespage: Say, if you get a spare moment, can I get you to verify https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1028038 ?
[13:39] <ubot2> Launchpad bug 1028038 in eglibc "sscanf always calls realloc/causes deadlock in google-perftools" [High,Fix committed]
[13:39] <jamespage> infinity, on my list
[13:40] <stgraber> xnox, cjwatson: do you know what the "part" parameter of p.readline_part_entry should look like?
[13:40] <infinity> jamespage: Kay.  Once I verify one other bug, yours it the only one holding up the copy to -updates.  No pressure.
[13:40] <stgraber> we're currently calling it with a string with a value like "32256-10737418239" and it seems a bit weird to me
[13:40] <stgraber> (but I don't know parted so it may totally be right)
[13:40] <cjwatson> Looks right
[13:40] <xnox> stgraber: that's partman's id for the partition. starbyte-endbyte
[13:41] <stgraber> ok
[13:41] <cjwatson> Indeed
[13:41] <cjwatson> Well, it's odd that it starts at 63 sectors with cylinder alignment, but that aside
[13:41] <cjwatson> (Not relevant here)
[13:41] <stgraber> so now the question is why mountpoint doesn't contain anything...
[13:42] <cjwatson> Well, find out why it's marked as free first
[13:43] <cjwatson> boot_device isn't cached as such directly, but it could be that we're calling it too early when it matters
[13:43] <cjwatson> The partman log *might* indicate something
[13:44] <tkamppeter> I have a question to the fix for bug 1034045, a CUPS crasher. It got accepted as SRU and then treated like an SRU: Put into -proposed, verified, and then passed on, but not into -updated but simply into Main. Does this mean that the fix is going onto the CDs?
[13:44] <ubot2> Launchpad bug 1034045 in cups "cupsd assert failure: *** glibc detected *** /usr/sbin/cupsd: free(): corrupted unsorted chunks: 0x00007f3dc478c0f0 ***" [High,Fix released] https://launchpad.net/bugs/1034045
[13:44] <infinity> tkamppeter: Yes.
[13:44] <cjwatson> You ought to see a call to PARTITIONS corresponding to the call to boot_device
[13:44] <jamespage> infinity, no pressure felt :-)
[13:45] <infinity> jamespage: Then I did it wrong. :0
[13:45] <xnox> stgraber: at the start of the gtk ubi-partman we populate grub_device_entry by using grub_default which down the road calls boot_device.
[13:46] <cjwatson> Do we populate that too early, maybe?
[13:46] <stgraber> xnox: indeed, though we should only use grub_device_entry when in manual install, the rest of the time we should call grub_default() after partitioning
[13:46] <xnox> we populate that drop down at partman initialisation.
[13:47] <xnox> stgraber: yes, but we call get_grub_choice and it doesn't do that =)
[13:47] <xnox> it always preffers the drop down, respective of the mode. Maybe it should...
[13:48] <xnox> self.preseed('grub-installer/bootdev', self.ui.get_grub_choice())
[13:48] <cjwatson> The only relevant calls I see are in ok_handler (should be well after partman cache is built) and maybe_update_grub (either explicitly just after building the cache, or when you ask to create or edit a partition)
[13:48] <xnox> in the ok_handler
[13:48] <cjwatson> Am I missing a path?
[13:48] <cjwatson> Oh, but ok_handler doesn't have a cache if you didn't use manual partitioning!
[13:48] <xnox> cjwatson: yes. get_grub_choice only calls into mics. only once.
[13:49] <xnox> hmmm...
[13:49] <cjwatson> But building the cache is fiendishly hard otherwise
[13:50] <cjwatson> When autopartitioning, we always know what disk we're operating on, right?
[13:50] <cjwatson> (Don't we?)
[13:50] <xnox> yes.
[13:50] <cjwatson> Then we could pass that down the layers and have that be used instead of boot_device()
[13:50] <cjwatson> Since boot_device() returns the disk, not the partition
[13:51] <cjwatson> That feels like it has a good chance of being the right answer, to me
[13:51] <cjwatson> grub_default and is_boot_device_removable would need to take boot_device=None parameters or similar
[13:52] <cjwatson> Er, boot=None to avoid shadowing the function name
[13:52] <cjwatson> And the get_grub_choice implementations too
[13:54] <cjwatson> infinity: So, mgltools-opengltk in unapproved fixes that build failure; spatialite is building; I removed the OOD binaries for sigx, structure-synth, and tetgen; and I believe doko/jamespage are working on eigenbase-resgen and mondrian
[13:54] <cjwatson> infinity: How goes gmap/powerpc?
[13:54] <cjwatson> I think that's the last one
[13:54] <infinity> cjwatson: Ask apw, I had him crying over the code.
[13:55] <apw> cjwatson, from what i can see its an endian issue, the problem with that is the code is utterly vile wtf to endian support and hand literally hundreds of endian specific stanzas
[13:55] <cjwatson> Ah, believeable
[13:55] <infinity> There's a distinct possibility that the code in question was always broken, and they just recently started testing it.
[13:55] <cjwatson> We *could* just remove it; no rdepends
[13:55] <doko> ohh, tetgen. hmm, I did want to work around it
[13:55] <cjwatson> it> the powerpc binary, that is
[13:56] <infinity> So, yeah, I was going to remove the binary, I think.
[13:56] <infinity> We're on the same page there.
[13:56] <cjwatson> doko: Feel free, me removing the one binary doesn't stop you :)
[13:56] <cjwatson> It just removes it as a blocker
[13:56] <cjwatson> infinity,apw: righto, removed
[13:57] <infinity> cjwatson: Oh, hah, I just did it dtoo.
[13:57] <infinity> Or, was about to.
[13:57]  * infinity answers "n".
[13:57] <cjwatson> So that's everything in outdate, as long as building with openjdk-6 fixes eigenbase-resgen
[13:57] <cjwatson> Which was the plan for mondrian
[13:58] <infinity> \o/
[13:58] <infinity> Two releases in a row.  This could be habit-forming.
[13:58] <cjwatson> I certainly hope so
[13:59] <cjwatson> And this time hopefully we won't still be finishing it on release morning
[13:59] <jamespage> infinity, eglibc SRU fix verified
[13:59] <infinity> jamespage: My hero.
[13:59] <doko> looking at gwt first, then eigenbase
[13:59] <jamespage> doko, lemme take eigenbase
[14:00] <jamespage> I got stuck on it last week - reverting to openjdk-6 is something I had not tried.
[14:01] <apw> stgraber, anything i can be doing to forward this issue ?
[14:02] <cjwatson> stgraber: Does my proposal make sense to you?
[14:02] <cjwatson> infinity: if we do manage to get britney going before auto-syncs, it should be easy to keep it there
[14:02] <stgraber> cjwatson: yep, trying to implement now
[14:06] <cjwatson> seb128: could somebody on your team look at bug 1066883, please?
[14:06] <ubot2> Launchpad bug 1066883 in linux "[Macmini 5,1] Fatal server error: Can not run in framebuffer mode on reboot" [High,Confirmed] https://launchpad.net/bugs/1066883
[14:06] <cjwatson> seb128: not clear whether it's a kernel or X bug
[14:06] <infinity> aptdaemon copied to release, FWIF.
[14:06] <infinity> FWIW, too.
[14:07] <seb128> cjwatson, ok, I will ping our xorg guys to have a look
[14:07] <cjwatson> Thanks
[14:18] <doko> jamespage, eigenbase solved
[14:18] <jamespage> doko, OK - you beat me
[14:18] <jamespage> what did I miss?
[14:18] <doko> infinity: please build libeigenbase-resgen using the debian ibeigenbase-resgen binary (self build dependency)
[14:20] <infinity> doko: s/lib// ?
[14:20] <doko> libeigenbase-resgen-java
[14:21] <infinity> doko: Which is from the eigenbase-resgen source, so yeah.  s/lib// :P
[14:21] <plars> slangasek: the bug I mentioned was bug #1067348
[14:21] <ubot2> Launchpad bug 1067348 in upstart "garbled character appears on the screen after inputting the passphrase of the encrypted hard disk during the boot process" [Undecided,New] https://launchpad.net/bugs/1067348
[14:21] <infinity> doko: That need rebootstrapping on all arches, or?
[14:21] <doko> i386 only
[14:21] <infinity> Oh, right.  Check.
[14:22] <plars> granted, it's probably in the wrong place
[14:22] <cjwatson> doko: Excellent
[14:23] <xnox> plars: somehow I think it's not a bug in upstart but rather console-setup.
[14:25] <cjwatson> I doubt it
[14:25] <cjwatson> plymouth seems more likely as a first guess
[14:26] <cjwatson> Nothing in console-setup would cause you to get those Unicode grid characters, at least not directly
[14:28] <xnox> cjwatson: apart from not generating the correct locale due to missing langpacks?
[14:28] <cjwatson> console-setup is not responsible for generating the locale
[14:28] <cjwatson> Is there any evidence that the locale is missing?
[14:29] <cjwatson> Also, if the locale weren't generated, I would not expect to be seeing translated messages
[14:29] <cjwatson> (Even mangled)
[14:29] <xnox> true.
[14:30] <xnox> hmm..
[14:30] <cjwatson> I've reassigned to plymouth
[14:31] <slangasek> plars: thanks
[14:34] <slangasek> plars, cjwatson: right, this looks like a straightforward matter of missing font support in the initramfs for our mountall strings
[14:35] <doko> is somebody looking at nvidia-tegra-codecs-ventana in NEW?
[14:36] <slangasek> would be nice if we could pre-render the images so we didn't have to keep shoving more fonts into the initramfs; but that's not something we can fix now-ish
[14:37] <stgraber> xnox: what's the right way of getting the auto disk target from get_grub_choice? I'm currently using self.get_current_disk_partman_id().replace('=', '/') but the function only exists in the Gtk implementation
[14:40] <xnox> stgraber: ui.get_autopartition_choice exists in both.
[14:40] <infinity> doko: I was going to look at both of ogra's nvidia* uploads, but if you want to review them, be my guest.
[14:40] <stgraber> xnox: oh, I somehow missed that one, thanks
[14:41] <xnox> stgraber: get_autopartition_choice[1] should be a useful dict.
[14:43] <tkamppeter> infinity, thanks.
[14:44] <doko> ogra: why are the b-d's for nvidia-tegra-codecs-ventana needed?
[14:47] <infinity> doko: To generate dhlibdeps?
[14:48] <infinity> doko: shlibdeps*
[14:48] <doko> ahh, ok
[14:49] <stgraber> xnox: hmm, and is there a convenient way of going from the "SCSI3 (0,0,0) (sda) - 10 GB QEMU QEMU HARDDISK" format to a device path or do I have to parse the string to extract sda?
[14:50] <infinity> doko: So, wait, was there going to be an upload of eigenwhatever, or did you just want the current version in the archive rebootstrapped against Debian?
[14:50] <xnox> stgraber: well the iterator in the gtk drop down has both from somewhere. first colum is /dev/sda3 the second column is that freaky thing.
[14:51] <doko> infinity, the current
[14:51] <xnox> stgraber: or poke around the self.extra_choices more. it should have something better.
[14:51] <xnox> options.
[14:51] <infinity> doko: Alrighty.
[15:03] <xnox> I have a "fix" for the replace issue. But I don't understand it. At the end of the for-loop $mountpoint is unmounted in the normal run, but not deleted. Then cleanup() trap kicks in and the code is a bit wrong cause it assumes if the $mountpoint is there - it should be unmounted. With this change http://paste.ubuntu.com/1283223/ it no longer hangs at that spot & shows the install options.
[15:03]  * Daviey checks in... everything good?
[15:04] <xnox> But there is a side effect. I think the "replace" option now kicks in, not displayed but instead "Reinstall 12.10" is insensitive now.
[15:04] <balloons> I thought iscsi got cleared up yesterday?
[15:04] <xnox> s/ kicks in / partman produces it /
[15:11] <cjwatson> xnox: Oh, so umount -l returns non-zero, I guess
[15:12] <cjwatson> The new code is clearer anyway
[15:12] <plars> balloons: are you talking about the iscsi bug reported? https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1066945 looks like jamespage was able to confirm it a bit ago
[15:12] <ubot2> Launchpad bug 1066945 in debian-installer "iSCSI root fails" [Undecided,Confirmed]
[15:12] <balloons> yes
[15:12] <balloons> plars, yes
[15:12] <plars> jamespage: looks like it could be release critical?
[15:13] <jamespage> plars, balloons: the part of that bug that has been fixed was release critical
[15:13] <jamespage> I'm not sure about the remaining issue...
[15:13] <plars> jamespage: ah, I didn't realize it was partially fixed
[15:13] <plars> jamespage: is that tracked in another bug somewhere?
[15:14] <jamespage> plars, the fixed bug is bug 1057635
[15:14] <ubot2> Launchpad bug 1057635 in Ubuntu Quantal "initramfs built during install does not contain a valid iscsi initiator name" [High,Fix released] https://launchpad.net/bugs/1057635
[15:14] <plars> thanks
[15:14] <jamespage> which stopped iscsi root working whatever nic type you used
[15:14] <xnox> cjwatson: yeah it does return non-zero and the error message is lost somewhere?!
[15:14] <cjwatson> xnox: I'm not sure I totally understand the side-effect you describe.  Could you explain the behaviour both before and after your patch?
[15:15] <balloons> right, there were 2 parts.. but I see a new iscsi in proposed -- or is it the same?
[15:15] <xnox> cjwatson: before my patch - we hang and do not proceed to the partman options.
[15:15] <cjwatson> balloons: That was precise-proposed
[15:15] <balloons> do'h
[15:16] <xnox> cjwatson: after this patch you get: unselectable reinstall, side-by-side, wipe-and-install, advanced.
[15:16] <cjwatson> xnox: Well, that certainly sounds better than a hang
[15:16] <cjwatson> I'd say go for it
[15:17] <xnox> cjwatson: i'm looking into making the replace option work, cause this upload will need to be in ubiquity as well.... so ubiquity is being uploaded...
[15:17]  * xnox digs back into ubiquity #2 pencil calculations.
[15:17] <stgraber> ... getting the target disk in ubi-partman in a way that works with all frontends and with all install options (except for manual) is a real nightmare
[15:18] <cjwatson> ubiquity's being uploaded anyway, since the fix stgraber is working on is stop-ship
[15:42] <cjwatson> stgraber: anything I can do to help?
[15:45] <stgraber> cjwatson: current implementation is http://paste.ubuntu.com/1283299/
[15:45] <stgraber> I'm just about to test if that stuff actually works
[15:46] <stgraber> well, once I fixed the obvious mistakes that pyflakes just highlighted
[15:46] <Laney> if we're spinning again, could I sneak that gdocs in? :-)
[15:46] <cjwatson> stgraber: boot=boot, not boot=None in grub_default
[15:47] <stgraber> cjwatson: http://paste.ubuntu.com/1283302/
[15:47] <cjwatson> stgraber: And I think an explicit boot= when calling grub_default, for documentation's sake
[15:48] <cjwatson> Yow, complexity in ubi-partman - presumably unavoidable
[15:48] <cjwatson> Looks plausible.  You might or might not need test changes too
[15:48] <stgraber> yeah and I'm really not happy to have to parse the string but well, ...
[15:49] <cjwatson> You have enough checks that I don't think it'll introduce crashes
[15:49] <cjwatson> And if it doesn't work it falls back to previous behaviour
[15:50] <skaet> Laney, gdocs?  is it on the pad?
[15:50] <stgraber> apw: still around?
[15:50] <Laney> skaet: I haven't put it there; it's heading for SRU but if we could sneak it in it would fix a top crasher
[15:50] <apw> stgraber, sure am, waiting on you :)
[15:51] <Laney> skaet: I wouldn't be offended if it goes via SRU though
[15:52] <stgraber> apw: I'm going to run a very quick test here to check that my code actualy runs in my test environment and should be ready in 5min to have it run on your machine
[15:53] <skaet> Laney,  what's the scope of change like?   risk for regressions?   if low impact, and low risk for regressions, am ok with it going on the pad as opportunity target,   fixing as an SRU is also an option.
[15:53] <Laney> catching an exception and exiting cleanly instead of crashing
[15:54]  * skaet nods
[15:55] <xnox> stgraber: *sigh* the controller needs to pass devices with the options i think, such that UI can "get it normally" =(((( sorry about that.
[15:55] <xnox> looks good though =)
[15:56] <cjwatson> infinity: Any luck with the bootstrap?  I can do it if you like ...
[15:56] <cjwatson> (eigenbase-java)
[15:56] <infinity> cjwatson: Oh, I'm still fiddling with other things.  Go ahead, if you want.
[15:56] <cjwatson> OK, will do
[15:56] <stgraber> spotted one mistake (isinstance is checking for list instead of tuple), fixing and re-trying
[15:57] <cjwatson> (er, eigenbase-resgen, of course)
[15:59] <stgraber> ok, code tested here and it seems to do the right thing with the gtk frontend at least
[16:00] <apw> stgraber, so i need to reset to before the install yes, then you'll have updated code for me ?
[16:00] <apw> (i can get doing that in parallel)
[16:00] <stgraber> apw: http://paste.debian.net/201083/ for /usr/lib/ubiquity/ubiquity/misc.py
[16:00] <stgraber> apw: http://paste.debian.net/201084/ for /usr/lib/ubiquity/plugins/ubi-partman.py
[16:02]  * stgraber grabs kubuntu desktop for a quick test run with the kde frontend
[16:10] <stgraber> ok, result on the kde frontend matches that of the gtk frontend. So just need to wait for apw to know whether the result is actually what we want
[16:10] <apw> stgraber,  on it
[16:11] <stgraber> apw: do you know roughly how long that install will take?
[16:11] <apw> stgraber, half hour ish
[16:12] <apw> stgraber, its booting into the installer now
[16:12] <stgraber> ok, I guess it's still reasonable to wait for it. If it'd have been longer I'd have suggested releasing ubiquity, pushing it to -proposed, letting it build and only pocket-copy once we know the test result
[16:13] <cjwatson> As long as somebody not involved in the upload will still be around to review it
[16:13] <cjwatson> I guess infinity will still be around
[16:14] <xnox> so I am running Oracle VM Virtualbox (which is oh so good are reproducing the replace bug) it also has an interesting property of having an IP address, NAT network yet not having any host name resolutions...
[16:15] <xnox> which makes ubiquity correctly detect that there is no network, but that does not stop apt-get update to be painfully slow further down the line (when trying for langpacks, etc.)
[16:15] <xnox> with 10s to time out per each network request....
[16:15] <cjwatson> That's an apt regression
[16:16] <cjwatson> It's supposed to notice that situation
[16:16] <skaet> just to note:  Kubuntu powerpc testing indicates probably best not to ship this image.   After discussion with ScottK,  have removed from Manifest and iso tracker.
[16:16] <cjwatson> infinity: The bootstrap archive appears to have fallen out of the i386 chroots
[16:17] <xnox> cjwatson: I see. But I also want to blame something else in either Oracle VirtualBox packaging or dnsmasq in Oracle VirtualBox for not giving me the internetz.
[16:17] <xnox> ok. will troubleshoot later.
[16:18] <infinity> cjwatson: Oh, it's out of all of them.  I'll re-enable it for i386.
[16:18] <infinity> cjwatson: I told you a couple of days ago that I'd disabled it for everything for release.
[16:18] <stgraber> xnox: can you get /etc/resolv.conf, /var/log/syslog and the "ps aux" output out of that VM?
[16:18] <infinity> cjwatson: Anyhow, fixing.
[16:18] <xnox> stgraber: sure.... let me think how am I going to do that.
[16:19] <cjwatson> infinity: Oh, I missed that.
[16:19] <stgraber> xnox: I usually "cat <file> | nc -l 1234" on one end, then "nc <ip> 1234 | pastebinit" on the other
[16:19] <cjwatson> infinity: Hopefully just need it for i386 briefly.
[16:19] <cjwatson> (missed or forgot)
[16:19] <xnox> stgraber: briliant =)
[16:20] <cjwatson> Yeah, it's in my scrollback and all
[16:22] <infinity> cjwatson: Uploaded.
[16:22] <cjwatson> Thanks.  Retrying eigenbase-resgen.
[16:23] <cjwatson> (The libeigenbase-resgen-java binary there is the result of a local sbuild run with the Debian libeigenbase-resgen-java package installed.)
[16:23] <infinity> I assumed, yes.  I trust you. :)
[16:25] <xnox> stgraber: http://paste.ubuntu.com/1283369/
[16:26] <slangasek> anyone know if the precise wubi build has been tested yet?
[16:26] <skaet> slangasek,  plars said he did earlier
[16:26] <xnox> stgraber: had to do the reverse, listen on my host & connect in the guest. But it worked like a charm =) also confirms that guest can get through to my host.
[16:26] <slangasek> skaet: when?  I only saw his testing of quantal wubi
[16:26] <Daviey> skaet: Everything kosher?
[16:26] <skaet> slangasek, call earlier
[16:27] <slangasek> ah
[16:27] <slangasek> ok then :)
[16:27] <skaet> Daviey,  how does MAAS on ARM look?
[16:28] <Daviey> skaet: *AWESOME*
[16:28] <Daviey> rbasak: ^^ confirm?
[16:28] <stgraber> xnox: is "host www.google.com 10.0.2.2" working from that VM?
[16:29] <rbasak> Daviey: confirmed!
[16:29] <Daviey> ta
[16:29] <skaet> thanks.  :)
[16:30] <xnox> stgraber: ;; connection timed out; no servers could be reached
[16:30] <stgraber> xnox: ok, so that's virtualbox's fault, not dnsmasq, resolvconf or NM
[16:31] <stgraber> (10.0.2.2 is the IP reported by NM as its upstream dns server)
[16:31] <skaet> Daviey,   any fixes ready on the server team's critical list that is left to pick up in next set of respins?  or are we pretty much set for you and rest is now SRU targets...
[16:31] <xnox> stgraber: cool. I'll try the open-sourcey edition and then decide where to file bugs =)
[16:31] <xnox> stgraber: thanks.
[16:32] <cjwatson> doko,infinity: eigenbase-resgen rebootstrapped.  I'll retry mondrian once that's published.
[16:46] <infinity> doko: What's going on with mondrian?
[16:47] <cjwatson> infinity: It'll be fixed with a retry after the rebootstrapped eigenbase-resgen publishes.
[16:47] <cjwatson> i.e. soon.
[16:48] <infinity> cjwatson: Ahh, kay.  Didn't notice they were a dependency chain.
[16:48] <infinity> cjwatson: So yay, we're done!
[16:48] <cjwatson> Yes!
[16:50] <stgraber> apw: how are things looking?
[16:53] <apw> stgraber, it literally just ran install-grub, from what i saw it went to sdc
[16:54] <stgraber> apw: yay!
[16:54] <apw> i'll have the logs in the near
[16:54] <stgraber> well, I'll mostly be interested to know whether it boots ;)
[16:55] <cjwatson> With and without the stick inserted
[16:56] <apw> cjwatson, indeed
[16:58] <cjwatson> And there's mondrian built
[17:05] <apw> stgraber, cjwatson, ok the stick is good seems to be internally referential, and the normal boot (though broken by the previous test, still points to the previous test)
[17:06] <apw> ie it was not updated by this install
[17:06] <stgraber> all good
[17:06] <stgraber> pushing my stuff and uploading then
[17:08] <cjwatson> Wait a sec
[17:10] <apw> stgraber, ^^ ?
[17:11] <stgraber> yep, I've been talking to cjwatson in #ubuntu-installer in parallel :)
[17:12] <cjwatson> Unblocked now
[17:15] <stgraber> uploaded
[17:17] <infinity> I'd like to promote chromium-browser at some point for lubuntu images as well, but I guess we can re-spin just lubuntu tomorrow morning after doing the world tonight.
[17:19]  * skaet nods
[17:21] <cjwatson> infinity: ^-
[17:22] <micahg> infinity: I don't think it's worth respinning lubuntu just for chromium unless they want it, chromium will be out of date in another week anyways
[17:23] <infinity> micahg: Yeah, but the world's respinning anyway, and chromium will be built in ~3h.
[17:23] <micahg> ok
[17:24] <cjwatson> Hmm, still several autopkgtest failures, but at least the ones I've looked at are test-only so it doesn't look worth trying to cram in fixes there
[17:25] <cjwatson> (software-properties and unattended-upgrades)
[17:26] <cjwatson> maas has never passed that, network-manager hasn't passed for a month ... will be a shock for a few people when we start making that gate entry to the release pocket :-)
[17:27] <stgraber> || true => "fixed" (isn't that how we deal with tests usually? ;))
[17:28] <cjwatson> hah
[17:28] <skaet> :P
[17:28] <cjwatson> Every other automatic release metric I can find is looking pretty good now
[17:29] <skaet> have all the -proposed opportunity targets been moved over?
[17:29] <cjwatson> pending-sru only lists chromium-browser, discussed above
[17:29] <infinity> skaet: Other than the ones I'm reviewing and accepting right now.
[17:29] <infinity> cjwatson: Want to review and/or have opinions on dbus-python?
[17:30] <cjwatson> infinity: Simon said in the bug that it fails the upstream regression tests
[17:30] <skaet> Laney, ^ looks like infinity +1'd -gdocs ;)
[17:31] <cjwatson> infinity: And at any rate it's complex enough that I'd rather not cram it in for release now
[17:31] <infinity> cjwatson: Check.  If you want to apply that opinion by rejecting, that would be lovely. :P
[17:31] <cjwatson> I'll just talk with barry
[17:31] <infinity> The tiny gnome-icons patch looks worth grabbing.  All the other gnome stuff was universe.
[17:32] <cjwatson> barry: ^- re your dbus-python upload - should we be including stuff that fails the upstream regression tests?
[17:32] <cjwatson> (You may have some good reason; it makes me nervous, though)
[17:33]  * stgraber -> dinner, be back in 30min
[17:33] <infinity> I may let the current state of build queues settle down before making some final proposed promotion choices and respinning tonight from my hotel room, if that sounds reasonable to others?
[17:33] <cjwatson> infinity: Er, re gnome-icon-theme, doesn't that need Replaces?
[17:34] <cjwatson> Because it should, as I read the bug, have the effect of moving files between packages
[17:34] <seb128> cjwatson, infinity: g-i-t has a replaces always updated to the current version
[17:34] <cjwatson> Ah, good
[17:34] <seb128> we keep moving icons between the binaries
[17:35] <infinity> What he said.
[17:35] <infinity> I think I've reviewed a few of these moves in the past and it no longer phases me.
[17:35] <cjwatson> Though not a Breaks from gnome-icon-theme to gnome-icon-theme-full, I notice, only the other way round
[17:35] <cjwatson> But that's fairly minor
[17:35] <infinity> Which could be poor practice on my end by now. :P
[17:35] <skaet> infinity,  challenge is the timing so that folks can start testing before EOD in North America
[17:35] <seb128> cjwatson, right...
[17:36] <infinity> skaet: Or, they can wake up to steamy fresh images in the morning instead. ;)
[17:36] <micahg> would me holding onto am armel buildd for a day or so be a problem at this point?
[17:36] <cjwatson> I think we do need something tonight
[17:36] <infinity> micahg: For..?
[17:36] <skaet> yeah I do too.
[17:36] <micahg> infinity: I'm symbols diving in webkit :)
[17:36] <cjwatson> infinity: Give me a list of stuff from -proposed you think is sensible, and I can promote and (if you're not around) start builds
[17:36] <infinity> Well, we'll look at the state of the world when ubiquity's done, it's a long(ish) build.
[17:37] <cjwatson> Heading off for dinner now, but that's fine since as you say ubiquity needs to build
[17:37] <infinity> cjwatson: I'll be around, I'm not going out tonight, just heading from the office to the hotel.
[17:37] <skaet> infinity,  let us know when you head out and are back online.    Please make sure the pad is updated with the bits you just reviewed and definitely want to see in.
[17:37] <cjwatson> Right, so "tonight" is actually "early this evening"
[17:37] <infinity> cjwatson: Yeah, not midnight or anything.
[17:37] <phillw> infinity: I'm okay with an updated Chrome, but as it is not due until tomorrow I'll double check with Julien (Having the latest Chromium IMHO is a good thing for us).
[17:38] <cjwatson> micahg: At minimum, please wait for a few hours until we're well into image building rather than package building again
[17:38] <cjwatson> There are enough long builds on armel at the moment that I'd rather have a bit more slack
[17:38] <skaet> +1
[17:38] <cjwatson> Anyway, as I say, dinner
[17:39] <micahg> cjwatson: ok, I can disable the arm builds for right now if it's problematic, that's why I was asking
[17:39]  * skaet thinks its  good time for lunch for me as well.
[17:39] <cjwatson> micahg: I'd rather you didn't tie up x86 builders right now either
[17:39] <cjwatson> Just give us a few hours
[17:40] <micahg> cjwatson: ok
[17:52] <seb128> (rejected that one because the upload was incomplete, I reuploaded it)
[17:55] <gilir> infinity, about chromium, no need to plan a respin for lubuntu only for the last update
[17:56] <infinity> gilir: Well, there is if we want to promote it to -release.
[17:56] <infinity> gilir: If we plan to make it a 0-day SRU, then no, no need to respin.
[17:58] <gilir> infinity, well, it's fine as a 0-day SRU
[17:59] <gilir> infinity, but if another respin happen later, it would be nice to have it in the ISO :-)
[18:00] <infinity> gilir: Right, well, I'll check timing tonight.  If I do lubuntu last in the build cycle, that's about when chromium will be ready anyway.
[18:00] <barry> cjwatson: re: dbus-python.  no, if it fails the test suite we should not include it.  i thought i had run the test and it passed, but i think my tree was not clean.  i'm now running it again and i see failures.  i'll take a closer look.  in the meantime, feel free to reject my upload and i'll do another when i get the test suite passing
[18:01] <gilir> infinity, great, thanks :-)
[18:01] <skaet> barry, cjwatson - done
[18:02] <barry> skaet: thanks.
[18:07] <apw> stgraber, cjwatson, just completely redid the ubiquity testing (usb to usb install) and confirmed the original disk is not affected now
[18:07] <skaet> thanks apw.  :)
[18:10] <slangasek> cjwatson: we don't have any of the hardware for reproducing bug #1040557 in house, do we?
[18:10] <ubot2> Launchpad bug 1040557 in ubuntu-cdimage "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
[18:10] <slangasek> cjwatson: have we actually had anyone confirm this happens when NOT writing the USB stick using a third-party tool?
[18:11] <infinity> slangasek: Even if we did, we'd only be able to test it once. ;)
[18:11] <slangasek> infinity: cking suggested removing the cmos battery is sufficient to clear the failure
[18:12] <apw> slangasek, that was on a different machine tho.
[18:12] <slangasek> ok
[18:12] <infinity> slangasek: I thought that was on a machine he'd bricked differently (a Lenovo, perhaps?), but maybe I got my wires crosses on that.
[18:12] <slangasek> so that was basically just cking dogpiling the bug, was it?  I see how it is
[18:13] <apw> slangasek, it may work there too.  though on the machine he had "just removing the battery" meant taking the whole machine appart
[18:13] <slangasek> well sure, but that's what machines are FOR
[18:32] <slangasek> cjwatson: so I've gotten in touch with someone from Samsung about this, but I'm trying to make sure I'm giving them clear information... the bug log is unfortunately muddled
[18:33] <slangasek> cjwatson: I'm trying to figure out what to tell them for a reproducer case
[18:38] <ScottK> Mark didn't happen to announce the new code name at the openstack summit keynote, did he?
[18:52] <slangasek> so after a more careful reading of bug #1040557, I see that there haven't actually been any confirmed reports of the original bug occurring with 12.10
[18:52] <ubot2> Launchpad bug 1040557 in ubuntu-cdimage "UEFI boot live-usb bricks SAMSUNG 530U3C,np700z5c laptop" [Critical,Confirmed] https://launchpad.net/bugs/1040557
[18:53] <slangasek> one reporter said he got a black screen, only *after* he successfully booted and installed 12.10 from usb
[18:53] <slangasek> (and then rebooted to Windows, and rebooted again)
[18:53] <slangasek> so not at all clear that it's the same bug
[18:57] <skaet> ScottK, not that I've heard.   waiting for the blog post.
[18:59] <jbicha> mutter failed to build on armel on sigbin but built successfully when I retried, who do I complain to?
[19:00] <infinity> jbicha: If you'd saved the log, you could complain to me.  Otherwise, complain to cosmic rays?
[19:00] <micahg> infinity: weren't you supposed to do something to sigbin?
[19:00] <jbicha> infinity: http://paste.ubuntu.com/1283668/
[19:01] <jbicha> it totally wasn't obvious to me that was a builder issue
[19:02] <skaet> slangasek, cjwatson, stgraber - I've gone through all the fixes in -proposed (from http://people.canonical.com/~ubuntu-archive/pending-sru ), and sorted them into 3 buckets on the pad.   1) bugs I believe we're picking up are at the bottom - waiting for respin.   2) bugs that should be going through SRU process  3) bug fixes that are going into unseeded universe, and should be allowed in before our freeze today if
[19:02] <skaet> they build ok.
[19:02] <skaet> infinity, ^
[19:02] <skaet> could you please cross check and make sure the details are accurate/adjust if needed so we all have the same picture.
[19:02] <slangasek> infinity: thanks for taking care of wubi
[19:03] <jbicha> skaet: when are you freezing universe today?
[19:05] <ScottK> jbicha: Is gnome-boxes amd64 only on purpose?
[19:06] <skaet> jbicha, 2100 UTC was the plan.
[19:06] <jbicha> ScottK: yes, because qemu-kvm-spice is amd64 only because of bug 928432
[19:06] <ubot2> Launchpad bug 928432 in qemu-linaro "spice backend fails to build on i386 with -Werror" [Undecided,Fix released] https://launchpad.net/bugs/928432
[19:06] <ScottK> OK.
[19:07] <jbicha> Boxes is i386 and amd64 on Debian though
[19:07] <ScottK> OK, so it just needs copying over at this point, right?
[19:08] <seb128> jbicha, sorry for screwing the arch stuff in boxes
[19:08] <seb128> upstream said that spice should work on i386
[19:08] <seb128> but I never managed to track down the right people to get that fixed for quantal...
[19:11] <infinity> jbicha: That's a random data corruption issue. :/
[19:11] <jbicha> seb128: np, it looks like your change was (accidentally?) reverted in 3.5.91-0ubuntu1
[19:11] <cjwatson> slangasek: in-house> not that I know of; third-party tool> I'm sure I remember hearing of such a case but it's not in the bug log
[19:12] <slangasek> cjwatson: phooey, ok
[19:12] <infinity> skaet: I hadn't actually accepted anything that I didn't plan to pick up for -release, but I'll double-check your lists.
[19:13] <slangasek> infinity: some of these on the list look quite dubious for -release - is empathy yours?
[19:13] <cjwatson> slangasek: Hmm, you're right that the concrete evidence for 12.10 having the same problem is thin on the ground, but I have a hard time asking people to test this deliberately.  I'm inclined to take comment #14 as a yellow flag at the very least
[19:13] <infinity> slangasek: empathy isn't in proposed...
[19:13] <infinity> slangasek: Unless you mean the gnome-icon-theme upload.
[19:14] <slangasek> cjwatson: yes - I think we should release note it as a possible issue, but at least for Samsung I'm pointing them at the 12.04.1 images only
[19:14] <slangasek> infinity: hrm, apparently I'm looking at the wrong section on the pad then
[19:15] <slangasek> skaet: I'm confused.  Where is the break-down of the packages in -proposed?
[19:15] <cjwatson> slangasek: OK, good catch, thanks; certainly given the hybridisation it's *possible* something changed
[19:15] <cjwatson> (I said on the call earlier that the timing was such that this followed our work on improved hybrid USB images for UEFI, but I was mistaken as that was never applied to 12.04.x)
[19:16] <slangasek> cjwatson: TBH I think if this has changed between 12.04.1 and 12.10 it's more likely due to upstream kernel drift; at least one user reported the bug with usb-creator, and all usb-creator's EFI code does is unpack efi.img and throw grub to the right path
[19:17] <slangasek> (unetbootin's code, in contrast, causes eye bleeding and C++ hatred, so I haven't bothered working out what it does)
[19:17] <cjwatson> slangasek: Sure, but our fixes might have fixed things for people who use dd
[19:18] <cjwatson> IIRC the usb-creator code is analogous to the older approach
[19:18] <cjwatson> Roughly
[19:18] <slangasek> infinity: fwiw I was referring to bug #1020959, which is on the pad in the "SRU" section but indeed does not appear to be in -proposed
[19:18] <ubot2> Launchpad bug 1020959 in empathy "Empathy call is missing an icon for dialpad the icon can be found in gnome-icon-theme-full but not the non full version" [Low,Triaged] https://launchpad.net/bugs/1020959
[19:18] <ScottK> jbicha: How confident are you really about no regressions in mutter?
[19:19] <infinity> slangasek: It is in proposed, but not as empathy, it's a simple one-line change in gnome-icon-theme.
[19:19]  * cjwatson copies ubiquity to quantal to start with
[19:20] <slangasek> cjwatson: well, my general sense was that there's very little space between what usb-creator writes out and what the new hybrid code outputs in terms of what UEFI would do with it
[19:20] <slangasek> but anyway, it's all speculative at this point
[19:20] <jbicha> ScottK: it works here and I'm ok with it going into quantal today but I filed the SRU bug anyway
[19:21] <slangasek> infinity: ah - and why is that something that's going to -release?  That looks like a very low-priority change
[19:21] <cjwatson> So, wait, what happened to the list of rebuild triggers?
[19:21] <ScottK> jbicha: OK.
[19:21] <cjwatson> A bunch of stuff that hasn't actually been respun for yet has been moved down to the historical section at the end
[19:21] <slangasek> infinity: does that fall under "target of opportunity, squeezed in because we know we're respinning for ubiquity anyway"?
[19:21] <cjwatson> This is confusing and seems not desperately helpful
[19:21] <infinity> slangasek: Because it was a simple and clean fix, and we had a respin happening anyway, mostly.  But, it's in proposed, it can stay there if people have massive objections.
[19:22] <ScottK> jbicha: Done (g-boxes too).
[19:22] <slangasek> infinity: my only objection is about knowing what's what :)
[19:22] <cjwatson> What else from -proposed is going in?  I can no longer keep track due to the pad mangling (plus that it takes forever to scroll the pad because the website is hopelessly broken, so stuff near the bottom I'll basically not see)
[19:23] <infinity> cjwatson: Honestly, I was fine with most everything there, but we seem to be having ongoing discussions. :P
[19:23] <infinity> cjwatson: The software-center GTK memleak workaround looks safe enough to me.
[19:23] <cjwatson> unity-scope-gdocs I thought was fairly agreed
[19:23] <ScottK> skaet: The two universe ones are done.
[19:23] <slangasek> skaet: where is the list of -proposed packages we're picking up?
[19:23] <infinity> Yeah, gdocs should be good.
[19:25] <skaet> slangasek,  I put the list of -proposed packages I believe we're accepting at the bottom of the pad - but that's what I want the double check on.
[19:27] <stgraber> FWIW I'm working on a small isc-dhcp fix that jdstrand mentioned in #security. It's clearly not a respin candidate and should at best be considered a nice to have in case of another mass respin.
[19:27] <slangasek> infinity: it's one thing for you to be fine with the stuff in -proposed being included, and another thing for it to be clear to everyone else that this is the intent... please document each -proposed accept on the pad so that if questions come up during the two hours you're asleep, I know what I should be doing with them
[19:28] <cjwatson> The pad seems to suggest that ubuntu-release-upgrader is to be accepted
[19:28] <slangasek> skaet: the last two headings at the bottom of the pad are "History (Respin Triggers and Reasons)" and "Build Timings" - I don't see the list?
[19:28] <skaet> cjwatson, sorry - I was trying to make sense of what was accepted, what was not between the must fix, and slew of things that were in proposed, so grouped all the ones I believed should/were going to be in the image at the bottom together - so there was a consistent view.
[19:28] <infinity> slangasek: Well, it was only an hour or two ago that all these accepts were discussed, including me respinning this evening.
[19:29] <cjwatson> skaet: I'm afraid it just confused me further
[19:29] <cjwatson> I see no purpose in the Build Timings section nowadays, BTW
[19:30] <skaet> cjwatson,  that section can be deleted
[19:30] <cjwatson> We shouldn't be spending time at this point analysing build performance
[19:30] <skaet> http://paste.ubuntu.com/1283717/
[19:30] <cjwatson> OK, good, done
[19:30] <cjwatson> Copied ubuntu-release-upgrader
[19:30] <skaet> cjwatson,  the paste has the set of packages/bug fixes I believe should be going into the respin.
[19:31] <skaet> but wanted more eyes on them,  since it got a bit confusing between what was in universe, what should be SRU, opportunity targets and must fix.
[19:31] <skaet> what's in the paste, is my best understanding of opportunity targets and must fix.
[19:31] <cjwatson> Where did unity-scope-gdocs go?
[19:32] <cjwatson> Oh, it's in opportunity target way up at the top.  Copy or not?
[19:32] <cjwatson> (BTW every time we go past :32 or so we lose another half-hour)
[19:32] <skaet> there was a second fix in it.
[19:32] <cjwatson> (or :02)
[19:32] <cjwatson> So I'm not sure why it's still in opportunity targets then ...
[19:32] <cjwatson> If it's been rejected
[19:33] <skaet> it was in -proposed
[19:33] <cjwatson> I know
[19:33] <infinity> skaet: I'm not sure what you mean with the software-center comment.  We *are* s-c upstream.  Unless you're referring to GTK upstream, which we're currently working around because we don't have a fixed GTK.
[19:33] <skaet> infinity,  last comment implied there was a GTK fix coming...
[19:33] <infinity> skaet: There's a GTK fix upstream, yes.  It's certainly not landing for release.
[19:34] <skaet> infinity,  why is this not an SRU target,  and getting sorted properly?
[19:35] <skaet> cjwatson, unity-scope-gdocs has two fixes,  one of which was dicussed and sounded safe,  other of which hasn't been.   Both in same upload, so wasn't clear what state should be to me.
[19:36] <cjwatson> It shouldn't be in an intermediate state if you've taken a decision to reject it, which it sounds like you have.
[19:36] <infinity> skaet: Because the memory leak is rather inexcusably large, and very easily worked around as an opportunity target for a respin we'd already planned.
[19:38] <skaet> infinity, document decision in bug then so its clear what's supposed to be happening.
[19:39] <stgraber> jdstrand: re-introduced the .links, test built isc-dhcp, confirmed the binary package now contains the symlink and uploaded to quantal-proposed. So if we don't end up having it on the media, it should be there as zero-day SRU.
[19:39] <jdstrand> stgraber: awesome, thanks!
[19:40] <infinity> skaet: Both the gdocs bugs seem pretty rough.  Which was the one that wasn't discussed enough?
[19:41] <cjwatson> Moved 42 to the this-respin section, since it's in the ubiquity upload that was copied (though the bug number was left out of the changelog by accident)
[19:41] <cjwatson> And deleted the stray copy of the same bug under release notes
[19:41] <infinity> skaet: bug #1041749 appears to render the package essentially pointless.
[19:41] <ubot2> Launchpad bug 1041749 in unity-scope-gdocs "Google documents open as a download, not for editing." [High,Confirmed] https://launchpad.net/bugs/1041749
[19:41] <skaet> https://bugs.launchpad.net/ubuntu/+source/unity-scope-gdocs/+bug/1041749
[19:41] <ubot2> Launchpad bug 1041749 in unity-scope-gdocs "Google documents open as a download, not for editing." [High,Confirmed]
[19:42] <skaet> yes, that was the one I hadn't seen  discussed.
[19:42] <skaet> kenvandine marked it as quantal-updates,  not critical though
[19:42] <skaet> so, ambiguous.
[19:43] <skaet> hence desire for discussion.
[19:43] <kenvandine> not critical, but high
[19:43] <kenvandine> the crasher had lots of dupes
[19:43] <infinity> I tend to take people's targets with a grain of salt.  Some are overly conservative to not annoy us, and some are overly liberal to attempt to produs to action. :P
[19:43] <kenvandine> s/lots/more than i like to see
[19:43] <skaet> yeah am +1 on the crasher ken.   it was the surprise of the other being in there that stalled things up.
[19:44] <kenvandine> oh... the link?
[19:44] <kenvandine> that one is important too
[19:44] <infinity> Indeed.
[19:44] <kenvandine> some files get downloaded instead of opening in a browser
[19:44] <kenvandine> never what a user expects
[19:44] <skaet> no argument,  which is why it wasn't flat out rejected.
[19:44] <kenvandine> :)
[19:45] <skaet> what testing's been done on it,  and what risk of regression?
[19:45] <kenvandine> i try to keep those guys in check :)
[19:45] <kenvandine> none really
[19:45] <kenvandine> the crasher has no chance of a regression
[19:45] <kenvandine> i tried the link change on a bunch of docs myself
[19:45] <kenvandine> and it did the right thing
[19:45] <kenvandine> i don't think there is a chance of regression there either
[19:45] <cjwatson> (We have 15 minutes or so to conclude these discussions if we want to be able to start builds in ~1hr.)
[19:46] <infinity> ^
[19:46] <skaet> fine then.   let it in.   Crasher should get fixed.
[19:46] <kenvandine> we have both link values from the API, it just used the wrong one before
[19:46] <kenvandine> great
[19:46] <kenvandine> :-D
[19:46] <infinity> gnome-icon-theme is clean, simple, and obvious (and was discussed in IRC previously).
[19:46] <kenvandine> is now the chance to point out the libunity-webapps upload?
[19:47] <infinity> Pending strong objections, I'm copying it.
[19:47] <kenvandine> adds affiliate codes to links for a few more countries
[19:47] <kenvandine> so just changes the link opened for those
[19:47] <kenvandine> trivial change
[19:47] <skaet> no strong objections there from me.
[19:47] <skaet> sorry
[19:48] <cjwatson> kenvandine: Where's this upload?
[19:48] <skaet> that comment was for infinity and gnome-icon-theme
[19:48] <infinity> kenvandine: Looks perfectly reasonable, but it won't hold up tonight's spins (and if they turn out to be final, won't make release)
[19:48] <skaet> not the libunity-webapps.
[19:48] <infinity> cjwatson: in the queue.
[19:48] <cjwatson> Oh, -proposed/unapproved
[19:48] <kenvandine> yeah
[19:48] <cjwatson> Keep being bitten by 'queue -Q unapproved info' not showing -proposed
[19:49] <cjwatson> Yeah, if we take more not-yet-built uploads at this point we push the respins out by at least another half an hour (probably an hour) and further diminish the odds of North American testing
[19:49] <cjwatson> tonight
[19:50] <infinity> Copying gdocs and icons.
[19:50] <kenvandine> cjwatson, certainly not worth a delay
[19:50] <kenvandine> infinity, thanks
[19:51] <infinity> So, that just leaves software-center in proposed.
[19:51] <infinity> We have another 10 minutes to debate its relevance in the modern world.
[19:52] <cjwatson> Oh, abiword needs to finish building and publishing on all architectures before Xubuntu and Lubuntu can be safely respun
[19:52] <cjwatson> If I'd noticed that I'd have required the sync to go to -proposed, sorry :-/
[19:52] <cjwatson> Oh eek, it failed on armel
[19:52] <cjwatson> Gah
[19:52] <infinity> cjwatson: Eek indeed.
[19:52] <cjwatson> "dangerous relocation: unsupported relocation"
[19:53] <cjwatson> What
[19:53] <infinity> cjwatson: Also, I was planning on doing lubuntu last, so it could pick up the chromium in proposed as well.
[19:53] <cjwatson> Well
[19:53] <slangasek> dangerous relocation: do not go in the attic
[19:53] <cjwatson> We aren't actually building any armel images, are we?
[19:53] <slangasek> we aren't
[19:53] <infinity> cjwatson: That feels like cosmic rays.  And yeah, doesn't affect images.
[19:53] <slangasek> do you mean to leave abiword FTBFS on armel in -release, then?
[19:53] <stgraber> infinity: can you try and get edubuntu early on? I haven't done any testing yet so if I can do some testing tonight it'd greatly appreciated
[19:53] <cjwatson> So it's not technically a respin blocker, but we can only get the archive consistent for release if we fix it
[19:54] <stgraber> edubuntu is a 30min build on i386+amd64 so not as bad as it used to :)
[19:54] <cjwatson> Let's hold off on Xubuntu and Lubuntu builds for as long as possible while we sort this out
[19:55] <infinity> Right then.  So.  Software-center?  Nasty memleak worked around, or drop it from proposed and insist on a GTK SRU to fix it "later"?
[19:56] <skaet> re: software-center - ok, looked at the diff, and see what its doing.
[19:56] <cjwatson> I see somebody's retried abiword/armel
[19:56] <skaet> get rid of the leak,  and let the proper fix be sorted later.
[19:56] <skaet> via an SRU
[19:57] <infinity> cjwatson: That was me, based on the fact that I can't see how the patch between -7 and -8 could have done that.
[19:57] <infinity> Alright, copying s-c.
[19:57] <cjwatson> Me neither, and the last build was recent
[19:57] <cjwatson> I think I'll try racing ishigaq with a build on scheat
[19:58] <infinity> ishigaq will win.
[19:58] <cjwatson> (scheat'll lose, but just in case it fails again)
[19:58] <infinity> Mostly because its name it less comical when spoken aloud.
[20:05] <infinity> Alright, looks like, barring some serious show-stopper in the next hour, we're past our last publisher cut-off for stuff for this respin.
[20:05] <infinity> And xubuntu and lubuntu will wait a bit longer.
[20:06] <infinity> (Also, chromium's just finishing up)
[20:06] <cjwatson> Ah, yes, it already wasn't built on powerpc
[20:06] <infinity> (Also, also: copying gnome-shell to -release)
[20:07] <kenvandine> infinity, so libunity-webapps didn't build in time?
[20:07] <infinity> kenvandine: It'll be two publisher cycles behind.
[20:08] <kenvandine> ok
[20:08] <infinity> kenvandine: Needs to build in proposed, publish, get copied, publish.
[20:08] <slangasek> kenvandine: even if it would have, it wouldn't get copied in time; there was not much time going around
[20:08] <infinity> kenvandine: So, no, unless the world stops for other reasons, it's stuck in proposed.
[20:08] <kenvandine> yeah, just checking
[20:08] <kenvandine> i hope it doesn't stop :)
[20:08] <kenvandine> get those isos!
[20:08] <kenvandine> :-D
[20:11] <slangasek> kenvandine: which means bug #1067461 ought to be properly SRUified so that it doesn't wind up stalling somewhere in the process
[20:11] <ubot2> Launchpad bug 1067461 in libunity-webapps "Update Amazon affiliates code for webapps runner target url" [Medium,Confirmed] https://launchpad.net/bugs/1067461
[20:12] <infinity> Thankfully, it's a 2 or 3 line SRUification, I suspect.
[20:13] <infinity> "Test-case: URLs look correct and go somewhere that's not goatse".
[20:14] <cjwatson> infinity: Did you by any chance keep a copy of the failing abiword log?  Just wondering what file it failed in.
[20:15] <infinity> cjwatson: No, if it does it again, then I'll be curious.
[20:15] <cjwatson> Irritating how we lose those logs quite so quickly on retry.  It'd be nice if the GC waited until the next build is finished.
[20:15] <infinity> cjwatson: It was GCed already?
[20:17] <cjwatson> I got a 404 from the librarian.  I think.
[20:17] <cjwatson> google says qt4-x11 had this problem recently, and doko recommended disabling parallelisation
[20:17] <cjwatson> Which would support the "retry might work" theory
[20:18] <jbicha> I'd rather get gdm in pre-release too, thanks!
[20:18] <cjwatson> (Unless -gstabs fixed it)
[20:18] <cjwatson> jbicha: I'd like to avoid loading the builders further just for a few hours
[20:19] <cjwatson> In particular if we have to upload something respin-critical I don't want to end up blocked on powerpc
[20:20] <jbicha> ok
[20:21] <cjwatson> Shouldn't take too long to clear ...
[20:23] <infinity> So, ftpmaster's nearly done publishing.  Who wants to drive?  I was going to, but I'm just as happy to hand it off to someone in a more pleasant timezone.
[20:23]  * infinity looks at slangasek.
[20:25] <skaet> if slangasek's not available, I can.
[20:25] <skaet> adjust the order of the pad build scripts though so lubuntu, and the other considerations are accurate please.
[20:26] <infinity> Less about order and more about skipping lubuntu and xubuntu entirely for now.  But I'm already prepping to start it all up.
[20:26] <phillw> he he, I never thought I'd ever ask "please build lubuntu last" :)
[20:27] <skaet> ok.  please post what you start off either here or the pad, so we don't overlook.
[20:27] <skaet> since we'll need to remember to tack on lubuntu and xubuntu later.
[20:27] <phillw> thanks for squeezing chromium in for lubuntu.
[20:30] <slangasek> oh usb-creator
[20:30] <slangasek> you're writting in python, so I'd really appreciate it if you didn't segfault
[20:31] <slangasek> s/writting/wrotnon/
[20:31] <slangasek> skaet: do you want me to drive, or are you doing it?
[20:31] <infinity> Alright, starting the world minux lubuntu/xubuntu.  The commands for x/l are in the pad to pick them up later.
[20:31] <infinity> s/minux/minus/
[20:31] <skaet> slangasek,  infinity's doing it.
[20:31] <slangasek> ok
[20:34] <skaet> infinity, slangasek - iso tracker marked for rebuilding now.
[20:36] <infinity> Alright, spinning away.
[20:38] <infinity> And chromium's done.  Will copy at :03
[20:39] <phillw> infinity: thanks :)
[21:26] <ScottK> stgraber: ^^^
[21:28] <hggdh> xnox: I un-milestoned bug 1062625. We will need somebody else to get a similar machine from Dell
[21:28] <ubot2> Launchpad bug 1062625 in ubiquity "Ubuquity partitioning fails to find /dev/sda" [High,Incomplete] https://launchpad.net/bugs/1062625
[21:29] <stgraber> ScottK: yay!
[21:34] <cjwatson> infinity: scheat is actually beating ishigaq, amusingly
[21:34] <cjwatson> Admittedly not by lots
[21:42] <cjwatson> I take that back.  By quite a lot.
[21:44] <cjwatson> scheat's reached dh_strip, lending credence to the "cosmic rays" theory.
[21:59] <infinity> Copying chromium-browser to release.
[22:04]  * phillw sends infinity cookies & beer :)
[22:17] <cjwatson> Oh, thank God for that.  abiword/armel built this time.
[22:19] <cjwatson> infinity: Xubuntu and Lubuntu will be good to build once chromium-browser has published, then.
[22:20] <cjwatson> Since the abiword build just means we won't have to do another source upload there.
[22:20] <infinity> cjwatson: Yep.
[22:21] <cjwatson> So, in fact, any time from now.
[22:23] <infinity> Indeed.  Going to spin the alternates, and then the other missing ones.
[22:27] <cjwatson> I'll take gdm now for jbicha
[22:27] <cjwatson> 23:27 <cjwatson> I'll take gdm now for jbicha
[22:28] <cjwatson> Although no opinion on whether it's a pre-release thing
[22:28] <cjwatson> I guess it's universe and unseeded so no particular reason not to
[22:29] <cjwatson> micahg: I think you're good to start in on webkit experimentation now if you want
[22:31]  * cjwatson goes to crash for a while.
[22:39] <ScottK> ^^^ would make a nice opportunity target if we respin again, but it's perfectly SRU able.
[22:44] <phillw> ScottK: again?!! :P
[22:58]  * infinity goes to bed, while the images continue to roll out.
[23:00] <slangasek> infinity: anything that I should worry about tending?
[23:00] <infinity> slangasek: All the builds look happy, so far.
[23:00] <slangasek> ok
[23:00] <infinity> slangasek: Reviewing proposedy things for hybrid opportunity/SRU acceptance wouldn't go amiss.
[23:14]  * skaet --> dinner
[23:37] <micahg> is the release team still accepting unseeded universe RC bugs?
[23:39] <slangasek> micahg: I haven't seen a freeze announcement go out, so AFAIK yes
[23:42] <jbicha> micahg: hurry before skaet returns from dinner :)