[02:30] <micahg> ^^ Bug #986387
[02:30] <ubot2> Launchpad bug 986387 in ubuntu "FFe: Sync django-celery 2.4.2-1 (universe) from Debian testing (main)" [Undecided,In progress] https://launchpad.net/bugs/986387
[02:30] <micahg> ScottK: ^^
[02:31]  * ScottK looks.
[02:34] <micahg> ^^ Bug #986017
[02:34] <ubot2> Launchpad bug 986017 in ruby-sequel "FFe: Sync ruby-sequel 3.33.0-1 (universe) from Debian testing (main)" [Wishlist,In progress] https://launchpad.net/bugs/986017
[03:40] <ScottK> slangasek: Bug #92782 has a branch with a proposed fix attached.  Seemed like something up your alley and perhaps a good early SRU candidate (if the fix is correct - I've no idea).
[03:40] <ubot2> Launchpad bug 92782 in ubuntu "/var/crash/_usr_bin_beryl.1000.crash" [Undecided,Invalid] https://launchpad.net/bugs/92782
[03:44] <ScottK> Bug #927828 would be it.
[03:44] <ubot2> Launchpad bug 927828 in sudo "sudo: pam_mount.c:417: modify_pm_count: Assertion `user != ((void *)0)' failed." [High,Triaged] https://launchpad.net/bugs/927828
[03:54] <ScottK> jbicha: gnome-sushi is unseeded.  It can go straight to -release.  Would you please re-upload it (I'll reject this one, no need to change the version number).
[03:56] <jbicha> ScottK: sure, I forgot it only ships one binary these days
[03:56] <ScottK> Thanks.
[08:41] <cjwatson> caph seems busted - failing to unpack chroots.  I've put it on manual for the time being.
[10:42] <phillw> Hi, with Xubuntu & Lubuntu running on non-pae kernel for 32 bit, is there an option of non-pae kernel in the netboot area?
[11:05] <phillw> Scrub that question... found it :)
[14:34] <skaet> slangasek,  cjwatson,  looks like we may have an issue with grub-installer, based on some recent bugs that have come in.
[14:34] <skaet> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/986797
[14:34] <ubot2> Launchpad bug 986797 in linux "package linux-image-3.2.0-23-generic 3.2.0-23.36 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 2 (dup-of: 916077)" [Undecided,Confirmed]
[14:34] <ubot2> Launchpad bug 916077 in grub-installer "grub-install - /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?)." [Undecided,Confirmed]
[14:35] <cjwatson> 986797 has nowt to do with grub-installer
[14:35] <skaet> appears likely to be a duplicate of https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/916077
[14:36] <cjwatson> incorrect duplication
[14:36] <skaet> yup,  sorry
[14:36] <skaet> https://launchpad.net/bugs/916077
[14:36] <ubot2> Launchpad bug 916077 in grub-installer "grub-install - /usr/sbin/grub-probe: error: cannot find a device for /boot/grub (is /dev mounted?)." [Undecided,Confirmed]
[14:36] <cjwatson> which is isolated, I wouldn't worry about that
[14:37] <cjwatson> in any event an upgrade problem cannot possibly be in grub-installer
[14:38] <cjwatson> the logs in 916077 are something entirely different due to LVM or something which isn't supported in ubiquity anyway, so I'm ignoring that
 skaet: looking at VarLogDistupgradeApttermlog, I'm seeing the following:
[14:39] <skaet> * shadeslayer (~shadeslay@ubuntu/member/shadeslayer) has joined #ubuntu-kernel
 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
 /usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
 run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-23-generic.postinst line 1010.
 dpkg: error processing linux-image-3.2.0-23-generic (--configure):
  subprocess installed post-installation script returned error exit status 2
[14:39] <shadeslayer> what
 skaet: which looks to actually indicate something going wrong with grub-probe
[14:39] <knome> omzg, double flood
[14:39] <skaet> sorry shadeslayer,  accidental pick up on the copy paste.
[14:39] <cjwatson> no need to repaste that, it's just stuff from the bug
[14:39] <shadeslayer> ok
[14:39] <skaet> ok
[14:42] <cjwatson> ogasawara: for the record, "issue with grub-probe" is kind of like "kernel hang", you can't just mark one a dup of another
[14:45] <cjwatson> skaet: this is essentially an isolated instance, despite being multiple bugs from the same user, so I'm not going to panic
[14:46] <cjwatson> skaet: I'm sure it's a real bug but it could well be confined to some particular weird mount layout
[14:46] <cjwatson> I've posted a comment requesting more information
[14:46] <skaet> cjwatson, fair nuf.   you've got the better instincts here (by far)
[14:47] <skaet> cjwatson,  bjf did confirm it though,  but more data is definitely needed.
[14:48]  * skaet goes to get some food... back later
[14:49] <cjwatson> skaet: by my reading, that "confirmed" means "has sufficient logs".
[14:49] <cjwatson> It could be something to do with doing an upgrade within aufs.
[14:51] <cjwatson> Actually maybe not, that would only be in --sandbox mode which isn't a real upgrade IIRC
[14:52] <cjwatson> Based on Erick's comments about having a working system afterwards, I suspect we may not be able to get more data
[14:53] <cjwatson> I'll try a manual test upgrade in a vm tomorrow and see if it reproduces
[14:54] <ogasawara> cjwatson: ack, noted for future reference.  will clean up the bugs.
[14:54] <cjwatson> already done
[14:55] <cjwatson> Erick's at least
[14:55] <ogasawara> cjwatson: ah, thanks
[14:57] <cjwatson> and yes, now analysed 916077 and it's definitely a different problem
[15:26] <astraljava> skaet: other release team members: Should the link to the images once precise gets released point to http://cdimages.u.c or http://releases.u.c?
[15:26] <astraljava> Oh sorry, this is re: release notes, of course.
[15:27] <knome> btw, clicking on xubuntu in releases.u.c points to cdimages.u.c ;)
[15:27] <knome> just notices
[15:27] <knome> *d
[15:28] <astraljava> Ahh... ok, I suppose that answers my question. Thanks.
[15:28] <cjwatson> Xubuntu images live on cdimage.ubuntu.com not releases.ubuntu.com, yes
[15:28] <cjwatson> Only the highest-traffic images are on releases
[15:28] <cjwatson> It's a question of mirroring
[15:28] <ScottK> cjwatson: re your comment on #ubuntu-devel awhile ago about making sure the New queue is clear: esteid-browser-plugin is waiting for a supportability ack from mozillateam (specifically chriscoulson).  Unless it gets that, it needed to be rejected again.
[15:28] <cjwatson> (Also, please use cdimage.ubuntu.com rather than cdimages.ubuntu.com; they're aliases, but I consider cdimage the canonical name)
[15:29] <cjwatson> ScottK: Right, I think Chris had informally acked that (possibly out of despair more than anything else) but I need to check that
[15:29] <cjwatson> I did mean clear by any means for release, though :-)
[15:30] <ScottK> Certainly.  Clear could go either direction and I wanted to make sure you were aware of the complications on that one.
[15:30] <cjwatson> In fact, the DNS considers cdimage the canonical name, too
[15:30] <cjwatson> I am :-/
[15:30] <cjwatson> but thanks
[15:30] <cjwatson> cdimages.ubuntu.com.    579     IN      CNAME   cdimage.ubuntu.com.
[15:31] <Laney> clears! the! ghc! transition!
[15:31] <astraljava> Thanks, cjwatson!
[15:38] <skaet> Thanks cjwatson,  re: 986797.
[16:05] <astraljava> What is the status of aptitude re: multiarch? I'm left with a confused mind after reading bug #831768 comments.
[16:05] <ubot2> Launchpad bug 831768 in aptitude "aptitude cannot handle conflicts with multiarch enabled" [Unknown,Fix released] https://launchpad.net/bugs/831768
[16:06] <astraljava> Am I to believe that we should still warn against using it for m-a setups?
[16:09] <cjwatson> It doesn't seem exactly ideal for such setups, no.
[16:09] <astraljava> Ok, thanks again.
[16:40] <Laney> FTBFS fix
[16:44] <stgraber> yay, was hoping for that one
[16:44] <Laney> :-)
[16:45] <stgraber> right, so it's seeded on Edubuntu. I'll do the review now but as we don't release for arm (where the FTBFS currently occurs IIRC), I'd just consider it an opportunity target
[16:46] <Laney> it's arch:all
[16:46] <Laney> but you shouldn't need to respin for it or anything
[16:47] <stgraber> argh, right, that one is the arch:all one :) vnc is the arch:armhf one that we don't care a lot about (as we don't release armel/armhf and it never build anyway)
[16:48] <stgraber> ah, right, it's a sync, so no diff for me... bad LP.
[16:48] <Laney> yeah, that is annoying
[16:50] <stgraber> right, diff looks good and that's giving us one less package with Ubuntu delta, +1
[16:51] <stgraber> I'll add it to the pad as opportunity target for Edubuntu
[16:59] <Laney> cheers
[17:04] <slangasek> ScottK: yes, there are several bugs in the area of sudo's pam handling that I want fixed in early SRU - the other one I don't have a patch for quite yet.  I'd rather do them as a single upload next week
[17:07] <slangasek> astraljava, cjwatson: I think the release note regarding aptitude multiarch could probably use refining however, as the current one seems to be based on the pre-0.6.6 behavior
[17:10] <astraljava> slangasek: Right, so what would you suggest? I haven't been near a precise box for over a week now, so don't have a hands-on feel for it. Can test some scenarios though later this evening.
[17:10] <slangasek> I would suggest that someone who uses aptitude document what the real issues are :-)
[17:10] <slangasek> (I don't use aptitude, so I can't say much)
[17:12] <astraljava> Yeah ok, well I suppose we can look at that during the final few days if someone who has more recent experiences steps up with the issues. I'll see whether I can find any.
[17:46] <cjwatson> and that's the Perl 5.14 transition complete, whee
[17:47] <maxb> heh
[17:51] <maxb> So the latest on the subversion FTBFS is that I've got it to build... sometimes. But have run into at least one test which occasionally misbehaves, and still isn't fixed to pass consistently in upstream's trunk, and it's not trivial to do so.
[17:52] <maxb> As such, the only way I see of having a reliably building Subversion right now would be the solution I originally proposed on ubuntu-devel@, of disabling the hash order randomization entirely
[17:52] <maxb> (Or just making the testsuite non-critical to build success)
[17:53] <maxb> Neither of which are exactly wonderful
[17:53] <maxb> In any case, it's probably far far too late to do anything for release now anyway
[18:34] <ScottK> maxb: Or disable that one test.
[18:35] <ScottK> Looking at Debian Bug #668227, I'm thinking we should just sync links2.  I verified it builds on Ubuntu and I think whatever feature risk the new release brings, retiring the known security issues in more important.
[18:35] <ubot2> Debian bug 668227 in links2 "links2: security bugs in links" [Grave,Fixed] http://bugs.debian.org/668227
[18:36] <ScottK> If some other release team person will second that, I'll copy/paste into an FFe bug and do it.
[18:39] <micahg> ScottK: I forgot gcc-mingw-w64 isn't a sync, but a sync+diff (our breaks/replaces version is different since our gcc is behind due to the freeze
[18:39] <ScottK> micahg: OK.  Please upload a fix and I'll approve it.
[18:39] <micahg> thanks
[18:45] <micahg> should a sub-minute package with an arch-all component go to-proposed?
[18:46] <astraljava> `gksudo update-manager -d` should mention of a devel cycle, correct? I'm not seeing it in my Xubuntu oneiric instance running in Parallels. Worth a bug, or does someone have ideas to try before I file one?
[18:47] <micahg> astraljava: we might have the final tarball in now (base-files was updated already)
[18:49] <astraljava> micahg: So, try again in an hour or so?
[18:49] <micahg> astraljava: huh?  no, I'm just telling you why it might already be like that
[18:49] <astraljava> Okay, then I'm not just understanding the cause -> effect chain here. :)
[18:50] <micahg> astraljava: precise no longer says it's development since we're in RC mode :)
[18:50] <astraljava> Ahh... ok, sorry for my dumbness. :D
[18:51] <astraljava> But, without that switch it isn't mentioning precise either.
[18:51] <knome> astraljava, no need to be sorry... i'm sorry *for you* for your dumbness.
[18:52] <astraljava> Are we in some sort of state of transition or something?
[18:52] <astraljava> knome: It will hit you at some point, though, and _then_ you'll be sorry.
[18:53] <knome> muahah.
[18:53] <ScottK> micahg: to -release is fine.
[18:54] <ScottK> micahg: Would you re-upload gcc-mingw-w64 to -release pleaee.
[18:54] <ScottK> please even.
[18:55] <cjwatson> micahg: base-files isn't involved there, it's the meta-release* files on changelogs.ubuntu.com that govern that
[18:55] <micahg> ScottK: that will cause uninstallability on systems with gcc-mingw32
[18:55] <ScottK> micahg: I think it's a niche enough package that it's OK.
[18:55] <micahg> cjwatson: ah, ok, so were those updated as well?
[18:56] <cjwatson> dunno, haven't looked :)
[18:56] <micahg> ScottK: you're the one pushing the button, reuploading :)
[18:56] <cjwatson> mvo doesn't normally do them 'til release day though
[18:56] <cjwatson> it's on ReleaseProcess
[18:56] <micahg> astraljava: ^^ so maybe :)
[18:57] <ScottK> micahg: Thanks.
[18:58] <astraljava> micahg: Ok, I'll try again, maybe the started `do-release-upgrade -d` but cancelled at prompt put the system in a weird state for that.
[18:58] <ScottK> Woah.  I see three powerpc builders.  \o/
[18:58] <ScottK> cjwatson: ^^^
[18:59] <Laney> NICE
[18:59]  * Laney uploads both GHC and Mono in celebration
[19:00] <astraljava> Hrm... no. Ok, I'll file one, then.
[19:00] <ScottK> Laney: Thoughts on my comment about links2 above?
[19:01] <Laney> let's look
[19:02]  * micahg starts package the tar and feathers...
[19:02] <micahg> s/package/packing
[19:11] <Laney> ScottK: Looks good, and the 'several […] security issues' make it seem worthwhile.
[19:12] <Laney> The changelog doesn't even seem massively featureful, and I smoke tested it a bit. Go for it.
[19:24] <ScottK> Thanks
[19:30] <ScottK> OK.  That leaves us with asterisk having the only "Grave bug fixed in Debian and not in Ubuntu."
[19:34] <Laney> s'alright, we've palmed that off to Daviey :-)
[19:37] <ScottK> Not sure if it's going to stick or not.
[19:37] <ScottK> He's also got a maas upload to review and then server-respins to handle.
[19:40] <Laney> Yeah. Who prepared the update? Was it jtaylor? We could interrogate him if any testing has been performed.
[19:44] <cjwatson> ScottK: aye, we got a present a few days back
[19:44] <ScottK> Very nice.
[19:44] <ScottK> I know it's been a long time coming.
[19:44] <cjwatson> sulfur was intended to be a livefs buildd, but it turned out to be no faster at that than royal
[19:44] <cjwatson> too I/O-bound
[19:45] <cjwatson> so we made it an lp-buildd instead since it has twice the cores or something
[19:45] <ScottK> Got it just in time for the first "Q" autosync.
[19:46]  * cjwatson is looking forward to NOT using sync-source.py -a for that
[19:47] <cjwatson> come to think of it non-C archive admins can do autosyncs now if they feel like it
[19:47] <cjwatson> though I expect I'll keep on doing them routinely unless I'm on holiday or whatever
[19:47] <ScottK> Did someone yet figure which day it is we can't progress towards opening the "Q" archive if sabdfl doesn't give us a name?
[19:49] <cjwatson> Thursday
[19:50] <ScottK> "It's going to be Quality Quail unless you give us a different one by Thursday ..."
[19:51] <ScottK> skaet: ^^^  that's for you.
[21:20] <ScottK> micahg: You have a gcc-mingw64 FTBFS on armel to look into ...
[21:20] <micahg> ScottK: I know, I e-mailed the debian maintainer, it's in gcc code though :(
[21:20] <ScottK> OK.  Thanks.
[21:33] <Daviey> Laney / ScottK: Yeah, thanks for the reminder.
[21:33] <Daviey> :)
[22:49] <cjwatson> skaet: Hmm.  Nobody remembered to set OFFICIAL="Release" in debian-cd ...
[22:50] <cjwatson> So we can't release the current image set
[22:50] <cjwatson> (Though we don't necessarily have to respin the livefses)
[22:50]  * cjwatson eyes the process pages
[22:54] <cjwatson> (added to the pad)
[22:54] <cjwatson> it's rolled out now, not doing respins just now though since we ought to talk about it first
[22:55] <CareBear\> do you get overtime?
[22:55] <CareBear\> or are you in Japan and it is Monday morning? :)
[22:55] <cjwatson> Neither
[22:55] <CareBear\> just crazy crunching on the weekend
[22:56] <cjwatson> One of those times where it's easier to do more in advance
[22:56] <CareBear\> absolutely! I love working nights and weekends because noone else is doing it
[22:56] <CareBear\> well except you then
[22:57] <cjwatson> Also I have kids, I can concentrate better at night sometimes
[22:57] <cjwatson> At least for longer uninterrupted periods
[22:57] <CareBear\> it would destroy productivity
[22:58] <CareBear\> which is low as it is
[22:58] <CareBear\> :)
[22:58] <CareBear\> at least at times
[23:59] <skaet> cjwatson,  thanks for catching and adding to pad.