[00:14] <nacc> Laney: ah! ok so each trigger gets specified?
[00:15] <nacc> Laney: good to know
[00:43] <nacc> slangasek: is someone from foundations looking at the remaining perl autopkgtest regression? I spent some time last week, but don't know if I should invest more time this week (libembperl-perl). The root cause is some sort of double evaluation of they DynaLoader module
[00:51] <nacc> mdeslaur: thoughts on (me) possibly looking into if we can separate out http2 support into its own pacakge which could live in universe? there isn't a precedent for that in src:apache2, but a lot of other apache2 modules are in universe.
[00:51] <sarnold> isn't that what we have today?
[00:52] <nacc> sarnold: no, we don't build it at all
[00:52] <nacc> sarnold: our apache2 has no mod_http2 available
[00:52] <nacc> sarnold: because it's not its own package in debian (so the above suggestion would be delta)
[00:53] <nacc> we might still pursue the MIR eventually, etc., but I'm trying to think of something that can resolve the lack of http2 at all in the short-term without that
[00:53] <nacc> Laney: do you mind if I document that on the same wiki page?
[01:01] <nacc> RAOF: thanks for the ping, doing it now
[01:01] <RAOF> nacc: Oh, sweet!
[01:01] <RAOF> Thanks.
=== NCommander is now known as Guest85295
[01:34] <nacc> RAOF: done
[01:35] <nacc> RAOF: thank you for the reminder!
[02:19] <RAOF> nacc: ...and released!
[03:49] <slangasek> nacc: I don't know that anyone is tracking that, no
=== JanC_ is now known as JanC
[05:17] <nacc> slangasek: ok, i'll try and debug it more tmrw
[07:17] <josvaz> Morning!
[07:19] <josvaz> Phil's daugther has a high fever (>40C = >104F) so he won't be in, at least in the morning
[07:19] <josvaz> wrong channel sorry
[09:03] <Laney> nacc: go for it
[09:10] <cpaelzer> Hey I'm involved in reviewing and sponsoring an SRU - it seems the last two SRUs (different problems) vanished in proposed (not verified and denied after timing out)
[09:10] <cpaelzer> I'm wondering if it is "ok" to just leave out the two versions in the changelog
[09:10] <cpaelzer> For the user they never happened, so it would be the correct changelog
[09:11] <cpaelzer> but I would like to have anybody confirming that it is ok to jump version.17 version.20 (with .18 and .19 being those that never made it through)
=== NCommander is now known as Guest80995
[12:07] <mdeslaur> nacc: can't it wait for z+1? we can MIR the http2 library as soon as z+1 opens...creating a universe package that you'll have to transition back is a lot of work, no?
[12:18] <rbasak> nacc: I'm not sure about that either. If something isn't in main due to quality (eg. "considered experimental upstream"), then I don't think it should be in universe either unless somebody else commits to looking after all the upgrade path issues etc. I don't think it's worth our time to do that.
[12:19] <rbasak> I think the expectation of quality here matches that of a PPA, so it should be in PPA if anywhere. It should be made very clear to users that the usual expectations of quality (eg. a best-effort-to-be-smooth upgrade path to new releases) don't apply to this module.
[12:20] <rbasak> IOW, I don't think it's OK for us to "throw" something into universe that we don't want to support in main.
[12:21] <rbasak> OTOH, if somebody else wants to commit time to maintaining something in universe by spending the effort to maintain it at better quality, then that's fine.
=== _salem is now known as salem_
[12:52] <sil2100> slangasek, infinity: hey! I was reviewing the thunar SRUs for xenial and yakkety and I think I would need a TB approval on getting this in
[12:52] <sil2100> slangasek, infinity: it's a new microrelease which doesn't mark all the bugs fixed through LP, and they don't have autopkgtests (or a good test suite)
[12:53] <sil2100> slangasek, infinity: the SRU process mentioned I'd need a single TB member to approve it in this case
[12:53] <zul> doko: ping
[12:53] <sil2100> The release makes sense in overall (besides needing a small tweak in the version number) - all changes look like welcome additions
[13:17] <rbasak> sil2100, tjaalton: in bug 1639896, is there any thought to testing users who are on AMD but not using Polaris?
[13:17] <ubottu> bug 1639896 in xserver-xorg-video-amdgpu (Ubuntu Xenial) "Backport support for AMD Polaris" [Undecided,Fix committed] https://launchpad.net/bugs/1639896
[13:17] <rbasak> We don't want to regress those users accidentally, right?
[13:17] <rbasak> For example, if the code that detected what card was in use was broken and was accidentally "always Polaris of course".
[13:19] <tjaalton> rbasak: all such tests use pci-id's. this adds new to support polaris
[13:19] <tjaalton> old radeons use -ati
[13:20] <tjaalton> this is for gcn1.0 and up iirc
[13:20] <rbasak> I'm talking of "regression risk in case our understanding is wrong", not "what is our understanding".
[13:21] <tjaalton> "code that detected" is in the driver
[13:21] <tjaalton> you assume it's broken
[13:22] <rbasak> I assume that broken-ness is unknown without some method to try to ensure that it's not.
[13:22] <tjaalton> it's in 16.10
[13:22] <tjaalton> guess we'd have heard by now
[13:23] <rbasak> That's fair.
[13:23] <tjaalton> also on 16.04.2
[13:23] <rbasak> Oh? 16.04.2 pulled from xenial-proposed for this package?
[13:24] <tjaalton> no, same version
[13:24] <tjaalton> x-x-v-amdgpu-hwe-16.04
[13:24] <rbasak> xserver-xorg-video-amdgpu is 1.1.0-1 in xenial release, doesn't exist in xenial-updates and is 1.1.2-0ubuntu0.16.04.1 in xenial-proposed, now?
[13:24] <rbasak> Oh, I see.
[13:24] <rbasak> OK
[13:25] <tjaalton> yes and zesty has 1.2.0
[13:25] <tjaalton> amd made 1.1.2 to add support for polaris in 1.1.x code
[13:27] <tjaalton> actually 1.1.2 was a one-commit fixup release. 1.1.1 had the other commits
[13:32] <Unit193> tjaalton: I don't suppose you saw my poking of jcristau in #debian-devel?
[13:41] <tjaalton> Unit193: what about?
[13:43] <Unit193> tjaalton: In regards to 60x11-common_xdg_path, which adds DESKTOP_SESSION to the XDG_CONFIG_DIRS path.
[13:44] <tjaalton> no
[13:44] <tjaalton> did not
[13:45] <Unit193> Before I had asked one of the Ubuntu devs if it was pushed to Debian, and at the time he said they didn't want it.  jcristau seemed to know nothing about it, and it's very useful in live-build ISOs.
[13:45] <Unit193> Do you happen to know?
[13:45] <tjaalton> nope
[13:46] <Unit193> Huh.  Alrighty, thanks.
[13:46] <tjaalton> needs a bug on debian side
[13:46] <tjaalton> if you want it there
[13:48] <Unit193> Yeah I was just trying to find out why not, but seems there might not be a reason so time to file.
[14:23] <juliank> cjwatson: We have a user in #debian-apt on oftc wondering how to best create a local partial mirror of Ubuntu archives. Seems that with apt-mirror he always runs into inconsistencies. Ideas?
[14:24] <cjwatson> not at the moment sorry
[14:24] <cjwatson> I mean I'd probably start with debmirror
[14:24] <cjwatson> but partial mirroring is always somewhat fiddly
=== DalekSec_ is now known as DalekSec
[14:28] <juliank> cjwatson: I think the problem is mostly that the mirror they are mirroring updates while they are mirroring, causing parts to be from the old state and parts from the new state.
[14:29] <juliank> How often are they updated? Every 30 minutes?
[14:35] <cjwatson> juliank: multiple times an hour, not on a fixed schedule exactly
[14:35] <juliank> ah, ok
[14:35] <cjwatson> juliank: sounds like something that might be fixed by having the mirroring tool use by-hash index files
[14:36] <cjwatson> juliank: the stay of execution for everything else is generous enough that that should be enough
[14:48] <caribou> barry: can I trusk sysconfig.get_config_vars() to return _EXACTLY_ the CFLAGS used to build the python interperter ?
[14:51] <barry> caribou: yes, should be accurate.  iirc it reads them right out of the makefile
[14:51] <caribou> barry: ok, thanks
[15:19] <smoser> hey. wonder if anyone has a solution.
[15:19] <smoser> rharper has been working some systemd-networkd bugs and support in cloud-init
[15:19] <smoser> we dont know how we can express what we want correctly
[15:19] <smoser>  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/317917
[15:19] <smoser> has more info. but basically , as rharper said
[15:20] <smoser> we don't have a way to express the idea that *if* you're using networkd  as your $networking_service *then* you need systemd >= X and resolvconf >= y
[15:25] <rbasak> You might be able to express that using virtual packages, but I don't know if that would be appropriate.
[15:25] <rbasak> (or metapackages)
[15:26] <rbasak> networkd Depends: systemd-networkd-support, systemd-networkd-support Depends: systemd >= X, etc.
[15:26] <rbasak> (or, virtually, a high enough version of systemd Provides systemd-networkd support)
[15:27] <rbasak> Seems ugly to me :-/
[15:27] <rbasak> (also I've never seen that done before, so perhaps there's a reason or better way)
[15:35] <juliank> apt 1.3.5 patch list: https://github.com/Debian/apt/compare/1.3.y...julian-klode:1.3.y?expand=1 - if someone thinks I missed something, or can drop some changes, let me know.
[15:35] <juliank> This brings yakkety up to 1.4~rc2 in terms of important bug fixes
[15:39] <juliank> Highlights: * Bugfix for partial requests on slashdot * The icon tarball thing fixed * sanitized environment for privilege dropping processes * installation ordering / progress fixes
[15:39] <juliank> I think most of that, excluding the installation ordering/progress stuff will also apply to 1.2 (xenial)
[15:40]  * juliank should force himself to more regular SRUs
[15:41] <juliank> Changelog: https://paste.ubuntu.com/24047071/
[15:42] <juliank> Some fixes are not really that important, but tiny, so I still picked them
[15:42] <juliank> stuff like "bash-completion: Only complete understood file paths for install"
[15:49] <nacc> mdeslaur: rbasak: ack, was just thinking through alternatives, as I read through your prior discussions on the topic
[15:49] <juliank> Oh, is there a way to search for apt bugs where I added xenial or yakkety tasks?
[15:50] <rbasak> juliank: https://bugs.launchpad.net/ubuntu/xenial/+source/apt
[15:50] <rbasak> Linked on the right at https://bugs.launchpad.net/ubuntu/+source/apt
[15:51] <rbasak> No idea how to "union" that with yakkety though.
[15:51] <juliank> rbasak: thanks, that's OK
[15:51] <juliank> rbasak: It's more of an or anyway :)
[15:52] <rbasak> Good point :)
[15:52] <juliank> Now I just have to annotate the commits with the proper launchpad bugs
[15:58] <caribou> barry: ah, that would explain why I don't see the LTO optimisation flags, they're passed in the make command during the build
[16:01] <juliank> Heh, we now have coverage information on the whole 1.3.4 to 1.3.5 diff, that seems useful: https://codecov.io/gh/julian-klode/apt/compare/15f32c417545d6e19d459004d510b7101bf6683f...e5f9d66fcc67c1cad96cbb3efa6cc1226ba0ccbf/diff
[16:12] <cult-> when is this bug going to be released? https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
[16:12] <ubottu> Launchpad bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed]
[16:22] <nacc> do isolation-container autopkgtests inherit the enviornment from the top-level (that is, values like no_proxy?)
[16:32] <slangasek> sil2100: nowadays the TB has delegated to the SRU team for the SRU exceptions; so what's your sense of whether thunar should be granted an exception?  Do you have confidence that the upstream QA for the microrelease was up to our standards, despite there not being autopkgtests?
[16:33] <rbasak> xnox: bug 1588330 above - not verification-done?
[16:33] <ubottu> bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed] https://launchpad.net/bugs/1588330
[16:33] <rbasak> slangasek, sil2100: do we (~ubuntu-sru) explicitly grant and document these exceptions currently? For consistency, I feel that we should.
[16:34] <slangasek> rbasak: if it's intended to be a standing exception, yes
[16:34] <slangasek> if it's a one-off, the paperwork doesn't pay for itself
[16:35] <rbasak> Perhaps we should ask uploaders to document in the bug whether it should be a standing or one-off exception (or ~ubuntu-sru could just edit the bug description on approval, etc).
[16:35] <rbasak> I agree it's not worth anything further for a one-off.
[16:35] <rbasak> s/edit the bug description/just comment/ even.
[16:37] <juliank> APT 1.2.20 queue: https://github.com/Debian/apt/compare/1.2.y...julian-klode:1.2.y?expand=1
[16:38] <juliank> Riddell: ^ might be interested :)
[16:39] <Riddell> juliank: Debian uses github?
[16:39] <rbasak> powersj: so I forgot to mention. The next thing that'll happen is a component mismatch, probably leading to an email to ubuntu-release@ saying that those packages are incorrectly in universe. An archive admin will spot this in the component mismatches report, find the approved MIR bug, and override those packages to main. So it's not entirely done, but needs no further action from us as the MIRs are
[16:39] <rbasak> approved.
[16:39] <juliank> Riddell: We mirror apt there, and I merge pull requests from there
[16:41] <juliank> Well, some bot mirrors there, not sure who is really responsible for that
[16:42] <rbasak> powersj: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg and related files in that directory are the component mismatches reports
[16:42] <Riddell> juliank: yay for "Only merge acquire items with the same meta key" merge :)
[16:42] <powersj> rbasak: ok thanks that will save me a few minutes of panic later today :)
[16:46] <juliank> Riddell: Yeah, now I just need to take a look at some failing tests, and then it should be ready for upload in one to two days.
[16:50] <juliank> Hmm, nothing troubling actually. Just the sections of some test packages being different
[16:51] <cult-> rbasak: can you set it to verification-done?
[16:53] <rbasak> cult-: not without being confident that it was actually verified and what was verified, no.
[16:53] <rbasak> That's why I asked xnox, because it looks like he knows and that approach is least likely to end badly.
[16:53] <xnox> rbasak, verified in xenial; did not finish verification in yakkety; i do have container about.
[16:54] <xnox> for it.
[16:55] <xnox> cult-, rbasak: the bug has not aged yet. It's only 5 days old, thus will not be released yet.
[16:58] <cult-> how many days need to be passed?
[16:58] <cult-> ah damn this is crazy
=== zyga_ is now known as zyga
[16:58] <rbasak> See https://wiki.ubuntu.com/StableReleaseUpdates for full details.
[16:59] <rbasak> Taking care to not regress millions of users isn't crazy.
[17:00] <cult-> i understand it, but the current binaries in universal are unusable
[17:00] <rbasak> And for 16.04 they've been unusable for 10 months. Two days won't make a difference.
[17:00] <cult-> so there's not much to break, if its already broken
[17:01] <cult-> rbasak: ok
[17:01] <xnox> cult-, you can use binaries from xenial-proposed which are mirrored world-wide
[17:01] <xnox> you know that, right?!
[17:01] <cult-> yes
[17:01] <cult-> :P
[17:19] <juliank> Riddell: sudo add-apt-repository ppa:deity/apt-1.2 - 1.2.20~rc1 should appear in the next hour or so, it's currently building
[17:21] <Riddell> that's awfae clever
[17:21] <nacc> xnox: since you're around, have you looked any further at the libaws/liblog4ada regressions in z-p? I am going to try and talk to the Debian maintainers if they have any suggestions
[17:22] <xnox> nacc, i ran a test with all-proposed and it did pass and migrate zlib for me
[17:22] <xnox> (i think libaws test passed)
[17:22] <nacc> xnox: interesting! thanks for that info!
[17:22] <xnox> nacc,and I don't care any more =) doko says that these things should be rebuild in order until it's right =/
[17:22] <xnox> but i'm not sure how to establish that
[17:23] <nacc> xnox: ack
[18:35] <toabctl> could somebody sponsor the fix with https://bugs.launchpad.net/ubuntu/+source/zypper/+bug/1638306 please?
[18:35] <ubottu> Launchpad bug 1638306 in zypper (Ubuntu) "[SRU] zypper binary shipped w/ Ubuntu Xenial requires rebuild (relocation error)" [High,Triaged]
[18:40] <nacc> toabctl: is it fixed in Y and Z? Your versioning also makes it hard to be sure the sort is correct relative to new versions. Maybe not critical, but e.g., 1.12.4-1ubuntu0.1 would make it clearer that it's an SRU (to me)
[18:40] <nacc> tbh, i'm also surprised anyone uses zypper on ubuntu, but that's neither here nor there
[18:42] <sarnold> wow I didn't know we packaged that :)
[18:42] <toabctl> nacc, you just need an rebuild. there is nothing to fix
[18:42] <toabctl> nacc, sarnold we need it in the openstack CI which runs on ubuntu but we also want to create suse images there. for that zypper is useful
[18:43] <nacc> toabctl: i understand, and even my version string above is wrong, since 1.12.4-1ubuntu0.1 would sort ahead of 1.12.4-1build1 (which is what is in y/z)
[18:43] <toabctl> anyway - this bug is really easy to reproduce (zypper -h) and really easy to fix and test the fix.
[18:47] <nacc> toabctl: my worry is that '1.12.4-1+b1' is already in use by Debian as a version string (unstable)
[18:47] <nacc> toabctl: it is wrong (aiui) to use that same string in ubuntu
[18:49] <sarnold> heh, "Binary-only non-maintainer upload for amd64" considering we don't do binary uploads in ubuntu, there's no maintainers, and you can't easily upload for just one architecture, I think every word in that sentence is a lie :) Also the cake is a lie.
[18:50] <nacc> toabctl: i fully agree your fix is probably correct, but i'm not comfortable sponsoring it as-is
[18:50] <Unit193> nacc: I've seen '1.12.4-1~ubuntu0.1'
[18:50] <nacc> Unit193: yeah i'm thinking the ~ is needed here to sort correctly
[18:50] <toabctl> doko, what the correct version string for a pkg rebuild?
[18:50] <Unit193> And I've seen cases like ca-certs that don't add that, thus the version in devel is older. :/
[18:50] <sarnold> what's the core cause of this fault? it feels unlikely to me that a rebuild alone would be sufficient.
[18:51] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mterry
[18:51] <sarnold> (I mean, sure, a rebuild is likely to -fix- it but what would prevent this from recurring?)
[18:56] <toabctl> sarnold, I guess a tighter dep on libzypp could help. but this is a bugfix
[18:56] <sarnold> toabctl: it -does- pass the "minimal effective" test quite well :)
[18:58] <sarnold> ahhhh, libzypp isn't built from the same source package as zypper; that's surprising.
[18:58] <toabctl> sarnold, it's a different thing
[19:03] <smoser> anyone else having issues with vpn ?
[19:05] <sarnold> smoser: zesty?
[19:05] <smoser> barry, ? i see you touched network manager recently... /me is unable to connect to a vpn
[19:05] <smoser> yeah, zesty
[19:06] <smoser> oh. fun. jgrimm
[19:06] <nacc> smoser: you need to do a tweak
[19:06] <smoser> is last-touched on openvpn
[19:06] <nacc> smoser: https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#OpenVPN
[19:07] <nacc> smoser: verify by name exactly in NM's advanced settings, then elid the '/CN:' string in the textbox
[19:07] <jgrimm> smoser, there's a pending doc update internally to the VPN notes as i understand it too
[19:09] <smoser> nacc, edit to ? canonical.com ?
[19:10] <nacc> smoser: the canonical vpn definition in NM
[19:11] <smoser> nacc, not following. i set " verify by name exactly in NM's advanced settings".
[19:12] <smoser> but then 'elid' (i assume edit) the '/CN:' string... edit to what ?
[19:12] <smoser> i currently have /CN=access.is there
[19:12] <jgrimm> smoser, change to 'access.is'
[19:13] <barry> yeah i saw some recent changes to the wiki page, but haven't tried connecting to the vpn yet
[19:14] <smoser> ok. that worked. \o/
[19:15] <nacc> smoser: sorry, yeah, just remove the '/CN=' part
[19:15] <smoser> elid is esparanto for delete
[19:16] <nacc> *elide :/
[19:19] <infinity> nacc: I tossed some comments on that zypper bug you were looking at.
[19:21] <sarnold> infinity: what do you mean with "but the packages don't"?
[19:21] <smoser> for anyone else who sees this..
[19:21] <smoser>  http://paste.ubuntu.com/24048268/
[19:21] <sarnold> that's a bit of packaging I never deal with :)
[19:21] <infinity> sarnold: The binary package name is libzypp, not libzypp1503
[19:22] <infinity> (Though, in this case, there appears to *also* be an undeclared ABI break happened within the upstream SONAME of 1503, but hard to throw stones at upstream when the packaging is so clearly broken anyway)
[19:23] <sarnold> interesting, I never noticed just how many lib* packages encode version numbers in the names. it always felt like a minority..
[19:24] <infinity> sarnold: Any lib* package that's an ELF library with an SONAME should use the SONAME as the package version.
[19:24] <infinity> s/package version/package name/
[19:24] <infinity> Brain and finger disagreement.
[19:25] <sarnold> infinity: thanks for the explanation :)
[19:25] <infinity> There are some packages so old that they don't conform (zlib1g might be one of the only ones left?), but anything that's had an ABI bump since the glibc transition follows that pattern or is wrong.
[19:26] <infinity> And with versioned provides, we could finally s/zlib1g/libz1/ if we really wanted to.
[19:27] <sarnold> and confuse the heck out of everybody??
[19:27] <infinity> But I kinda like that it's had a stable ABI for so long that it's lived through decades of policy.
[19:39] <nacc> infinity: thanks
[19:44] <nacc> infinity: and just to be clear, re: your last comment, no rebuild is needed for zesty; but xenial only
[19:49] <infinity> nacc: Yeah, yakkety (and thus zesty) got a rebuild for a different transition, which happened to fix this bug in the process. :P
[19:50] <nacc> infinity: yep :)
[19:54] <infinity> nacc: My guess is that the Debian maintainer maintains both packages and hand-waves over the glaring packaging bug by not uploading zypper until libzypp is built everywhere.  Which broke in Ubuntu when we mass-synced.
[19:55] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
[19:56] <nacc> infinity: that makes sense
[20:36] <toabctl> nacc, thanks for sponsoring. Where can I find the package now? will it popup in proposed?
[20:42] <nacc> toabctl: https://wiki.ubuntu.com/StableReleaseUpdates
[20:42] <nacc> toabctl: SRU team needs to handle it once it's built
[20:46] <toabctl> nacc, ok. thx
[21:10] <nacc> lamont: hey, just touching base on maas and python-django. Anything I can do to help?
[21:18] <nacc> slangasek: re: libemperl-perl, I think this is actually a change in behavior in pkg-perl-tools 0.34 (this is when the tests started failing in debian as well). a) they updated autopkgtest to run with PERL_DL_NONLAZY=1 and b) they also added a whitelist functionality for output during a test run, but libembperl-perl doesn't use this for output; and I think it's actually correct for libembperl to emit
[21:18] <nacc> the redefinition error it does when that environment variable is set
[21:21] <jackpot51> I have patches for WPA 2 enterprise support in ubiquity - what should I do with them?
[21:24] <lamont> nacc: I've been working through just how much work it is, and it's not quite trivial
[21:36] <jackpot51> Patches can be seen here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1107935
[21:36] <ubottu> Launchpad bug 1107935 in ubiquity (Ubuntu) "Support for WPA Enterprise wireless networks" [Wishlist,Triaged]
[21:40] <jbicha> jackpot51: it's best to subscribe ~ubuntu-sponsors to a bug when you attach a patch, https://wiki.ubuntu.com/SponsorshipProcess
[21:41] <jackpot51> ok, cool
[21:42] <jackpot51> Done
[21:51] <jackpot51> Here is an additional change for network-manager-applet: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1667129
[21:51] <ubottu> Launchpad bug 1667129 in network-manager-applet (Ubuntu) "Python cannot create NMGtkWifiDialog" [Undecided,New]
=== salem_ is now known as _salem
[23:01] <nacc> slangasek: in any case, sent to Debian as well, uploaded, and retriggering the tests. I think perl should migrate now
[23:34] <Unit193> cjwatson: It's safe to presume putty won't be making it into Zesty?
[23:43] <Unit193> !info libpcsclite1 yakkety
[23:43] <ubottu> libpcsclite1 (source: pcsc-lite): Middleware to access a smart card using PC/SC (library). In component main, is optional. Version 1.8.14-1ubuntu1.16.10.1 (yakkety), package size 22 kB, installed size 70 kB
[23:43] <Unit193> !info libpcsclite1 zesty
[23:43] <ubottu> libpcsclite1 (source: pcsc-lite): Middleware to access a smart card using PC/SC (library). In component main, is optional. Version 1.8.14-1ubuntu1 (zesty), package size 22 kB, installed size 75 kB
[23:45] <slangasek> nacc: cool!