[02:04] I think I'm going to need help with LP: #1718085 tomorrow (or at least this week) [02:04] Launchpad bug 1718085 in ubuntu-gnome-meta (Ubuntu) "FFe: Transition to ubuntu-desktop and provide vanilla-gnome-desktop" [Undecided,New] https://launchpad.net/bugs/1718085 [02:05] apologies for not doing it sooner, my excuse is that agreeing on a name (even an apparently simple one) is hard [04:06] jbicha: Can I bikeshed that name? :P [04:08] sure but it might not change the name ;) [04:25] Speaking of, did anyone look into how notification-daemon slipped into every ISO? [04:36] ... no? which ISO are you expecting it to not be in? [04:45] 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] cyphermox: nplan autopkgtests regressed again? [07:06] 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] also ldc should be fixed now [07:06] 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) === Guest19724 is now known as RAOF [09:04] doko, stuff seems to build better with the new ldc https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/debhelper/+build/13392398 [09:04] what is your opinion? it is FTBFS on armhf, but at least if we remove binaries there we can finish the transition [10:06] bdmurray, i believe i have fixed up templates on all the sru bugs =/ [10:21] LocutusOfBorg: you could do a test build for powerpc on trusty and xenial to see if it is still needed [10:22] doko, context please? [10:22] llvm? [10:22] well, that's what you asked? [10:23] yep, I was wondering about ldc, the second question [10:23] actually that FUZZER variable was tested but never defined [10:23] better keep armhf and fix it for th next release [10:24] so, in each case, the sync -f has not changed the status quo [10:24] for armhf, I pushed an llvm 5.0 that might fix it [10:25] -opt_flags = -g -O2 [10:25] +opt_flags = -g1 -O2 [10:25] +ifneq (,$(filter $(DEB_HOST_ARCH),arm64 ppc64el)) [10:25] + opt_flags = -g1 -O2 [10:25] +endif [10:25] maybe you didn't want to change opt_flags regardless of the architecture? [10:25] otherwise the if test would have been useless [10:27] why? did you find out what caused the explosion of the debug symbol size? [10:29] that is an odd if, it has the same value both ways [10:30] LocutusOfBorg, ^ [10:30] ^^ that one, the first line [10:30] as in you reverted the first line [10:30] of that existing diff ? [10:31] AFAIK the explosion of debug symbol size has been a thing in arm64 and ppc64el [10:31] so, using -g1 only there should be the exact thing to do [10:31] the above is the diff between the current ubuntu and the current debian [10:32] (me, discard the latest sentence) [10:32] the current debian is "good" [10:32] * LocutusOfBorg wrt the if statement [10:33] http://launchpadlibrarian.net/337530714/llvm-toolchain-5.0_1%3A5.0-1ubuntu2_1%3A5.0-2~build1.diff.gz [10:33] no, you are wrong, it' see for s390x as well, even for debian. so please don't speculate [10:33] look at the above diff for 5.0 [10:34] it is enabled in +ifneq (,$(filter $(DEB_HOST_ARCH),amd64 arm64 ppc64el s390x)) [10:36] well, you just said: "the explosion of debug symbol size has been a thing in arm64 and ppc64el" [10:36] which is wrong [10:37] 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] slangasek any update on the armhf network errors? [13:32] 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] sil2100: does this look ok? https://code.launchpad.net/~jbicha/ubuntu-cdimage/drop-ubuntu-gnome-artful/+merge/330983 [14:10] Ukikie: seems notification-daemon is on the Kubuntu iso also. trying to work out how to evict it! [14:15] 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] 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] cjwatson: yeah, I'm just weaving my way through those depends and recommends [14:21] lets try that then. see what germinate things on the next iso build [14:21] *thinks [14:21] jbicha: commented on it [14:26] acheronuk: The important bit is explicitly seeding things that you want to be picked instead of the default. [14:29] cjwatson: indeed. thanks for pointing that out. saved me some time puzzling..... [14:33] I'm not entirely sure what the problem is in the Xubuntu case. xfce4-notifyd in core should suffice. [14:42] slangasek: could you accept the python-certbot-nginx binNEW for Xenial please? [14:54] 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] cyphermox, did you see my comment regarding the console-setup udev rule ? [14:56] ogra_: I did [14:56] good [14:56] 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] 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] 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] it does handle it correctly? [15:06] Xorg has the same problem - you can't change the console mode underneath it [15:07] rbasak: done [15:07] cyphermox: ok cool [15:07] Laney: things were working fine under X [15:07] no, they worked fine under lightdm/Unity because it was on tty7 [15:07] 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] it happens there too [15:07] partly because things were running on tty7, but I would wager it was also jigling the console modes differently [15:08] No [15:08] It's K_OFF, and then when you get K_UNICODE it breaks [15:08] I can't begin to explain why you'd see your password in clear text on the screen when it crashes then. [15:08] That does explain why you see that [15:08] and that^ makes me very scared on it [15:09] slangasek: thanks! [15:09] ...don't switch the keyboard mode... [15:09] Laney: not the right place to discuss this in any case. [15:09] k [15:10] slangasek: any idea what that issue with nplan might have been? [15:10] cyphermox: nope! [15:11] yipee.\ [15:23] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu20] [15:24] cyphermox: did you try to reproduce this locally? [15:24] File "/tmp/autopkgtest.OH8cTq/build.rJx/nplan-0.28/tests/integration.py", line 104, in create_devices [15:24] raise SystemError('mac80211_hwsim module already loaded') [15:24] SystemError: mac80211_hwsim module already loaded [15:24] of course I did, it works locally when not using -proposed (because there was another issue with python xml yesterday) [15:25] this is specifically the kind of failure you see if the test previously ran but was killed before the end [15:25] (ie. cleanup didn't run) [15:25] that paste was from my machine [15:26] why would this happen though? [15:26] did you use lxc as the runner or qemu? [15:26] qemu [15:26] err [15:27] with proposed? [15:27] nplan from proposed [15:27] --apt-pocket=proposed or not? [15:27] no [15:27] proposed=src:nplan [15:27] because I had nplan build locally, in that qemu. [15:28] ie. autopkgtest -U -s . -- qemu ~u/adt-artful-amd64-cloud.img [15:28] autopkgtest.u.c doesn't do it like that [15:28] I know that [15:29] ok [15:29] but it's the closest I can emulate "netplan from proposed" without uploading it to proposed. [15:30] furthermore, that has always worked fine until now; so I had no reason to do otherwise. [15:32] sil2100: I resubmitted the cdimage change (not sure if it sent you an email or not) [15:32] if you want the actual package from proposed, then --apt-pocket=proposed=src:nplan is the way to ask for that [15:33] you can see the autopkgtest invocation used near the top of the logs; that helps when reproducing failures [15:34] Laney: that's fine once something is in proposed [15:35] this broken nplan is? [15:35] 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] 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] I can't reproduce the failure here. [15:37] http://paste.ubuntu.com/25573075/ [15:37] 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] 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] or why it fails for you [15:39] ugh, that paste is incomplete [15:40] this here is complete: http://paste.ubuntu.com/25573084/ [15:42] 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] sergiusens: oh, or somebody already did let it through which is also good [15:43] (but didn't badtest it, which is bad) [15:44] (badtest added) [15:51] 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] it's also a fresh image built 30 minutes ago or so [15:56] slangasek, how would they have let it through without a badtest/skiptest [15:56] Laney: ta. I have an idea, perhaps I know what this is [16:12] 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] slangasek, derp in a stable release, of course [17:49] 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] glibc is now only stopped by the libhardware/libhybris stack [18:23] 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] and why did flatpak 0.8.7-5 run tests on s390x if there are no binaries :P [18:26] 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] 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] 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] acheronuk: Yeah it looks like a regression somewhere as the package is everywhere, even when an acceptable alternative is seeded. [19:58] infinity, xnox: were either of you still working the libhybris dep chain? [20:10] 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] I don't know what happened there, also why it is showing "published 3h ago" when it built back in Aug 22nd [20:14] ahasenack: it's in universe instead of main because we haven't yet seeded it in ubuntu-minimal [20:14] someone probably demoted it as a component-mismatch [20:15] (which was not wrong; it's on me for not having seeded it before now) [20:18] 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] so autopkg tests for universe packages can catch up [20:19] slangasek, why would you want to work on the libhybris dep chain? [20:23] xnox: it's still blocking glibc. Is there an agreed path forward? Is someone working on resolving this? [20:23] slangasek, i do not see it blocking glibc [20:24] slangasek, just need to wait for britney to migrate it, as far as i can tell. [20:24] slangasek, publisher is slow [20:24] xnox: did you look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt ? [20:24] yes [20:24] slangasek, did you look at https://launchpad.net/ubuntu/+source/libhybris/0.1.0+git20151016+6d424c9-0ubuntu26 ? [20:25] heh [20:25] * xnox likes to call & raise [20:26] xnox: you didn't close LP: #1718030 in the changelog :) [20:26] Launchpad bug 1718030 in libhybris (Ubuntu) "libhybris fails to build with glibc 2.26" [Undecided,New] https://launchpad.net/bugs/1718030 [20:27] slangasek, it's not like it would have made a different until after the package migrates.... [20:27] slangasek, ahasenack: sorry, yes I demoted it [20:28] xnox: are you sure I'm not scraping changes emails for bug references? [20:28] ;) [20:28] xnox: thanks for the fix [20:28] slangasek, if you were scrapping changes emails, you would have noticed that i uploaded libhybris ;-) [20:29] xnox: not if I was filtering for bugs I care about! [20:29] it's plausible [20:30] deniability [20:30] anyway. publisher is so slow [20:30] publisher, or britney? [20:31] publisher says it's published. britney doesn't show it moving [20:31] it's not yet even in rmadison output [20:31] 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] ... and the builds finished building 1h ago, hence i blame publisher for the delays [20:32] 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] 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] 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] doko, do you need that package to start archive rebuild or something? [20:33] slangasek: sure, fine. please lower the priority and enjoy yourself looking at the logs ;p [20:33] xnox: britney talks to ftpmaster.internal directly. rmadison data is generated from ftpmaster.internal. [20:34] xnox: I've given up on that. will do the tst rebuild with -proposed enabled :/ [20:34] doko: they are already in the low-priority queue [20:34] 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] xnox: no, it's just a version bump [20:34] doko, yeah anything that triggers more than a few tests automatically ends up in a different queue in the autopkgtests. [20:35] 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] but i think it does not do round-robin across releases [20:35] I think it is [20:35] thus one has to wait for xenial to be drained before artful is tested. [20:35] hm, ok. [20:37] 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] slangasek: well, it's not that these autopkg tests would catch anything which is not already in the release pocket [20:39] 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] is something that you care about blocked / slow? [20:39] slangasek, hm so new publisher run does not start until after a britney run finishes? i would have thought that is decoupled. [20:39] slangasek, such that things in -proposed can publish multiple times whilst britney is running [20:40] lol, 1pm in bed? [20:40] shhh [20:40] 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] doko: a saying [20:40] slangasek: britney runs are currently slow, for whatever reason [20:41] yes. maybe they're slow because they're trying to check a lot of autopkgtest results [20:42] slangasek, so a run 20 minutes ago, did not notice libhybris that finished 1h ago and published 57 minutes ago? [20:42] although it may be a lie that it published 57 minutes ago, could have been just the source publication [20:42] xnox: the 'generated' timestamp is near the end of the britney run, not the start, fwiw [20:43] 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] britney run that "started" 20 minutes ago [20:49] 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] 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] it does feel like britney locks and block ftpmaster.internal [20:52] it doesn't [21:13] migrating \o/ [21:18] wonders still happen [21:20] uh [21:20] arpack++ now shows up as a regression under glibc, where did that come from? [21:20] skiptested, so not fatal, but [21:21] oh, because it passed for the first time with new openblas, so it's a retroactive regression ;P [21:57] now finally clang demoted to universe. we really should take more care about auto promotions to main [22:17] xnox: \o/ [23:11] 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] 2011. Can I JFDI or do you want me to file a bug for the FFe for the kdesudo port? [23:11] I just don't know if it deserves an FFe. [23:12] 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] Thoughts? [23:18] if someone from the release team could review the FFE at LP: #1658469, I'd appreciate it. [23:18] Launchpad bug 1658469 in apache2 (Ubuntu) "[FFe] mod_http2 is not available in Apache" [Low,Triaged] https://launchpad.net/bugs/1658469 [23:28] (actually, might work better as separate gdebi upload, let's get that out of the way) [23:28] (bugfix) [23:46] -queuebot:#ubuntu-release- New binary: cockpit [amd64] (xenial-backports/universe) [150-2git1~ubuntu16.04.1] (no packageset)