[02:04] <jbicha> I think I'm going to need help with LP: #1718085 tomorrow (or at least this week)
[02:05] <jbicha> apologies for not doing it sooner, my excuse is that agreeing on a name (even an apparently simple one) is hard
[04:06] <infinity> jbicha: Can I bikeshed that name? :P
[04:08] <jbicha> sure but it might not change the name ;)
[04:25] <Ukikie> Speaking of, did anyone look into how notification-daemon slipped into every ISO?
[04:36] <slangasek> ... no?  which ISO are you expecting it to not be in?
[04:45] <Ukikie> slangasek: Xubuntu, Ubuntustudio, Lubuntu and likely Kubuntu, Ubuntu MATE.  The former ship xfce4-notifyd which provides notification-daemon (expected, same as the last many releases) and I presume KDE and MATE provide something as well.
[05:20] <slangasek> cyphermox: nplan autopkgtests regressed again?
[07:06] <LocutusOfBorg> doko, I want to see if the llvm fixes are all in debian, I already have a merge ready for the python change (llvm 3.9) http://launchpadlibrarian.net/337517278/llvm-toolchain-3.9_1%3A3.9.1-13ubuntu7_1%3A3.9.1-16.diff.gz I couldn't find references in changelog for the FUZZER change, maybe not needed anymore
[07:06]  * LocutusOfBorg good morning btw
[07:06] <LocutusOfBorg> also ldc should be fixed now
[07:06] <LocutusOfBorg> will appear in some minutes in new queue
[07:16] -queuebot:#ubuntu-release- New binary: ldc [amd64] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
[07:17] -queuebot:#ubuntu-release- New binary: ldc [ppc64el] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
[07:22] -queuebot:#ubuntu-release- New binary: ldc [i386] (artful-proposed/universe) [1:1.4.0-1ubuntu1] (no packageset)
[09:04] <LocutusOfBorg> doko, stuff seems to build better with the new ldc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper/+build/13392398
[09:04] <LocutusOfBorg> what is your opinion? it is FTBFS on armhf, but at least if we remove binaries there we can finish the transition
[10:06] <xnox> bdmurray, i believe i have fixed up templates on all the sru bugs =/
[10:21] <doko> LocutusOfBorg: you could do a test build for powerpc on trusty and xenial to see if it is still needed
[10:22] <LocutusOfBorg> doko, context please?
[10:22] <LocutusOfBorg> llvm?
[10:22] <doko> well, that's what you asked?
[10:23] <LocutusOfBorg> yep, I was wondering about ldc, the second question
[10:23] <LocutusOfBorg> actually that FUZZER variable was tested but never defined
[10:23] <doko> better keep armhf and fix it for th next release
[10:24] <LocutusOfBorg> so, in each case, the sync -f has not changed the status quo
[10:24] <LocutusOfBorg> for armhf, I pushed an llvm 5.0 that might fix it
[10:25] <LocutusOfBorg> -opt_flags = -g -O2
[10:25] <LocutusOfBorg> +opt_flags = -g1 -O2
[10:25] <LocutusOfBorg> +ifneq (,$(filter $(DEB_HOST_ARCH),arm64 ppc64el))
[10:25] <LocutusOfBorg> +  opt_flags = -g1 -O2
[10:25] <LocutusOfBorg> +endif
[10:25] <LocutusOfBorg> maybe you didn't want to change opt_flags regardless of the architecture?
[10:25] <LocutusOfBorg> otherwise the if test would have been useless
[10:27] <doko> why? did you find out what caused the explosion of the debug symbol size?
[10:29] <apw> that is an odd if, it has the same value both ways
[10:30] <apw> LocutusOfBorg, ^
[10:30] <LocutusOfBorg> ^^ that one, the first line
[10:30] <apw> as in you reverted the first line
[10:30] <apw> of that existing diff ?
[10:31] <LocutusOfBorg> AFAIK the explosion of debug symbol size has been a thing in arm64 and ppc64el
[10:31] <LocutusOfBorg> so, using -g1 only there should be the exact thing to do
[10:31] <LocutusOfBorg> the above is the diff between the current ubuntu and the current debian
[10:32] <LocutusOfBorg> (me, discard the latest sentence)
[10:32] <LocutusOfBorg> the current debian is "good"
[10:32]  * LocutusOfBorg wrt the if statement
[10:33] <LocutusOfBorg> http://launchpadlibrarian.net/337530714/llvm-toolchain-5.0_1%3A5.0-1ubuntu2_1%3A5.0-2~build1.diff.gz
[10:33] <doko> no, you are wrong, it' see for s390x as well, even for debian. so please don't speculate
[10:33] <LocutusOfBorg> look at the above diff for 5.0
[10:34] <LocutusOfBorg> it is enabled in +ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el s390x))
[10:36] <doko> well, you just said: "the explosion of debug symbol size has been a thing in arm64 and ppc64el"
[10:36] <doko> which is wrong
[10:37] <LocutusOfBorg> you are right, sorry! I was meaning "for a subset of the whole architecture list", and now debian has that list embedded into the rules file
[11:26] <sergiusens> slangasek any update on the armhf network errors?
[13:32] <cyphermox> slangasek: it's possible, but I did run it twice on amd64 before uploading, and both passed no problem. admittedly not against proposed, because proposed was otherwise broken atm (python xml). I'll have a look, given that it passes without proposed, it ought to be a fairly simple debugging session
[13:41] <jbicha> sil2100: does this look ok? https://code.launchpad.net/~jbicha/ubuntu-cdimage/drop-ubuntu-gnome-artful/+merge/330983
[14:10] <acheronuk> Ukikie: seems notification-daemon is on the Kubuntu iso also. trying to work out how to evict it!
[14:15] <cjwatson> acheronuk: I think it will work if you explicitly seed plasma-workspace in kubuntu.artful/desktop rather than relying on it being pulled in via dependencies.
[14:16] <cjwatson> acheronuk: At the moment, germinate hasn't yet worked out that plasma-workspace is going to be pulled into desktop at the point when it's resolving dependencies (well, Recommends) of libnotify4 while expanding desktop-common, so it picks the real package rather than realising that the Kubuntu-ish replacement is wanted.
[14:17] <acheronuk> cjwatson: yeah, I'm just weaving my way through those depends and recommends
[14:21] <acheronuk> lets try that then. see what germinate things on the next iso build
[14:21] <acheronuk> *thinks
[14:21] <sil2100> jbicha: commented on it
[14:26] <cjwatson> acheronuk: The important bit is explicitly seeding things that you want to be picked instead of the default.
[14:29] <acheronuk> cjwatson: indeed. thanks for pointing that out. saved me some time puzzling.....
[14:33] <cjwatson> I'm not entirely sure what the problem is in the Xubuntu case.  xfce4-notifyd in core should suffice.
[14:42] <rbasak> slangasek: could you accept the python-certbot-nginx binNEW for Xenial please?
[14:54] <cyphermox> slangasek: I re-ran the nplan autopkgtests, currently waiting in the queue. the failure looked like something about the infra though -- as if the tests had been run on the host somehow, and the modules/directories were not cleaned up afterwards -- mac80211_hwsim should never be on any system to begin with, unless it ran the tests and exploded midway :)
[14:56] <ogra_> cyphermox, did you see my comment regarding the console-setup udev rule ?
[14:56] <cyphermox> ogra_: I did
[14:56] <ogra_> good
[14:56] <ogra_> someone should at least test if it doesnt break initrd input ... (not sure if it does or does not, but we used to install the rule there)
[15:00] <cyphermox> well, if it did, it's still being in the way now. I'm sure there is a better way to handle this
[15:00] <cyphermox> that said, my current thought is why the hell did things need to start using tty1 for graphical, and why can't wayland handle the input correctly anyway?
[15:05] <Laney> it does handle it correctly?
[15:06] <Laney> Xorg has the same problem - you can't change the console mode underneath it
[15:07] <slangasek> rbasak: done
[15:07] <slangasek> cyphermox: ok cool
[15:07] <cyphermox> Laney: things were working fine under X
[15:07] <Laney> no, they worked fine under lightdm/Unity because it was on tty7
[15:07] <Laney> start an X session from GDM and reproduce this bug
[15:07] -queuebot:#ubuntu-release- New: accepted python-certbot-nginx [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
[15:07] <Laney> it happens there too
[15:07] <cyphermox> partly because things were running on tty7, but I would wager it was also jigling the console modes differently
[15:08] <Laney> No
[15:08] <Laney> It's K_OFF, and then when you get K_UNICODE it breaks
[15:08] <cyphermox> I can't begin to explain why you'd see your password in clear text on the screen when it crashes then.
[15:08] <Laney> That does explain why you see that
[15:08] <cyphermox> and that^ makes me very scared on it
[15:09] <rbasak> slangasek: thanks!
[15:09] <Laney> ...don't switch the keyboard mode...
[15:09] <cyphermox> Laney: not the right place to discuss this in any case.
[15:09] <Laney> k
[15:10] <cyphermox> slangasek: any idea what that issue with nplan might have been?
[15:10] <slangasek> cyphermox: nope!
[15:11] <cyphermox> yipee.\
[15:23] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu20]
[15:24] <Laney> cyphermox: did you try to reproduce this locally?
[15:24] <Laney>   File "/tmp/autopkgtest.OH8cTq/build.rJx/nplan-0.28/tests/integration.py", line 104, in create_devices
[15:24] <Laney>     raise SystemError('mac80211_hwsim module already loaded')
[15:24] <Laney> SystemError: mac80211_hwsim module already loaded
[15:24] <cyphermox> of course I did, it works locally when not using -proposed (because there was another issue with python xml yesterday)
[15:25] <cyphermox> this is specifically the kind of failure you see if the test previously ran but was killed before the end
[15:25] <cyphermox> (ie. cleanup didn't run)
[15:25] <Laney> that paste was from my machine
[15:26] <cyphermox> why would this happen though?
[15:26] <cyphermox> did you use lxc as the runner or qemu?
[15:26] <Laney> qemu
[15:26] <cyphermox> err
[15:27] <cyphermox> with proposed?
[15:27] <Laney> nplan from proposed
[15:27] <cyphermox> --apt-pocket=proposed or not?
[15:27] <Laney> no
[15:27] <Laney> proposed=src:nplan
[15:27] <cyphermox> because I had nplan build locally, in that qemu.
[15:28] <cyphermox> ie. autopkgtest -U -s . -- qemu ~u/adt-artful-amd64-cloud.img
[15:28] <Laney> autopkgtest.u.c doesn't do it like that
[15:28] <cyphermox> I know that
[15:29] <Laney> ok
[15:29] <cyphermox> but it's the closest I can emulate  "netplan from proposed" without uploading it to proposed.
[15:30] <cyphermox> furthermore, that has always worked fine until now; so I had no reason to do otherwise.
[15:32] <jbicha> sil2100: I resubmitted the cdimage change (not sure if it sent you an email or not)
[15:32] <Laney> if you want the actual package from proposed, then --apt-pocket=proposed=src:nplan is the way to ask for that
[15:33] <Laney> you can see the autopkgtest invocation used near the top of the logs; that helps when reproducing failures
[15:34] <cyphermox> Laney: that's fine once something is in proposed
[15:35] <Laney> this broken nplan is?
[15:35] <cyphermox> my point was, I tested this locally before uploading, and the autopkgtests were passing with no issues, so I have no idea why it would fail in the infra.
[15:37] <Laney> ok, well I came in where there was a claim that the infrastructure was broken and a retry was issued - at that point it was possible to reproduce the same failure without needing local packages
[15:37] <cyphermox> I can't reproduce the failure here.
[15:37] <cyphermox> http://paste.ubuntu.com/25573075/
[15:37] <cyphermox> this is admittedly *not* the same command as you provided, but it *is* the same package being used (it's logged as nplan 0.28)
[15:38] <cyphermox> I'm not claiming that the infra is broken, just trying to figure out where something is different so I know why it works here, but doesn't work in autopkgtests.ubuntu.com
[15:38] <cyphermox> or why it fails for you
[15:39] <cyphermox> ugh, that paste is incomplete
[15:40] <cyphermox> this here is complete: http://paste.ubuntu.com/25573084/
[15:42] <slangasek> sergiusens: I've done some quick smoketests and hammering the DNS server from inside with lookups in a loop was not enough to trigger the problem. :/ I'll go ahead and badtest snapcraft/armhf now to let it through, and continue tugging at that problem
[15:42] <slangasek> sergiusens: oh, or somebody already did let it through which is also good
[15:43] <slangasek> (but didn't badtest it, which is bad)
[15:44] <slangasek> (badtest added)
[15:51] <Laney> cyphermox: sorry, team meeting --- here's three commands which failed in the same way for me https://paste.ubuntu.com/25573149/, not sure if that's helpful
[15:52] <Laney> it's also a fresh image built 30 minutes ago or so
[15:56] <apw> slangasek, how would they have let it through without a badtest/skiptest
[15:56] <cyphermox> Laney: ta. I have an idea, perhaps I know what this is
[16:12] <slangasek> apw: because proposed-migration remains completely advisory for SRUs; we need to change sru-release to write hints instead of doing copy-package in order to change this
[16:12] <apw> slangasek, derp in a stable release, of course
[17:49] <jbicha> slangasek: please update your badtest for (artful) flapak/ppc64el and add s390x (since it's NBS on s390x), also please update the badtest for ostree (L_aney's hint file)
[18:15] <doko> glibc is now only stopped by the libhardware/libhybris stack
[18:23] <slangasek> jbicha: fixing the autopkgtest failure is something any Ubuntu dev has access to do; updating the hint is something only the release team can do; why not fixing the flatpak/ppc64el test failure instead?
[18:23] <slangasek> and why did flatpak 0.8.7-5 run tests on s390x if there are no binaries :P
[18:26] <sergiusens> slangasek thanks, I wasn't even aware it went through! We can certainly look into it live next week and get some proper data to pin point the problem
[18:27] <slangasek> sergiusens: yeah... it's confusing, as I said I have seen more lookup failures on armhf than elsewhere, but they've seemed pretty infrequent - not enough for me to expect snapcraft to fail continuously
[18:30] <jbicha> flatpak only passed 4 times in its history on ppc64el on Ubuntu so it seems more likely that some change in the infrastructure helped it pass
[18:47] <Ukikie> acheronuk: Yeah it looks like a regression somewhere as the package is everywhere, even when an acceptable alternative is seeded.
[19:58] <slangasek> infinity, xnox: were either of you still working the libhybris dep chain?
[20:10] <ahasenack> hi, for some reason ubuntu-advantage-tools v8 is in artful/universe instead of main (https://launchpad.net/ubuntu/+source/ubuntu-advantage-tools), could someone "push" it over to main, like it is in all other ubuntu releases before AA?
[20:12] <ahasenack> I don't know what happened there, also why it is showing "published 3h ago" when it built back in Aug 22nd
[20:14] <slangasek> ahasenack: it's in universe instead of main because we haven't yet seeded it in ubuntu-minimal
[20:14] <slangasek> someone probably demoted it as a component-mismatch
[20:15] <slangasek> (which was not wrong; it's on me for not having seeded it before now)
[20:18] <doko> slangasek: please could you skip the autopkg tests for python3-defaults? the queue gets large. I see the the ones for build-essential are almost done, and the ones for python-defaults aretriggerring almost the same packages as python3-defaults
[20:18] <doko> so autopkg tests for universe packages can catch up
[20:19] <xnox> slangasek, why would you want to work on the libhybris dep chain?
[20:23] <slangasek> xnox: it's still blocking glibc.  Is there an agreed path forward?  Is someone working on resolving this?
[20:23] <xnox> slangasek, i do not see it blocking glibc
[20:24] <xnox> slangasek, just need to wait for britney to migrate it, as far as i can tell.
[20:24] <xnox> slangasek, publisher is slow
[20:24] <slangasek> xnox: did you look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ?
[20:24] <xnox> yes
[20:24] <xnox> slangasek, did you look at https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu26 ?
[20:25] <slangasek> heh
[20:25]  * xnox likes to call & raise
[20:26] <slangasek> xnox: you didn't close LP: #1718030 in the changelog :)
[20:27] <xnox> slangasek, it's not like it would have made a different until after the package migrates....
[20:27] <doko> slangasek, ahasenack: sorry, yes I demoted it
[20:28] <slangasek> xnox: are you sure I'm not scraping changes emails for bug references?
[20:28] <slangasek> ;)
[20:28] <slangasek> xnox: thanks for the fix
[20:28] <xnox> slangasek, if you were scrapping changes emails, you would have noticed that i uploaded libhybris ;-)
[20:29] <slangasek> xnox: not if I was filtering for bugs I care about!
[20:29] <slangasek> it's plausible
[20:30] <xnox> deniability
[20:30] <xnox> anyway. publisher is so slow
[20:30] <slangasek> publisher, or britney?
[20:31] <slangasek> publisher says it's published.  britney doesn't show it moving
[20:31] <xnox> it's not yet even in rmadison output
[20:31] <slangasek> rmadison is post-publisher
[20:31] -queuebot:#ubuntu-release- Unapproved: cockpit (zesty-backports/universe) [148-1~ubuntu17.04.1 => 150-2git1~ubuntu17.04.1] (no packageset)
[20:32] <xnox> ... and the builds finished building 1h ago, hence i blame publisher for the delays
[20:32] <slangasek> doko: I only see long 'huge' queues of autopkgtests, not regular queues.  It's fine for these autopkgtests to run as low-priority jobs, unless there are things queued behind these in the 'huge' queue that you care about?
[20:32] <xnox> britney doesn't notice things until they are in rmadison. Maybe imprecise timing, but that is my perception from how things look to me.
[20:32] -queuebot:#ubuntu-release- Unapproved: cockpit (xenial-backports/universe) [148-1~ubuntu16.04.1 => 150-2git1~ubuntu16.04.1] (no packageset)
[20:33] <slangasek> doko: also, dumping the tests is different than letting python3-defaults through before the tests are done; is the latter what you care about?
[20:33] <xnox> doko, do you need that package to start archive rebuild or something?
[20:33] <doko> slangasek: sure, fine. please lower the priority and enjoy yourself looking at the logs ;p
[20:33] <slangasek> xnox: britney talks to ftpmaster.internal directly.  rmadison data is generated from ftpmaster.internal.
[20:34] <doko> xnox: I've given up on that. will do the tst rebuild with -proposed enabled :/
[20:34] <slangasek> doko: they are already in the low-priority queue
[20:34] <xnox> doko, or is that the fix for parsing that debian file?
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (xenial-backports) [150-2git1~ubuntu16.04.1]
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (zesty-backports) [150-2git1~ubuntu17.04.1]
[20:34] <doko> xnox: no, it's just a version bump
[20:34] <xnox> doko, yeah anything that triggers more than a few tests automatically ends up in a different queue in the autopkgtests.
[20:35] <xnox> it's round robin across ubuntu, ppas, upstream, and "things that triggered a lot of tests". To not starve "small" upgrades, by the "large ones".
[20:35] <xnox> but i think it does not do round-robin across releases
[20:35] <slangasek> I think it is
[20:35] <xnox> thus one has to wait for xenial to be drained before artful is tested.
[20:35] <xnox> hm, ok.
[20:37] <slangasek> doko: I'm not opposed to doing something here to expedite.  what I'm asking is that we be clear about what we're doing, and the rationale.  Clearing the autopkgtest queues doesn't make python3-defaults migrate any faster; adding a skiptest hint for python3-defaults would make it migrate faster
[20:38] <doko> slangasek: well, it's not that these autopkg tests would catch anything which is not already in the release pocket
[20:39] <slangasek> doko: ok, but what is it that you are trying to accomplish? "empty autopkgtest queues" is not a goal that gets me out of bed
[20:39] <slangasek> is something that you care about blocked / slow?
[20:39] <xnox> slangasek, hm so new publisher run does not start until after a britney run finishes? i would have thought that is decoupled.
[20:39] <xnox> slangasek, such that things in -proposed can publish multiple times whilst britney is running
[20:40] <doko> lol, 1pm in bed?
[20:40] <xnox> shhh
[20:40] <slangasek> xnox: they are decoupled.  I was only saying that if you want to know when britney will see it, looking in rmadison has false-negatives
[20:40] <slangasek> doko: a saying
[20:40] <doko> slangasek: britney runs are currently slow, for whatever reason
[20:41] <slangasek> yes.  maybe they're slow because they're trying to check a lot of autopkgtest results
[20:42] <xnox> slangasek, so a run 20 minutes ago, did not notice libhybris that finished 1h ago and published 57 minutes ago?
[20:42] <xnox> although it may be a lie that it published 57 minutes ago, could have been just the source publication
[20:42] <slangasek> xnox: the 'generated' timestamp is near the end of the britney run, not the start, fwiw
[20:43] <xnox> looking at the current running log at http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-19/20:20:05.log
[20:43] <xnox> britney run that "started" 20 minutes ago
[20:49] <slangasek> xnox: right, new update_excuses up and still no libhybris; I'll dig if time allows, but I have a call in 10 minutes
[20:51] <xnox> slangasek, and now that that britney is done, new libhybris appeared in rmadison, and i suspect next run of britney will have the new libhybris.
[20:51] <xnox> it does feel like britney locks and block ftpmaster.internal
[20:52] <slangasek> it doesn't
[21:13] <xnox> migrating \o/
[21:18] <doko> wonders still happen
[21:20] <slangasek> uh
[21:20] <slangasek> arpack++ now shows up as a regression under glibc, where did that come from?
[21:20] <slangasek> skiptested, so not fatal, but
[21:21] <slangasek> oh, because it passed for the first time with new openblas, so it's a retroactive regression ;P
[21:57] <doko> now finally clang demoted to universe. we really should take more care about auto promotions to main
[22:17] <infinity> xnox: \o/
[23:11] <tsimonq2> Release team: I'd like to do a change to gdebi that's all in one upload. One change (that I've already made locally) fixes a bug that Ubuntu MATE was having, the other thing that I would like to do is port away from the obsolete, insecure framework kdesudo and instead use kdesu for gdebi-kde. kdesudo has already been removed in Debian because it's KDE 3 and hasn't been touched upstream since
[23:11] <tsimonq2> 2011. Can I JFDI or do you want me to file a bug for the FFe for the kdesudo port?
[23:11] <tsimonq2> I just don't know if it deserves an FFe.
[23:12] <tsimonq2> I'd consider it a bugfix in the sense that kdesu is generally more secure and has less bugs, but a feature in the sense that it's porting to a new framework.
[23:12] <tsimonq2> Thoughts?
[23:18] <nacc> if someone from the release team could review the FFE at LP: #1658469, I'd appreciate it.
[23:28] <tsimonq2> (actually, might work better as separate gdebi upload, let's get that out of the way)
[23:28] <tsimonq2> (bugfix)
[23:46] -queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [150-2git1~ubuntu16.04.1] (no packageset)