[00:40]  * tsimonq2 wonders why cdimage.ubuntu.com isn't HTTPS
[00:43] <xnox> tsimonq2, $$$$$ most of cdimage.ubuntu.com, is a shop-front for a CDN
[00:43] <tsimonq2> xnox: Ah ok, and the CDN doesn't support HTTPS?
[00:44] <xnox> tsimonq2, well, it breaks things, as one would strain things via cdimage, rather than redirect connect people to the cdn.
[00:44] <tsimonq2> xnox: Ah ok, thanks.
[00:54] <xnox> vim build.... probably somebody did something in the archive
[00:54] <xnox> so we are now down to subversion on arm64 & s390x to be in shape for ruby2.5-only migration
[00:56]  * tsimonq2 wonders why we don't have Ubuntu archive CDNs as wel..
[00:56] <tsimonq2> *well...
[00:58] <xnox> tsimonq2, we have extensive archive mirror network; e.g. in every cloud region out there, more or less.
[00:58] <tsimonq2> xnox: Right, but something like deb.debian.org I mean
[00:59] <xnox> tsimonq2, and archive, is no nearly as much strain as cdimage. cdimage is very large single file.
[00:59] <tsimonq2> xnox: Right
[00:59] <xnox> tsimonq2, i keep pondering to setup deb.debian.org for ubuntu, and check how much it would actually cost to run.
[00:59] <xnox> tsimonq2, debian gets it sponsored to them, for free.
[01:00] <tsimonq2> xnox: If you've been pondering it meaning to do it and it's a reasonable thing to calculate, please, do it, I've been wondering about this for a while now :)
[01:10] <xnox> tsimonq2, storage cost at S3 is ok, looks like $30 a month; push to cloudfront is free; but then it's like $0.085 a GB a month cost.
[01:10] <xnox> download a gig of updates over a month, for a single machine is trivial.
[01:11] <xnox> thus even 10,000 installs hitting cloudfront will cost $850 a month, which is not sustainable.
[01:15] <tsimonq2> Right
[01:16] <tsimonq2> OK
[01:45] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [17.2-35-gf576b2a2-0ubuntu1~16.04.1 => 17.2-35-gf576b2a2-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[02:45] <blackboxsw> bdmurray: thanks for the xenial-verification-failed tag on the SRU bug. Fix is queued for cloud-init
[04:48] -queuebot:#ubuntu-release- New sync: libmanette (bionic-proposed/primary) [0.2.0-1]
[04:58] -queuebot:#ubuntu-release- New sync: materia-gtk-theme (bionic-proposed/primary) [20180110-1]
[05:15] <blackboxsw> tjaalton if you get a chance today, cloud-init 17.2.35 regression fix upload is queued (currently only affects artful). If there is time to get that published to proposed I'll be able to validate the SRU-cherry pick tomorrow morn my time.
[05:16] <blackboxsw> xenial is queued too (but xenial wasn't published to updates yet)
[05:16] <blackboxsw> I've gotta head out for the night, but will look in early tomorrow
[05:58] <slangasek> xnox: a bunch of ruby autopkgtests were failing because ruby-typhoeus was uninstallable (depends ruby-ethon -> libcurl3).  I've uploaded ruby-ethon, so any of those tests are retriable against -proposed once it publishes
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [amd64] (bionic-proposed) [8.5.2-1ubuntu1]
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [armhf] (bionic-proposed) [8.5.2-1ubuntu1]
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [ppc64el] (bionic-proposed) [8.5.2-1ubuntu1]
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [arm64] (bionic-proposed) [8.5.2-1ubuntu1]
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [s390x] (bionic-proposed) [8.5.2-1ubuntu1]
[06:08] -queuebot:#ubuntu-release- New: accepted kopanocore [i386] (bionic-proposed) [8.5.2-1ubuntu1]
[07:56] <slangasek> ok, I think most of the test regressions on update_excuses are now 'interesting' (very few that are going to pass by changing the combination of triggers)
[07:57] <tjaalton> blackboxsw: sure thing
[07:58] <tjaalton> acheronuk: are you handling the remaining mesa tests? kdepim-addons tests take ~4h to timeout.. so retrying needs to be coordinated
[08:00] <slangasek> looks to me that kdepim-addons is going to need something other than a retry
[08:01] <acheronuk> tjaalton slangasek: I have been looking this morning. that kdepim-addons test has been timing out on KDE's own CI autotests since at least beginning of December
[08:01] <tjaalton> quality.
[08:01] <slangasek> tjaalton: also, I've added a skiptest hint for mesa; now it's only blocked on glibc
[08:01] <tjaalton> slangasek: ok
[08:02] <acheronuk> was going to suggest ignoring for now. as I'll have to report it and action may not be quick. even if I ignore it somehow, taht will take time to re-run
[08:02] <acheronuk> *that
[08:03] <slangasek> the autopkgtest runners are pretty idle right now; don't hesitate to throw any tests at them that are needed
[08:06] <acheronuk> I don't see mesa etc in what would migrate in update_output_notest.txt, so are there issues more than just test fails still?
[08:29] -queuebot:#ubuntu-release- Builds: 39 entries have been added, updated or disabled
[09:21] <tjaalton> infinity: looks like glibc tests need updating? see the s390x failure
[09:21] <tjaalton>     /usr/lib/gcc/s390x-linux-gnu/7/include/varargs.h:4:2: error: #error "GCC no longer implements <varargs.h>."
[09:21] <tjaalton>      #error "GCC no longer implements <varargs.h>."
[09:21] <tjaalton>       ^~~~~
[09:21] <tjaalton>     /usr/lib/gcc/s390x-linux-gnu/7/include/varargs.h:5:2: error: #error "Revise your code to use <stdarg.h>."
[09:21] <tjaalton>      #error "Revise your code to use <stdarg.h>."
[09:39] <LocutusOfBorg> apw, slangasek, please update vbox hint "force-badtest virtualbox/5.2.8-dfsg-2"
[09:48] <apw> LocutusOfBorg, britney hasn't even tested that version yet
[09:51] <LocutusOfBorg> but it will fail exactly the same way, I didn't fix it
[09:51] <LocutusOfBorg> I fixed an issue that was throwing a lot of errors during installation
[09:59] <apw> but as it is changed it might fail an altogether new way too, so till we see the log to confirm it is the old way, it isn't safe to change the hint
[10:05] <tseliot> apw: hi, can you approve libnvidia-common-390 (nvidia-graphics-drivers-390), please? It's the only binary that is still in NEW
[10:05] <apw> tseliot, looking
[10:08] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-390 [amd64] (bionic-proposed) [390.25-0ubuntu2]
[10:09] <tjaalton> apw: we need glibc migrated, but the remaining tests don't pass
[10:09] <tjaalton> fpc and glibc itself (on s390x)
[10:10] <tjaalton> packages built against libglvnd in proposed migrate happily because bionic has an old version of it which doesn't pull in the mesa bits
[10:10] <tjaalton> which "breaks" the system
[10:11] <tjaalton> since the updates pull in libegl1
[10:11] <tjaalton> that'll replace the lib from mesa
[10:12] <tseliot> apw: thanks!
[10:13] <tseliot> oh no. apw ^^
[10:14] <tjaalton> the result is no acceleration
[10:14] <tjaalton> there was bug 1714451
[10:14] <ubot5`> bug 1714451 in libglvnd (Ubuntu) "please remove libglvnd from the archive" [Undecided,Invalid] https://launchpad.net/bugs/1714451
[10:15] <tjaalton> and when I noticed it was still open when the migration was about to start, I closed it
[10:15] <tjaalton> didn't think it would bite this way
[10:17] <apw> glibc's own tests not passing on an arch seems pretty worrying
[10:17] <tjaalton> look a few lines up
[10:17] <tjaalton> it's just a buggy test with current gcc
[10:20] <tjaalton> so a tradeoff of a possibly buggy fpc versus crippled desktops is a simple one to me
[10:20] <LocutusOfBorg> apw, http://autopkgtest.ubuntu.com/packages/v/virtualbox/bionic/amd64
[10:31] <apw> tjaalton, i am struggling to even understand the attempt fcp is making at telling me what it thinks is wrong with its tests
[10:32] <tjaalton> apw: yes, so just badtest it
[10:33] <tjaalton> at least for now
[10:33] <tjaalton> I couldn't figure it out either
[10:35] <apw> tjaalton, so i think you miss-read the failure for s390x, that gcc thing is XFAIL for the previos test
[10:35] <apw> tjaalton, backtrace4 and 5 are complaining that the trace is short
[10:36] <tjaalton> indeed, varargs test is skipped anyway
[10:36] <apw> tjaalton, the other two, who can say as they tell you next to nothing, ass-hattery for a test-suite output
[10:37] <apw> the backtrace ones you could argue are not likely to be highly exercised except in debugging
[10:37] <apw> but the other two, i have next to no idea what they are even testing, the names are opaque
[10:45] <tjaalton> right
[11:43] <tjaalton> apw: so, what's the verdict?
[11:54] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.7 => 3.168.8] (ubuntu-desktop, ubuntu-server)
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (artful-proposed) [17.2-35-gf576b2a2-0ubuntu1~17.10.2]
[12:51] <stikonas> xnox: hi. Will Ubuntu 18.04 ship with util-linux 2.31.1?
[12:52] <xnox> stikonas, it is possible. it has not migrated yet. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#util-linux
[12:52] <xnox> i am trying to upgrade it to 2.31.1
[12:53] <tsimonq2> slangasek: topic> aww, you're no fun :P
[12:53] <xnox> stikonas, are you aware of any bugs? or require any outstanding patches?
[12:53] <stikonas> xnox: well, I have one patch: https://github.com/karelzak/util-linux/commit/8175ed3d74adacc895657ded7546cb3c5deeabad
[12:53] <stikonas> this is part of 2.32
[12:54] <xnox> stikonas, that's not in. Please open a bug on launchpad, specify impact / test case / pointer to the patch. And we can review it.
[12:54] <stikonas> there are two more patches that are part of 2.31.1, so hopefully those will be in
[12:54] <stikonas> xnox: ok, will do it
[12:54] <xnox> stikonas, assume, to fill the bug out, as if you'd want to request an LTS SRU.
[12:55] <xnox> stikonas, please note, that I am busy in meetings all next week, so may not get to it, until two weeks time.
[12:55] <stikonas> ok, no problem, it's not urgent
[13:21] <stikonas> ok, I filled in the bug report https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1752876
[13:21] <ubot5`> Ubuntu bug 1752876 in util-linux (Ubuntu) "sfdisk: allow disabling boot flag on MBR partition table" [Undecided,New]
[14:07] <smoser> tjaalton: could you look at the cloud-init sru for xenial also ?
[14:08] <smoser> you did the artful one, we'd like the xenial in -proposed also.
[14:11] <tjaalton> smoser: alright
[14:13] <tjaalton> smoser: so one needs to be rejected then?
[14:16] <smoser> i uploaded 2, the second upload (2 hours later) has the better changes file.
[14:17] <smoser> 'rejected', from the queue, right?
[14:18] <tjaalton> right
[14:19] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.2]
[14:19] <smoser> yeah, reject the first upload.
[14:20] <smoser> where is the udoes the queue just not show the .changes file ?
[14:20] <smoser> https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[14:22] <smoser> oh. funny. no. you just have to click on the package name.  i just assumed the package name would do the same thing as the twisty/expand arrow.
[14:22] -queuebot:#ubuntu-release- New binary: mate-menus [amd64] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:22] -queuebot:#ubuntu-release- New binary: mate-menus [s390x] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:22] -queuebot:#ubuntu-release- New binary: mate-menus [i386] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:23] -queuebot:#ubuntu-release- New binary: mate-menus [ppc64el] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:24] -queuebot:#ubuntu-release- New binary: mate-menus [arm64] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:24] -queuebot:#ubuntu-release- New binary: mate-menus [armhf] (bionic-proposed/universe) [1.20.0-1ubuntu1] (ubuntu-mate, ubuntukylin)
[14:25] <smoser> thank you!
[14:33] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [17.2-35-gf576b2a2-0ubuntu1~16.04.2]
[14:33] <tjaalton> there
[14:39] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (xenial-proposed) [3.168.8]
[15:41] <blackboxsw> excellent thanks tjaalton smoser
[15:44] -queuebot:#ubuntu-release- Unapproved: zfs-linux (artful-proposed/main) [0.6.5.11-1ubuntu3.1 => 0.6.5.11-1ubuntu3.2] (core)
[15:56] -queuebot:#ubuntu-release- New sync: linux-aws (bionic-proposed/primary) [4.4.0-1052.61]
[15:56] -queuebot:#ubuntu-release- New sync: linux-gke (bionic-proposed/primary) [4.4.0-1034.34]
[15:56] -queuebot:#ubuntu-release- New sync: linux-azure (bionic-proposed/primary) [4.13.0-1011.14]
[15:56] -queuebot:#ubuntu-release- New sync: linux-hwe (bionic-proposed/primary) [4.13.0-36.40~16.04.1]
[15:56] -queuebot:#ubuntu-release- New sync: linux-meta-aws (bionic-proposed/primary) [4.4.0.1052.54]
[15:56] -queuebot:#ubuntu-release- New sync: linux-meta-gke (bionic-proposed/primary) [4.4.0.1034.35]
[15:56] -queuebot:#ubuntu-release- New sync: linux-meta-kvm (bionic-proposed/primary) [4.4.0.1019.18]
[15:56] -queuebot:#ubuntu-release- New sync: linux-kvm (bionic-proposed/primary) [4.4.0-1019.24]
[15:56] -queuebot:#ubuntu-release- New sync: linux-meta-hwe (bionic-proposed/primary) [4.13.0.36.55]
[15:56] -queuebot:#ubuntu-release- New sync: linux-meta-azure (bionic-proposed/primary) [4.13.0.1011.12]
[16:10] <fossfreedom> are we in the middle of transition graphics at the moment in bionic?  both of our ISO builds failed today with a " libgl1-mesa-glx : Conflicts: libgl1"
[16:29] <acheronuk> fossfreedom: same with kubuntu's
[16:31] <acheronuk> tjaalton: fallout from the current mesa/everything? ^^
[16:40] <dpb1> tjaalton: is it appropriate to revert? https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1752481
[16:40] <ubot5`> Ubuntu bug 1752481 in snapcraft (Ubuntu) "Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35)" [Critical,In progress]
[16:47] <tjaalton> acheronuk: yes
[16:47] <tjaalton> dpb1: i'll check
[16:50] <slangasek> tjaalton: do you know what's going on with images failing to build today due to libgl1-mesa-glx Conflicts: libgl1?  Is that something already fixed in -proposed that needs migrating?
[16:52] <slangasek> tjaalton: sorry, I see this was the discussion immediately above. :P  anyway, what do I need to do to help fix it?  Get mesa migratable?
[16:52] <tjaalton> slangasek: yes, the problem is that bionic had an old libglvnd which provides packages for libgl1/libegl1
[16:53] <slangasek> ok
[16:53] <tjaalton> and packages that were built in proposed migrated because that version was good enough for them
[16:55] <tjaalton> i did file a removal bug last august, but it was still there when the migration began, so I closed it and couldn't imagine this would've still been possible...
[16:56] <tjaalton> anyway, glibc made some tests unhappy (including it's own on s390x)
[16:56] <slangasek> yeah, I know
[16:57] <tjaalton> the deps on libegl1/libgl1 also break acceleration on upgrade..
[16:58] <tjaalton> and login to wayland isn't possible
[16:58] <tjaalton> because of that
[16:59] <tjaalton> so, make glibc green/yellow asap ;)
[17:03] <tjaalton> +please
[17:03] <slangasek> yes, but that needs analysis of the test failures on s390x
[17:03] <slangasek> xnox: ^^
[17:07] <tjaalton> hmm, didn't think of pinging him, we had a look at them with apw
[17:13] <blackboxsw> plumpcow
[17:13] <Laney> yummy
[17:13] <blackboxsw> hah!
[17:14] <blackboxsw> #ENOSUCHLOGIN
[17:16] <blackboxsw> slangasek:  I'm adding the verification logs right now to the outstanding SRU regression fix for cloud-init. Just wondering about process for a known user-data affecting SRU regression cherrypick. Does it wait in pending-sru for 7 days or does it publish to updates faster
[17:17] <slangasek> blackboxsw: it publishes faster if you talk to the SRU team and remind us to pay attention that it's ready
[17:17] <slangasek> blackboxsw: certainly for targeted fixes for regressions, we don't make them age
[17:17] <blackboxsw> excellent slangasek, will ping shortly. nearly done w/ verification thanks
[17:20] <slangasek> LocutusOfBorg: vbox hint updated
[17:25] <LocutusOfBorg> <3
[17:25] <LocutusOfBorg> oops it wasn't needed anymore btw, I fixed dkms
[17:25] <LocutusOfBorg> it will be needed again once the linux folks update their vbox driver
[17:26] -queuebot:#ubuntu-release- New binary: libmstoolkit [s390x] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:27] -queuebot:#ubuntu-release- New binary: libmstoolkit [ppc64el] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: libmstoolkit [amd64] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:29] -queuebot:#ubuntu-release- New binary: libmstoolkit [i386] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:32] -queuebot:#ubuntu-release- New binary: libmstoolkit [arm64] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:36] -queuebot:#ubuntu-release- New binary: libmstoolkit [armhf] (bionic-proposed/universe) [82-4ubuntu1] (no packageset)
[17:36] <slangasek> alright, glibc is now hinted; thanks to everyone who helped sorting through the autopkgtests
[17:39] <tjaalton> \o/
[17:40] <slangasek> and adding a 'hint' hint, because update-output is being inscrutable
[17:44] <slangasek> worked out by chance that libhybris also still needed a no-change upload, so done
[17:58] <blackboxsw> slangasek: thanks for looking and the cherry pick fix. Just appended all verification logs and updated all necessary cloud-init SRU tags on bug #1752711 and bug #1747059.
[17:58] <ubot5`> bug 1752711 in cloud-init (Ubuntu Artful) "cloud-init no longer processes user data on GCE in artful" [Critical,Fix committed] https://launchpad.net/bugs/1752711
[17:58] <ubot5`> bug 1747059 in cloud-init (Ubuntu Xenial) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2-35-gf576b2a2-0ubuntu1~16.04.1" [Medium,Fix committed] https://launchpad.net/bugs/1747059
[17:59] <blackboxsw> on 1752711 I also added lxd and ec2 integration logs even though the code path changed is strictly limited to GCE datasource only so lxd and ec2 can't even touch this path.
[18:00]  * tsimonq2 will kick qt* this afternoon, hopefully hard enough to make it migrate
[18:01] <tjaalton> dpb1: I'm not sure what is asked of the SRU team there
[18:03] -queuebot:#ubuntu-release- New binary: gst-plugins-good1.0 [armhf] (bionic-proposed/main) [1.13.1-1ubuntu1] (desktop-core, ubuntu-server)
[18:12] <nacc> tjaalton: dpb1: i think we'd need to upload a 2.39.3+is+really+2.35 or something
[18:13] <tjaalton> ah, probably
[18:15] <Laney> slangasek: tried the hint tester: https://paste.ubuntu.com/p/jdJq7Kk8wH/ - looks like bro needs a rebuild, not sure why it got those upper bounds
[18:15] <Laney> no time to do it myself, so heads up for you
[18:15] <Laney> see you
[18:17] <ScottE> slangasek: Thanks for looking at bug #1752722 - we can validate the fix pretty quickly once it's released or in -proposed
[18:17] <ubot5`> bug 1752722 in systemd (Ubuntu Bionic) "systemd 237 reports incorrect state when drop-in present" [High,Triaged] https://launchpad.net/bugs/1752722
[18:18] <xnox> imho, we should not ship libhybris anymore slangasek https://bugs.launchpad.net/ubuntu/+source/libhybris/+bug/1752953
[18:18] <ubot5`> Ubuntu bug 1752953 in libhybris (Ubuntu) "RM: obsolete product" [Undecided,Triaged]
[18:18] <Laney> actually I can do it, my test build finished faster than expected
[18:19] <Laney> done & see you for realz
[18:25] <slangasek> Laney: "hint tester"?
[18:26] <slangasek> ScottE: great, I've got that bug on our list to sort
[18:28] -queuebot:#ubuntu-release- Unapproved: aptdaemon (artful-proposed/main) [1.1.1+bzr982-0ubuntu17 => 1.1.1+bzr982-0ubuntu17.1] (ubuntu-desktop)
[18:35] <slangasek> Laney: I thought you had no time to do the upload :)
[18:35] <slangasek> Laney: ah, you said.  anyway, thanks :)
[18:39] <slangasek> blackboxsw: so AIUI this was a regression in artful; but in xenial it wasn't, because 17.2-35-gf576b2a2-0ubuntu1~16.04.1 did not get released to -updates yet
[18:39] <slangasek> blackboxsw: is that correct?
[18:39] <slangasek> blackboxsw: if it is, I would not release the xenial SRU today (on a Friday, right before everyone travels) without another compelling reason
[18:41] <smoser> slangasek: you are correct.
[18:42] <slangasek> ok
[18:42] <smoser> and i agree with delaying the SRU release. leave it in -proposed and move it on monday is fine.
[18:42] <smoser> for xenial
[18:42] -queuebot:#ubuntu-release- New binary: mutter [s390x] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[18:43] <xnox> ScottE, are there any other systemd cherry-picks / SRUs that you are expecting, for systemd, e.g. on xenial? at one point it was mentioned to me on telegram, but alas, not much in further details?
[18:44] -queuebot:#ubuntu-release- New binary: mutter [ppc64el] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[18:48] -queuebot:#ubuntu-release- New binary: mutter [amd64] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[18:48] -queuebot:#ubuntu-release- New binary: mutter [i386] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[18:52] -queuebot:#ubuntu-release- New binary: mutter [arm64] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[18:58] -queuebot:#ubuntu-release- New binary: mutter [armhf] (bionic-proposed/main) [3.27.91-1] (desktop-extra, ubuntu-desktop)
[19:09] <ddstreet> slangasek if you have time, you feel like approving dpkg upload in trusty?  it's in queue, uploaded by infinity
[19:09] <ScottE> xnox: I don't think so, but I'll double check
[19:22] <infinity> tjaalton: That has nothing to do with the failure, and is meant to happen.
[19:24] <tjaalton> infinity: right, misread the output.. those were skipped anyway
[19:24] <nacc> dpb1: tjaalton: I'm testing that now (via a side PPA) and will update the bug if so
[19:24] <ScottE> xnox: The only other systemd bug I'm aware of that affects xenial is bug #1651278 - we applied a local workaround via drop-ins
[19:24] <ubot5`> bug 1651278 in systemd (Ubuntu) "systemd-sysv-generator does not fully translate facilities to targets" [Undecided,Confirmed] https://launchpad.net/bugs/1651278
[19:26] <nacc> slangasek: for an SRU regression that's already released, where the fix is to go back to the version that was in xenial-updates before the most recent update, do I need to keep the broken version in the changelog? Or can I go back to the old version, insert a changelog entry like <new-version>+really+is+<old-version> (so that it goes later than it to apt) ?
[19:27] <infinity> Anyone have context on the ruby-prof regression?
[19:27] <infinity> slangasek: ^?
[19:29] <infinity> slangasek: I'm badtesting glibc/s390x, the 4 regressed tests are only in the 31-bit library, and only under certain conditions (note the same tests pass during the build).  I'm not through trying to bisect the how and the why, but I also don't think a few cancel/backtrace tests in a not-really-supported biarch build should hold things up.
[19:30] <infinity> slangasek: Oh, you already skiptested.  Nevermind, then.
[19:39] <slangasek> infinity: yeah, the ruby-prof regression was "passed with ruby-defaults in -proposed, then migrated, then newly-failed with -proposed glibc + release ruby-defaults" :P
[19:39] <infinity> slangasek: Neat.
[19:39] <slangasek> infinity: oh. these were the bits that you referenced as being 31-bit only?
[19:39] <slangasek> infinity: had I realized that I think we would've short-circuited that investigation a bit sooner :)
[19:40] <infinity> slangasek: Yes.  If you read the log more carefully, you'll notice the testsuite failing is the "s390" target.  Thousands of lines up, the native testsuite passes fine.
[19:40] <slangasek> nacc: no requirement that the SRU fix keep the broken version in the changelog; only requirement is that the versions increase
[19:40] <slangasek> infinity: ack
[19:40] <infinity> slangasek: Probably a bit too early for upstream bugs too, but there they are now.  So will follow up there.
[19:41] <slangasek> ddstreet: I will try to find time to do some SRU processing today, but mostly today is focused on unblocking bionic-proposed wrt feature freeze
[19:41] <infinity> slangasek: It's quite likely it's not glibc or the kernel immediately at fault, but rather the switch from gcc-6 to gcc-7, though it's clear the kernel is also involved.
[19:41] <ddstreet> slangasek ack, of course, thnx
[19:44] <slangasek> dannf: grub2 uploads in the SRU queue> which queue do you mean? I don't see any in {trusty,xenial,artful}-proposed unapproved queue
[19:44] <dannf> slangasek: xenial - i see them here: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
[19:45]  * slangasek reads more closely
[19:45] <slangasek> dannf: found and rejected, thanks
[19:45] <dannf> slangasek: cool, thx
[19:46] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (xenial-proposed) [1.66.18]
[19:46] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
[19:46] <nacc> slangasek: ack, thanks
[19:56] <slangasek> ok, glibc 2.27 has cleared
[19:56] <slangasek> and that includes mesa
[19:56] <nacc> nice
[19:57] <tjaalton> *phew*
[19:58] <slangasek> why in the world does an upload of citadel trigger an sbuild autopkgtest?
[19:59] <slangasek> because mail-transport-agent
[19:59] <tjaalton> wait, did libglvnd migrate too?
[19:59]  * slangasek looks askance at this logic
[19:59] <acheronuk> cleared = migrate?
[19:59] <slangasek> tjaalton: libglvnd is still stuck because of nvidia-graphics-drivers-390
[19:59] <slangasek> acheronuk: yes
[19:59] <tjaalton> ugh
[19:59] <acheronuk> :D
[19:59] <acheronuk> oh
[20:00] <slangasek> tjaalton: but this may be a simple component-mismatch; looking
[20:00] <slangasek> tjaalton: nope, it's an unsatisfiable dep because libnvidia-{en,de}code-390 don't exist on armhf
[20:00] <tjaalton> ...
[20:01] <slangasek> I'll upload the fix
[20:01] <tjaalton> thanks
[20:01] <tjaalton> tseliot left
[20:01] <slangasek> sensible of him
[20:01] <slangasek> :)
[20:01] <tjaalton> yeah  :)
[20:02] <blackboxsw> slangasek: sorry was at lunch. Correct Xenial never published because mid-point-release and then rejected prior to publish. Just artful published. no rush on xenial fix
[20:02] <blackboxsw> so an artful publish to fix is excellent and we can sort xenial cloud-init next week
[20:12] <tsimonq2> slangasek: What's a nice color for queued tests in excuses? I like a darker blue. (Let's not bikeshed albeit it's somewhat important in the implementation of bug 1654761).
[20:12] <ubot5`> bug 1654761 in Auto Package Testing "Use another status for retried but queued items" [Undecided,Confirmed] https://launchpad.net/bugs/1654761
[20:13]  * tsimonq2 wonders if there's a standard for this, somewhere...
[20:14] <slangasek> tsimonq2: why would it be a different color than what we already use for 'in progress'?  E.g. we already use the same shade for states IGNORED-FAIL and ALWAYSFAIL
[20:15] <tsimonq2> slangasek: Good point, let's just do it that way.
[20:15] <slangasek> tsimonq2: and I think a certain amount of bikeshedding about both the colors and the text is called for here fwiw
[20:15] <slangasek> the UX of that page is generally terrible, but the UX is still important :)
[20:16] <tsimonq2> Right :)
[20:17] <tsimonq2> I've prioritized this fix so expect a fix within a week or less, it's a PITA to not have...
[20:17] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.12 => 4.2.4-7ubuntu12.13] (core)
[20:18] <tsimonq2> (Sometimes duplicate tests won't be queued if we know they aren't in the queue, so this fix should come before bug 1686929.)
[20:18] <ubot5`> bug 1686929 in Auto Package Testing "Duplicate tests can be queued" [Undecided,Confirmed] https://launchpad.net/bugs/1686929
[20:18] <tsimonq2> s/aren't/are/
[20:19] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (xenial-proposed/main) [4.3.3-5ubuntu12.9 => 4.3.3-5ubuntu12.10] (core)
[20:20] <tsimonq2> As a side note for that bug, I think it's a good idea to have an override to do duplicate tests justincase but it shouldn't be default. Does anyone oppose?
[20:21] -queuebot:#ubuntu-release- Unapproved: isc-dhcp (artful-proposed/main) [4.3.5-3ubuntu2.2 => 4.3.5-3ubuntu2.3] (core)
[20:24] <tsimonq2> Soooo the bug reports live at b.lp.net/auto-package-testing which also has a code repo but that bzr repo shows as deprecated in favor of a git repo which also shows as deprecated in favor of lp:autopkgtest-cloud which is a git repo whose corresponding LP bug tracker isn't set up. I can figure that out, but it's hella weird (unless ofc there's a reason I'm not seeing)...
[20:26] <tsimonq2> slangasek, Laney ^^^
[20:35] <slangasek> tsimonq2: it's valuable to have auto-package-testing as a high-level project name for bug reporting; I'm not sure a good way to "reroute" https://code.launchpad.net/auto-package-testing to autopkgtest-cloud
[20:35] <slangasek> I suppose we could move lp:autopkgtest-cloud to lp:auto-package-testing, maybe
[20:35] <tsimonq2> That'd be a good idea imho
[20:43] <tsimonq2> slangasek: Also, why does ~ubuntu-archive own lp:britney but ~ubuntu-release owns Ubuntu's britney2 code? Shouldn't ~ubuntu-release own both?
[20:46] <slangasek> it's possible ubuntu-archive should own both
[20:46] <slangasek> because it's code that acts with privileges on the archive
[20:47] <tsimonq2> Right, but we're talking proposed migration, which imho Release Team territory
[20:47] <tsimonq2> s/imho/imho is/
[20:49] <tsimonq2> Yes it gives priviledges, but only to a codebase that just seems to touch proposed migration, not things like upload queues or package removals
[20:55] <slangasek> tsimonq2: decisions about what to copy are a release team operation.  The privileges with which the code operates to apply those copies are an archive admin acl.
[20:57] <tsimonq2> slangasek: Correct, but if the decisions on what to copy still lie with the Release Team, and if this group is trusted with those specific rights only indirectly via this tooling, I can see now ~ubuntu-release should still have access
[20:58] <tsimonq2> s/now/hoe
[20:58] <tsimonq2> grr
[20:58] <tsimonq2> s/now/how/
[20:58] <tsimonq2> that ^
[21:00] <tsimonq2> *shrug* I'm not a member of either, so not my decision, just my two cents
[21:39] <blackboxsw> slangasek: thanks for the publish for cloud-init. just validated fix is published and works on GCE/artful
[21:46] <slangasek> only 1200 autopkgtest regressions reported now... less than half of what was showing yesterday morning.  Nice
[21:50] <slangasek> stgraber: were you still working on the lx* autopkgtest blockers?
[21:50] <stgraber> slangasek: yeah, I'm looking at them. I uploaded something that should unblock go-lxc and am looking at the lxcfs failure on s390x (seems to have been around for a while) and on why lxc is hitting timeouts now on all arches
[21:50] <slangasek> ok
[22:00] -queuebot:#ubuntu-release- Unapproved: nplan (artful-proposed/main) [0.32~17.10.2 => 0.32~17.10.3] (core)
[22:00] <acheronuk> slangasek: hi. could you look at removing libkolab from bionic please?
[22:01] <acheronuk> https://bugs.launchpad.net/ubuntu/+source/libkolab/+bug/1752998
[22:01] <ubot5`> Ubuntu bug 1752998 in libkolab (Ubuntu) "Please remove libkolab from bionic 18.04" [Undecided,New]
[22:02] <slangasek> acheronuk: reverse-depends tells me this will make the kdepim-runtime package uninstallable; do we need kdepim-runtime to migrate first?
[22:02] <stgraber> ah, the lxcfs s390x failure is funny, we've seen that on ppc64el before, basically the minimum amount of memory a process requires to get spawned on s390x is much greater than on other arches :)
[22:02] <stgraber> will add a similar hack as ppc64el then
[22:02] <acheronuk> slangasek: that will block KDE PIM migration if it stays, and new PIM obsoletes it
[22:03] <slangasek> acheronuk: how does it block?
[22:04] <slangasek> really wonder why someone made redis buildable again on i386
[22:04] <acheronuk> slangasek: it depends on libkf5calendarutils5 libkf5mime5abi1 from PIM 17.08
[22:05] <acheronuk> The following packages will be REMOVED:
[22:05] <acheronuk>   libkf5calendarutils5 libkf5mime5abi1 libkolab1
[22:05] <acheronuk> and libkolab becomes uninstallable
[22:05] <slangasek> acheronuk: ok; ideally we would do the removal once kdepim-runtime is a candidate
[22:06] <slangasek> to minimize the number of uninstallables in the release pocket
[22:06] -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.3 => 0.32~16.04.4] (no packageset)
[22:07] <acheronuk> slangasek: yes. you are right. sorry. end of a long day, and not thinking clearly
[22:08] <jbicha> slangasek: your nvidia upload didn't work :(
[22:08] <slangasek> nacc: php7.2 7.2.2-1ubuntu2 blocked by kopanocore tests, claims that php-mapi is uninstallable (?)
[22:08] <slangasek> acheronuk: no worries
[22:08] <slangasek> jbicha: oh?
[22:09] <jbicha> I didn't look closely. I just see it still depends on stuff on armhf
[22:09] <slangasek> hmm
[22:09] <nacc> slangasek: i will take a look in amoment
[22:09] <slangasek> jbicha: debian/control.in <shakes fist>
[22:09] <slangasek> jbicha: hmm, no, not on this branch. <digs further>
[22:21] <slangasek> r-base is going to be complicated vs. curl
[22:22] <slangasek> under the circumstances I'm going to force nvidia-graphics-drivers-390 as-is and fix up armhf after
[22:26] <slangasek> and found the hidden control.in that was to blame
[22:27] <tsimonq2> slangasek: Huh, what's up with Britney promoting before the publisher finishes?
[22:27] <slangasek> tsimonq2: how do you mean?
[22:28] <acheronuk> [18:15] <infinity> Badness with britney promotions racing the publisher, actually
[22:28] <tsimonq2> slangasek: It seems mesa et al binaries became available after metadata was updated, failing some qtbase rdep autopkgtests
[22:29] <tsimonq2> (is "at al." proper or "et al"? *shrug*)
[22:29] <tsimonq2> s/at/et/
[22:29] <slangasek> 'et al.'
[22:31] <acheronuk> the period is important
[22:31] <slangasek> as for updates, britney and the publisher are both constantly running; britney should in general only be using the published archive as its source of information about things
[22:31] <slangasek> anything else should probably be considered a bug
[22:33] <nacc> slangasek: hrm, weird, chdist says it's fine
[22:33] <tsimonq2> slangasek: et al.>cool, thanks
[22:34] <acheronuk> had it the other day on an image build. failed as things were migrtating
[22:34] <acheronuk> tsimonq2: lubuntu I think?
[22:34] <nacc> slangasek: i'm testing the dep8 itself now (in proposed)
[22:35] <tsimonq2> acheronuk: prolly, yeah
[22:35] <slangasek> nacc: sorry, I triggered a retry the same time I posted, it's already passing again ;)
[22:36] <tsimonq2> acheronuk: If you can hunt down logs (for justification), feel free to assign a bug to me
[22:36] <nacc> slangasek: ok good!
[22:36] <acheronuk> ok
[22:41] <nacc> slangasek: ok, talked to kyrofa and we ahve agreed to revert snapcraft with the version i suggested earlier ... can we get that pushed through (we've got a bug tracking the regressions) if uploaded?
[22:41] <slangasek> nacc: yah
[22:41] <nacc> slangasek: LP: #1752481 for context
[22:41] <ubot5`> Launchpad bug 1752481 in snapcraft (Ubuntu) "Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35)" [Critical,In progress] https://launchpad.net/bugs/1752481
[22:41] <nacc> slangasek: thanks
[22:42] <nacc> slangasek: do you have an example changelog verbage for such a regression update?
[22:43] <slangasek> nacc: not to hand :)
[22:43] <nacc> slangasek: np, i can make something up :)
[22:47] <nacc> slangasek: version should be '2.39.3+is+really+2.35' iiuc?
[22:47] <nacc> (where 2.39.3 is what is currently in x-p/x-u and 2.35 is the version we're going back to)
[22:52] <cjwatson> 2.39.3+really2.35 would be a bit more usual
[23:01]  * slangasek stabs r-cran-curl in the bits
[23:03] <slangasek> nvidia-390 through the gauntlet
[23:05] <nacc> cjwatson: ack, i can do that instead
[23:08] <dx> hi! is it too late in the 18.04 cycle to request removal of an unstable/insecure package imported from debian?
[23:08] <dx> if not, what do i file bugs against?
[23:08] <nacc> dx: against the source pacakge
[23:08] <slangasek> dx: no; the process is to file a bug against the package and subscribe the ubuntu-archive team
[23:08] <dx> thank you
[23:09] <slangasek> dx: if you care to mention here what the package is, we can also discuss
[23:10] <dx> sure. it's "xchat", see this post by the hexchat dev: https://tingping.github.io/2018/03/02/when-distros-get-it-wrong.html
[23:11] <dx> (my plan was to fuzz it for 5 minutes to have some concrete evidence that it's insecure)
[23:12] <slangasek> dx: that would be useful; a much stronger statement than "it's insecure, believe us", given that /most/ software has undisclosed vulnerabilities
[23:13] -queuebot:#ubuntu-release- Unapproved: snapcraft (xenial-proposed/universe) [2.39.3 => 2.39.3+really2.35] (no packageset)
[23:13] <nacc> slangasek: --^ fyi
[23:13] <slangasek> statistically speaking, R is indistinguishable from nodejs