=== JanC_ is now known as JanC === koza|away is now known as koza [09:37] 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] it is now linked that library, so moving it seems to be useless [13:55] bdmurray, hey, do you have time to review my patches for apport? [14:33] bdrung: I'm catching up from a sprint last week but will add it to my todo list. [14:34] bdmurray, thanks. ping me in case you have questions. [15:08] 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] bdmurray: ^ this is about the master package team mapping list [15:20] seb128: what about the packages to which desktop-packages is subscribed to and desktop-bugs is not? [15:25] 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] bdmurray, like "amarok" is there which we never users/maintained [15:30] 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] 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] bdmurray, ~desktop-packages is a team owned by pedro who left the project years ago [15:31] it's just an outdated leftover [15:31] 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] seb128: I'm happy to make such a list. [15:32] bdmurray, I can do the list, it's basically copying +packagebugs from both teams and diffing [15:32] but thanks [16:04] bdmurray: any chance of getting click and snapcraft in proposed today? Or maybe I should ping the person in SRU vanguard today. [16:18] 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] The -v options returns nothing too [16:28] gsilvapt: The control file is inside a debian/ directory and isn't "different" in any way like a changed filename? [16:30] gsilvapt: are you running wrap-and-sort from the top level of your source tree? [16:32] No, Skuggen and yes, rbasak [17:11] infinity: hello. We need help to get click and snapcraft into -proposed. [17:29] elopio: Of which release? [17:30] we need click 0.4.46+17.10.20170607.3-0ubuntu1 and snapcraft 2.31. In xenial, yakkety and zesty -proposed. [17:30] last I heard on friday we were waiting for the dput of click in artful. [17:31] 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] elopio: I see no click in the xenial queue. [17:31] slangasek: yes, I added it on friday. [17:31] ok [17:32] infinity: I see it for yakkety+zesty; perhaps bdmurray didn't make it as far back as xenial for the sponsorship [17:33] https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4 [17:33] Launchpad bug 1693226 in click (Ubuntu Zesty) "Break the conflicts with click the optparser" [Undecided,New] [17:33] Rather than just fix the bug, looks like someone decided to backport it? [17:33] https://bugs.launchpad.net/ubuntu/+source/click/+bug/1693226/comments/4 [17:33] Right and I didn't feel comfortable sponsoring that. [17:34] right [17:34] oh. [17:34] What can we do to make sure it's safe? [17:34] we can not do a wholesale backport [17:34] ^ [17:35] instead of including unrelated changes and then having to figure out how to prove they're safe [17:35] SRUs should be about fixing targetted bugs, not upgrading everything to the latest and shiniest. [17:35] (I realise snapcraft and snapd may have set unrealistic expectations here. :P) [17:36] not at all, I understand the goal of SRUs. I just thought Sergio had it all covered. [17:37] 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] And the test fixes, probably [17:37] Yes. [17:38] the other change was to get the tests passing in artful, so that won't be necessary. [17:38] Oh that was artful-specific? Handy [17:39] 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] Same bug(s). [17:39] 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] I doubt the code has changed much [17:41] I think it should conflict at least a little. But doesn't sound hard. [17:41] elopio: A debdiff between current xenial and the proposed fixed package should do. [17:41] infinity: awesome, thanks. [17:42] 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] But should be trivial to reconstruct it conceptually by hand. [17:43] Trivial, but time consuming, so I'd rather it was your time. ;) [17:44] infinity: oh, of course, it's not something we should outsource :) [17:45] unless we could get our Naming Chief Officer to do it... [17:45] PS: Can someone hop in a time machine to when unified diff was specced and add mv, link, and mode? Thanks. [17:46] And rm. [17:46] "This whole file became /dev/null" is such a helpful way to represent a deletion. [18:00] infinity: if you're doing SRU candidates, could you look at libgweather 3.24.1/zesty (you can reject 3.24.0) [19:24] 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] infinity, re the xenial click patch, what do I do with the changelog version in such a case? [20:28] juliank, yes. [20:32] xnox: But how? Just updating e2fsprogs to 1.43.something seems dangerous, should we have an e2fsprogs-hwe package? [20:34] Or just in -backports? [20:35] (both would work, obviously) === CRogers_________ is now known as crogers [23:52] mdeslaur: are you working LP: #1574670 ? [23:52] Launchpad bug 1574670 in update-manager (Ubuntu Xenial) "ubuntu-support-status returns inaccurate information" [Undecided,Confirmed] https://launchpad.net/bugs/1574670