[08:51] <rbasak> apw, cking: I'm confused. https://launchpad.net/ubuntu/+source/zfs-linux/0.6.5.9-5ubuntu5 doesn't appear in https://launchpad.net/~colin-king/+uploaded-packages and doesn't appear to have needed sponsorship. What am I missing?
[08:59] <apw> rbasak, could it have been a sync into -proposed from cking's ppa and then when its been copied again that is lost ?
[09:00] <apw> rbasak, as to why its not on his +uploaded-packages ...
[09:01] <apw> rbasak, i wonder if those are the first ones since the buildinfo
[09:02] <apw> rbasak, or indeed if artful is missing from that list
[09:02] <apw> (+uploaded-packages)
[09:05] <apw> rbasak, ok that artful zfs is listed under _my_ sync's.  iirc that was the first upload he did which had .buildinfo included
[09:05] <rbasak> apw: ah, yes, thanks. https://launchpad.net/ubuntu/+source/zfs-linux/0.6.5.9-5ubuntu5/+publishinghistory
[09:05] <apw> rbasak, and that meant i could not sponsor it as an upload (he test builds them in a PPA) so i copied it out of the PPA
[09:06] <apw> there begin a bug in that pull-lp-source does not get .buildinfo
[09:07] <rbasak> Not relevant to my reason for asking, but I'm curious as to why buildinfo gets in the way here. Why could you not sponsor it as an upload?
[09:15] <dupondje_> I got some gzip issues in Tomcat. But after downgrading zlib1g it works again. Is there somebody with some experience in this? :D
[11:38] <dupondje_> xnox: happen to be around?
[11:38] <xnox> dupondje_, sure
[11:39] <dupondje_> I upgraded my system recently to 17.04. And was having an issue with my 'UniFi' controller. Seems like gzip compression in the build-in tomcat was broken. "curl: (23) Error while processing content unencoding: invalid code lengths set"
[11:39] <dupondje_> Now I was able to pinpoint it, and the following commit fixes my issue: https://github.com/madler/zlib/commit/f9694097dd69354b03cb8af959094c7f260db0a1.patch
[11:40] <dupondje_> I don't see any other bugreports, so it must be some edge case I guess. But would an SRU be possible for this you think?
[11:41] <xnox> dupondje_, yes, please open a bug report.
[11:41] <dupondje_> the SRU style kinda bug report? :)
[11:49] <dupondje_> xnox: https://bugs.launchpad.net/ubuntu/+source/zlib/+bug/1692870
[11:52] <xnox> dupondje_, if you could update the bug description to follow https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template that would be awesome
[11:52] <xnox> dupondje_, specifically how to reproduce the problem/bug would be very useful. As I am not familiar with tomcat.
[11:57] <dupondje_> adjusted
[12:00] <dupondje_> Thing is I didn't had time to test if tomcat is affected somehow. But as the UniFi guest portal is using tomcat in the background, and relies on java (which uses the zlib). I guess it will (in some cases)
[15:45] <mdeslaur> kees, infinity, stgraber, slangasek: tech board meeting in 15 minutes
[15:45]  * slangasek nods
[15:57] <ddstreet> stgraber sorry to bug you, but i noticed you've done a few sponsor uploads for the ifupdown and vlan pkgs, could you review and/or sponsor bug 1573272 if you have a chance?
[16:17] <slangasek> kees: now why are bindnow numbers still so low?
[16:27] <kees> slangasek: those aren't benefited from the generous PIE logic. i.e. bindnow is only detected on executables with it set
[16:28] <kees> slangasek: so, 50% of source packages have a PIE executable (with bindnow), and 80% of source packages lack an ET_EXEC (i.e. not not PIE)
[16:29] <kees> (does that make sense?)
[16:33] <slangasek> kees: so you're saying the heuristic is lowballing?
[16:35] <slangasek> rbalint: hi, so when PIE was turned on in Debian, did you do anything systematically with static linking?
[16:36] <slangasek> rbalint: thinking about how we might do this more cleanly this time around, since when we turned it on for amd64 we spent a long time chasing opaque build failures.
[16:39] <rbalint> slangasek: i tracked down every issue, and finally the solution was recompiling the static libs with PIE
[16:39] <rbalint> they don't need to be PIC, PIE is enough
[16:39] <slangasek> rbalint: so what I'm wondering is if we shouldn't analyze the archive for "-dev build-deps that don't produce shared lib runtime deps", do build tests of those packages, confirm they FTBFS, rebuild the build deps, rebuild the dependent packages, confirm it fixes the FTBFS
[16:41] <rbalint> yes, this would be the way to go archive-wide IMO
[16:41] <slangasek> rbalint: ok.  would you like to drive this? :)
[16:41] <slangasek> rbalint: I'm interested in making sure that we fix these build failures early so that developers don't trip on them
[16:42] <rbalint> slangasek: sure :-)
[16:46] <slangasek> cool
[16:46] <slangasek> rbalint: to be clear, we would want this analysis across all of main and universe
[16:48] <rbalint> slangasek: sure, it was my understanding, too
[17:35] <nacc> cyphermox: would you happen to have any insight into LP: #1688018 or LP: #1682227 ?
[17:37] <cyphermox> not sure the second is accurate, would need to dig in more about the first...
[17:51] <cyphermox> nacc: too many people with unrelated issues touching these bugs, some are about VPN and network interfaces, other about suspend/resume behavior, and others about $somethingelse
[17:51] <nacc> cyphermox: yeah, me neither yet
[17:52] <nacc> cyphermox: right, so there are (i think) two classes of bugs, as you noted
[17:52] <nacc> s/r is supposedly fixed (or is confirmed fixed for many users)
[17:52] <nacc> the dns 'leak' is a separate bug
[17:52] <nacc> *class
[17:52] <cyphermox> yes, suspend resume is probably fixed.
[17:52] <nacc> i agree they are all really noisy :)
[17:53] <nacc> rbasak: LP: #1573624, not sure if you've seen that last comment?
[17:53] <cyphermox> yeah... well it's a "common problem" and people don't usually have the esoteric knowledge of DNS in the context of VPNs
[17:53] <nacc> cyphermox: right
[17:54] <cyphermox> I have no idea why some of these have been marked as duplicate when they pretty obviously look like not
[17:55] <rbasak> nacc: that comment sounds like bug 1592669
[17:55] <rbasak> nacc: I'll comment
[17:55] <nacc> cyphermox: yeah, the s/r bug that is fix-released had a crazy number of dupes, i'm not sure where they all came from
[17:55] <nacc> rbasak: yep, thanks!
[17:56] <cyphermox> nacc: so first step would be to make sure dnsmasq indeed has the requisite fixes, so at least we know we don't need to look at suspend/resume too much
[17:56] <cyphermox> (I'm doing this, just including the running commentary)
[17:57] <cyphermox> err, why is this done without patches?
[17:59] <nacc> cyphermox: dnsmasq is a 1.0 source format pkg
[17:59] <nacc> iirc
[17:59] <cyphermox> doesn't matter, we still do patches for that?
[17:59] <cyphermox> (usually anyway)
[18:00] <cyphermox> it doesn't matter, it's just yucky
[18:01] <nacc> cyphermox: maybe i am misunderstanding, but i thought a 1.0 source package was an orig tarball plus a diff tarball (a single patch to apply aiui)
[18:04] <nacc> cpaelzer: would you be able to respond to LP: #1540692 from a qemu perspective?
[18:04] <nacc> cpaelzer: i'm guessing we're just following debian's lead, but would like confirmation
[18:06] <cyphermox> nacc, you can still use a patching tool like quilt for 1.0 format packages; it only needs a bit of configuration
[18:07] <nacc> cyphermox: ah ok, i guess maybe it's not available by default and the tool i usually use (e.g., `dpkg-source --commit`) just says "no" :)
[18:07] <nacc> *not configured by default
[18:09] <cyphermox> nacc: in any case, looks like dnsmasq is up to par (at least AFAICT), so focusing on the VPN situation...
[18:10] <nacc> cyphermox: ok
[18:37] <nacc> cyphermox: here is another possibly related (with a specific missing connection between NM and openvpn being claimed): LP: #1686252
[18:37] <nacc> the 'repeatedly tell OpenVPN to connect' seems similar
[18:41] <cyphermox> no, that's something different
[18:45] <nacc> cyphermox: ok :)
[18:49] <nacc> rbasak: it appears that perhaps this is a real bug: LP: #1688068 ?
[18:51] <nacc> sarnold: for something like LP: #1687930 which is really just a report of https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-8779.html, what does the security team usually do with such bugs?
[18:52] <sarnold> nacc: we normally mark it confimred, public security, and add the bug to the UCT entry so we stand a chance of closing the bug when updates are issued
[18:53] <nacc> sarnold: ok, are you able to do that for this bug? i can do the first part, not sure if i have permissions to do the second
[18:53] <sarnold> nacc: of course if it's in universe we add the usual "this package is community-supported, please provide debdiffs" etc etc
[18:54] <nacc> sarnold: right
[18:54] <sarnold> nacc: heh yeah, it's not worth figuring out how to do merges in bzr to add one line to the file :) hehe
[18:55] <nacc> sarnold: thanks!
[19:09] <cpaelzer> nacc: done on the qemu bug
[19:10] <cpaelzer> nacc: it is not only debians lead, but also component mismatch and full of CVEs recently
[19:10] <cpaelzer> nacc: I wrote it in the bug to be clear with the reporter
[20:07] <nacc> cpaelzer: thanks!
[20:59] <bdmurray> What would I use on Lubuntu and Xubuntu that is equivalent to gnome-session-quit?
[21:00] <wxl> it's via lxsession if memory serves correctly
[21:00] <wxl> (for lubuntu)
[21:06] <nacc> cpaelzer: fwiw, re: c#2.6 in LP: #1686679, the Author should be the patch's author, not the backporter's.
[21:11] <bdmurray> wxl: Is there anyway you could confirm that for me so I can fix a software-properties bug?
[21:12] <Unit193> What precisely does gnome-session-quit do?
[21:14] <bdmurray> gnome-session-quit - End the current GNOME session
[21:14] <bdmurray> There's a reboot button in software-properties-gtk that I'm guessing doesn't do anything on Lubuntu or Xubuntu.
[21:15] <Unit193> xfce4-session-logout --reboot
[21:15] <bdmurray> Unit193: will there be a prompt too?
[21:15] <Unit193> If you want that, drop '--reboot'
[21:16] <wxl> i'm on kubuntu right now and plasma ain't behaving for me. once i get it going again i'll open a vm for you, bdmurray
[21:17] <bdmurray> wxl: cool, thanks
[21:17] <bdmurray> Unit193: Thanks
[21:20] <wxl> lxsession-logout
[21:21] <Unit193> bdmurray: Sure thing!
[21:21] <bdmurray> wxl: I've put this issue in bug 1693038 since it might be worth SRU'ing.
[21:22] <wxl> bdmurray: if you subscribe lubuntu packages team, we'll notice :)
[21:30] <nacc> rbasak: https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt from LP: #1689015 appears to be a bug in the mysql apport hook?
[21:32] <bdmurray> nacc: For sure with the 2nd traceback
[21:33] <nacc> bdmurray: yep
[21:35] <bdmurray> nacc: At least in zesty there is try except for the other one
[21:35] <nacc> bdmurray: ah ok, good to know
[21:43] <rbasak> nacc, bdmurray: I suspect the user has replaced /usr/bin/python with python 3.
[21:43] <rbasak> We should have apport pick up on that and have a bug pattern on it.
[21:45] <bdmurray> rbasak: Why do you suspect that in that bug? Also re apport bug 1681528.
[21:45] <rbasak> bdmurray: I'd need to check, but https://launchpadlibrarian.net/318686604/HookError_source_mysql_5.7.txt and I don't think that the hook has been converted to Python 3. So I wouldn't expect that error. Also I've seen users do this before, IIRC wrt. mysql.
[21:46] <rbasak> I could be wrong. Just a hunch.
[21:53] <nacc> rbasak: yeah there was another bug that i triaged today with  that issue (they eventually get a backtrace about ConfigParser, which is now configparser in python3)
[21:56] <bdmurray> rbasak: running python3 /usr/share/apport/package-hooks/source_mysql-5.7.py or python  /usr/share/apport/package-hooks/source_mysql-5.7.py works for me on a xenial system
[21:56] <rbasak> bdmurray: could it be an edge case?
[21:56] <rbasak> bdmurray: what does the shebang say?
[21:56] <bdmurray> rbasak: there is no shebang in it
[21:58] <rbasak> bdmurray: http://paste.ubuntu.com/24637495/
[21:58] <rbasak> This is why I think it's a 2 vs 3 thing.
[22:00] <rbasak> bdmurray: so I don't know how he's got things running under Python 3, but I'm pretty sure the hook was not written to target 3.
[22:01] <rbasak> We can fix it of course.
[22:01] <rbasak> We should update it to work on both at a minimum. And perhaps there's a dependency that's not being declared.
[22:01] <rbasak> Or, perhaps it's an edge case code path that we haven't noticed and is always buggy since something in apport was deliberately switched to use 3.
[22:02]  * rbasak EODs
[22:03] <bdmurray> python3-apport is seeded and apport just uses all the stuff in /usr/share/apport/package-hooks/
[22:03] <bdmurray> The point being I don't think the user did anything wrong but that the hook needs updating.