[01:19] <mwhudson> cjwatson: Unit193 is really called ged?
[01:30]  * Unit193 looks at mwhudson a little funny.
[13:13] <rbasak> ahasenack: FWIW, it's a bit frustrating to review the iproute2 SRU when the same quilt patch has a different name in the different uploads.
[13:13] <rbasak> I realise that you're just following the Debian maintainer's convention of numbering in the filenames.
[13:14] <rbasak> So I don't really have a strong opinion on which is right.
[13:14] <rbasak> But the quilt series file makes that numbering redundant IMHO, and I thought I'd give you some feedback on how it's annoying :)
[13:16] <ahasenack> yes, I was cherry picking to begin with, then I noticed the numbering
[13:16] <ahasenack> I wasn't sure how picky the maintainer was wrt to that
[13:17] <ahasenack> imagine how annoying it was for me to fix the filename, commit message and d/changelog entry :)
[13:18] <rbasak> The Debian maintainer will never see the SRUs though I don't think?
[13:20] <ahasenack> I don't remember if I checked if debian was affected
[13:20] <ahasenack> I should have
[13:20] <rbasak> Even if Debian is affected, the patch to Debian could follow the convention even if the SRUs don't.
[13:21] <rbasak> You could just call them "ubuntu-sru-ip-maddr..." in the SRUs for example.
[13:21] <ahasenack> if they add the same patches, then the numbering would be correct, and our delta would be zero
[13:21] <ahasenack> in that regard
[13:21] <rbasak> Right at the end of series
[13:21] <rbasak> We don't care about the delta for stable series though
[13:21] <ahasenack> hm, didn't know that
[13:22] <ahasenack> had I not renumbered the patches, I imagined myself having a very similar conversation with a reviewer where he would argue "why these numbers? Why did you skip?" :)
[13:22] <rbasak> I agree :)
[13:23] <ahasenack> the response would be to make cherry-picking possible
[13:33]  * rbasak wonders if iproute2 upstream have a ban on code comments or something
[13:34] <rbasak> "Let's fix this surprising behaviour bug with fixup code with no associated explanation"
[13:35] <ahasenack> sounds like you are entering a rabbit hole :)
[13:36] <ahasenack> good that we are handing it off to another team, heh? :)
=== freyes__ is now known as freyes
[15:28] <doko> cjwatson: just because that came up on -dektop with demoting gtk2: did you find out about a new system-config-kickstart version?
[15:29] <jbicha> RAOF: since we're reducing the number of stuff in main depending on gtk2, what do you think of Debian bug 883334?
[15:29] <ubottu> Debian bug 883334 in src:colord-gtk "colord-gtk: Please drop the gtk2 library" [Normal,Open] http://bugs.debian.org/883334
[15:35] <seb128> cjwatson, also how likely is it to see debconf ported to gtk3 this cycle?
[15:35] <cjwatson> doko: I haven't had time yet, still on my list
[15:35] <cjwatson> seb128: quite likely
[15:36] <seb128> cjwatson, that's good news, thanks!
[15:36] <cjwatson> seb128: (i.e. it's mostly done, I just need to debug a couple of things)
[18:15]  * infinity wonder what part of his desktop install has suddenly decided to pull in apache...
[18:16] <infinity> Ahh, gnome-user-share
[18:16] <jbicha> infinity: gnome-user-share was demoted to universe pending LP: #1731065
[18:16] <ubottu> Launchpad bug 1731065 in mod-dnssd (Ubuntu) "[MIR] mod-dnssd" [Undecided,New] https://launchpad.net/bugs/1731065
[18:16] <infinity> How lovely.
[18:17] <infinity> jbicha: Unfortunately, "demoted to universe" doesn't magically remove it from my system. :P
[18:17] <jbicha> but it's not a bad part of Apache, is it?
[18:17] <jbicha> well, we're proposing moving it back to the default install this cycle
[18:17] <infinity> apach2-bin and deps, so no, I assume it won't run on startup, but still bloaty mcbloaterson.
[18:18]  * infinity shrugs.
[18:18] <jbicha> gnome-user-share has been broken in Ubuntu for many years, those deps actually fix it :|
[18:19] <infinity> Fair enough.  Upgrade ahoy.
[18:21] <jbicha> “Disgusting and terrible, but there doesn't seem to be a better way”, right?
[18:26] <mdeslaur> oh gawd, sharing local directories over the network and over bluetooth?
[18:26] <mdeslaur> how about we just remove it completely ;)
[18:26] <mdeslaur> not sure why having that at all would be a good idea
[18:27] <jbicha> it's turned off by default, but the MIR is open for feedback …
[18:33] <rbasak> "bloaty mcbloaterson"
[18:33] <rbasak> Surely that should be "bloaty mcbloatface"?
[18:34] <rbasak> Or is that just a UK thing? :)
[18:37] <rbasak> ahasenack: also where that list appears incomplete, you can ask the DMB to add to it.
[18:37] <rbasak> Since it's autogenerated from the seed, it isn't perfect when multiple flavours seed a package.
[19:26] <Nafallo> rbasak: Sweden has done better by now I believe. We have Trainy McTrainface and Paley McPaleface :-)
[19:34] <jbicha> http://www.bbc.com/news/uk-england-south-yorkshire-42026485
[19:36] <sarnold> nice
[19:53] <dpb1> hey all -- what's the next step to get attention on https://bugs.launchpad.net/xenial-backports/+bug/1717040, subscribe ubuntu-backporters?  ping someone specfically?
[19:53] <ubottu> Launchpad bug 1717040 in Xenial Backports "Please backport libzstd 1.3.1+dfsg-1 (universe) from artful" [Undecided,Confirmed]
[19:56] <sarnold> dpb1: just between you and me, I suspect -backports is entirely the wrong place to handle that (a) backports seems dead (b) not many people use it (c) it sounds like something that ought to be addressed for all users
[19:56] <dpb1> sarnold: ya, I was thinking an SRU for somethign like there, where a package is simply not usable
[19:57] <dpb1> since the current version likely isn't anyone cares about
[19:57] <dpb1> (in xenial)
[19:57] <sarnold> dpb1: but of course, one runs the risk of utterly breaking existing users :(
[19:58] <dpb1> well, not just a risk even, it appears the contract from what is in xenial to 1.0.0 has changed
[19:58] <dpb1> hm
[19:59] <ahasenack> sarnold: the soname changed at least
[19:59] <ahasenack> which brings another problem then: the lib is a new package
[19:59] <ahasenack> I wonder how many sru rules this would bend
[19:59] <sarnold> heh
[20:00] <ahasenack> dpb1: the build (of the new pkg) runs a ton of tests
[20:00] <dpb1> ahasenack: that's good
[20:04] <infinity> ahasenack: Well, the good news is that it has no rdeps in xenial (has a few in bionic)
[20:04] <jbicha> new packages are allowed as SRUs but in my experience, you have to bring a much larger bribe than usual to the SRU Team ;)
[20:05] <infinity> The only rdep of libzstd0 in xenial is zstd itself.
[20:06] <ahasenack> what would happen with libzstd0?
[20:06] <infinity> "real-time compression scenarios at zlib-level compression ratio"
[20:06] <infinity> Like... zlib?
[20:06] <ahasenack> we leave it there, and make the -dev package conflict?
[20:06] <infinity> ahasenack: What would need to "conflict"?
[20:07] <infinity> ahasenack: Assuming this was done as an SRU, anything built against -updates would get the new -dev and link to libzstd1.  Anything built before that (or against the release pocket) would depend on libzstd0
[20:07] <ahasenack> infinity: so if this is sru'ed, nothing will produce libzstd0 anymore
[20:08] <ahasenack> people will just have it lingering in their systems? If they had it installed
[20:08] <infinity> ahasenack: Yeahp.  But it would still be in the archive, obviously.
[20:08] <ahasenack> ah, in release
[20:08] <ahasenack> updates would have 1
[20:08]  * infinity nods.
[20:08] <ahasenack> ok
[20:08] <infinity> SOVER bumps are not things I'd normally condone in an SRU, but there can be exceptions.
[20:09] <infinity> And in this case, "complete leaf package, no rdeps in the archive, and (presumably) good argument about why the old version is a steaming heap" would likely do it.
[20:10] <infinity> Also doesn't hurt that we'd be backporting a version from LTS+1, not some whacky interim version that no one will care about.
[20:10] <infinity> (And I think "follow-up with another SRU to match the bionic release version, and keep them in sync until xenial dies" might be a condition of accepting such a thing)
[20:11] <infinity> Though, I guess it's only in universe, so maybe I could relax on the last point.
[20:12] <infinity> Would be an easier sell if someone backported *and* renamed it to libzstd1-dev/zstd1 and then added transitional packages to bionic to pull people back to the unversioned versions.
[20:13] <infinity> Though, that might be counter to the intent.
=== santa is now known as Guest67357
=== Guest67357 is now known as santa_