[04:29] <Unit193> slangasek: But alas it is needed for Ed25519 keys in net-ssh.  Anywho, you can sync the package now if you'd like.
[04:31] <slangasek> Unit193: done, thanks
[04:31] <Unit193> As I said, thank *you*
[10:48] <doko> xnox: are you aware of anything which needs given back for numpy installability?
[10:51] <xnox> doko, i was only aware that cython is broken and needs to be rebuilt somehow; the rest should just work
[10:52] <xnox> doko, and it looks like you are fixing cython
[10:53] <doko> right
[11:08] <jamespage> doko: that dep8 failure for defusedxml looks like a similar timeout issue I hit with OVS - resubmitted test jobs will keep an eye on them
[12:15] <LocutusOfBorg> people, vlc-3 master-daily ppa is FIXED. please use and test, and bother to me in case you are not happy with it
[12:15] <LocutusOfBorg> https://code.launchpad.net/~videolan/+recipe/master-daily
[12:16] <LocutusOfBorg> I fixed it some days ago, but today I would like to have some broader feedback if possible
[12:21] <LargePrime> hello regarding https://packages.ubuntu.com/zesty/libgnutls30 gnutls version is 3.6
[12:22] <LargePrime> http://gnutls.org/news.html has had updates for almost a year
[12:22] <LargePrime> how can i help get gnutls updated?
[12:23] <LargePrime> sorry ubuntu version s 3.5.6.  latest is 3.5.15
[12:23] <juliank> LargePrime: What's your need for an update?
[12:23] <LargePrime> bug fixed.  gnutls has a tls bug
[12:24] <LargePrime> juliank,
[12:24] <juliank> There are always two options: Backport the bug fix or (if the update is not too invasive and bug fix only) update to a later bug fix release.
[12:24] <juliank> But the latter needs far more convincing than the former
[12:25] <juliank> Or well, it might get stuck for months because it's a big update nobody wants to review or something
[12:25] <LargePrime> do you mind explaining why one would back port a bug fix for a bug fix of the same version
[12:26] <ogra_> LargePrime, do you have the CVE number for the bug ?
[12:26] <juliank> LargePrime: The less stuff you change the less stuff you can break.
[12:26] <LargePrime> um, checking ogra_
[12:27] <juliank> Also less stuff to review.
[12:27] <ogra_> (there were definitely quite a bunch of CVE fixes to the package)
[12:27] <juliank> There was a security update in June corresponding to 3.5.13
[12:27] <juliank> there were no reported security issues since then
[12:29] <ogra_> yeah https://usn.ubuntu.com/usn/usn-3318-1/
[12:29] <juliank> A good first step would be upgrading artful from 3.5.8 to 3.5.15
[12:29] <LargePrime> https://gitlab.com/gnutls/gnutls/issues/223
[12:31] <LargePrime> wat do
[12:31] <juliank> So, pick the relevant commits out of there, put them into patch files, prepare an update with that for artful, and then it can be updated in zesty as well.
[12:33] <juliank> Or merge 3.5.15 from debian unstable to artful
[12:33] <juliank> and then cherry-pick the commits into zesty
[12:33] <juliank> 4 commits, even, https://gitlab.com/gnutls/gnutls/merge_requests/433/commits
[12:34] <juliank> ehm, https://gitlab.com/gnutls/gnutls/merge_requests/434
[12:34] <juliank> A first step is to write a bug report in launchpad :)
[12:35] <juliank> Preferably directly following the template at https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[12:37] <juliank> I'm not sure if a new 3.5.x release would qualify for zesty, it depends on if you consider "Added support for IDNA2008 for internationalized DNS names." from 3.5.9 a feature or a bug fix I guess.
[12:38] <Odd_Bloke> artful is in feature freeze now, so you'd also have to determine it there as well.
[12:39] <juliank> and of course it's a critical piece of software, so cherry-picking individual commits seems like a more sensible choice.
[12:39] <juliank> Odd_Bloke: true
[12:46] <juliank> Debian fixed the bug in question in 3.5.8-5+deb9u3
[12:47] <juliank> https://anonscm.debian.org/cgit/pkg-gnutls/gnutls.git/commit/?h=gnutls28_09_stretch&id=aebb4e1b78758d6395e17a3137f2c67a2fb7a334
[12:51] <LargePrime> does that mean i still should file a bug report?
[12:51] <juliank> LargePrime: Yes, of course, without a bug report, there can be no update to a stable release :)
[12:52] <juliank> The patches from Debian apply to zesty, so it seems fairly trivial
[12:53] <juliank> We should also pick the AES GCM breakage on aarch64 as in https://gitlab.com/gnutls/gnutls/commit/228b18dfbf934d8924d3305dc24d7b0162352eba
[12:56] <juliank> LargePrime: Let me know the bug number then, I might just take care of this
[12:57] <LargePrime> kk
[13:01] <LargePrime> Timeout error
[13:01] <LargePrime> Sorry, something just went wrong in Launchpad.
[13:01] <LargePrime> We’ve recorded what happened, and we’ll fix it as soon as possible. Apologies for the inconvenience.
[13:01] <LargePrime> Trying again in a couple of minutes might work.
[13:01] <LargePrime> (Error ID: OOPS-11dfb04dc9e16f2f531d539566a9206c)
[13:04] <cjwatson> when it says "try again in a couple of minutes", it's correct
[13:04] <cjwatson> (this is a known occasional issue that generally goes away within 10 minutes or so)
[13:05] <juliank> launchpad is the only service I know that times out a lot
[13:06] <juliank> well, a lot is probably below 10%, but still
[13:06] <juliank> It's more fun if it times out during autopkgtests and breaks them :D
[13:07] <cjwatson> it's a long way under 10% :)
[13:07] <juliank> cjwatson: Maybe it's about 1%?
[13:08] <cjwatson> most other services just let pages take forever to render and degrade service for everyone else; timing out is a deliberate strategy to avoid that (though obviously any timeout is a bug)
[13:09] <cjwatson> we issue about 800 timeouts a day at the moment
[13:11] <LargePrime> happened again.  i have to re do the bug each time, right?
[13:11] <cjwatson> back button doesn't retrieve it?  usually does for me
[13:13] <juliank> cjwatson: I mostly use Google and Facebook services, so it's not really an accurate representation of normally scaling services :D
[13:13] <LargePrime> "libgnutls30" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[13:13] <LargePrime> um
[13:13] <juliank> LargePrime: It's gnutls28
[13:13] <juliank> there's some weird naming going on there
[13:13] <cjwatson> unless our stats are egregiously lying to me, that's <0.01% of requests timing out
[13:15] <juliank> 99.99% availability seems OK
[13:15] <LargePrime> what is the cli ubuntu pastebin ?
[13:15] <cjwatson> pastebinit -b http://paste.ubuntu.com
[13:15] <rbasak> LargePrime: pastebinit
[13:16] <LargePrime> cause i have libgnutls30
[13:16] <cjwatson> libgnutls30 is a binary package produced by the gnutls28 source package
[13:16] <cjwatson> bugs are grouped by source package
[13:18] <cjwatson> LP's search widget next to "in what package did you find this bug?" will find gnutls28 for you, though
[13:18] <LargePrime> https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1714506
[13:19] <LargePrime> juliank,
[13:19] <cjwatson> http://people.canonical.com/~cjwatson/tmp/gnutls28-search.png
[13:19] <LargePrime> assuming it gets patched, how soon would it be pushed out?
[13:20] <juliank> LargePrime: a few weeks
[13:20] <juliank> at the earliest
[13:20] <LargePrime> great
[13:20] <LargePrime> i guess i could build it?
[13:21] <juliank> LargePrime: I mean, the update goes into -proposed early, you can then install it from there and it needs to be validated to enter the normal -updates thing
[13:21] <juliank> There's a mandatory period of 7 days from proposed to updates
[13:22] <juliank> (IIRC)
[13:22] <juliank> also needs manual review for being accepted into -proposed which probably won't happen this week
[13:23] <cjwatson> security updates may take a different route though
[13:25] <juliank> cjwatson: Yes, but that's not security related
[13:25] <juliank> cjwatson: Well, not a security update
[13:25] <cjwatson> OK
[13:25] <juliank> It's a "cannot connect to server" kind of update
[13:29] <juliank> So, https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1707172 and https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1714506
[13:31] <juliank> I'm not happy with the AES256-GCM one the test is to run yes in gnome-terminal and wait for it to crash
[13:36] <juliank> found the original bug report with a better test case :D
[13:50] <xnox> doko, infinity: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1714514 is this known?
[13:51] <juliank> Hmm is there a way to mark a macro that expands to an attribute as deprecated in gcc?
[13:51] <juliank> APT_CONST expands to __attribute__((pure)) now, but I'd also like a pragma or something that says "hey, APT_CONST is deprecated, use APT_PURE instead."
[13:52] <juliank> Maybe __attribute__((pure)) _Pragma("Use APT_PURE")?
[13:53] <juliank> Ehm, _Pragma("GCC warning \"Use APT pure\"")
[13:54] <doko> xnox: no, is using -C a real world example?
[13:54] <xnox> doko, yes, unfortunately.
[13:55] <xnox>  509      AC_MSG_WARN([Default pre-processing command '$CPP' do not preserve
[13:55] <xnox>  510                     comments. Please define an appropriate pre-processor
[13:55] <xnox>  511                   with --with-cpp, or you will only be able to use ACSL
[13:55] <xnox>  512                   annotations in already pre-processed files])
[13:55] <xnox> it's this frama-c thing this is analysis tool crazy thing
[13:55] <doko> juliank: isn't gnome using some depracted thing for functions? maybe have a look at glib or gtk
[13:55] <xnox> doko, i will try to work around this issue, as i don't think it needs -C whilst building a file that includes math.h
[13:55] <xnox> doko, but this works on all other arches =/
[13:55] <juliank> doko: Probably __attrribute__((deprecated)) but I want to mark the macro as deprecated, not the function using the macro :(
[13:56] <juliank> But the pragma seems to work
[13:57] <doko> ahh, ok
[14:42] <doko> jamespage: left a comment in https://bugs.launchpad.net/ubuntu/+source/xclip/+bug/1713617
[14:45] <jamespage> doko: ta
[14:46] <LargePrime> juliank, thanks
[14:50] <doko> jamespage: pyperclip doesn't run tests for python3
[14:50] <seb128> bdmurray, I +1ed https://code.launchpad.net/~azzar1/update-notifier/ngettext-livepatch/+merge/329982 but I'm going to let you handle the merge/upload if it's fine?
[14:51] <seb128> bdmurray, the code is fine, I'm just not going to get to handle the vcs/upload this week
[14:56] <doko> coreycb, rbasak: highlighing https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/173783  because ubuntu-security-bugs and ubuntu-server are a bug subscriber
[14:58] <doko> nmap has an embedded ssh2 copy anyway
[15:43] <coreycb> doko: was that meant for me?
[15:43] <doko> coreycb: if you are ubuntu-server, yes
[15:44] <nacc> doko: coreycb is not :)
[15:46] <coreycb> doko: i'm a member. i just wasn't sure if it was meant for security team.
[15:47] <doko> coreycb, nacc: both teams are subscribed, I just want to at least ONE party involved, not no party
[15:47] <coreycb> doko: thanks
[15:59] <rbasak> niedbalski: looking at bug 1657256. Is there a bug filed against Percona with the patches you're applying here please?
[15:59] <rbasak> Percona upstream I mean.
[16:09] <niedbalski> rbasak, there is no, as power isn't an official architecture supported by percona upstream, they just support intel.
[16:12] <rbasak> niedbalski: then could you please link instead to their rejection of the patches or some published general rejection policy from them? Then the question will be answered to anyone trying to find the upstream bug link.
[16:12] <rbasak> niedbalski: also it just FTBFS. Please could you take a look?
[16:13] <Mmike> rbasak, it's mentioned here: https://www.percona.com/services/support/mysql-support/supported-platforms
[16:13] <Mmike> rbasak, last line: "All hardware platforms are i686 and x86_64 only."
[16:13] <Mmike> percona only cares about intel
[16:13] <rbasak> Mmike: that doesn't say "we will reject patches regarding other architectures" however.
[16:14] <rbasak> "Enterprise and Premier Percona MySQL Support includes the option for additional operating systems support"
[16:14] <rbasak> Mmike: that suggests they would be happy to accept patches for other platforms, since some of their customers are paying for support for those.
[16:14] <Mmike> rbasak, I think we tried that in the past, there are some bugs from pxc-5.5 in trusty, we had similar conversations then...
[16:14] <Mmike> sec, I can ping someone on #percona to point me to proper documentation about that
[16:14] <rbasak> In any case, please just leave a public paper trail of their rejection.
[16:15] <rbasak> If it isn't in a public policy, then just submit the patches publicly and link to that. They can reject as they wish.
[16:15] <niedbalski> rbasak, OK, i will do that, submit and link a reference to it.
[16:15] <rbasak> I don't think pre-empting that with "they won't accept them" is acceptable unless there's some publicly available citation in support of that statement.
[16:15] <rbasak> Thanks!
[16:17] <rbasak> I'm not trying to create pain for you every time. If they reject once saying they don't support ppc64el, then that's fine. Every future time you need to patch, you could just copy and paste a link to that statement from them.
[16:17] <niedbalski> rbasak, makes perfect sense to me.
[16:18] <rbasak> Thanks. To be clearer, I should've said "saying they don't *accept patches for ppc64el-specific bugs*".
[16:18] <rbasak> Since "support" is quite an overloaded term and doesn't necessarily mean that.
[16:19] <niedbalski> rbasak, FTBFS seems related to compiler warnings that weren't enabled before (?), doesn't seems related to the patch itself, might be related a recent bump in gcc versions?
[16:20] <rbasak> niedbalski: yeah. A gcc transition happened I hear :-/
[16:21] <rbasak> I'm interested to hear what this channel think. In general I think that compiler warnings intended for upstreams and that don't represent real bugs being turned to errors isn't appropriate for distributions.
[16:22] <niedbalski> rbasak, I am quite sure that this will break the build regardless of the patch, trying a pristine build.
[16:22] <rbasak> niedbalski: agreed. Seems likely.
[16:23] <rbasak> I think a minimal distro patch that stops warning->error for non-bugs is OK to fix this. The challenge is to make sure it doesn't overreach such that it accidentally suppresses real problems (now or in the future).
[16:24] <rbasak> niedbalski: you might find https://launchpad.net/ubuntu/+source/squid3/3.5.23-5ubuntu1 helpful - ahasenack had to fix squid3 for similar reasons.
[16:28] <niedbalski> rbasak, ok the pristine build of the package also fails , so any subsequent rebuild of percona will break.
[16:28] <niedbalski> rbasak, what's your suggested approach for this?
[16:33] <rbasak> niedbalski: sorry I pre-empted your test a bit. The last two lines I just said :)
[16:38] <rbasak> slangasek: could you accept Xenial NEW certbot-related packages with your AA hat please? Or do you consider my SRU hat acceptable for that? No idea about actual ACLs but Launchpad's UI suggests that I can.
[16:38] <rbasak> I've just double checked the certbot packages in Xenial's queue (both new and unapproved) and I think they're ready for proposed.
[16:39] <rbasak> The ones in unapproved should go last.
[16:39] <rbasak> (not strictly required but that we can back out more easily if the stuff in NEW is rejected)
[16:39] <rbasak> So python-certbot, python-certbot-nginx and python-certbot-apache from NEW please.
[16:41] <rbasak> bmw: sorry I've been slow in getting round to this. I need an Ubuntu archive admin to release the packages (as they're technically new due to the project rename). I hadn't requested it as I wanted to double check everything first - now done.
[16:41] <rbasak> (see above)
[16:43] <slangasek> rbasak: can you give me a list of the packages by name that are "certbot-related", or a bug # that has all the relevant bug tasks?  I'm fine policy-wise you using your SRU hat to accept new packages that are already in later series; however last I knew the acl didn't actually allow it
[16:43] <slangasek> rbasak: (that's why folks who process kernel SRUs have an honorary AA bit)
[16:46] <bmw> rbasak: no problem
[16:46] <bmw> thanks for the update and moving things along
[16:54] <kasperi> hi, is that gnome shell theme that was shown in didirocks blog coming to ubuntu 17.10?
[16:54] <kasperi> https://didrocks.fr/2017/08/25/ubuntu-gnome-shell-in-artful-day-8/
[16:55] <rbasak> slangasek: bug 1640978, for xenial new, just python-certbot, python-certbot-nginx and python-certbot-apache from NEW please.
[17:00] <niedbalski> rbasak, ok, I will address the build errors via a different LP bug (https://bugs.launchpad.net/ubuntu/+source/percona-xtradb-cluster-5.6/+bug/1714554) , proposing a patch for suppressing the warning->errors inducted by the new gcc version, so you can continue working on bug 1657256 subsequently. is that ok for you?
[17:01] <rbasak> bmw: BTW, did you mention that you had an amendment to the test script you suggested? Feel free to amend https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript, or alternatively feel free to maintain that somewhere else (eg. in an upstream repo). I intentionally didn't formally make that part of our exception so that it can be tweaked easily.
[17:01] <rbasak> If you move it we can link to the new location instead.
[17:15] <slangasek> rbasak: and you've already checked that the delta between later releases and what's uploaded to xenial is sane? (so I can just rubber stamp this?)
[17:29] <rbasak> slangasek: yes. I scripted the generation of it, and nacc reviewed the generating for me.
[17:30] <slangasek> rbasak: ok (and surprisingly, sru-review actually gave me a diff).  accepted
[17:30] <rbasak> Thanks! FTR, the backport generation scripts are at https://anonscm.debian.org/git/letsencrypt/python-certbot.git/tree/?h=rbasak-guest/backport-tools
[17:47] <bmw> rbasak: apparently I don't have permission to edit the TestScript page
[17:48] <bmw> if we can land my edits and continue hosting it there that's preferable to me, otherwise, I can host it somewhere
[18:05] <slangasek> bmw: edit rights should only require you to log in, no special privileges beyond that
[18:08] <bmw> slangasek: I am logged in but at the top of the page it says "Immutable Page" and if I choose "Load" from the Action dropdown and try to upload a new version, it says I am not allowed
[18:09] <slangasek> curious
[18:19] <rbasak> bmw: you may need to belong to some special Launchpad group. I know there have been spam issues in the past.
[18:20] <rbasak> bmw: would you mind asking in #canonical-sysadmin please? Give them your Launchpad ID, etc. I'll happily lurk there and help out if needed.
[18:20] <rbasak> "special Launchpad group" -> "I'm not a spammer" group. If so I'm sure we can get you added :)
[18:22] <bmw> will do!
[18:24] <niedbalski> rbasak, ^^
[21:10] <smoser> slangasek, i'd appreciate input on https://code.launchpad.net/~smoser/ubuntu/+source/initramfs-tools/+git/initramfs-tools/+merge/330043
[21:11] <smoser> theres 2 things there... a.) general support for functional dns in initramfs after dhcp
[21:11] <smoser> b.) non-tested attempt to write netplan configs from the 'ipconfig' otuput files... thus affecting the real-root network configuration from the initramfs configuration, including dns.
[21:11] <smoser> or xnox ^
[21:11] <smoser> i have to run.