=== cpaelzer__ is now known as cpaelzer
[07:29] <vicamo> bdmurray: https://code.launchpad.net/~vicamo/ubuntu/eoan/apport/bug-1847967/+merge/374263 , do you have some time to review this or maybe suggest another reviewer?
[08:30] <seb128> vorlon, hey. I'm a bit confused on what should be done with e.g cockpit, it's blocked in focal-proposed because its autopkgtests are failing on i386 but the version in proposed didn't even built for that arch... what are we supposed to do in those cases?
[08:33] <didrocks> bdmurray: can we get foundation team being subscribed to golang-1.13 package so that I can promote it and unblock golang-defaults?
[08:33] <seb128> vorlon, same for firefox, firejail/i386 fails because it tries to install firefox which doesn't exist anymore on that arch
[09:02] <oSoMoN> sil2100, good morning! I attached debdiffs to bug #1841191 for the cargo SRU, I am going to update the bug description now
[09:02] <ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,In progress] https://launchpad.net/bugs/1841191
[09:12] <sil2100> oSoMoN: thanks! Once you update the description, I could sponsor that into ubuntu - but then I think I wouldn't be able to accept it into -proposed
[09:13] <sil2100> oSoMoN: also, looking at the debdiff I think it might also be a good thing to include LP: #1850651 in the changelog, so that we know one shouldn't go without the other
[09:13] <ubottu> Launchpad bug 1850651 in thunderbird (Ubuntu Eoan) "[SRU] Authentication constantly re-requested for Google" [High,Fix committed] https://launchpad.net/bugs/1850651
[09:13] <sil2100> But I can do that before sponsoring
[09:19] <oSoMoN> sil2100, ack, would it be better if I found someone else to sponsor, so you could accept it in -proposed?
[09:20] <oSoMoN> I'll update the debdiffs to include LP: #1850651
[09:26] <oSoMoN> seb128, could you maybe sponsor my cargo uploads (xenial and disco) that are attached as debdiffs to bug #1841191
[09:26] <ubottu> bug 1841191 in cargo (Ubuntu Disco) ""error: failed to acquire package cache lock" in sbuild" [Undecided,In progress] https://launchpad.net/bugs/1841191
[09:27] <oSoMoN> (for context this is needed for the thunderbird 60.9.1+build1 SRU, which is accepted in {xenial,disco}-proposed, but is FTBFS because of that cargo bug)
[09:32] <seb128> oSoMoN, I'm joining a meeting now but trying to have a look
[09:32] <oSoMoN> thanks!
[09:37] <mwhudson> oSoMoN: finally got rustc and cargo all done... must be time for the next update nearly
[09:38] <oSoMoN> mwhudson, thanks!
[11:23] <rbasak> kanashiro: did you make any progress with rrdtool please? I got an email about it still being stuck in proposed.
[11:25] <kanashiro> rbasak, sorry I forgot to follow up, I have this MP but it is still waiting for review: https://code.launchpad.net/~lucaskanashiro/ubuntu-seeds/+git/ubuntu/+merge/376068
[11:26] <rbasak> kanashiro: ah - subscribe ~canonical-server to that please, so it appears in our team's review queue.
[11:26] <rbasak> I'll take a look later if I get a chance
[11:27] <kanashiro> rbasak, ack, thanks in advance :)
[11:28] <rbasak> Note: src:rrdtool is in main, as well as some binary packages, so isn't quite correct to say "rrdtool, not in main"
[11:28] <rbasak> kanashiro: ^
[11:30] <kanashiro> rbasak, ok, I'll check this out and fix the comment
[11:55] <santa_> vorlon: good morning. if you have some time I would like to ask you a few questions about network-manager packaging
[11:59] <kanashiro> rbasak, FWIW the rrdtool MP should be fixed now
[12:07] <kanashiro> rbasak, we also have an autopkgtest failure in slurm-llnl due to rrdtool proposed update, could you please trigger it again since we have this failure only in ppc64?
[12:12] <vicamo> bdmurray: ping
[12:36] <seb128> kanashiro, rbasak, I demoted python3-rrdtool-dbg earlier which was blocking migration because it depends on python3-rrdtool which is universe, I don't know if that's enough to get it migrated but that should help at least
[12:39] <kanashiro> thanks seb128 , I think the problem now is just those autopkgtest failures then (munin in armhf and slurm-llnl in ppc64)
[12:40] <seb128> kanashiro, indeed, looks like it
[12:40] <seb128> kanashiro, those look flaky ones, I did give them a retry
[12:41] <kanashiro> seb128, thanks again :) since I don't have permission yet I need to ask people to do it for me
[12:42] <seb128> np!
[13:20] <rbasak> ogra: I already addressed what you said in the post you replied to, in the second paragraph. It's not a limitation of what we're doing; what you're asking for would be an entirely separate project.
[13:20] <rbasak> (with its own upstream code!)
[13:20] <rbasak> It's not anything certbot can do today.
[13:50] <oSoMoN> seb128, have you had a chance to look at those cargo debdiffs?
[13:51] <seb128> oSoMoN, I didn't since I was unsure if mwhudson comment meant he was looking at it, seems he did not, I'm looking now, thx for the reminder!
[13:52] <oSoMoN> seb128, sorry for the confusion, mw_hudson meant that he had finished packaging the next version of cargo and rustc (which contains the patch I'm trying to SRU), but it's still desirable to have that SRU for timing reasons
[13:53] <seb128> oSoMoN, right, I though he might be sponsoring those fixes while he was at it, wishful thinking :)
[13:55] <ahasenack> Skuggen: hi, do you know if a mysql-8 test result file can contain wildcards, when checking matches?
[13:55] <ahasenack> Skuggen: I have a silly bug in./mysql-test/t/mysqlpump_basic_lz4.test where it outputs the lz4 version and that gets added to the log file, but is not present in the results one
[14:06] <seb128> kanashiro, rbasak, retries worked, rrdtool migrated to focal now
[14:09] <kanashiro> \o/
[14:10] <seb128> oSoMoN, done, they are in the queues
[14:12] <oSoMoN> seb128, thanks!
[14:12] <seb128> oSoMoN, np!
[14:13] <oSoMoN> sil2100, can you please accept the cargo SRUs in {xenial,disco}-proposed ?
[14:14] <Skuggen> ahasenack: Hi. The bug was discussed some time back, but lost track of it, sorry
=== ricab is now known as ricab|lunch
[14:15] <Skuggen> ahasenack: We have a fix for it upstream. The issue is that lz4 has moved some output from stderr to stdout, so the old redirect the test does to hide it no longer works. The fix just fixes the redirect
[14:15] <ahasenack> Skuggen: why not redirect to /dev/null?
[14:15] <ahasenack> or is that what the fix does?
[14:16] <ahasenack> ah, the log file it redirects to is not what is used to compare with the result?
[14:16] <Skuggen> The problem is that it redirects stderr
[14:17] <Skuggen> But the extra output is sent to stdout as of the last lz4 version
[14:17] <ahasenack> I got that
[14:17] <Skuggen> Right, it uses a log file to hide the output (just in case there are some actual problems that need to be investigated later)
[14:17] <ahasenack> I just didn't understand why it was redirected to the lz4 log file
[14:18] <ahasenack> we have a patch to redirect both streams to the log file, but the failure still happens
[14:18] <ahasenack> I'm troubleshooting that now
[14:19] <ahasenack> we do this:   --exec lz4 -V > $LZ4_EXEC_LOG 2>&1
[14:19] <Skuggen> Is that patch somewhere I can look at it?
[14:19] <ahasenack> Skuggen: https://git.launchpad.net/~usd-import-team/ubuntu/+source/mysql-8.0/tree/debian/patches/new_lz4_compat.patch
[14:20] <ahasenack> in 0ubuntu3, and https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lz4 still shows a failure on amd64
[14:22] <Skuggen> Hm, that looks like the same fix we have
[14:23] <Skuggen> That's a different test failing, it seems
[14:24] <Skuggen> main.mysql_client_test
[14:24] <ahasenack> ah, you are right
[14:24] <Skuggen> Which didn't test with the previous try. Could be an unstable test. Could you retry it?
[14:24] <Skuggen> didn't fail*
[14:24] <ahasenack> weird, in arm64 it was the lz4 one
[14:25] <ahasenack> ah, but 8.0.17-ubuntu3
[14:25] <ahasenack> not 8.0.18-ubuntu3
[14:27] <ahasenack> this was retried once already, according to http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/amd64
[14:33] <ahasenack> I'll do a local run see if I get more logs
[14:34] <Skuggen> I see we have some recent fixes to that test (mysql_client_test) to make it more stable, so my guess is that it's that, since it didn't fail with ubuntu2
[14:35] <ahasenack> ok
[14:35] <ahasenack> I'll do one more retry, while I try manually in parallel
[14:36] <Skuggen> Yeah, thanks
[14:37] <Skuggen> Actually, I see that those changes where in 8.0.18 as well, hmm
[14:38] <Skuggen> But if you look at the glibc update on the excuses page, 8.0.18-0ubuntu3 is green
[14:46] <ahasenack> ok
[14:49] <didrocks> doko: golang-1.13 promoted, thanks for subcribing your team.
[14:53] <seb128> didrocks, thx for chassing people down and doing the promotion!
[14:53] <didrocks> yw
[14:59] <ahasenack> Skuggen: passed locally on the first attempt
[14:59] <ahasenack> let's see how the retry goes
=== ricab|lunch is now known as ricab
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
[16:09] <ahasenack> is the excuses report stuck, or just slow? "Generated: 2019.12.03 13:38:28 +0000"
[16:09] <ahasenack> that's about 2h30 ago
[16:13] <vorlon> seb128: the process there is to unconditionally add badtest overrides for all the failing i386 tests, and yearn for a future where this bug in britney's calculation of what tests to run is fixed (this is a longstanding nuisance, made more obvious now by the large number of package removals)
[16:16] <seb128> vorlon, hey, so what's the process ... badtest is limited to ubuntu-release right? it's quite a bottleneck for uploads to be able to get moving
[16:16] <seb128> do we just need to mp and chase down r-t members?
[16:16] <seb128> (Laney is off this week which is a bit unfortunate for us in desktop)
[16:18] <vorlon> seb128: broadly, yes; at the moment I'm batch-overriding all the ones I find in excuses that we should be ignoring
[16:19] <seb128> vorlon, can you add firejail/i386 if you are already editing things?
[16:19] <seb128> I will mp the next ones I cross
[16:23] <vorlon> seb128: yeah, part of the batch of 29 badtests I just added
[16:23] <seb128> vorlon, great, thanks!
[16:24] <vorlon> santa_: 4am is not really my morning; and I am not likely to be the right person for you to ask questions of about network-manager packaging, but go ahead :)
[16:25] <santa_> vorlon: ah, sorry for some reason I tought you were in some european time zone
[16:26] <seb128> vorlon, is http://autopkgtest.ubuntu.com/packages/p/plinth/focal/i386 on your list as well?
[16:26] <vorlon> ahasenack: fwiw after you asked, a new report has appeared, timestamped 16:07:40
[16:27] <vorlon> seb128: yeah, I just added that one too
[16:27] <seb128> thx
[16:28] <santa_> vorlon: the thing is, I have been digging into a couple of VPN DNS leaking bugs of n-m, and you mentioned in one of them in ubuntu we have now n-m using systemd-resolved instead of dnsmasq
[16:28] <ahasenack> vorlon: ah, thanks
[16:28] <vorlon> santa_: sure
[16:29] <ahasenack> Skuggen: all green now: autopkgtest for mysql-8.0/8.0.18-0ubuntu3: amd64: Pass, arm64: Pass, armhf: Always failed, i386: Pass, ppc64el: Always failed, s390x: Always failed
[16:29] <santa_> vorlon: so is there any public explanation of why it was changed?
[16:29] <ahasenack> Skuggen: oh, wait, that's the run for another package, not lz4
[16:30] <santa_> I found an old mail @ ubuntu-devel which just mentions the decision but not the reasons
[16:30] <ahasenack> the lz4 run hasn't updated yet, it's stil from november
[16:30] <santa_> I also tried to find something in the package changelog, but no luck
[16:39] <santa_> https://lists.ubuntu.com/archives/ubuntu-devel/2017-August/039954.html
[16:40] <santa_> ↑ the only interesting mail I could find that mentions systemd-resolved
[16:40] <vorlon> santa_: because resolved is already on the system via systemd; we had evaluated it for use on server to address various longstanding issues caused by not having a local resolver; that evaluation included determining if it was a suitable replacement for dnsmasq on the desktop so that desktop and server would be using the same implementation
[16:43] <santa_> vorlon: hmm, do you remember any of this issues? I got hit by one issue with systemd-resolved which doesn't happen in dnsmasq
[16:43] <vorlon> santa_: please file a bug on the systemd package
[16:45] <santa_> that's what I planned to do. it's that it doesn't support AXFR queries
[16:45] <vorlon> ok, I'm not sure what an AXFR has to do with the operations of a local resolver
[16:45] <vorlon> but please file a bug so it can be discussed there
[16:46] <santa_> ack just a couple of things and I'm done:
[16:49] <santa_> is configuring network-manager with dnsmasq still supported? i.e. if I find an VPN DNS leaking bug with that configuration and I provide a patch, would be possible get it into the official package?
[17:17] <santa_> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1854976
[17:17] <ubottu> Launchpad bug 1854976 in systemd (Ubuntu) "systemd-resolved doesn't work with "host -l" / AXFR queries" [Undecided,New]
[17:17] <santa_> vorlon: ↑ and I won't bother you more :P
[17:18] <vorlon> santa_: cheers, I'll flag that for the team to look at
[17:18] <santa_> thanks for your time
[17:18] <vorlon> santa_: regarding your other questions: I don't think configuring network-manager with dnsmasq is still supported, I think we've disabled that plugin for sanity (but I could be wrong).  And VPN DNS leaking bugs are definitely bugs we care about.
[17:20] <santa_> vorlon: it can be configured like that + disable systemd-resolved
[17:21] <vorlon> ok
[17:22] <oSoMoN> sil2100, any chance you can review the cargo uploads in the xenial and disco unapproved queues? sorry if I sound insistent, I'm eager to get those thunderbird SRUs building
[17:27] <sil2100> oSoMoN: ah, sure! Again I seem to have had some notification malfunction
[17:28] <oSoMoN> no worries, I appreciate that you must be getting pinged left and right all the time
[17:30] <sil2100> grrr, LP of course didn't generate a correct diff, at least not against what was in -updates, need to diff manually
[17:31] <oSoMoN> sil2100, yeah, I saw that… the debdiffs are attached to the bug report, if that helps
[17:33] <sil2100> oSoMoN: no, that's fine
[17:33] <sil2100> Although LP times out like crazy right now
[17:50] <oSoMoN> sil2100, thanks!
[19:12] <Skuggen> ahasenack: I think it's green now?
[19:17] <ahasenack> Skuggen: it is!
[19:18] <Skuggen> Maybe need to disable the test and report it upstream (I'll find out if anything more has been done to make it more stable, first)
[19:59] <vorlon> infinity, stgraber, kees: TB meeting? (mdeslaur sent regrets)
[21:23] <seb128> rbalint, hey, do you plan to forward your newpid fix to Debian?