=== andrewc is now known as Guest94335
[06:45] <infinity> stgraber: Why does the lxd 'track' debconf question default to "latest" instead of "3.0"?  I'd think the latter is the behaviour you'd want if people don't know which to select (or install noninteractive).
[06:46] <stgraber> infinity: it does 3.0 when installed on a LTS release of Ubuntu, 3.x otherwise. That matches what we were doing with the LXD releases as debs
[06:46] <infinity> stgraber: Ahh.  Okay.
[06:47] <infinity> stgraber: Except.  What if I install on 19.10 and upgrade to 20.04? :P
[06:48] <infinity> stgraber: Also, neat:
[06:48] <infinity> ==> Running migration from Deb to Snap
[06:48] <infinity> error: The following packages depend on [lxd lxd-client]: juju-2.0
[06:48] <infinity> dpkg: error processing archive /tmp/apt-dpkg-install-0xjWRT/08-lxd_1%3a0.3_all.deb (--unpack):
[06:48] <infinity>  new lxd package pre-installation script subprocess returned error exit status 1
[06:48] <stgraber> I'm starting to seriously consider removing that particular migration check given that it keeps finding deprecated packages on people's systems :)
[06:49] <stgraber> I don't actually know whether the juju-2.0 deb can use the LXD snap so not sure if I should whitelist that particular one or not
[06:50] <infinity> Hrm, I seem to have juju deb and snap installed anyway.
[06:50] <infinity> What a mess
[06:51] <infinity> stgraber: Maybe help them migrate too? :P
[06:51] <stgraber> juju-2.0 deb got removed from the archive in 17.10 I think, so yeah, no idea what that does :)
[06:51] <infinity> stgraber: You're TIL.
[06:51] <infinity> uju-core (2.0.2-0ubuntu2) zesty; urgency=medium
[06:51] <infinity>   * Update debian/tests/setup-lxd.sh to support LXD storage API.
[06:51] <infinity>  -- Stéphane Graber <stgraber@ubuntu.com>  Fri, 17 Feb 2017 00:17:30 -0500
[06:52] <stgraber> oh so 17.04 then, not 17.10
[06:52] <stgraber> IIRC I'm also the one who processed its removal
[06:52] <infinity> stgraber: Right, this is the problem that occurs with deb->snap without migration. :P
[06:52] <infinity> (And I remember arguing at the time that it would leave users dead-ended)
[06:52] <stgraber> yep
[06:53] <stgraber> it's unfortunate that it's the LXD migration noticing that because there are more pleasant ways to handle those kind of things than another package failing in preinst :)
[06:53] <stgraber> it's gonna confuse a bunch of people for sure
[06:53] <stgraber> especially during 18.04 -> 20.04
[06:54] <infinity> stgraber: Purging juju debs and trying again, I now get:
[06:54] <infinity> => Running sanity checks
[06:54] <infinity> error: The source server is running a more recent version than the destination.
[06:54] <infinity> dpkg: error processing archive /var/cache/apt/archives/lxd_1%3a0.3_all.deb (--unpack):
[06:54] <infinity>  new lxd package pre-installation script subprocess returned error exit status 1
[06:54] <stgraber> oh, you selected 3.0?
[06:54] <infinity> I did.
[06:54] <stgraber> I was actually right about to fix that :)
[06:54] <stgraber> one sec
[06:54] <infinity> It was an option .:P
[06:55] <infinity> I can pick the other.  Sec.
[06:55] <stgraber> cosmic has 3.0.2, 3.0 snap has 3.0.1
[06:55] <stgraber> I'm about to promote 3.0.2 to stable
[06:55] <infinity> Ahh.
[06:55] <infinity> Okay.
[06:55] <infinity> Do that.
[06:55] <infinity> I can try again in 10m.
[06:55] <stgraber> done
[06:57] <infinity> Oh, but now I need to refresh it manually, I tihnk.
[06:58] <infinity> There we go.
[06:58] <infinity> stgraber: Better.
[06:58] <infinity> stgraber: But yeah, maybe helping the juju people with proper migration would be nice.
[06:58] <infinity> stgraber: (and maybe getting that SRUed back to bionic too...)
[06:59] <stgraber> yeah, an empty transitional package with a debconf message and no lxd depends would fix that particular issue and maybe un-confuse some users
[06:59] <infinity> stgraber: Something that actually installs the snap would be even better.
[07:14] <stgraber> https://bugs.launchpad.net/juju/+bug/1793074
[07:14] <ubot5> Ubuntu bug 1793074 in juju "Leftover pre-snap Juju causing upgrade issues" [Undecided,New]
[07:21] <cjwatson> (Also bear in mind that some people use juju from the juju team's PPA)
[07:21] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1019.22]
[07:23] <infinity> cjwatson: Wait, they still maintain the deb in a PPA, but not in the archive?
[07:23] <infinity> cjwatson: That's all kinds of special.
[07:32] <infinity> juliank: 91.189.88.149
[07:33] <sil2100> Argh, the langpack instance is hanged
[07:35] <cjwatson> infinity: I think it's disrecommended, I just haven't migrated away yet (no doubt along with many others)
[08:15] <tjaalton> armhf binaries for 389-ds-base, 389-ds-base-dev, 389-ds-base-libs should be removed to let 389-ds-base to migrate.. I missed this arch the last time
[08:18] <apw> stgraber, i selected latest and it ate my machine leaving me with lxd demandind a epoch 0 version and lxd-client demanding a epoch 1 version and not resolving
[08:18] <apw> stgraber, i had to remove lxd to get the installation to complete
[08:30] <stgraber> apw: do you have a log of that apt session?
[08:31] <stgraber> apw: errors from preinst can be pretty confusing, the version mismatch thing is usually an indication that something went wrong in preinst like that juju-2.0 thing that infinity ran into
[08:31] <stgraber> apw: you said the install completed after you removed lxd, did you mean lxd-client?
[08:59] <apw> stgraber, i removed both, and in error purged both, so that didn't do any of my containers any good
[09:00] <apw> i tried to remove just lxd-client and it wouldn't
[09:00] <apw> the primary issue seemed to be related to
[09:00] <apw> error: The following packages depend on [lxd lxd-client]: python3-libertine-lxd
[09:01] <stgraber> apw: ah, python3-libertine-lxd, wtf is that
[09:02] <apw> dunno but it was most unhappy to be removed
[09:02] <stgraber> rmadison can't even find any record of this thing
[09:02] <stgraber> looks like a leftover xenial thing maybe
[09:03] <apw> now that becomes a good question
[09:03] <stgraber> apw: so you tried removing python3-libertine-lxd manually and apt was pretty upset by that too?
[09:03] <apw> yeah i had to remove that, lxd and lxc-client together
[09:03] <apw> which is when i mad a sad a purged
[09:04] <stgraber> hmm, ok, so that may be a bit of a problem... so far everyone that ran into this kind of issue has been able to either use "apt remove --purge -f <whatever>" or "dpkg --purge <whatever>" to clear the package after they've confirmed they don't completely depend on it
[09:06] <stgraber> anyway, I think I'm now of the opinion that our migration code shouldn't do this check when run from within preinst because well, whether it passes or not doesn't matter that much, you need to upgrade anyway
[09:06] <stgraber> so I'll change that check to be non-fatal when it's run inside preinst, it'll still log the packages that may need manual attention but that should fix the actual upgrade failures
[09:11] <stgraber> apw: do you still have anything under /var/lib/lxd post-purge?
[09:12] <stgraber> apw: if you do or if you were using zfs or lvm for your containers, we may still be able to recover them with a bit of work
[09:16] <apw> stgraber, na, looks like you did an awsome job of cleaning up
[09:47] <Odd_Bloke> stgraber: FWIW, juju-2.0 is still produced in the Juju PPA, which I'm using.
[09:50] <stgraber> Odd_Bloke: interesting, anyway, the change I just pushed to the snap (waiting for build + CI still) will turn this into a warning, so won't break upgrades at least
[09:51] <Odd_Bloke> OK, cool.
[09:51] <Odd_Bloke> I just removed Juju. :p
[11:35] <slangasek> mfo: why does the new libuv1 fail its autopkgtest on armhf?
[11:35] <mfo> slangasek, hi. thanks for the libuv1 upload. would you mind triggering a nodejs rebuild for s390x on cosmic-proposed, so it picks up the libuv1 change and passes the FTBFS/test-case failure?  the other archs shouldn't need rebuilds, since this is a runtime-only change, but up to you.
[11:35] <mfo> slangasek, nice timing :)
[11:35] <mfo> slangasek, i'll check, one sec.
[11:36] <slangasek> mfo: nodejs/s390x retrying
[11:36] <mfo> slangasek, thanks.
[11:49] <mfo> slangasek, the libuv1 autopkgtest failures in armhf are errors in uv_{tcp,udp}_bind() (non-zero return status). looking at libuv/src/unix/{fs,tcp,udp}.c, it doesn't look like there's any relation between the udp/tcp-bind and the fs realpath calls.   i see you already requested a re-test which failed too, so that's interesting and i'll try to go w/ some emulation here to reproduce it.. but for now, is it possible for you to request the previous version
[11:49] <mfo> (1.22.0-3) to be re-tested? (i.e., trying to confirm whether it's something else in the armhf environment that's causing this between 08-28 and 09-17)
[11:49] <seb128> doko, looking at the summary of changes on https://github.com/libjpeg-turbo/libjpeg-turbo/releases it looks like https://bugs.launchpad.net/ubuntu/+source/libjpeg-turbo/2.0.0-0ubuntu1 should have required a ffe?
[11:49] <ubot5> Error: ubuntu bug 2 not found
[11:50] <seb128> "Overhauled the build system to use CMake on all platforms, and removed the autotools-based build system."
[11:50] <seb128> "Added AVX2 SIMD implementations of the colorspace conversion, chroma downsampling and upsampling, integer quantization and sample conversion, and slow integer DCT/IDCT algorithms."
[11:50] <seb128> looks like non trivial/bugfix changes
[11:56] <ahasenack> hi, do we know who synced tdb with debian today, or yesterday? tdb (1.3.15-4 to 1.3.16-1)
[11:57] <cjwatson> ahasenack: https://launchpad.net/ubuntu/+source/tdb/+publishinghistory does
[11:57] <seb128> ahasenack, I did
[11:57] <cjwatson> (answer: seb128)
[11:58] <ahasenack> cjwatson: it says "archive robot" sponsored it
[11:58] <cjwatson> ahasenack: second entry, not first
[11:58] <cjwatson> the second is the copy from -proposed to release
[11:58] <ahasenack> ah, the deleted one
[11:58] <cjwatson> *the first is the ...
[11:59] <ahasenack> ok, I was afraid it would trigger a rebuild of other packages like samba and sssd, but since it migrated, maybe not
[11:59] <seb128> ahasenack, no reason it would, there are little changes between the versions
[12:00] <seb128> ahasenack, also unsure why desktop owns that one, but if some other team has interest in it I would be happy to hand that one over
[12:00] <ahasenack> I think ldb is the one that retriggers many
[12:01] <seb128> we have no real interaction or knowledge of that one, but it's on our report which is why I updated it
[12:01] <ahasenack> but was there a particular reason to do it after feature freeze?
[12:02] <ahasenack> I'm also not sure why it would be a desktop pkg
[12:03] <seb128> ahasenack, the changes looked like bugfixes only, which is good candidate to get post ff
[12:03] <ahasenack> ok
[12:05] <ahasenack> rhythmbox, pulseaudio, are in the rdepends list, maybe that's why it's desktop
[12:08] <seb128> likely, I'm just unsure we are the ones knowing it best/using it most
[12:14] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]
[13:25] <mfo> slangasek, ping. the armhf emulation is taking forever here, not even past debootstrap yet.  does autopkgtest allow you to request a re-test of the previous version (1.22.0-3) ?  i tried by changing the request URL, but it failed as i dont have access.
[13:30] <ginggs> mfo: i've triggered libuv1/1.22.0-3
[13:32] <mfo> ginggs, thanks!  it takes a while (maybe finish?) to show up in some page, like this one?
[13:32] <mfo> https://autopkgtest.ubuntu.com/packages/libuv1/cosmic/armhf
[13:34] <ginggs> mfo: it's only been running for 2 min 50, should take about 10 min in total to run, then maybe another 10 min or so to appear on that page
[13:35] <mfo> ginggs, ah ok. and i just learned about this running.json file (linked in the main page) i see it there, w/ some logging, cool. thanks again. :)
[13:38] <slangasek> mfo: I've retriggered a test for the release version of libuv1 now
[13:54] <slangasek> ginggs: you can't trigger a test against the release version of a package that way when there's a version in proposed (http://autopkgtest.ubuntu.com/packages/libu/libuv1/cosmic/armhf)
[13:56] <ginggs> slangasek: :o - so how to do it then?
[13:56] <slangasek> ginggs: see my faked-up trigger
[13:56] <mfo> slangasek, thanks!  ok, so the 1.22.0-3 run finished, and the failures are the same between release/proposed. not too bad!  does that impact this upload to -proposed?
[13:57] <slangasek> ginggs: and there may be some changes soon to make it easier to do this
[13:57] <mfo> (failures: search for 'not ok' in the logs)
[13:57] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (bionic-proposed/main) [0.130ubuntu3.3 => 0.130ubuntu3.4] (core)
[13:57] -queuebot:#ubuntu-release- Unapproved: initramfs-tools (xenial-proposed/main) [0.122ubuntu8.12 => 0.122ubuntu8.13] (core)
[13:58] <slangasek> mfo: I will mark this as a badtest to let the package migrate
[13:58] <ginggs> slangasek: thanks, so what made you pick binutils, would glibc have worked too?
[13:58] <mfo> slangasek, ok, great. thank you.
[13:58] <mfo> ginggs, thanks o/
[13:59] <ginggs> mfo: yw! not that i did anything useful
[14:00] <mfo> ginggs, lol, i undertand, but no worries, thanks for being willing to help. that does count, i think :)
[14:01] <slangasek> ginggs: I picked binutils as one that is unlikely to have a version in -proposed at any given time
[14:02] <ginggs> slangasek: ah, ok!
[14:59] <tsimonq2> I should probably mention that before the beta I plan on doing a patch version bump Qt transition, which doesn't break feature freeze but does need a convenience ABI virtual package bump.
[14:59] <tsimonq2> Please voice objections soon if you have them.
[15:13] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)
[15:18] -queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)
[15:19] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [amd64] (bionic-proposed) [4.18.0-8.9~18.04.1]
[15:19] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe-edge [ppc64el] (bionic-proposed) [4.18.0-8.9~18.04.1]
[21:00] -queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.5] (core)
[21:01] -queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.5 => 1.93.6] (core)
[23:02] <mfo> slangasek, hey. when you're back around, could you please review/sponsor another nodejs test-case fail/fix in LP #1793226 ?  following your request on the previous one, I already submitted to Debian (BTS 909151) and included Bug-Debian/Bug-Ubuntu tags in the patch. :)  Thanks again!
[23:02] <ubot5> Launchpad bug 1793226 in node-cloneable-readable (Ubuntu) "'Uncaught TypeError: nextTick is not a function' with node-process-nextick-args 2.0.0" [Undecided,In progress] https://launchpad.net/bugs/1793226