[05:10] <slangasek> hmm. why is mksh in the core packageset?
[05:10] <slangasek> historical, I guess
[05:11] <Ukikie> Heh, and ubuntustudio-* isn't in ubuntustudio it seems, or so queuebot said.
[05:13] <slangasek> https://bugs.launchpad.net/ubuntu/+source/mksh/+bug/1018162 is the reason, it's only a 4-year-old MIR, recent history how could I have forgotten
[05:13] <ubot5`> Launchpad bug 1018162 in mksh (Ubuntu) "[MIR] mksh" [Undecided,Fix released]
[05:18] <slangasek> zequence: are you building these ubuntustudio source packages on Debian instead of Ubuntu?  Because your .changes files are broken and will not autoclose bugs...
[05:18] <infinity> slangasek: re: lua, srsly?
[05:18] <slangasek> infinity: what about it?
[05:18] <infinity> slangasek: The version-script thing.  This is just asking more questions than it answers for me. :P
[05:19] <slangasek> infinity: you can read the bug, I opened you a task on glibc
[05:19] <infinity> slangasek: Unless it's exporting symbols that clash with glibc or something hilarious?
[05:19]  * infinity finds the bug.
[05:20] <slangasek> infinity: glibc's stdio destructors get all pissy on powerpc if you use a version script on an executable that hides some special _is_stdio_in_use symbol
[05:20] <slangasek> (paraphrased symbol name)
[05:20] <slangasek> _IO_stdin_used
[05:21] <slangasek> (and nevermind that it's stdout that causes the explosion)
[05:21] <infinity> slangasek: Fascinating.  I'll forward that to IBM for extra WTFery.
[05:21] <infinity> slangasek: While technically a regression, the response might be "don't do that, then", but we'll see when people dig deeper.
[05:24] <slangasek> infinity: I would suspect the bug severity of being higher on account of shared libs also possibly using stdio and hiding the symbol, but I can't find that symbol in any shared lib on my system so I guess that's not how it works
[05:55] <otto___> Hello! Current mariadb-10.0 in xenial pocket is buggy. I've been trying to upload a new one but have had multiple failures in the test suite due to specialities of Launchpad environment (these are all false positives).
[05:56] <otto___> Now everything is should be fixed, both the actual bugs and test suite issues.
[05:56] <otto___> Sync request filed as #1569922
[05:57] <otto___> Since this is the last day before final release, I thought it is best to mention the urgent need to sync here in irc. Thanks for your help!
[06:32] <pitti> cjwatson: oh, oops; I'm afraid I forgot the context of that (it happened a year ago); should I just revert this for now, and we just live with the longer runtime?
[07:27] <mwhudson> infinity: so that dh-golang bug got fixed again and better in debian (by me again :-p), is it worth syncing or too much trouble at this stage?
[07:28] <infinity> mwhudson: diff?
[07:29] <mwhudson> infinity: http://paste.ubuntu.com/15824938/
[07:30] <mwhudson> um no
[07:30] <mwhudson> infinity: http://paste.ubuntu.com/15824944/
[07:31] <infinity> mwhudson: Does that pick up the compiler itself, too?
[07:32] <mwhudson> infinity: yes
[07:32] <mwhudson> infinity: it doesn't pick up the golang-defaults version, but well
[07:32] <mwhudson> it probably shouldn't
[07:32] <infinity> mwhudson: If it seems to DTRT, it's certainly more conceptually correct than using build-deps.
[07:32] <mwhudson> (no part of golang-defaults ends up in the binary after all)
[07:32] <infinity> Yeah, golang-defaults shouldn't relate.
[07:33] <mwhudson> infinity: i test-built lxd, and dropping golang-defaults was the only change to b-u
[07:34] <infinity> mwhudson: Then I say sync it.  We want this all working correctly for xenial, IMO, and future attempts at proper security management.
[07:35] <pitti> infinity: just uploaded apt to unapproved; I know, final freeze, and apt and so, but it got tested a full round, the patch is rather obvious, and it breaks upgrades fairly hard
[07:36] <pitti> we should also SRU this, but apparently (during the tests) apt tends to get upgraded early enough
[07:36] <pitti> or do-release-upgrade has some special provisions to take the new apt (IIRC it does that)
[07:36] <infinity> pitti: Eek.
[07:37] <pitti> but the bug is piling up duplicates rather quickly
[07:37] <infinity> pitti: I don't even need to see it in action, the patch tells me exactly what the bug is.   Gross.
[07:37] <pitti> infinity: the fun thing was that we've had this for 5 years and it managed to stay under the radar
[07:38] <infinity> And we were so close to shipping a non-ubuntu-versioned apt, too. :P
[07:38] <pitti> infinity: oh, wait
[07:38] <infinity> Oh, wait?
[07:38] <pitti> infinity: I can re-upload as 1.2.10+git1 if you want
[07:38] <infinity> Hahaha.
[07:38] <infinity> No. :P
[07:38] <pitti> as that's what it really is
[07:38] <pitti> I usually do that for some of my packages to keep them auto-syncable
[07:38] <infinity> It'll get ubuntu revisions in SRUs soon enough anyway.
[07:39] <infinity> And we'll sync over it in a week or two in 16.10.  No big deal.
[07:39] <pitti> well, the fix hasn't been uploaded to Debian yet, otherwise I'd have taken that
[07:39] <infinity> Why yes, I would love to "review" a 1.1MB command-not-found diff. :/
[07:40] <pitti> btw, is the bot AWOL?
[07:40] <pitti> I didn't see my apt upload, neither the ones I'm reviewing/accepting ATM
[07:40] <infinity> He's not in the channel right now.
[07:41] <infinity> Jerk bot.
[07:41] <infinity> stgraber_: queuebot had a sad.
[07:42] <pitti> o_O we have a package snap*d* which is a client CLI tool?
[07:42] <pitti> what was wrong with snappy-cli, or at least snap-cli
[07:42] <infinity> Dunno.  I don't name these things.
[07:43] <pitti> yeah, I know, rhetorical questino
[07:43] <pitti> at least because mvo isn't here
[07:43] <infinity> I doubt mvo had any say either.
[07:43] <pitti> the plotutils sync looks suspicious, debian changelog doesn't mention any of our ubuntu changes
[07:43] <infinity> And "snap" is already in the archive as something entirely different.
[07:43] <infinity> So why not pretend it's a daemon. :P
[07:44] <pitti> ah, we raced on php7.0
[07:44] <pitti> so you are doing command-not-found? looking at bind9 then
[07:44] <pitti> infinity: just FAOD, we'll keep base-files until Monday or so, right?
[07:45] <pitti> infinity: I can also accept it on Sunday along with the langpacks
[07:45] <infinity> pitti: Weekend seems reasonable for base-files.
[07:46] <infinity> pitti: The plotutils sync includes a dh(1) conversion and some mention of testsuite patches, so that covers all but the symbols delta.
[07:46] <infinity> There is, indeed, no symbols file in the Debian version, though.
[07:47] <infinity> So you could reject on that basis.
[07:48] <pitti> ah, the kubuntu_test thing is obsolete? (didn't look at the diffs yet)
[07:49] <pitti> bug 1565392 should be an FFE, hasn't been approved yet
[07:49] <ubot5`> bug 1565392 in bind9 (Ubuntu) "add support for native pkcs11" [Undecided,Fix committed] https://launchpad.net/bugs/1565392
[07:49] <infinity> Yeah, lamont mentioned that.  Kinda figured that we'd do FFe/queue review as a bundle and reject if we hated it. :P
[07:50] <pitti> it's a bit of a mouthful
[07:50] <pitti> I don't see anythign obviously wrong, but there's certainly enough change that anything could go wrong
[07:51] <pitti> but oh well, I'd take it
[07:51] <infinity> Yeah.  There are definitely changes we want from that upload, even if you decide the pkcs11 stuff is too risky, but we can make him cherry-pick those.
[07:51] <infinity> (like the dep fixes)
[07:52] <infinity> I was okay with the pkcs11 stuff conceptually, but wasn't braining well enough to read the diff yet.
[07:55] <mwhudson> infinity: (master)mwhudson@aeglos:dh-golang$ syncpackage dh-golang
[07:55] <mwhudson> syncpackage: Error: Debian version 1.14 has not been picked up by LP yet. Please try again later.
[07:56] <mwhudson> heh too impatient
[07:58] <pitti> rejected plotutils
[08:59] <cjwatson> pitti: So there's definitely a way it can be changed to preserve at least some of the runtime wins while being more correct, but rather than just changing it, I wanted to make sure that I'd adequately communicated what the data-loss problem was (since it's quite subtle)
[09:00] <pitti> cjwatson: so I understand it's because the objects returned by LP are not really lists, but volatile iterators, and they can change underneath you?
[09:00] <cjwatson> pitti: sort of
[09:00] <pitti> cjwatson: I guess I just ignored the comment back then, or we had some IRC conversation or whatnot
[09:01] <cjwatson> pitti: lazr.restfulclient fetches a batch of 75 at a time; when it needs a new batch it's basically just like saying OFFSET 75 LIMIT 15
[09:01] <cjwatson> er LIMIT 75
[09:01] <cjwatson> so it depends what the database state looks like at the time when the next query comes in
[09:02] <cjwatson> with just order_by_date, this is OK because the worst that can happen is that something gets pushed onto the front and shuffles everything else back, so you get duplicates
[09:03] <cjwatson> with an extra status filter, what can happen is that a publication from the batch you were processing gets deleted which shuffles everything the other way, so publications can land in the gap between batches
[09:03] <pitti> ah, that makes sense
[09:04] <cjwatson> pitti: what I think we should do here, and I can implement it if you agree, is to move the status filter to a check inside the iteration (or possibly out in ddeb_retriever.py, but same deal)
[09:04] <cjwatson> pitti: actually iterating over the collection elements is probably not too expensive here due to the batching; I bet the expense comes when you end up doing things that make additional per-element requests
[09:04] <pitti> cjwatson: that makes sense; I faintly remember having to deal with ddebs which never got published, we must filter them out
[09:05] <pitti> so beyond that functional issue, the main effect should be that the query/processing takes longer without the filter, but as we still have the date threshold that should not matter much
[09:05] <cjwatson> right
[09:05] <cjwatson> pitti: oh, we can probably also process packages in status "Pending"
[09:05] <cjwatson> maybe?
[09:06] <cjwatson> you might end up with ddebs running ahead of the primary archive a bit, but my thought was that it would increase the chance of ddebs being available when their deb partners are published
[09:06] <cjwatson> though this only works if ddebs can cope with multiple versions of the same package/arch in a suite
[09:07] <pitti> right, pending is fine, but we don't want "deleted"
[09:07] <pitti> or superseded
[09:07] <pitti> cjwatson: they should be able to, I think we fixed that to just publish multiple versions in the Packages
[09:10] <cjwatson> pitti: OK, can you have a look at r168 and r169 and see if those look right?
[09:11] <pitti> cjwatson: LGTM, thanks for fixing this
[09:11] <pitti> cjwatson: rolled out
[09:11] <cjwatson> thanks!
[09:44] <zequence> slangase`: Really? Yes, I do build on Debian, but have not had that problem before.
[09:47] <cjwatson> zequence: it's been this way since 2007; perhaps you simply haven't ever had automatic closing of Ubuntu bugs from the changelog working for you
[09:47] <cjwatson> (or you manually edited Launchpad-Bugs-Fixed fields into the .changes, but that seems less likely)
[09:48] <zequence> cjwatson: Pretty sure it has worked in the past, but I was using dpkg-buildpackage then. This time, bzr-buildpackage
[09:49] <cjwatson> zequence: I'm pretty sure it can never have done using Debian's dpkg-dev.
[09:51] <zequence> cjwatson: Bug 1565078
[09:52] <ubot5`> bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
[09:52] <zequence> I'm thinking now it's because I've been not adding a space in the right place
[09:53] <zequence> In this case, it's (LP: #1565078), but in other cases it has been (LP:#1570052)
[09:53] <ubot5`> Launchpad bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
[09:57] <cjwatson> zequence: You must add a space there, yes - look in /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm for the regex - but LP: annotations in the changelog are also only parsed if dpkg-dev thinks it's operating for the "ubuntu" vendor.
[09:57] <cjwatson> zequence: LP:#1570052 will do nothing.
[09:57] <cjwatson> zequence: LP: #1565078 is the usual form.
[09:57] <ubot5`> Launchpad bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
[09:59] <zequence> cjwatson: Yep. Silly mistake.
[10:02] <zequence> cjwatson: Are you saying the LP annotations end up somewhere else as well in the changes file, except for under "Changes:"? Seemingly, the bugs have been autoclosed in the past, if the regex was fine
[10:02] <zequence> Just wondering from which part launchpad parses the LP annotations
[10:15] <zequence> I will of course close any affected bugs of late.
[10:27] <cjwatson> zequence: The way it works is that dpkg-genchanges is responsible for actually parsing the bug closures out of the changelog, and it adds a Launchpad-Bugs-Fixed field to the .changes file with the results of the parsing.  Launchpad itself only looks at the Launchpad-Bugs-Fixed field.
[10:27] <cjwatson> zequence: (This is the exact same way that it works in Debian, only with a different field instead of Closes.)
[10:34] <zequence> cjwatson: Perhaps launchpad is also checking the "Changes" field? I have built all packages in Debian for the past year, and it has worked so far (except for the last few times, when I forgot to use space)
[10:35] <zequence> I wouldn't build a kernel like this, but these packages are just archives of files
[10:35] <cjwatson> zequence: No, it doesn't.
[10:35] <cjwatson> Really.
[10:36] <cjwatson> zequence: Can you give me an example of a recent-ish package you uploaded built this way, and I'll go and check logs?
[10:36] <cjwatson> zequence: (One that had the space in there.)
[10:36] <apw> sometimes nice people parse it and fix bugs which were miss-specified
[10:37] <cjwatson> Well, also, if it's a sync from some other archive (e.g. Debian's) I believe we parse the changelog directly
[10:38] <zequence> This one was uploaded last, together with another package with the wrong regex. But, this one has the right one Bug 1565078
[10:38] <ubot5`> bug 1565078 in ubuntustudio-sounds (Ubuntu) "Please remove ubuntustudio-sounds from Xenial" [Undecided,Confirmed] https://launchpad.net/bugs/1565078
[10:38] <cjwatson> But direct changelog parsing is only used in the copy path.
[10:39] <zequence> No, sorry. That was from the past week. But, recent, anyway
[10:39] <cjwatson> Let's see if I can find out how that got there.
[10:40] <cjwatson> Oh!  I see
[10:40] <cjwatson> Of course, all packages end up going through the copy path nowadays, because of proposed-migration
[10:40] <cjwatson> I forgot about that
[10:42] <cjwatson> Hmph, OK, this is sort of not how it was meant to work, but I guess it's convenient in zequence's case
[10:44] <cjwatson> Strictly, I think we should probably fix this, but need to work out how to do so without breaking use cases that are unambiguously desirable
[10:45] <cjwatson> At least we should prefer Launchpad-Bugs-Fixed if it's there, but it's a bit tricky in the case of a copy with a difference of multiple versions
[10:45] <cjwatson> zequence: OK, I apologise for having forgotten about the convolutions of modern upload handling
[10:45] <LocutusOfBorg> question: a lot of stuff has been NMUed in debian for libpng1.6, my proposal is: for xenial+1 when the archive is not open, sync libpng1.6, MIR it, and then let the auto import fix ~100 packages
[10:45] <LocutusOfBorg> is it possible?
[10:46] <zequence> cjwatson: I'm sure there are other reasons why I'm doing it the wrong way. I used to use a virtual machine for Ubuntu development, and should probably start doing that again.
[10:46] <cjwatson> LocutusOfBorg: Yes, I think we can remember to do that.  (We don't need to do the MIR before auto-sync, though; it will just block migration.)
[10:46] <cjwatson> infinity: ^-
[10:46] <LocutusOfBorg> <3
[10:47] <LocutusOfBorg> also gdk-pixbuf needs a rebuild, to avoid having to retry and retry the gtk reverse-deps
[10:47] <LocutusOfBorg> don't worry I'll bother you when xenial is out :p
[10:47] <LocutusOfBorg> BTW I'm not a core-dev, so I'll probably need some help
[10:48] <LocutusOfBorg> not sure how much of the reverse-deps are in main, I guess not too many
[10:48] <cjwatson> libpng will at least have a fairly respectable number.
[10:49] <LocutusOfBorg> well, with some help we can have a smooth transition, as we did in Debian
[11:06] <doko> gave back all failed builds one last time
[11:07] <pitti> yay, got libvigraimpex to build
[11:11] <LocutusOfBorg> still #1562480 not fixed
[11:11] <LocutusOfBorg> bad xenial on powerpc is bad
[11:11] <LocutusOfBorg> LP: #1562480
[11:11] <ubot5`> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
[11:12] <pitti> libvigraimpex FTBFS fix in unapproved -- review SVP?
[12:35] <coreycb> doko, just forwarded you an email about possible ways to fix sunpy autopkgtest failures
[13:21] <ginggs> Hi, anyone from ubuntu-release able to look over two FFes please? LP: #1566326
[13:21] <ubot5`> Launchpad bug 1566326 in papi (Ubuntu) "FFe: Sync papi 5.4.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1566326
[13:22] <ginggs> and LP: #1565286
[13:22] <ubot5`> Launchpad bug 1565286 in htop (Ubuntu) "[FFe] Please sync htop 2.0.1-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1565286
[13:26] <cyphermox> good morning!
[13:34] <LocutusOfBorg> hint also git git
[13:38] <lamont> LocutusOfBorg: ~rc3 into an LTS?  that seems overly aggressive to me.
[13:38] <LocutusOfBorg> lamont, it has nice features
[13:38] <lamont> though at least it's not ~b1 or such
[13:38] <LocutusOfBorg> BTW git 2.8.0 is out
[13:39] <LocutusOfBorg> but I think it is the same as rc3
[13:39] <LocutusOfBorg> if you grant an FFe I can prepare a packaging
[13:40] <lamont> LocutusOfBorg: I'm sure it'll find its way into xenial-backports in the near future.  I'm not on the release team, but I'd be surprised if they'd grant the FFE at this stage.
[13:40] <LocutusOfBorg> me too
[13:41] <LocutusOfBorg> I asked it a while ago
[13:41] <lamont> and that's coming from someone with a history of pushing the edges on FFe-sanity
[13:41] <LocutusOfBorg> but too late indeed
[13:41] <lamont> especially in this world of -backports and ppas
[13:41] <LocutusOfBorg> parallel submodules fetching is something I really need to have, and I'll probably have in my ppa
[14:13] <pitti> Laney: eww @ large gnome-software patch; reviewing this isn't realistic, can I have your word that this version is sane?
[14:15] <pitti> barry: python-webob sync> large amount of changes, lots of rdepends, no FFE or other bug; do you have some details about that?
[14:16] <barry> pitti: i meant to do an ffe, i'll do that now
[14:19] <pitti> jamespage: same question about ceph -- no FFE, large changes, unreviewable -- how was this tested?
[14:20] <jamespage> pitti, same way I did before - built in PPA, tested upgrades and deployment from .1
[14:20] <jamespage> (referenced in the FFe linked in the changelog)
[14:22] <pitti> jamespage: ok, thanks; so I take it you want that in xenial
[14:37] <cyphermox> davmor2: don't tell me, I broke the "Install Ubuntu" option, it doesn't just get you ubiquity anymore :'(
[14:37] <davmor2> cyphermox: haven't had time to try a new install will fire one up in a second
[14:38] <cyphermox> it's some kind of ugly systemd unit start race
[14:38] <cyphermox> I only just noticed, it was definitely working well when I tested here before uploading :/
[14:42] <davmor2> cyphermox: so current is working which is last built on 14th, or at least the uefi version is getting to the let me try pending and also try non uefi
[14:43] <davmor2> cyphermox: meh nevermind that was trusty wrong image D'oh
[14:54] <jamespage> pitti, yup please
[14:56] <Laney> pitti: haha
[14:56] <rbasak> I want to drop the lxd seed from depends to recommends for server - just acked by kirkland. Will there be any issue with that?
[14:56] <Laney> pitti: It's "more" sane IMO, but will definitely have more uploads to come
[14:57] <Laney> depending on attente's brain to finger bandwidth that might be SRU though
[14:57] <Laney> a lot of the delta will be because I moved the patches into the orig
[14:58] <Laney> which is a one time cost
[14:59] <willcooke> hi gang!  This:  https://bugs.launchpad.net/ubuntu/+source/muon/+bug/1562406
[14:59] <ubot5`> Launchpad bug 1562406 in muon (Ubuntu) "[FFe] Update to latest upstream version" [Undecided,Confirmed]
[15:00] <willcooke> There is a comment that it might not need a FFe, and a report of a missing dependency
[15:00] <willcooke> Can anyone say if it doesn't need an FFe, or if it can or cannot be acked?
[15:00] <willcooke> mhall119, ^
[15:01] <mhall119> thanks wi
[15:01] <willcooke> heh
[15:58] <Laney> mhall119: I replied
[16:10] <infinity> rbasak: The only person likely to complain is Mark.
[16:11] <rbasak> infinity: OK, thanks. kirkland acked it so we're good.
[16:11] <stgraber> infinity: it would still be pre-installed where Mark wants it pre-installed. I don't think he particularly cares about depends vs recommends.
[16:11] <stgraber> anyway, I did the seed and meta change to move it to recommends earlier
[16:12] <infinity> stgraber: Works for me.
[16:12] <mhall119> thanks Laney
[16:14] <mhall119> Laney: so what's the next step for this? Will someone in the release team take it from here or does Kubuntu need to do something else?
[16:51] <doko> the give back in main produced one more build success in main, and 22 in universe
[16:54] <doko> coreycb, I don't think I will push for a new numpy at this stage
[16:58] <coreycb> doko, ok I understand that, it's not just bug fixes
[17:05] <Laney> mhall119: They can upload it now
[17:05] <mhall119> clivejo: ^^
[17:08] <Laney> mhall119: I think they should get someone to replace Riddell on the release team too
[17:09] <mhall119> Laney: what's the process for somebody to get on the release team?
[17:09] <Laney> I think there's usually a quick email poll
[17:09] <ogra_> proving experience ?
[17:09] <infinity> mhall119: core-dev + agreed team trust.
[17:10] <infinity> mhall119: (which involves experience, etc)
[17:10]  * Laney is too formalist :P
[17:11] <infinity> To be fair, most flavours don't have someone in ~ubuntu-release
[17:11] <infinity> Losing ScottK and Riddell was more a loss to the project as a whole than just to kubuntu.
[17:12] <Laney> It'd be good to have someone who might be more inclined to help flavours out
[17:12] <Laney> I personally haven't given FFe/queue reviews as much time as I might have liked
[17:13] <flexiondotorg> infinity, Laney Is the a role I can be mentored for?
[17:15] <ogra_> flexiondotorg, needs core-dev
[17:16] <flexiondotorg> ogra_, OK. A more long term goal then.
[17:16] <ogra_> :)
[17:17] <ogra_> though i guess the universe FFe stuff can be handed to someone not core-dev
[17:17] <ogra_> that would probably drop some load from people like LAn
[17:17] <ogra_> *Laney
[17:19] <flexiondotorg> Well, I'm game.
[17:19]  * flexiondotorg needs to go home now.
[18:19] <Odd_Bloke> Could a core dev merge (and release) https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/interface-naming/+merge/291928, please?
[18:19] <Odd_Bloke> smoser: ^ is relevant to your interests.
[18:28] <smoser> Odd_Bloke, man..
[18:32] <slangasek> smoser: does that mean you're taking it?
[18:33] <smoser> Odd_Bloke, please set a commit message
[18:35] <Odd_Bloke> smoser: Do I have to uncommit/commit to set the fixes data?
[18:36] <smoser> no. just mention it at least
[18:36] <smoser> you could bzr commit --fixes lp:
[18:36] <smoser> and then it would say "do you want to commit with no changes"
[18:36] <smoser> and you say "yes please"
[18:36] <smoser> but i just wanted it linked someway to that bug
[18:42] <Odd_Bloke> smoser: Done.
[18:45] <smoser> Odd_Bloke, do i have to upload this ?
[18:45] <smoser> versus just pushing to trunk
[18:45] <Odd_Bloke> smoser: I would appreciate it if you would, because we're trying to build on top of released versions.
[18:45] <smoser> yeah. ok.
[18:46] <Odd_Bloke> smoser: Thanks. <3
[18:49] <smoser> just uploaded.
[19:00] <doko> cjwatson, slangasek: ^^^ pyjunitxml still remains in the core package set. is this expected?
[19:00] <slangasek> doko: packagesets are not automatically cleaned up.  I suppose someone needs to go through and reconcile that, but I don't remember where either the tools or the reports are
[19:07] <cjwatson> somebody in the DMB would need to do it
[19:07] <doko> ok, I assume that would be colin. never managed package sets myself
[19:09] <cjwatson> doko: Me?  No, I haven't been in the DMB for years
[19:09] <infinity> Laney traditionally does the bulk updates.
[19:09] <infinity> s/does/did/
[19:10] <infinity> I think he needs to hand that off to someone else.
[19:10] <doko> cyphermox?
[19:10] <cjwatson> https://code.launchpad.net/~developer-membership-board has the code
[19:10] <cyphermox> hello?
[19:10] <infinity> Ah, I found the email from him detailing it.
[19:11] <infinity> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Automatically_managed_packagesets
[19:14]  * infinity kicks off a run.
[19:18] <infinity> cjwatson: Ahh, found one spot magicmirror misses splitting with by-hash.  $series/by-hash/* contains all the Contents files.
[19:19]  * infinity says, while watching this very slow rsync.
[19:20] <cjwatson> infinity: Mm, yeah, that's tricky for it to do.
[19:20] <cjwatson> Not sure how to fix that.
[19:21] <cjwatson> It can't just drop the by-hash files there that don't match current by-name files for supported arches, because that defeats the purpose of by-hash.
[19:22] <cjwatson> And I don't really want to drop by-hash for Contents, since with modern apt-file, apt will actually try to download them and I think would even complain about mismatches.
[19:23] <cyphermox>  doko: cjwatson: infinity: do you need me to do that packageset update? I'm still looking at grub-mkfont...
[19:23] <infinity> cyphermox: It's already running here.
[19:23] <cyphermox> ack
[19:24] <infinity> cjwatson: Yeah, unsure.  I was going to suggest 'stat -c %h' and then realized the same thing, that we kinda want unreferenced files because, well, by-hash.
[19:24] <cyphermox> cjwatson: btw this issue affects Debian as well, you might see that with the current freetype, there are missing glyphs at least in zh_CN
[19:25] <cjwatson> cyphermox: No idea about that at the moment, sorry
[19:26] <cyphermox> no, i wasn't expecting you to, just saying. I'm looking at the issue and I'll write a patch
[20:08] <infinity> doko: ^-- That should be the final glibc upload.
[20:08] <infinity> FYI.
[20:08] <bdmurray> infinity: when are you planning on doing the freeze?
[20:08] <sgclark> Hello folks, I have a pile of KDE bugfix release uploads, and I was hoping I could do this tonight, ( PST US time ) any objections?
[20:09] <infinity> bdmurray: After I ingest a hamburger and write the email.
[20:10] <infinity> sgclark: Bugfixes generally welcome, if reviewable and sane.  In about an hour, final freeze is upon us, and the general rule will be "if it would be acceptable for an SRU, go ahead and try, but we won't guarantee it gets in".
[20:10] <infinity> sgclark: But if this all gets in quickly, you can ignore the second half of that sentence.
[20:11] <sgclark> It is acceptable for SRU fixes, oh so I have an hour haha. Let me free up some time then. thanks.
[20:12] <infinity> sgclark: An hour until the email is sent.  We can cut you some slack on the actual uploads.  Correct is better than hasty. :P
[20:12] <sgclark> infinity: lol thanks!
[20:42] <barry> infinity: can you reject the webob sync?  on further testing i don't want to deal with the potential dep8 failures
[20:43] <infinity> barry: Someone rejected it 22m ago.
[20:43] <infinity> barry: Service with a time machine.
[20:44] <barry> thanks someone!
[20:45] <infinity> barry: You should have had mail about it telling you who to blame.
[20:45] <barry> infinity: not yet, which is why i pinged
[20:45] <infinity> Weird.
[20:46] <barry> yeah, that's mildly concerning
[20:49] <cjwatson> There are a couple of ntfs-3g sync requests that somebody might want to take a look at.  They claim to be stability improvements, haven't really checked, just keep seeing people making increasingly urgent metadata changes to them.
[21:00] <doko> infinity, not sure if I will finish the c-t-b packages before the final freeze
[21:02] <infinity> doko: That's fine.
[21:11] <mwhudson> infinity: i wanted to sync dh-golang but it seems to have got stuck on the debian side, do you know where i can look/poke to investigate that?
[21:13] <mwhudson> oh
[21:16] <doko> mwhudson, it needs some time to become visible for syncing. if you want to fetch it look at http://incoming.debian.org/debian-buildd/pool/
[21:17] <mwhudson> doko: also somone filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821000
[21:17] <ubot5`> Debian bug 821000 in dh-golang "dh-golang: matched no packages; no buildable Go source files" [Serious,Open]
[21:18] <mwhudson> which is not the most helpful bug report ever
[21:18] <infinity> Seems somewhat suboptimal.
[21:18] <infinity> Both the bug and the report. :P
[21:19] <mwhudson> yeah
[21:19] <doko> does kubuntu have a freeze exception?
[21:19] <infinity> They have a vaguely global MRE.
[21:19] <infinity> Which doesn't extend beyond final freeze, but close enough.
[21:20] <doko> ok to accept these?
[21:21] <doko> glibc ftbfs on i386
[21:22] <doko> timer issue, timer sig2 invoked too soon: 3.900357757 instead of expected 3.900607522
[21:23] <infinity> Blaming qemu and retrying. :P
[21:24] <infinity> And yeah, should be okay to accept the kde stuff with a cursory review to make sure nothing terribad happened in any of them.
[21:28] <doko> many of these are just no-change releases
[21:38] <infinity> slangasek: Hrm.  Would you expect in the new world order that packagesets use --no-follow-build-depends?
[21:39] <infinity> slangasek: Cause without it, we're adding a ton of new stuff to core.
[21:39] <infinity> (With it, I imagine we'll remove a huge mess of things...)
[21:39] <slangasek> infinity: yes, I would think so
[21:39] <infinity> Alright, need to grab germinate from git and retry this, then.
[21:40] <slangasek> and if this causes things to drop out that make us go "wait, that package should not be a free-for-all", that's probably a candidate for seeding
[21:40] <infinity> Check.
[21:40] <infinity> I'll post the output delta before committing anything.
[21:40] <infinity> cjwatson: Were you planning on a germinate upload before release, so xenial's vaguely self-hosting?
[21:44] <cjwatson> infinity: Oh, a good point.
[21:44] <cjwatson> Lemme shove that into Debian now and sync it tomorrow morning.
[21:46] <cjwatson> (done)
[22:39] <infinity> slangasek: http://lucifer.0c3.net/~adconrad/packageset-changes.txt
[22:40] <infinity> slangasek: A fair bit to comb through.
[22:46] <xnox> infinity, i still want to shove things in =)
[22:46] <infinity> xnox: I'll file an HR complaint.
[22:47] <xnox> infinity, i meant installer changes into xenial!
[22:47]  * infinity lunches, finally.
[22:47] <infinity> xnox: Yeah, I have installer fixes too.  Those get a free(ish) pass, as long as they're not crazy.
[22:48] <xnox> infinity, multipath discovery by default on s390x.
[22:48] <xnox> it works, and is expected by zfcp users....
[22:51] <xnox> infinity, https://launchpadlibrarian.net/253795754/hw-detect_1.117ubuntu1_1.117ubuntu2.diff.gz ^