[02:57] <micahg> infinity: can you give back the armhf chroot failures for the rebuild?
[03:58] <rsalveti> infinity: finally got xbmc to work! had it building since yesterday, but the tinyxml replacement (patch from debian) is still lacking one method, that broke the support when using GLES
[03:59] <rsalveti> infinity: I'm forwarding the fixes first to the debian maintainer, so he can review it, then I should have the proper debdiff in place probably tomorrow/wednesday
[04:00] <rsalveti> also have the extra functions for jockey to support the sgx driver, waiting one fix to land at nvidia-common tomorrow
[04:00] <rsalveti> (nvidia-common in theory should be graphics-card-common)
[05:25] <infinity> micahg: We have some?
[05:25] <infinity> micahg: I think cjwatson had some API magic to hunt those down.
[05:26] <micahg> infinity: nasl was still hosed, I got hloeung to fix it a couple hours ago
[05:26] <infinity> Err, not "still", then, "newly".
[05:26] <infinity> Cause it was fine after thedac recovered it.
[05:27] <micahg> ok, well, it tripped again then :)
[05:27] <infinity> Disconcerting.
[05:29] <micahg> infinity: oh, and I stole roseapple back for a chromium build
[05:29] <infinity> Pff.  Impatient.
[05:29] <micahg> infinity: no, I needed the RAM :)
[05:29] <micahg> gcc-4.5 + chromium on natty + i386 = FTBFS
[05:30] <infinity> Oh.
[05:30] <infinity> Special.
[05:30] <micahg> lucid on the same builder was fine
[05:31] <micahg> actually, it could be binutils as I think it's linking where it runs out of memory
[05:32] <infinity> Build with -gstabs
[05:32] <infinity> I assume you're already using the other linker flag to make it be less grumpy.
[05:32] <micahg> yeah, I think that's in the gyp config
[05:39] <pitti> hm, is the bot down?
[05:39] <infinity> Doesn't seem to be connected.
[05:39] <infinity> So, that's a yes. :P
[05:39] <pitti> I reviewed a bunch of stuff in unapproved, and uploaded apport, but nothing did appear here
[05:39] <pitti> ah
[05:39] <infinity> stgraber: queubot's a sad panda.
[06:27] <micahg> infinity: you can take roseapple back if you like
[06:58] <pitti> I'd appreciate if someone could review my apport and cups-filters uploads
[06:59] <pitti> ttf-dejavu as well (but that still needs to get diffy)
[07:17]  * pitti leaves a "do not accept" comment for cobbler in the pad
[07:17] <pitti> Daviey: ^ distro-info is in universe ATM
[07:18] <micahg> pitti: bug 964008
[07:18] <ubot2> Launchpad bug 964008 in shunit2 "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,Fix committed] https://launchpad.net/bugs/964008
[07:19] <pitti> micahg: ah, thanks
[07:19] <pitti> ack, accepting/promoting then
[07:23] <stgraber> infinity: fixed
[07:30]  * Daviey goes home, i'm not needed :)
[07:33] <stgraber> pitti: looking at your uploads now
[07:37] <stgraber> pitti: ttf-dejavu is good to go
[07:37] <micahg> pitti: can you please copy {lucid, maverick, natty}/chromium-browser from ubuntu-security-proposed to -proposed?
[07:37] <pitti> stgraber: will you accept, or are you not in the archive-admin team yet?
[07:38] <stgraber> pitti: I'm not in archive-admin, so you'll need to do the accepting
[07:38] <pitti> stgraber: accepted, thanks for the review
[07:38] <pitti> micahg: running
[07:39] <stgraber> pitti: apport is good to go too
[07:39] <micahg> pitti: once that finishes, can you copy maverick only to -security and -updates (want to do it before it gets too late, it's almost the 11th somewhere :))
[07:40] <pitti> micahg: you mean the version that I just copied from the PPA?
[07:40] <pitti> micahg: why copy it to -proposed in the first place then?
[07:40] <micahg> pitti: yes
[07:40] <micahg> pitti: that's the SRU approval that it has to go through -proposed :)
[07:40] <stgraber> pitti: and cups-filters is good too
[07:41] <pitti> stgraber: cheers
[07:41] <pitti> micahg: hm, I don't quite understand the purpose of this then, but if that's been discussed, fine with me :)
[07:42] <pitti> micahg: so, to double-check, you want 18.0.1025.151~r130497-0ubuntu0.10.10.1 (which is in the PPA, I am currently copying to -proposed) to -updates as well?
[07:42] <micahg> pitti: that's how I understood the original approval :), I just looked for proof and couldn't find it :)
[07:42] <micahg> pitti: yes, and -security
[07:42] <infinity> There's zero point in putting it in proposed if you're doing updates and security at the same time...
[07:42] <pitti> yes, that's what I meant
[07:42] <infinity> proposed only makes sense if you intend to let it get tested.
[07:43] <micahg> I did test it :), I am looking for what was said now
[07:43] <infinity> I meant "get it more broadly tested", smartass. ;)
[07:43] <apw> whats written as process does not always make sense in the real world
[07:44] <infinity> apw: Which is why I defiantly wipe with my left hand and eat with my right.
[07:44] <infinity> (was that my out loud voice?)
[07:44] <apw> [fully outside]
[07:45] <micahg> ok, now I wonder if my mind invented that, I can't seem to find any record of the requirement of -proposed
[07:45] <pitti> micahg: all done, as our meticulous queuebot documented :)
[07:45]  * micahg will ask jdstrand in the morning
[07:46] <micahg> pitti: excellent, thanks
[07:47] <micahg> ok, herés what it is, as infinity said basically :), https://wiki.ubuntu.com/SecurityTeam/PublicationNotes#Chromium_Browser
[07:48] <micahg> or at least implied as such
[07:49] <stgraber> pitti: can you approve epoptes please?
[07:49] <infinity> micahg: Yeah, see, assuming a full (binary+source copy) from the PPA, and also assuming that you're the only person testing, the in-between -proposed step is pointless paperwork.
[07:50] <infinity> micahg: If there was a "cooking time" in proposed, where other testers got involved, that would be different, but there intentionally appears not to be.
[07:50] <pitti> or if it was copying the source only
[07:50] <pitti> stgraber: done
[07:50] <infinity> micahg: So, having tested the binaries, you've tested the binaries, I don't care where you downloaded them from when you did.
[07:50] <micahg> infinity: well, sometimes I just don't get to it and then it has bake time
[07:50] <stgraber> pitti: thanks
[07:50] <infinity> pitti: Yeah, hence why I specified source+binaries.
[07:50] <micahg> infinity: but as today is Maverick's EOL, I didn't want to push it out too late :)
[07:50] <infinity> ;)
[07:51] <micahg> lest someone accuse me of updating an EOL release
[07:51] <infinity> You could have celebrated maverick's EOL by not pushing updates for it at all. :P
[07:51]  * apw raises a glass to the mighty MM
[07:51] <pitti> oh, is it already?
[07:51] <micahg> infinity: I get to do that too :)
[07:51] <infinity> pitti: 10.10.10 + 18
[07:51] <pitti> oh, indeed
[07:51] <pitti> plus a leap day :)
[07:51] <micahg> infinity: bug 972840
[07:51] <ubot2> Launchpad bug 972840 in thunderbird "Thunderbird 11 stable release migration" [Undecided,In progress] https://launchpad.net/bugs/972840
[07:52] <infinity> Time flies when you're... Doing whatever we do.
[07:52] <Daviey> oh dear, i still have some Maverick machines.. can we not EOL it until tomorrow? :)
[07:52] <pitti> rm maverick.tar.gz
[07:52] <infinity> Daviey: It's not going to archive to old-releases that quickly, we're slack.
[07:52] <pitti> Farewell, Meerkat
[07:53]  * Daviey can feel secure for a little longer.
[07:53]  * infinity notes that, in practice, it's probably a bad idea to technically EOL (though, clearly, it's officially EOL today) an in-between release until the next LTS is out.
[07:54] <infinity> I don't feel the urge to pile on to the upgrade path confusion, even if we do get it all flawlessly right.
[07:54] <micahg> infinity: well, seemingly the people still on lucid want to stay there until the LTS
[07:54] <infinity> (That said, time to get the wheels in motion to have it copies to old-releases and make sure update-manager DTRT, etc)
[07:54] <nigelb> micahg: yes. yes. :)
[07:55] <infinity> micahg: No, but people on Maverick are on, well, Maverick, and things sometimes go a little pear-shaped when we archive releases.
[07:55] <micahg> infinity: yes, well, they have an upgrade path :)
[07:55] <infinity> (Not an excuse for us not making sure we do it right, just saying I'm more comfy with the maverick->natty->oneiric->precise path happening entirely on archive.u.c for now)
[07:55] <infinity> micahg: Don't forget that maverick-updates is part of that upgrade path.
[07:56] <micahg> infinity: well, yes, maybe we should starting blinking warning at people before their release is EOL
[07:58] <micahg> pitti: you copied the wrong package to -updates/security
[07:58]  * micahg should pay attention to queuebot
[07:59] <micahg> .151 is the one that needs to go
[07:59] <pitti> pitti | micahg: so, to double-check, you want 18.0.1025.151~r130497-0ubuntu0.10.10.1 (which is in the PPA, I am currently copying to -proposed) to -updates as well?
[07:59] <micahg> [02:44] -queuebot/#ubuntu-release- Unapproved: chromium-browser (maverick-security/universe) [18.0.1025.142~r129054-0ubuntu0.10.10.1 => 18.0.1025.142~r129054-0ubuntu0.10.10.1] (no packageset) (sync)
[07:59] <micahg> [02:44] -queuebot/#ubuntu-release- Unapproved: chromium-browser (maverick-updates/universe) [18.0.1025.142~r129054-0ubuntu0.10.10.1 => 18.0.1025.142~r129054-0ubuntu0.10.10.1] (no packageset) (sync)
[07:59] <pitti> micahg: oh, so sru-release apparently did not yet catch the new one; there was a previous 18.0 in -proposed apparently?
[07:59] <micahg> yes
[08:00] <micahg> these updates have been one right after the next
[08:00] <pitti> meh, since when does that need a publisher
[08:01] <pitti> micahg: so, I'll wait a bit for the publisher to run
[08:02] <micahg> ok, Ím not really worried as I haven't had an update totally blow up except for one :) (but this version .142 has been tested in multiple releases already without  major issue)
[08:06] <pitti> micahg: hm, publisher shoudl be running now, and still doesn't show 151; I'll re-try in 30 mins, going to supermarket now
[08:08] <micahg> pitti: ok, hopefully Íll be asleep when you return :)
[08:43] <stgraber> ^ ltsp should be a very easy review, just converting a dangling symlink into a file
[09:15] <pitti> stgraber: done
[09:15] <pitti> can someone please review lightdm? grave security issue
[09:18] <pitti> micahg: ^ FYI
[09:31] <tseliot> hi, can anybody reject my last upload of nvidia-common, please?
[09:31] <tseliot> pitti: ^
[09:31] <pitti> tseliot: *zap*
[09:44] <tseliot> pitti: thanks, it's ok to approve my new upload now, as previously discussed via email
[09:47] <pitti> tseliot: thanks, LGTM
[09:59] <tseliot> pitti: thanks again
[10:07] <gord> hey guys, any chance we can get some form of ack on https://bugs.launchpad.net/ayatana-design/+bug/839480 ? ffe needed for the release
[10:07] <ubot2> Launchpad bug 839480 in ayatana-design "[FFe, UIFe] Dash - When the Dash is open and there is a maximised app in the background, the top bar background should not disappear" [Critical,Fix committed]
[10:07] <pitti> I just tried to see what this is about, but the description isn't sufficient for me to understand it
[10:07] <pitti> the panel looks no different to me, regardless of whether I have a maximized app or not
[10:08] <pitti> oh, I guess that's the thing you want to change
[10:08] <pitti> consistency is for the weak?
[10:08] <gord> hrm hold on, maybe the bug got targeted to the wrong branch accidentally, let me properly check
[10:09] <pitti> infinity: Debian finally packaged py3cairo with a few fixes (undistributable files, splitting out docs, more modern packaging)
[10:09] <pitti> infinity: I verified that the Debian package builds and works, and it has zero rdepends in precise
[10:10] <pitti> infinity: I'd like to sync it; want a bug/debdiff for review, or JFDI?
[10:10] <infinity> pitti: Is the diff even remotely readable?
[10:10] <pitti> readable yes, but not that small
[10:10] <infinity> pitti: Heh.  How about debdiffing the debs instead?
[10:11] <pitti> http://paste.ubuntu.com/923080/
[10:11] <infinity> pitti: Make sure they end up with the same files installed, etc.
[10:11] <pitti> infinity: binary diff: http://paste.ubuntu.com/923081/
[10:11] <infinity> pitti: It's not like python packaging is particularly magical.  If it's right, it's right.
[10:11] <pitti> i. e. no surprise except that the new -doc package doesn't exist in our packaging
[10:12] <infinity> pitti: Yeah, that looks sane.
[10:12] <cjwatson> pitti: FWIW you can just temporarily hack sru-release to search for Pending rather than Published, for the sort of problem you had with chromium-browser
[10:12] <pitti> cjwatson: oh, of course; thanks
[10:15] <gord> pitti, okay i checked, so the best way to see the difference is to open the dash on a workspace with no windows on it, you'll see your wallpaper behind the panel, move to a workspace with a maximised window, open the dash, you'll see no wallpaper behind your panel
[10:17] <infinity> pitti: Accepted, and napping.
[10:17] <pitti> infinity: cheers, and good night
[10:20] <Riddell> chrisccoulson: ping
[10:20] <Riddell> are you happy for me to accept esteid-browser-plugin now?
[10:21] <chrisccoulson> Riddell, no. i sent an e-mail to Q-FUNK and had no response so far, and i haven't checked if it addressed my technical concerns either
[10:21] <chrisccoulson> uploading a firefox extension implies a commitment from me to maintain it for 5 years, which i'm not willing to do
[10:23] <Riddell> chrisccoulson: he's uploaded a version he says is fixed now
[10:23] <Riddell> and can't it go in universe?
[10:24] <infinity> Riddell: Even in universe, it has a commitment, since we rev firefox with new majors every 3 days.
[10:24] <infinity> Riddell: It's why we blacklist all mozilla extensions from Debian.
[10:24] <infinity> Riddell: Cause that's saner than having them all break two weeks after release.
[10:25] <infinity> Riddell: I mean, it's not that we overtly make a commitment, but it's silly to ship software we know we're going to intentionally break, without the uploader at least somewhat committing to unbreaking it.
[10:25] <chrisccoulson> Riddell, it still pollutes the main window global JS scope in firefox, which means it would even be rejected from addons.mozilla.org
[10:26] <chrisccoulson> we can't accept things that the firefox addon reviewers wouldn't accept
[10:26] <chrisccoulson> although, that still doesn't address the maintenance issue either
[10:26] <chrisccoulson> firefox extensions belong on addons.mozilla.org. they don't belong in the ubuntu archive ;)
[10:28] <Riddell> well you could argue that is a breakage in the design of firefox then but they're not known for wanting to work in the normal linux distro way
[10:29] <Riddell> I'll reject it and tell qfunk to make you happy first
[10:29] <chrisccoulson> thanks
[10:29] <chrisccoulson> he's going to have a hard time making me happy today ;)
[10:34] <stgraber> tseliot: speaking of nvidia-common. Did you have a chance to look at bug 976779?
[10:34] <ubot2> Launchpad bug 976779 in nvidia-common "hybrid-detect changes file in /usr" [Undecided,New] https://launchpad.net/bugs/976779
[10:36] <tseliot> stgraber: that's definitely doable. I don't see a problem with your approach
[11:02] <cjwatson> I've created a Lubuntu package set, as discussed
[11:12] <pitti> erk, automatic langpack updates coming in; I guess I'll accept them wholesale
[11:15] <doko> pitti: could you have a look at python2.7? just the version bump
[11:15] <pitti> doko: currently reading the diff :)
[11:17] <cjwatson> slangasek: you should install gnome-common on the machine where you build update-notifier source packages
[11:22] <pitti> ^ this fixes a couple of FTBFS in precise, see recent ML discussion
[11:22] <pitti> I'd appreciate a review
[11:40] <stgraber> pitti: lightdm looks good
[11:41] <stgraber> (glib is still pending diff)
[11:51] <pitti> stgraber: cheers
[12:10] <Riddell> debfx: spammer!
[12:11] <ScottK> nasl  is going nuts again
[12:12] <ScottK> cjwatson: I think nasl needs shut down again
[12:12] <pitti> debfx: your kdeplasma-addons upload removes debian/patches/kubuntu_fix_qreal_float.diff, is that intended?
[12:15] <debfx> pitti: yes, the patch wasn't applied anymore in the package as it's included upstream
[12:15] <pitti> debfx: ok, thanks
[12:16] <ogra_> geez, cant we exclude the kde langpacks from queuebot like we do with the other ones ?
[12:16] <ogra_> or is there any particular reason to have them all listed
[12:21]  * pitti plays more whack-a-langpack
[12:26] <cjwatson> ScottK: manualed
[12:26] <cjwatson> and I've asked for it to be fixed
[12:31]  * cjwatson trawls through the failures list again

[12:33] <cjwatson> incidentally, the fix to -proposed publishing was rolled out this morning
[12:36] <stgraber> pitti: hmm, glib's diff is a bit confusing, containing a bunch of timestamp bump making it pretty long and the change initially seemed to affect gwin32 instead of gversionmacros, though re-reading carefuly, it looks fine :)
[12:36] <pitti> stgraber: yes, you need to look twice on the file headers in the patch; when I looked at it first, I fell into the same trap
[12:37] <stgraber> pitti: anyway, marked as ok on the pad, feel free to accept
[12:37] <pitti> stgraber: cheers, done
[12:41] <cjwatson> ScottK: nasl is building stuff successfully again, and lp-shell is currently busy retrying everything
[12:48]  * stgraber just uploaded a no change rebuild of gst-plugins-bad0.10 for bug 964926
[12:48] <ubot2> Launchpad bug 964926 in cheese "Cheese can't find vp8enc" [Undecided,Incomplete] https://launchpad.net/bugs/964926
[12:48] <stgraber> I confirmed that fix to work on a test netbook
[12:48] <stgraber> though it then hangs because of bug 966294
[12:48] <ubot2> Launchpad bug 966294 in ubiquity "Ubiquity loops forever from ubiquity_webcam_play" [High,Confirmed] https://launchpad.net/bugs/966294
[12:48] <stgraber> but that's another problem I'm still looking into ;)
[12:49] <cjwatson> grr, it's exploded again
[12:56] <cjwatson> right, whack-a-moled
[12:58] <rsalveti> nvidia-common had a chroot problem with it's builder: https://launchpad.net/ubuntu/+source/nvidia-common/1:0.2.44/+build/3394505
[12:58] <rsalveti> anyone looking at that already?
[12:58] <cjwatson> rsalveti: I'll sort it out, thans
[12:59] <cjwatson> thanks
[12:59] <cjwatson> that builder is already disabled and I gave back everything it failed in the test rebuild, but I need to do the main archive now
[13:00] <rsalveti> cjwatson: ok, thanks!
[13:12] <cjwatson> rsalveti: all done
[13:12] <rsalveti> cjwatson: thanks
[13:24] <gord> hey again, any news on https://bugs.launchpad.net/ayatana-design/+bug/839480 ?
[13:24] <ubot2> Launchpad bug 839480 in ayatana-design "[FFe, UIFe] Dash - When the Dash is open and there is a maximised app in the background, the top bar background should not disappear" [Critical,Fix committed]
[13:31] <didrocks> gord: I pinged pitti and jbicha on it
[13:31] <pitti> gord: well, I'm still not quite clear what this is about
[13:31] <pitti> right now it's quite consistent
[13:31] <pitti> so the proposal is to make it behave _differently_ depending on whether or not you have a fullscreen window?
[13:32] <jbicha> pitti: I agree that I don't understand why maximizing a window should matter when the Dash is opened
[13:32] <gord> right now, if you have a maximised application and open the dash, you can see the wallpaper behind panel, which looks odd. really all it does is make it so you can't see the wallpaper
[13:33] <jbicha> gord: but doesn't it look odd to have the wallpaper showing where the menubar is in all cases?
[13:34] <zul> Daviey:  bug #978033
[13:34] <ubot2> Launchpad bug 978033 in swift "FFE for swift 1.4.8" [Undecided,New] https://launchpad.net/bugs/978033
[13:35] <pitti> jbicha +1
[13:35] <pitti> gord: I see it when I have three non-maximized windows
[13:36] <pitti> so if it's wrong for a maximized window, why isn't it wrong for the other cases then? the panel looks identical in all cases
[13:36] <gord> jibel, no, the issue is that when you don't have maximised windows, your windows are "complete" so to speak, they have their own titlebars and such. when you have a maximised window, the title bar is the panel, so it looks odd when you have a maximised window with the dash open
[13:36] <pitti> I don't particularly object to changing the behaviour, I just wonder why it needs to be so inconsistent
[13:39] <jbicha> I think quite a few people wonder why the menu bar isn't the colored translucency like the launcher, but having it opaque gray unless the Dash is open and no apps are maximized seems odd & arbitrary
[13:40] <jbicha> oh it's a different gray too when the Dash is open with a maximized window
[13:43] <gord> if you open the dash without a maximised window, its just coloured transparent, its only when you have a window maximised that a layer of gray is added
[13:44] <gord> anyway, i'm not the guy to be talking to for this ;) its a design decision, just want to make sure we don't have to revert out a good branch because of a lack of ffe
[13:47] <pitti> gord: jbicha and I followed up in the bug
[13:48] <gord> awesome, thanks :)
[14:35]  * skaet starts in on EOL checklist for 10.10
[14:39] <skaet> mvo, http://changelogs.ubuntu.com/meta-release, can you update maverick to Supported: 0
[14:41] <mvo> sure
[14:41] <mvo> doing that now
[14:42] <skaet> thanks mvo.  :)
[14:42] <cjwatson> skaet: before you get too deeply into that, did you see the discussion here earlier about not EOLing maverick too enthusiastically until precise is out?
[14:42] <knome> anybody know why the xubuntu alternate images went oversize?
[14:43] <mvo> skaet, cjwatson: uh, should I undo my action?
[14:43] <skaet> cjwatson,  no missed that.
[14:43] <cjwatson> http://irclogs.ubuntu.com/2012/04/10/%23ubuntu-release.html#t07:53
[14:44] <cjwatson> mvo: no, I think that's OK as it is, the main thing is that we probably shouldn't rush to move it off archive
[14:44] <mvo> aha, ok
[14:44] <cjwatson> because maverick was an anomalously early relase
[14:44] <cjwatson> *release
[14:44] <cjwatson> knome: your job to investigate that kind of thing :)
[14:45] <cjwatson> (you plural anyway)
[14:45] <mvo> all updated now
[14:45] <skaet> cjwatson,  it won't be moved off for archive for several months,  due to standing OEM request, so we should be fine.
[14:45] <cjwatson> right
[14:45] <cjwatson> fair enough
[14:45] <skaet> thanks for flagging cjwatson.
[14:45]  * skaet gets back to her checklist ;)
[14:45] <knome> cjwatson, well, we didn't do any changes, and a quick comparing in file list didn't show anything obvious...
[14:46] <knome> i was just wondering if somebody knew
[14:47] <doko> did cjwatson loose his piece of bread?
[14:47] <cjwatson> doko: ...?
[14:48] <pitti> hey skaet
[14:48] <skaet> hiya pitti
[14:48] <doko> cjwatson, ohh, I assume you don't know Asterix in Switzerland ...
[14:49] <cjwatson> I know Asterix, but not in Switzerland, and the English translation is quite a bit different
[14:49] <cjwatson> oh, I see, google reveals all
[14:49] <doko> =)
[14:49] <cjwatson> still not desperately sure I get the joke :)
[14:50] <cjwatson> oh, "flagging"?
[14:54] <doko> cjwatson, ohh, I read flogger ;)
[14:55] <cjwatson> that explains it :)
[15:08] <slangasek> cjwatson: ah?  what's the impact of not having gnome-common installed?
[15:10] <cjwatson> slangasek: have a look at the configure diff, and the build log (search for GNOME_COMMON_INIT)
[15:10] <cjwatson> slangasek: I think in practice it happens to be harmless, but I don't think leaving unexpanded macros in configure for uploaded packages is a good idea anyway
[15:11] <slangasek> ah, heh
[15:29] <pitti> stgraber: http://launchpadlibrarian.net/101053108/isc-dhcp_4.1.ESV-R4-0ubuntu4_4.1.ESV-R4-0ubuntu5.diff.gz looks a bit weird -- no semicolon after the "onetry = 0"?
[15:31] <stgraber> pitti: hmm, good catch, something went wrong ... let me re-generate that patch and re-upload...
[15:31] <stgraber> pitti: strangely enough that package actually built and worked, I've tested it from my ppa
[15:32] <pitti> stgraber: hm, perhaps the log_info() stuff is a macro which just happens to deal with that
[15:35] <stgraber> pitti: please reject, pushing a new one now (didn't test build, just added the missing semicolon)
[15:35] <pitti> stgraber: done
[15:35] <pitti> could someone please have a look at apport in the queue? I uploaded it, so can't self-review
[15:36] <stgraber> pitti: I'll take a look
[15:36] <pitti> stgraber: there is no new test for the apt cache part, the existing tests cover that pretty well (that was refactoring, not a bug fix)
[15:37] <pitti> the other bug has tests (quite a lot for a single-digit fix, in fact)
[15:43] <stgraber> pitti: the refactoring looks sane, the bugfix as well and the test changes are a bit difficult to check as there's a missing chunk at the middle of the diff but from the bits that are in the diff, it looks good
[15:45] <pitti> stgraber: thanks for the review
[15:45]  * pitti goes to review a bunch of ktp-* stuff
[15:48] <skaet> Daviey,  can you do the review on maas-enlist?   like to get it in today if its reasonable.
[15:49] <Daviey> skaet: ack
[15:52] <pitti> skaet: we currently keep track of accepted stuff in http://pad.ubuntu.com/ubuntu-frozen-archive
[15:52] <pitti> skaet: I guess we can clean that up every day? or do you want to keep this?
[15:52] <pitti> (or is it ok to not record accepted packages there in the first place?)
[15:53] <skaet> pitti,  its ok not to record accepted packages,   since they'll be in the archive.
[15:53] <pitti> ok, so that pad is only for questionable stuff, or for putting "blockers" on packages
[15:53] <skaet> yes,  and making sure if something's been lingering for over a day that someone looks at it.
[15:54] <skaet> (maas-enlist) for instance
[15:54] <pitti> ack, that makes it easier
[15:54] <pitti> I clean up the "recently accepted" stuff
[15:54] <skaet> thanks pitti.
[15:55] <skaet> everyone on release team should feel free to edit it, and pose questions there as needed.
[15:55] <pitti> Riddell: ktp-text-ui has a considerable chunk of fixes and no bug links; are you ok with that new version?
[15:55] <pitti> I don't feel comfortable with rubber-stamping this myself TBH
[15:56] <pitti> Riddell: OOI, what was the decision for 12.04? telepathy or not?
[15:59] <pitti> ok, I'm through with ktp-*, the others look good
[16:01]  * pitti takes a deep breath and accepts LibO
[16:02] <pitti> better get this built ASAP
[16:02] <skaet> slangasek,  whoopsie-daisy - can you take a look at it?  (it seems to be adding features as well as bug fixes,  and I can't seem to see bug 973687 which the changelog refs.).
[16:02] <cjwatson> why was that uploaded to precise rather than precise-proposed?
[16:02] <Daviey> <-- will take swift.
[16:02] <cjwatson> should've been a textbook case for -proposed, I thought
[16:02] <pitti> cjwatson: uh -- "fail"
[16:03] <slangasek> skaet: looking
[16:04] <slangasek> ev: ^^ what's bug #973687?  Referenced in the whoopsie-daisy changelog, and none of us have access to it
[16:05] <ev> slangasek: added ubuntu-release to that bug
[16:05] <slangasek> ta
[16:06]  * Daviey wonders if that bug really needs to be private.
[16:06] <Daviey> oh wait, i read the comment.
[16:08] <Riddell> pitti: kopete, kde-telepathy is moved to universe I think
[16:11] <slangasek> skaet: whoopsie features look to be in the backend/ directory, which we don't ship in the package; looks sane to me, shall I accept?
[16:12] <skaet> slangasek,  sure,  and thanks.
[16:12] <slangasek> ev: why did you add dpkg-dev to the build-depends, btw?  That's build-essential
[16:12] <ev> I hadn't thought to check
[16:13] <slangasek> I didn't see any other changes in the code that require dpkg-dev either
[16:13] <slangasek> but it's harmless, so accepted
[16:17] <skaet> unity-mail is referencing bug 976459
[16:17] <ubot2> Launchpad bug 976459 in unity-mail "Please upload unity-mail 0.92.2" [Undecided,In progress] https://launchpad.net/bugs/976459
[16:19] <ev> slangasek: dpkg-parsechangelog in the Makefile
[16:20] <slangasek> ah
[16:20] <slangasek> well anyway :)
[16:20] <slangasek> right, there it is; apparently my brain slid right over that line :P
[16:22] <ev> that's okay, my brain slid right past that obviously being a part of the core system :-P
[16:22] <ev> huh, FTBFS, yet it worked fine on my local machine
[16:22]  * ev digs
[16:35] <skaet> infinity,  could you take a look at isc-dhcp?   be nice to get this one in today as well.
[16:36]  * skaet thinks it looks fine, but based on discussion in bug, not sure its resolved after smoser's last comments.
[16:37] <smoser> infinity, ping me if you want. and i think stgraber had a hold on it.
[16:49] <ev> so we've agreed in #security to drop cron.daily/whoopsie as apport actually handles this at a more frequent interval (7 days rather than 14)
[16:49] <ev> presumably I want to do something like: dpkg-maintscript-helper rm_conffile /etc/cron.daily/whoopsie 0.1.25 whoopsie -- "$@"
[16:49] <ev> correct?
[16:49] <cjwatson> use a .maintscript file (man dh_installdeb)
[16:50] <cjwatson> and don't bother including the package name (the 'whoopsie' argument at the end)
[16:50] <ev> nice!
[16:50] <ev> indeed, defaults to that
[16:50] <ev> cheers
[16:51] <cjwatson> so 'rm_conffile /etc/cron.daily/whoopsie 0.1.25' in debian/whoopsie.maintscript and Pre-Depends: ${misc:Pre-Depends}
[16:51] <cjwatson> grr, http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html has gone non-empty again
[16:51]  * cjwatson whacks some more moles
[17:06] <infinity> skaet / smoser: Looks rather straightforward, just hard to tell what the 1-line patch does without some (more) context.
[17:09] <cjwatson> brltty and horizon fix the two chunks of stuff on http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html
[17:15] <cjwatson> I've copied debian-installer to lucid-updates, but I'm deliberately not doing the manual procedure for copying its custom upload piece right now, because I'm testing a speculation that using the PackageCopyJob mechanism for that (which we started doing since the last time we investigated all this) might Just Work
[17:15] <cjwatson> if it doesn't, I'll start trying to construct an LP test case
[17:15] <infinity> cjwatson: Would be kinda nice if that could all happen magically.
[17:15] <cjwatson> yay, the precise proposed->release tracker works again
[17:16] <infinity> cjwatson: The cruft-tracking for d-i bits is annoying. :/
[17:16] <cjwatson> infinity: yep, the reason I'm testing this was that I read through all the code I could find on the subject and my conclusion was "huh, it looks as though that should work already"
[17:16] <cjwatson> infinity: it's also the last remaining reason for archive admins to need lp_publish access
[17:17] <cjwatson> if this works, I intend to ask IS to take that away from us
[17:18]  * infinity sniffs.
[17:18] <cjwatson> I know, but I'll really be a lot happier once I don't have to worry about shells I leave running all the time having unrestricted write access to the archive
[17:18] <cjwatson> if we need to stop the publisher we can ask ops for that
[17:19] <cjwatson> libwacom in -proposed looks good, copying to release
[17:20] <cjwatson> (I mean, it's built, and nobody told us it needed any special staging)
[17:23]  * skaet nods
[17:40] <SpamapS> I am going to sponsor an upload of openssl for precise.. should I upload that to precise-proposed ?
[17:40] <SpamapS> its for bug 968753
[17:40] <ubot2> Launchpad bug 968753 in openssl "ssh crashed with SIGSEGV" [High,Triaged] https://launchpad.net/bugs/968753
[17:41] <SpamapS> or should I just go right into release pocket and wait for release team to wave it through?
[17:45] <infinity> SpamapS: I'll let cjwatson field that one, it's his baby (and he might want the patch in Debian too).
[17:46] <infinity> Also, reading that patch reminds me that I really dislike x86 assembly.
[17:46] <cjwatson> SpamapS: Just precise is fine.
[17:46] <cjwatson> Hm, Debian has a new version, wonder what's in it
[17:46] <infinity> cjwatson: Candy.
[17:47] <cjwatson> We should do a merge from Debian instead.
[17:47] <cjwatson> 1.0.1-3/1.0.1-4 fixed this.
[17:47] <infinity> cjwatson: And a remarkably predictable RNG!
[17:47] <cjwatson> And included a signature algorithms change which might correspond to what I pulled from upstream
[17:48] <SpamapS> cjwatson: so merge rather than explicit patch?
[17:48] <stgraber> infinity: I updated bug 974284
[17:48] <ubot2> Launchpad bug 974284 in isc-dhcp "invoking dhclient3 with -1 causes issue if no dhcp server available" [High,Confirmed] https://launchpad.net/bugs/974284
[17:49] <infinity> stgraber: Oh man, I haven't been paying attention.  "static-networking" isn't static entries? ;)
[17:49] <infinity> THAT'S NOT CONFUSING AT ALL.
[17:49] <stgraber> hehe
[17:52] <infinity> stgraber: Hrm.  Your comment and smoser's don't actually match, despite your "that is what I implemented" confirmation. :P
[17:52] <infinity> stgraber: He said "exit failure, *but* fork a retry loop", but you claim you're exiting *or* forking, depending on success.
[17:52] <stgraber> oh right
[17:54] <infinity> stgraber: Is his actually doable?  I haven't looked at dhclient.
[17:54] <stgraber> it's doable but you don't want to do it
[17:54] <stgraber> as it'll configure the IP at some random point without triggering the post-up scripts
[17:54] <infinity> Oh, right.  We're talking about ifupdown here.
[17:54] <smoser> stgraber, well...
[17:54] <cjwatson> SpamapS: I think so.  Want me to look at it?
[17:54] <smoser> i dont know.
[17:54] <infinity> Yeah.  Bad idea to return failure to ifupdown and then do it anyway. :P
[17:54] <smoser> i'd rather have a network interface up, and no scripts have been run
[17:55] <smoser> then no scripts have been run and no network up
[17:55] <infinity> smoser: It messes up ifupdown state completely.
[17:55] <infinity> smoser: It'll think the interface is down.
[17:55] <smoser> wel...
[17:55] <stgraber> and you won't get your services started as static-network-up won't be emited then
[17:55] <smoser> that was the case up until right before 11.10
[17:55] <SpamapS> cjwatson: you seem to be more familiar, and will need to look at it anyway, so yes I think thats the best course of action.
[17:55] <infinity> A total rethink with callbacks or something could solve that, but that's not small.
[17:55] <stgraber> or anything using net-device-up
[17:55] <smoser> stgraber, thats fine, really.
[17:55] <smoser> ssh will be up
[17:55] <smoser> so you can get to the system and fix it.
[17:56] <smoser> as opposed to dead
[17:56] <cjwatson> OK.  The patch for TLS 1.2 problems in Debian is a strict subset of the one we're currently carrying
[17:56] <smoser> that was my thought process  in suggesting that.
[17:56] <smoser> i'm confused as to what you're saying you changed, though.
[17:56] <cjwatson> And the VPAES fix is identical to the one posted in the Ubuntu bug
[17:57] <stgraber> what I changed is that in the past if "dhclient -1" failed to reach a dhcp server on renewal, it'd exit for good
[17:57] <slangasek> cjwatson: blah, did I miss the dpkg pre-dep on brltty?
[17:57] <stgraber> now if it got an initial lease and forks in the background, it won't ever die and will always try to get a new lease
[17:57] <smoser> ah. ok.
[17:58] <smoser> so the case that we're still screwed in is the power fail recovery.
[17:58] <infinity> Yeah.
[17:58] <smoser> so you fixed the "dhcp server dropped off the network"
[17:58] <infinity> But now dhclient's behaviour matches ifupdown's state, for better or worse...
[17:58] <cjwatson> slangasek: 'fraid so
[17:58] <slangasek> :/
[17:58] <stgraber> smoser: mostly taking care of comment $1
[17:58] <cjwatson> slangasek: brltty had it but not brltty-x11
[17:58] <stgraber> smoser: #1
[17:58] <slangasek> cjwatson: ahh, ok
[17:59] <smoser> stgraber, right. but no comment 0
[17:59] <slangasek> that's because brltty-x11 was an afterthought :P
[17:59] <smoser> :)
[17:59] <smoser> i think comment zero is less important... but its really still quite severe.
[17:59] <cjwatson> in practice brltty-x11 Depends: brltty Pre-Depends: dpkg would have almost certainly sorted it out, but not provably
[17:59] <smoser> we're carrying a change in behavior in ubuntu versus just about everything else.
[18:00] <stgraber> no we don't
[18:00] <stgraber> debian merged our change
[18:00] <smoser> oh wow. well, that kind of sucks.
[18:00] <infinity> Give interfaces a new keyword (sketchy-dhcp yes) that switches from calling dhclient with -1 to not? :P
[18:01] <stgraber> infinity: or simply do:
[18:01] <stgraber> iface eth0 inet manual
[18:01] <stgraber>     up dhclient eth0
[18:01] <stgraber> :)
[18:01] <infinity> ;)
[18:01] <infinity> But yeah, I dunno.  I can see how the current (including the patch in the queue) behaviour may feel like least surprise.
[18:01] <infinity> That said, it's not what "other OSes do".
[18:02] <stgraber> well, install Network Manager then :)
[18:02] <infinity> "Least surprise" to a programmer isn't always "least surprise" to a user.
[18:02] <cjwatson> slangasek: remind me what the UDD bug# is for "I overwrote the importer's idea of what's current and now it refuses to touch anything"?
[18:02] <stgraber> NM will detect dhcp failure and retry, running all its hooks and everything properly, but that's quite easy for it to do it right as it's a daemon
[18:03] <cjwatson> slangasek: I remember you commented on that recently
[18:03] <slangasek> cjwatson: bug #714622
[18:03] <ubot2> Launchpad bug 714622 in udd "import fails when lp branch has been push --overwrite'n" [High,Confirmed] https://launchpad.net/bugs/714622
[18:03] <cjwatson> thanks
[18:04] <smoser> stgraber, so.. i guess i'm ok with the fix as it is.
[18:04] <infinity> stgraber: I don't see any particular reason why ifupdown can't fork and background an 'ifup ethN' that blocks on dhclient doing something useful.
[18:04] <cjwatson> slangasek: do you know what the consequences of requeue_package.py --full are?  does it result in losing history from the Debian branch or anything like that?
[18:04] <smoser> and your suggested work around is not really that bad, i don't think.
[18:04] <infinity> stgraber: But that's totally out of scope for right now. :P
[18:04] <slangasek> cjwatson: no idea... I'm not even sure where the source for the importer is
[18:05] <cjwatson> lp:udd
[18:05] <slangasek> oh, well
[18:05] <slangasek> guess I coulda brute-forced it
[18:05] <slangasek> :)
[18:05] <stgraber> infinity: well, we'd at least need to get ifupdown's definition of interface state somewhat saner first :)
[18:05] <cjwatson>     parser.add_option("--full", dest="full", action="store_true",
[18:05] <cjwatson>             help="Also remove the revids: DANGEROUS")
[18:06] <stgraber> infinity: currently it's basically "mark it up as soon as you call ifup" and it doesn't have any kind of state besides up and undefined :)
[18:06] <infinity> stgraber: It just needs "upping" and "downing" states.
[18:07] <infinity> stgraber: But yeah.  Lots of re-engineering.  I wonder if it shouldn't just be scrapped sometimes.
[18:08] <stgraber> infinity: well, 0.7 is starting to look pretty good, then the problem is all the plugins doing weird things and all the copy/paste around them...
[18:08] <ogasawara> skaet: I've got the kernel ready for upload, just want to re-confirm it's ok to do so.
[18:08] <ogasawara> skaet: It does contain 7 bug fixes we felt were important to make the release, I've summarized as follows to hopefully help with review and approval in the queue:
[18:08] <ogasawara> skaet: bug 977246 - Patches add the Hyper-V KVP daemon to the linux-tools package.  Positive test feedback received.
[18:08] <ubot2> Launchpad bug 977246 in linux "linux: Add Hyper-V KVP daemon tools" [Undecided,Fix committed] https://launchpad.net/bugs/977246
[18:09] <ogasawara> skaet: bug 948360 - Patch allow alsamixer to be fully functional on affected hardware. Positive test feedback received.
[18:09] <ubot2> Launchpad bug 948360 in linux "[Gigabyte GA-H61M-S2PV, ALC887] No sound with on-board ALC887 sound" [Medium,In progress] https://launchpad.net/bugs/948360
[18:09] <ogasawara> skaet: bug 919281 - Patch adds dm-mirror and dm-raid to the md-modules udeb thus allowing server installas for fakeraid controllers. Confirmed the modules now exist in the md-modules udeb, need this to land in a daily iso for installation test confirmation.
[18:09] <ubot2> Launchpad bug 919281 in linux "devmapper kernel modules missing from precise server cd" [Critical,Fix committed] https://launchpad.net/bugs/919281
[18:09] <ogasawara> skaet: bug 974403 - Patches remove dangling symlink in the linux-headers package.  Positive test feedback received.
[18:09] <ubot2> Launchpad bug 974403 in linux "linux-headers has erroneous asm link" [Undecided,Fix committed] https://launchpad.net/bugs/974403
[18:09] <ogasawara> skaet: bug 974982 - Patch fixes a regression introduced in upstream stable kernel v3.2.14 which renders a system unbootable in pvops mode. Positive test feedback received.
[18:09] <ubot2> Launchpad bug 974982 in linux "pvops NULL pointer dereference oops in latest precise kernel" [Medium,Fix committed] https://launchpad.net/bugs/974982
[18:09] <ogasawara> skaet: bug 974090 - Patch fixes an invalid mixer nid value which results in fixing a broken volume slider on a machine hoping to be certified.  Postive test confirmation received.
[18:09] <ubot2> Launchpad bug 974090 in linux "ALSA: HDA: Virtual master gets wrong dB values on some Realtek codecs" [Medium,In progress] https://launchpad.net/bugs/974090
[18:09] <ogasawara> skaet: bug 944772 - Patches allow proper system shutdown.  Positive test feedback received.
[18:09] <ubot2> Launchpad bug 944772 in linux "shutdown does not work" [Medium,Confirmed] https://launchpad.net/bugs/944772
[18:09] <skaet> ogasawara, thanks,   please upload to -proposed at this point.
[18:10] <stgraber> infinity: NM recently got bond, vlan and bridging support added so I guess they'll try to push it for server use. Which wouldn't be completely bad if it had a decent cli interface and could read /etc/network/interfaces as a "legacy" source. But I suspect a lot of people being completely opposed to that just because it's NM :)
[18:11] <ogasawara> skaet: ack, will do.  It is an ABI bumper, so it we'll see uploads for linux-backports-modules and linux-meta as well once the kernel has finished building.  I'll make sure they go to -proposed as well.
[18:16] <slangasek> ev: nack on this whoopsie update, we already fixed apport to *only* remove files from /var/crash that don't match the whoopsie extensions
[18:16] <slangasek> ev: so that would need to be sorted first
[18:16] <slangasek> ev: this was done for bug #957102
[18:16] <ubot2> Launchpad bug 957102 in apport "apport's cron job will delete whoopsie stamp files" [Undecided,Fix released] https://launchpad.net/bugs/957102
[18:17] <ev> slangasek: http://paste.ubuntu.com/923741/
[18:17] <ev> tl;dr, that's not my understanding of that find command
[18:17] <slangasek> ev: hah, doh
[18:17] <slangasek> you're right
[18:17] <slangasek> s/nack/ack/
[18:17] <ev> well, mdeslaur is right. I'm just along for the ride.
[18:19] <ev> yay
[18:19] <ev> here's hoping this one fares slightly better on the buildds
[18:20] <slangasek> fooey, empathy, gwibber both out of sync in the archive right now... shoulda been to -proposed?
[18:21] <rbasak> cyphermox: ^^. I've no idea of the procedure now.
[18:21] <seb128> slangasek, it would help to have a  list of sources that create out of sync issues ;-)
[18:22] <slangasek> seb128: isn't that every package you upload? ;-P
[18:22] <slangasek> I thought it was part of the desktop team package guidelines :-)
[18:22] <seb128> slangasek, I though so, but when I asked pitti why glib didn't go through proposed today he told me glib didn't have out of sync issues :p
[18:22] <seb128> slangasek, I'm puzzled since ;-)
[18:23] <slangasek> heh
[18:23] <cyphermox> rbasak: just let the release team review the upload
[18:23] <seb128> cyphermox, did you fix the libical armel ftbfs as well?
[18:23] <cyphermox> seb128: oops
[18:24] <cyphermox> well, that's something to fix then ;)
[18:24]  * rbasak hides
[18:24] <seb128> cyphermox, it has your name on it now! ahaha ;-)
[18:24]  * seb128 hides
[18:24] <cyphermox> ahaha :)
[18:27] <cyphermox> and to think it was one I was avoiding on purpose. I blame rbasak!
[18:29] <seb128> cyphermox, joke aside do you want to look at the testsuit on armel issue?
[18:29] <seb128> I'm happy for somebody else to pick it up ;-)
[18:29] <cyphermox> sure, I'm looking now
[18:29] <seb128> cyphermox, thanks
[18:30] <cyphermox> I'll give it a quick shot, in case I can figure it out
[18:30] <cjwatson> seb128: it's fairly easy to check, look for mixed Architecture: any/all binaries which have exact versioned dependencies on each other
[18:30] <cjwatson> that pretty much finds most of them
[18:34] <seb128> cjwatson, source:Version should be replaced by upstream:Version or something ;-)
[18:41] <cjwatson> seb128: doesn't always work, and requires guessing the next point at which compatibility will break
[18:41] <seb128> cjwatson, yeah, I guess the real fix is to keep the arch all binaries available for other archs until the rebuilds are done
[18:43] <cjwatson> They are
[18:43] <cjwatson> But it doesn't work right in both directions, and apt etc. doesn't quite do the right thing with those
[18:43] <infinity> seb128: They are.  But it needs some apt mangling to DTRT for end-users, and some buildd-mangling to DTOP (do the opposite thing) for buildds and dep-waits.
[18:44] <cjwatson> OK, debian-installer-images auto-copying doesn't work even in the new world order
[18:44] <infinity> That is, I want end-users to just get "the latest combination that works" (mvo was looking at this last week), while on the buildd side, I need to jam some code in to do more intelligent dep-waiting instead of hard-failing (or building against old versions).
[18:45] <infinity> cjwatson: Boo.
[18:45] <cjwatson> It was worth a shot
[18:45] <seb128> infinity, we should just kill arch all binaries :p that would reduce the number of stupid binaries added for 150k of translations that got stripped in langpacks anyway in Ubuntu and fix those issues ;-)
[18:46] <infinity> :P
[18:46] <cjwatson> Because obviously nobody uses arch all binaries for anything other than translations. :-P
[18:47] <infinity> Our current "solution" in soyuz also blatantly ignores the hilarious case where i386 is the arch that fails to build.
[18:47] <infinity> Thankfully, that's fairly rare.  Ish.
[18:47] <seb128> cjwatson, well, "libgtk-3-common_3.4.0-0ubuntu5_all.deb (139.1 KiB)"
[18:47] <seb128> is the most frequent case we run into
[18:48] <seb128> we = desktop
[18:48] <seb128> if that was not for debian I would have merged that back in the lib
[18:48] <cjwatson> desktop != rest of world ;-)
[18:48] <infinity> seb128: There are other reasons I need to fix the buildd dep-wait code anyway, and it'll fix the gtk3 pain in the process.
[18:48] <infinity> seb128: But, for now, staging gtk uploads in proposed isn't world-ending, I hope.  Sure beats the previous status quo.
[18:49] <seb128> infinity, if it makes ogra stop looking at me at every gtk upload because it breaks armel for a day that's great ;-)
[18:49] <infinity> That would be a pleasant side-effect.
[18:49] <infinity> But I could just ask Oli to stop looking at you.
[18:49] <infinity> I know Germans make you nervous. ;)
[18:49] <seb128> infinity, you say that because you were not around when I almost broke launchpad before a 4 days w.e and made cjwatson stress on a end of week ;-)
[18:49] <ogra_> seb128, you are sooo behind ... i only look at you for armhf uploads nowadays :)
[18:50] <seb128> infinity, I did upload gtk to proposed thursday, that just hit a published bug on the way :p
[18:50] <seb128> ogra_, arm* same difference ;-)
[18:50]  * ogra_ would also accept some good sponsored sunglasses to hide the looks ;)
[18:51] <infinity> seb128: Exposing bugs is good.  Just stop doing it before long weekends. ;)
[18:51] <seb128> hehe
[18:53] <cjwatson> seb128: that bug's fixed now
[18:53] <seb128> cjwatson, thanks for that ;-)
[18:53] <cjwatson> and you only *almost* broke it anyway :)
[18:57]  * infinity wonders why nasl is manual *after* it seems to have been cleaned up...
[18:57] <infinity> Or, so the build history would imply.
[18:58] <cjwatson> It broke again.
[18:58] <cjwatson> Almost straight away.
[18:59] <infinity> cjwatson: Oh.  And those were given back, I guess.
[18:59] <infinity> cjwatson: Unlike the ones in the history...
[18:59] <cjwatson> Yes, I mass-retried everything that broke.
[18:59] <cjwatson> I think it worked for a build or two before it fell over again.
[18:59] <infinity> And yet, we've seen this on other machines.
[19:00] <infinity> Which makes it hard to blame nasl, as much as I'd like to.
[19:00] <infinity> I kinda want to just blame natty/armel, scream "la la la, we're upgrading to precise/armhf" and not try debugging it.
[19:01] <infinity> But maybe if nasl can be made to reproduce it more easily for some reason, we could get a shell on it and see.
[19:01] <slangasek> uhoh, why are ligatures broken for me in firefox?
[19:01] <infinity> slangasek: Even after you restart the browser?
[19:02] <slangasek> no, restarting browsers is painful :)
[19:02] <infinity> slangasek: They exploded for me on upgrade, but I haven't restarted yet.
[19:02] <infinity> And I'm just used to everything in mozilla UIs exploding when you upgrade them.
[19:02] <infinity> XUL isn't friendly about that sort of thing.
[19:03] <slangasek> I'm used to xul breaking; this is specifically ligatures, which is a strange sort of thing to break due to a missing .js file
[19:03] <infinity> Yeah, I saw the same thing.
[19:03] <infinity> I suppose I should see if restarting makes it happy.
[19:03] <infinity> But.
[19:03] <slangasek> alright, restarting to see
[19:04] <micahg> cjwatson: would that mass retry explain why 4 year old hppa builds were being retried?
[19:04] <cjwatson> micahg: Yes
[19:05] <infinity> cjwatson: You didn't limit it to a release? :P
[19:05] <cjwatson> I didn't worry desperately about excluding old ones; they were in the "Chroot problem" state, they had a current source publication, and can_be_retried was True
[19:05] <slangasek> infinity: yeah, restart cleared it up for me; fiddlesticks
[19:06] <cjwatson> oh and the distroseries they were attached to wasn't Obsolete
[19:06] <infinity> slangasek: You were hoping for a broken browser?
[19:06] <infinity> cjwatson: So, this bzip issue isn't new: https://launchpadlibrarian.net/80339115/buildlog_ubuntu-oneiric-armel.setools_3.3.6.ds-7.2ubuntu3_CHROOTWAIT.txt.gz
[19:06] <slangasek> infinity: I was hoping things hadn't gotten so bad that upgrades now cause letters to go missing from the running browser
[19:06] <infinity> cjwatson: It may just seem "worse" now because we finally have the buildd power to do mass-rebuilds on ARM.
[19:06] <cjwatson> Fun
[19:07] <cjwatson> slangasek: it's the first sign of incipient zalgo
[19:07] <slangasek> heh
[19:08] <cjwatson> The <center> cannot hold
[19:08]  * infinity groans.
[19:19] <seb128> infinity, what are the chances that bug #929219 gets fixed for precise?
[19:19] <ubot2> Launchpad bug 929219 in glibc "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [Medium,Confirmed] https://launchpad.net/bugs/929219
[19:19] <seb128> infinity, I just saw it mentioned in some user discussions about precise
[19:20] <seb128> infinity, there is a "potential fix" on http://sourceware.org/bugzilla/attachment.cgi?id=6307&action=diff
[19:20] <infinity> seb128: I'm doing a glibc upload this week (in the next couple of days), I just need to be able to reliably reproduce that bug so I can be sure one of the proposed fixes actually fixes it.
[19:21] <seb128> infinity, ok, good to know ;-)
[19:22] <infinity> Screw reliably.  I need to be able to reproduce the bug, full stop.
[19:22] <infinity> Maybe I'll install a few VMs until chaos does me a favour and makes it stop working for me.
[19:24] <seb128> infinity, or trust the other distro,upstream testers, throw the potential fix in if it seems theoretically correct and see if users are happy ;-)
[19:24] <infinity> Yeah.  That's my second option.
[19:24] <micahg> infinity: I've also seemingly "reproduced" this with and without nscd installed
[19:24] <infinity> Or, rather, I'll read the patches over and make sure they appear to do no harm and fix what they claim to fix.
[19:24] <infinity> But that doesn't necessarily translate to "fixing chrome".
[19:25] <infinity> micahg: Yeah, I've tried both with and without, as the bug log wasn't clear to me which was meant to be the problem.
[19:25] <infinity> micahg: Turns out that neither is.  or both.
[19:25] <infinity> Or something.
[19:26] <infinity> seb128: I'm probably going to have to go with the fixing it blind option, given how intermittent it is, even for people who CAN reproduce it, but that means it needs to pass my anal-retentive logical audit instead, cause it's a bit late for me to just be shoving something into libc willy-nilly.
[19:59] <ogasawara> when someone has a moment, could I get the linux-3.2.0-23.36 kernel approved in the queue?
[20:07] <slangasek> ogasawara: looking
[20:07] <ogasawara> slangasek: thanks.  I posted a summary of fixes earlier for skaet in hopes it would help when reviewing.
[20:07] <slangasek> posted in the channel?
[20:08] <ogasawara> slangasek: yep
[20:08] <ogasawara> slangasek: lemme copy and paste again
[20:08] <slangasek> nah, I've got it
[20:08] <ogasawara> ack
[20:08] <slangasek> no need to make everyone else's scrollback longer ;)
[20:08] <ogasawara> hehe
[20:10] <cjwatson> looks fine to me FWIW, but slangasek had already taken the baton
[20:11]  * cjwatson accepts some unseeded universe stuff
[20:11] <tumbleweed> thanks
[20:13] <cjwatson> (that was a duplicate)
[20:13] <slangasek> ogasawara, cjwatson: yep, accepted
[20:14] <ogasawara> slangasek: thanks!
[20:14] <cjwatson> qemu-kvm looks fine, accepted
[20:15] <cjwatson> uploading openssl merge as discussed earlier
[20:16] <cjwatson> libvirt looks fine, accepted
[20:18] <cjwatson> libical looks fine, accepted
[20:19] <cjwatson> brasero looks fine, accepted
[20:22] <cjwatson> (allegedly.  timeouts)
[20:23] <cyphermox> cjwatson: thanks. as for the ical ftbfs, I'm currently trying to install precise on my board so that I can test things
[20:24] <infinity> cyphermox: There's always scheat.
[20:24] <cjwatson> accepted libdbusmenu and mobile-broadband-provider-info
[20:25] <cyphermox> infinity: yeah, but I should update it anyway :)
[20:26]  * infinity notes that it fails on arches that all happen to have unsigned chars, and is curious if that's a coincidence.
[20:26]  * infinity looks for gcc cast warnings in the build log.
[20:26] <cyphermox> infinity: if you find it this quickly you're my hero.
[20:27] <cyphermox> infinity: what I wanted to test was what is in the debian bug -- that it might be observable because of DST or not.
[20:30] <infinity> This test suite output is unreadable...
[20:34] <slangasek> is it an eye test suite?
[20:36] <cyphermox> infinity: look at the very start of the tests
[20:36] <ScottK> cjwatson: Thanks (just now got back on line) re nasl failures.
[20:37] <slangasek> that's pronounced "nasal", right?
[20:37] <slangasek> (nasl, velr, glottl, palatl...)
[20:38] <cjwatson> Goes with arwoof, thematically.
[20:51] <infinity> cyphermox: I'll leave it to you to decipher, cause I apparently have other things to do.  Or, so my TODO list claims.
[20:51] <cyphermox> np. did anything jump out?
[20:51] <infinity> cyphermox: But I'd still put good money on it relating to char signedness.  Maybe someone using chars for pointer arithmetic, or something equally evil.
[20:52] <cyphermox> k
[20:52] <infinity> cyphermox: (The part in the build log where it looks like someone might be stuffing chars at free() could be a hint)
[20:57]  * ScottK looks at kdesdk and akonadi.
[20:59] <slangasek> sigh, why does bzr bd -S no longer work on the plymouth branch?
[21:19]  * skaet ^ accepted deja-dup,  mythbuntu-common
[21:28] <ScottK> skaet: depreciated/deprecated (re the wubi bug) - just in case you're reusing the verbiage somewhere else.
[21:29] <skaet> ScottK, :)  ta.
[21:45] <doko> infinity, I'm reassigning roseapple to i386 for the python2.7 build (give it back)
[21:49] <doko> done, and it's amd64 again
[21:49] <infinity> doko: mmkay.
[21:49] <infinity> doko: Fails with i386 kernels? :/
[21:51] <doko> infinity, no, timeout in the db tests, which are time consuming. didn't have any issues with these in the past
[22:02] <Daviey> ^^ please can that be accepted, trivial typo.
[22:06] <cjwatson> Daviey: accepted
[22:06] <Daviey> thanks
[22:46] <slangasek> cjwatson: ok, so speaking of whether that udd option would break anything... do you know why the plymouth branch has just had an old version auto-merged on top of it?
[22:52] <zul> can someone accept swift as well its been acked by a release manager please
[22:53] <infinity> zul: Looking.
[22:53] <cjwatson> slangasek: no, and slightly scared to pull to find out
[22:53] <cjwatson> the web interface is timing out
[22:53] <slangasek> cjwatson: alright; I'm doing the only sensible thing then and push --overwriting :P
[22:54] <cjwatson> slangasek: that's pretty special
[22:54] <cjwatson> slangasek: might be worth asking maxb/james_w
[22:55] <cjwatson> looks like it's trying to make precise look like oneiric (aka the last version in the archive)
[22:56] <slangasek> yeah; it did that effectively
[22:56] <slangasek> which is the problem :)
[22:56] <slangasek> that version was already tagged
[22:56] <doko> infinity, slangasek: build did succeed, so I assume vernadsky has a latent disk issue too
[22:56] <doko> python2.7
[23:05] <maxb> slangasek: oh, was it requeued with --full?
[23:05] <slangasek> I don't know
[23:05] <maxb> that would sort of make sense if it was
[23:05] <slangasek> what I asked for is "please make what's already in the branches authoritative for UDD"
[23:07] <cjwatson> hmm, zh_CN image build failure due to whoopsie
[23:07]  * cjwatson doubts ev is around at this hour
[23:15]  * infinity lunches before tackling the ubiquity diff.