[01:36] <dtchen> blarg. Would an archive admin please reject gtkgl2 from precise*?
[01:41] <infinity> dtchen: Sure.
[01:42] <infinity> dtchen: Also, thanks for all the FTBFS fixes lately.
[01:44] <dtchen> infinity: danke :)
[07:38] <Daviey> stgraber: Can you confirm who said bug 1057358 wasn't urgent?
[07:38] <ubot2> Launchpad bug 1057358 in isc-dhcp (Ubuntu Precise) "dhcpd in isc-dhcp-server-ldap cannot read /etc/ldap/ldap.conf due to missing entry in apparmor profile" [Medium,Fix committed] https://launchpad.net/bugs/1057358
[07:39] <stgraber> Daviey: stokachu at last week's foundations team meeting
[07:40] <Daviey> stgraber: ok, thanks
[07:41] <stgraber> 15:09 < stgraber> stokachu: isc-dhcp, what's the priority on that? Currently it's on bug to-bundle-with-next-SRU list, should it be bumped to fine-to-upload-on-its-own?
[07:41] <stgraber> 15:10 < stokachu> stgraber: nah just as long as its on your radar
[07:41] <stgraber> 15:10 < stgraber> ok, definitely still on my radar. (I go through all netstack bugs weekly)
[07:41] <stgraber> 15:10 < stokachu> stgraber: cool, thats good enough for me, thanks
[07:42] <stgraber> so as it wasn't urgent, my plan was to look at it post-release and post-client-sprint (so 2nd to 3rd week of May)
[07:42] <Daviey> stgraber: I didn't doubt you.  I just wanted to be sure when asked, i had an answer :)
[07:43] <Daviey> stgraber: I do think bug 1069570 requires more careful consideration.  It is the only way that has been determined so far, that avoids multiple IP leases being issued.  There can be upto 3 leases issued for each boot, which quickly exhausts pools.
[07:43] <ubot2> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged] https://launchpad.net/bugs/1069570
[07:43] <seb128> stgraber, if you want others to stay away from things that you have on your list you should comment on the bug saying you will handle uploads and unsubscribe sponsors
[07:44] <Daviey> (MAAS isn't specifically relevant for that bug)
[07:44] <Daviey> seb128: he did this :)
[07:44] <stgraber> seb128: I know, I thought I did but when checking this morning I noticed I hadn't (fixed now).
[07:45] <seb128> Daviey, well, I think I sponsored the debdiffs on that bug once and when I did he hadn't done that
[07:45] <Daviey> ah.  He has now.. Which promoted me for more info :)
[07:46] <seb128> should be all good now ;-)
[07:46] <stgraber> seb128: yeah, I think you sponsored the first one which was broken. At the time the bug wasn't even on my radar, so I didn't actually mind someone sponsoring the fix, just nobody testing it pre-upload (not your job, but the submitter should have) ;)
[07:47] <seb128> right; well I sanity check what I sponsor but I didn't catch, from the diff, that the series was sorted in a special way there
[07:48] <stgraber> seb128: I'd have thought that after one broken upload the sponsors or SRU team member would at least look at the bug history and notice that re-uploading the same thing wasn't going to work any better ;)
[07:48] <stgraber> seb128: yeah, I don't blame you, I blame the submitter for that one. However I certainly blame whoever re-uploaded the exact same thing and I'm very surprised the SRU team didn't see it when they went through the bug report...
[07:49] <stgraber> I mean, it's fairly easy to see in the diff:
[07:49] <stgraber>  #ldap backend for dhcp server (docs and code)
[07:49] <stgraber>  #these get reverted during the build, so put non-ldap
[07:49] <stgraber>  #patches earlier
[07:50] <stgraber> anyway, I hope that my last comment will keep everyone away from this bug for the time being until someone bumps the priority high enough that I have to take care of it immediately or until I prepare the next batch of isc-dhcp SRUs
[07:50] <seb128> should be fine ;-)
[08:12] <jamespage> please could the horizon update for raring be accepted; this fixes from problems that early adopters are seeing with compressed assets
[09:25] <cjwatson> Laney: I think I'm going to have to do http://paste.ubuntu.com/5697878/ to unblock conduit et al; any objections?
[09:26] <Laney> Yeah I suppose having YES there is a bit of a lie isn't it?
[09:26] <Laney> Make completely sure that the ABI hashes don't change ...
[09:27] <cjwatson> Laney: In particular doctest looks at whether it says YES or NO
[09:27] <cjwatson> If it's NO it'll automatically skip doctests
[09:27] <cjwatson> Laney: Damn, I was hoping to avoid an N-hour test build
[09:27] <cjwatson> Or do you mean on i386?
[09:28] <Laney> any arch
[09:28] <cjwatson> It wouldn't surprise me if the libghc-ghc-dev hash justifiably changed as a result of disabling ghci
[09:28] <cjwatson> But its rdep chain is fairly short
[09:28] <Laney> Right; I mean base or similar
[09:29] <ogra_> cjwatson, do you plan a livecd-rrotfs upload today ?
[09:29] <ogra_> *rootfs
[09:29] <cjwatson> ogra_: no
[09:29] <ogra_> do you mind if i do one ?
[09:29] <cjwatson> ogra_: not at all
[09:30] <ogra_> good :)
[09:30] <cjwatson> Laney: OK, guess I'd better get started on test builds then
[09:30] <Laney> IME if it changes on one arch it'll change on all of them, so just do it on your local machine and debdiff the binary you get
[09:31] <Laney> I'm less worries about ghc-dev changing on arm as that's expected and dealable-with
[09:31] <cjwatson> Mm, I can see the possibility for a single-arch configuration change of this nature to change the base hash, so worth a full build on arm I Think
[09:32] <cjwatson> *think
[09:32] <cjwatson> hopefully it'll be a bit quicker without ghci
[09:32] <Laney> you could build it in canonical-arm-dev and then copy over if it's alright
[09:33] <cjwatson> I guess, but I might want to debug locally - might as well just go ahead with a local build I think
[09:34] <xnox> \o/ thanks
[09:34] <xnox> wikimedia foundation should be happy =)
[09:48] <stgraber> I just requested the sync of ltt-control from Debian for bug 1163358
[09:48] <ubot2> Launchpad bug 1163358 in ltt-control (Ubuntu) "[FFe] Sync ltt-control and remove lttng-tools to fix broken lttng in 13.04" [Undecided,Triaged] https://launchpad.net/bugs/1163358
[09:49] <stgraber> this is showing up as source New because the source in Ubuntu was named lttng-tools. The packaging is 90% identical (some missing transitional package in Ubuntu) and I've done basic testing on it.
[09:49] <stgraber> it'd be appreciated if an AA could therefore let this one through, binNEW any of the new debs then remove lttng-tools (the source) from the archive
[09:49] <Laney> didrocks is an archive admin who was interested in it ;-)
[09:50] <Laney> (revenge ping :P)
[09:50] <didrocks> but but but… :p
[09:50] <didrocks> ok, what I wouldn't do for PS in the end… :p
[09:50] <stgraber> ah good point, didrocks^ (it's been +1ed by the release team, so it's an AA thing now ;))
[09:50] <didrocks> (mean Laney ;))
[09:51] <stgraber> didrocks: I can paste you the packaging diff between lttng-tools and ltt-control if you want, but besides that, I don't think it's worth a full review as it's essentially a source rename (from the right name to a wrong name, but well, that's how Debian likes it apparently ;))
[09:51] <didrocks> stgraber: oh, that would be lovely! Yeah, I'll just double check the transition
[09:52] <didrocks> so a diff will avoid me having to deal with it :)
[09:52] <stgraber> at least the binaries use the same name, it's just adding a bunch of transitional packages that will be of no use to us
[09:52] <didrocks> sounds good, i'll just do a quick sanity check with the diff, just in case ;)
[09:53] <stgraber> didrocks: http://paste.ubuntu.com/5697941/ (that's the diff for debian/ from our current source to the debian source)
[09:53] <didrocks> stgraber: thanks!
[09:58] <didrocks> stgraber: looking good, acking ;)
[10:05] <cjwatson> Laney: you dropped a modification from BenC in haskell-hint to build on any architecture - was that intentional?
[10:08] <Laney> cjwatson: I can't remember but I suspect not - could go to Debian in any event
[10:09] <cjwatson> OK, I'll have a look at that
[10:09] <Laney> I think it was from before the ghc-ghci days
[10:12] <cjwatson> ah, so it should just build-dep on ghc-ghci and leave it at that?
[10:13] <cjwatson> ... which indeed is what Ben's patch does, roughly.  OK
[12:49] <GunnarHj> cjwatson: Hi Colin, can you ask someone to test https://launchpad.net/ubuntu/+source/openssh/1:5.9p1-5ubuntu1.1 for the openssh SRU at bug 952185? Guess you can't just refer to the gdm comment this time. ;-)
[12:49] <ubot2> Launchpad bug 952185 in gdm (Ubuntu Precise) "~/.pam_environment not parsed by default" [Medium,Fix committed] https://launchpad.net/bugs/952185
[13:10] <cjwatson> GunnarHj: mm, I can probably manage to test it but it'll have to involve a VM
[13:14] <GunnarHj> cjwatson: Ok, good. It's the last thing at that bug report. :)
[14:00] <ochosi> hm, could any of you help out a poor xubuntu developer get a tiny bugfix sponsored upload for raring? (doing it out of pity is totally fine by me ;))
[14:01] <jbicha> stgraber: um, how do we handle bug 1162478? other distros have been shipping it for a while and I really think we should have it for raring
[14:01] <ubot2> Launchpad bug 1162478 in libnss-myhostname (Ubuntu) "[FFe] [MIR] libnss-myhostname" [Undecided,New] https://launchpad.net/bugs/1162478
[14:03] <seb128> jbicha, hey
[14:03] <jbicha> I apologize for not filing a ffe because it felt like just a bugfix to me
[14:03] <seb128> jbicha, stgraber: I've a revert ready, let me know what you conclude so I know if I should upload
[14:04] <stgraber> jbicha: as I've said in the bug, I don't think adding a new NSS plugin that close to release is a good idea. I'm not saying we'll reject that for 13.10 (and it won't really be our call anyway as it's already in main), but for 13.04, I'd prefer we live without it
[14:05] <stgraber> slangasek: not sure if you're awake already, if you are, this sounds like the kind of things you'd be interested in ^
[14:06] <jbicha> stgraber: the Release Team does have power to reject features but I think it would be good to come to a decision before having us revert (in case we just end up adding it back tomorrow)
[14:07] <stgraber> jbicha: as far as I'm concerned, this is a "not for 13.04" kind of thing. If you turn it back on in 13.10 it should be fine, provided nobody finds it to break things badly (which it unfortunately has the potential to do)
[14:15] <jbicha> ok, could I get a second release team member to weigh in on libnss-myhostname?
[14:16] <seb128> jbicha, stgraber pinged slangasek, but it's still a bit early for him
[14:16] <seb128> so let's wait a bit
[14:49] <cjwatson> could somebody have a quick look at haskell-word8 and haskell-project-template in NEW?  they're fairly trivial syncs needed to unblock builds
[14:51] <cjwatson> Laney: http://paste.ubuntu.com/5698672/ - look sane to you?
[14:52] <cjwatson> (drops ghc-ghci, changes libghc-ghc-dev ABI hash, drops a bunch of associated files)
[14:53] <cjwatson> s'pose I should check that conduit can now build, otherwise it's a pointless exercise
[14:54] <seb128> cjwatson, looking
[14:54] <seb128> ups
[14:54] <cjwatson> ups?
[14:54] <seb128> I had a moment of "should it be a r-t member looking at those/approving"
[14:55] <seb128> sorry ;-)
[14:55] <seb128> looking in any case
[14:56] <cjwatson> well, I think at this point it's fairly obvious that we're committed to finishing the ghc transition
[14:56] <cjwatson> from an r-t point of view
[15:02] <Laney> cjwatson: Looks sane. I didn't know what the .o files were but checking with a Debian binary built without ghci showed that they weren't there either
[15:03] <seb128> cjwatson, ^
[15:03] <cjwatson> seb128: thanks
[15:22] <slangasek> seb128, jbicha, stgraber: I'm not keen on libnss-myhostname as a technology, period; I consider it an unnecessary moving part when /etc/hosts already points the hostname at 127.0.1.1
[15:22] <seb128> slangasek, "the hostname"?
[15:22] <seb128> slangasek, what should be updating /etc/hosts when the hostname changes?
[15:23] <seb128> slangasek, oh, and good morning ;-)
[15:23] <slangasek> seb128: whatever tool updates the hostname should update /etc/hosts as well
[15:23] <slangasek> libnss-myhostname is a bandaid
[15:24] <seb128> basically you are saying "lennart should merge libnss-myhostname in systemd"
[15:24] <seb128> ?
[15:24] <seb128> it's hostnamed from systemd-services that allows changing the hostname
[15:35] <slangasek> seb128: well, I think updating the hostname should also update /etc/hosts according to the distro policy, yes :)
[15:36] <slangasek> seb128: didn't lennart write libnss-myhostname anyway?  Not sure it matters whether it's in systemd ;)
[15:36] <seb128> slangasek, k, in any case I guess you second the FFe nack for raring ;-)
[15:36] <seb128> jbicha, ^
[15:41] <slangasek> seb128: followed up
[15:41] <seb128> slangasek, thanks
[15:42] <doko> all the GCC 4.7.3 packages in unapproved
[15:59] <stokachu> stgraber: why did they remove isc-dhcp 4.1.ESV-R4-0ubuntu5.7
[16:00] <stokachu> stgraber: i thought we just bump the rev and move on
[16:00] <cjwatson> "SRU abandoned (verification-failed)"
[16:00] <cjwatson> https://launchpad.net/ubuntu/+source/isc-dhcp/+publishinghistory
[16:00] <cjwatson> we bump the rev and move on *if somebody actually gets round to uploading that and it gets reviewed*
[16:01] <cjwatson> removing is the fallback option
[16:02] <stokachu> i fixed both with this https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/42
[16:02] <ubot2> Launchpad bug 1069570 in MAAS "1 MAC Address, two IPs - DNS is "out of sync" with DHCP leases databases, I think..." [Critical,Triaged]
[16:02] <stokachu> but doesn't matter it was declined anyway
[16:05] <stgraber> stokachu: my understanding from the tester is that it was yet again the wrong debdiff which was uploaded for the ldap isc-dhcp bug, so we removed it again and this time I left a clear comment that I'm going to take care of it
[16:06] <stokachu> yea that was after i did those changes
[16:07] <stgraber> stokachu: for 1069570, I see why people want it, but I still very much don't like the idea of adding a new config option to a released version of the package, especially as another package will then be SRUed to migrate user to use said option
[16:08] <stgraber> considering the option isn't upstream and it's only landed in Ubuntu pretty recently, I'm not terribly confident we won't get another breakage as a result
[16:08] <stokachu> ok
[16:08] <stgraber> (there's also the issue the config options in ISC are numbered and that every option we had makes it even more painful to rebase, though I've already had to accept that fact when I accepted the patch in raring...)
[16:08] <stokachu> you'll probably be getting a lot of pushback on this
[16:10] <stgraber> I'm also still not sure that there wasn't another way to deal with the problem and that could be used as a workaround for the SRU
[16:10] <stgraber> isc-dhcp can do pattern matching on fields, so someone could very easily pattern match iPXE and set a 30s lease for those
[16:10] <stgraber> which avoids the problem of pool exhaustion that Daviey described in the bug
[16:14] <doko> cjwatson, what effect does have disabling the ghc interpreter?
[16:15] <cjwatson> doko: it will cause haskell-doctest to not try to run doctests, which allows building at least haskell-conduit, haskell-attoparsec-conduit, haskell-wai
[16:15] <cjwatson> (as far as I've tested so far)
[16:15] <doko> hah!
[16:15] <cjwatson> I've spent several days trying to get the interpreter to actually work, and while I've made progress, it's incomplete and I don't know how much longer it would take
[16:16] <cjwatson> so I think it's better not to advertise that the interpreter works
[16:16] <bdmurray> unity-chrome-extension can be removed from quantal-proposed due to lack of verification
[16:16] <cjwatson> we'll have to rebuild about 6 packages with the new ghc, but that's perfectly manageable
[16:18] <cjwatson> and with any luck the only remaining bits of the transition after that will be removing a handful of packages
[16:19]  * cjwatson looks forward to regaining his sanity
[16:59] <bdmurray> disregard my comment about unity-chrome-extension
[17:00] <bdmurray> however, I'm working on a change to sru-report to identify bugs tagged removal-candidate.  Are there any suggestions for a color or something to identify them?
[17:00] <seb128> whoever rejected totem, please accept both next time of the changes doesn't use -v
[17:00] <seb128> or is there any issue to accept 2 versions?
[18:25] <barry> i think mvo may have beating me to apt 0.9.7.7ubuntu4 for raring
[18:26] <barry> *beaten
[19:34] <rtg_> slangasek, can you approve the raring kernel packages ? linux, linux-meta, and linux-signed.
[19:34] <slangasek> rtg_: ah, today must be kernel freeze :-)
[19:34] <rtg_> indeed
[19:35] <rtg_> everything from now on is subject to SRU
[19:37] <slangasek> can linux-signed be accepted in parallel, or does it need to wait for linux to publish first?
[19:37] <rtg_> slangasek, I think you can do them all at the same time
[19:37] <slangasek> rtg_: I'll hold you to that :)
[19:37] <slangasek> accepted
[19:38] <rtg_> slangasek, guess we'll find out.
[22:19] <bdmurray> slangasek: https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/gray-removals/+merge/158502