[09:37] <LocutusOfBorg> mdeslaur, hello, I *think* pcsc-lite can be sync'd now, because the dlopen stuff in wpa supplicant is now useless https://packages.debian.org/unstable/wpasupplicant
[09:37] <LocutusOfBorg> it is now linked that library, so moving it seems to be useless
[13:55] <bdrung> bdmurray, hey, do you have time to review my patches for apport?
[14:33] <bdmurray> bdrung: I'm catching up from a sprint last week but will add it to my todo list.
[14:34] <bdrung> bdmurray, thanks. ping me in case you have questions.
[15:08] <seb128> slangasek, hey, can we get $team-reports to use ~desktop-bugs instead of ~desktop-packages? we have been using -bugs for MIRs&co for a while and the other team was an old QA created one by pedro which is unmaintained and subscribed to random components pedro wanted to include in qa reports back then
[15:09] <cyphermox> bdmurray: ^ this is about the master package team mapping list
[15:20] <bdmurray> seb128: what about the packages to which desktop-packages is subscribed to and desktop-bugs is not?
[15:25] <seb128> bdmurray, not sure what you mean, those are a random collection ~desktop-packages is a list pedro made back then to build qa reports of things "desktopish", why would we have those on our list?
[15:25] <seb128> bdmurray, like "amarok" is there which we never users/maintained
[15:30] <bdmurray> seb128: The goal with the subscriptions was to have a team who'd look after a bug if an important one came up about a package e.g. https://bugs.launchpad.net/~foundations-bugs/+packagebugs is stuff we are subscribed to.
[15:30] <seb128> bdmurray, yes, I know, and we have been using ~desktop-bugs as our team for MIRs for years so that's the correct one
[15:31] <seb128> bdmurray, ~desktop-packages is a team owned by pedro who left the project years ago
[15:31] <seb128> it's just an outdated leftover
[15:31] <bdmurray> seb128: Okay, but we I think its still worth reviewing packages subscribed to by that team and not by desktop-bugs to make sure we don't lose anything legitimate.
[15:32] <bdmurray> seb128: I'm happy to make such a list.
[15:32] <seb128> bdmurray, I can do the list, it's basically copying +packagebugs from both teams and diffing
[15:32] <seb128> but thanks
[16:04] <elopio> bdmurray: any chance of getting click and snapcraft in proposed today? Or maybe I should ping the person in SRU vanguard today.
[16:18] <gsilvapt> Hello all. I'm trying to arrange a debian/control file with wrap-and-sort but the command does nothing and there is stuff to sort within the control file. Any suggestion?
[16:18] <gsilvapt> The -v options returns nothing too
[16:28] <Skuggen> gsilvapt: The control file is inside a debian/ directory and isn't "different" in any way like a changed filename?
[16:30] <rbasak> gsilvapt: are you running wrap-and-sort from the top level of your source tree?
[16:32] <gsilvapt> No, Skuggen and yes, rbasak
[17:11] <elopio> infinity: hello. We need help to get click and snapcraft into -proposed.
[17:29] <infinity> elopio: Of which release?
[17:30] <elopio> we need click 0.4.46+17.10.20170607.3-0ubuntu1 and snapcraft 2.31. In xenial, yakkety and zesty -proposed.
[17:30] <elopio> last I heard on friday we were waiting for the dput of click in artful.
[17:31] <slangasek> elopio: when I spoke with bdmurray on Friday, he was reviewing it and found that the SRU bug for click did not have the necessary information
[17:31] <infinity> elopio: I see no click in the xenial queue.
[17:31] <elopio> slangasek: yes, I added it on friday.
[17:31] <slangasek> ok
[17:32] <slangasek> infinity: I see it for yakkety+zesty; perhaps bdmurray didn't make it as far back as xenial for the sponsorship
[17:33] <infinity> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4
[17:33] <infinity> Rather than just fix the bug, looks like someone decided to backport it?
[17:33] <bdmurray> https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4
[17:33] <bdmurray> Right and I didn't feel comfortable sponsoring that.
[17:34] <slangasek> right
[17:34] <elopio> oh.
[17:34] <elopio> What can we do to make sure it's safe?
[17:34] <slangasek> we can not do a wholesale backport
[17:34] <infinity> ^
[17:35] <slangasek> instead of including unrelated changes and then having to figure out how to prove they're safe
[17:35] <infinity> SRUs should be about fixing targetted bugs, not upgrading everything to the latest and shiniest.
[17:35] <infinity> (I realise snapcraft and snapd may have set unrealistic expectations here. :P)
[17:36] <elopio> not at all, I understand the goal of SRUs. I just thought Sergio had it all covered.
[17:37] <elopio> but I'm just not sure I understand what's needed. Should I hand-pick the module rename on top of the version that's on xenial?
[17:37] <kyrofa> And the test fixes, probably
[17:37] <infinity> Yes.
[17:38] <elopio> the other change was to get the tests passing in artful, so that won't be necessary.
[17:38] <kyrofa> Oh that was artful-specific? Handy
[17:39] <elopio> infinity: what should I give you? a diff, a branch, a deb? And do I need to make a separate bug for xenial?
[17:39] <infinity> Same bug(s).
[17:39] <infinity> Odds are that http://launchpadlibrarian.net/323335627/click_0.4.45.1+16.10.20160916-0ubuntu1_0.4.46+16.10.20170607.3-0ubuntu1.diff.gz will sort of just work for the older version, unless the code moved around a bit between xenial and yakkety.
[17:40] <kyrofa> I doubt the code has changed much
[17:41] <elopio> I think it should conflict at least a little. But doesn't sound hard.
[17:41] <infinity> elopio: A debdiff between current xenial and the proposed fixed package should do.
[17:41] <elopio> infinity: awesome, thanks.
[17:42] <infinity> I imagine applying the patch wholesale will conflict a tad just because OMG WHOLE FILE RENAMES really don't agree with diff/patch.
[17:42] <infinity> But should be trivial to reconstruct it conceptually by hand.
[17:43] <infinity> Trivial, but time consuming, so I'd rather it was your time. ;)
[17:44] <elopio> infinity: oh, of course, it's not something we should outsource :)
[17:45] <elopio> unless we could get our Naming Chief Officer to do it...
[17:45] <infinity> PS: Can someone hop in a time machine to when unified diff was specced and add mv, link, and mode?  Thanks.
[17:46] <infinity> And rm.
[17:46] <infinity> "This whole file became /dev/null" is such a helpful way to represent a deletion.
[18:00] <jbicha> infinity: if you're doing SRU candidates, could you look at libgweather 3.24.1/zesty (you can reject 3.24.0)
[19:24] <juliank> I wonder if we could have an e2fsprogs backport for xenial that supports metadata_csum, as the HWE kernel supports that. Does that make sense to anyone other than me?
[20:14] <kyrofa> infinity, re the xenial click patch, what do I do with the changelog version in such a case?
[20:28] <xnox> juliank, yes.
[20:32] <juliank> xnox: But how? Just updating e2fsprogs to 1.43.something seems dangerous, should we have an e2fsprogs-hwe package?
[20:34] <juliank> Or just in -backports?
[20:35] <juliank> (both would work, obviously)
[23:52] <nacc> mdeslaur: are you working LP: #1574670 ?