/srv/irclogs.ubuntu.com/2018/09/18/#ubuntu-release.txt

=== andrewc is now known as Guest94335
infinitystgraber: 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:45
stgraberinfinity: 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 debs06:46
infinitystgraber: Ahh.  Okay.06:46
infinitystgraber: Except.  What if I install on 19.10 and upgrade to 20.04? :P06:47
infinitystgraber: Also, neat:06:48
infinity==> Running migration from Deb to Snap06:48
infinityerror: The following packages depend on [lxd lxd-client]: juju-2.006:48
infinitydpkg: 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 106:48
stgraberI'm starting to seriously consider removing that particular migration check given that it keeps finding deprecated packages on people's systems :)06:48
stgraberI 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 not06:49
infinityHrm, I seem to have juju deb and snap installed anyway.06:50
infinityWhat a mess06:50
infinitystgraber: Maybe help them migrate too? :P06:51
stgraberjuju-2.0 deb got removed from the archive in 17.10 I think, so yeah, no idea what that does :)06:51
infinitystgraber: You're TIL.06:51
infinityuju-core (2.0.2-0ubuntu2) zesty; urgency=medium06: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 -050006:51
stgraberoh so 17.04 then, not 17.1006:52
stgraberIIRC I'm also the one who processed its removal06:52
infinitystgraber: Right, this is the problem that occurs with deb->snap without migration. :P06:52
infinity(And I remember arguing at the time that it would leave users dead-ended)06:52
stgraberyep06:52
stgraberit'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
stgraberit's gonna confuse a bunch of people for sure06:53
stgraberespecially during 18.04 -> 20.0406:53
infinitystgraber: Purging juju debs and trying again, I now get:06:54
infinity=> Running sanity checks06:54
infinityerror: The source server is running a more recent version than the destination.06:54
infinitydpkg: 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 106:54
stgraberoh, you selected 3.0?06:54
infinityI did.06:54
stgraberI was actually right about to fix that :)06:54
stgraberone sec06:54
infinityIt was an option .:P06:54
infinityI can pick the other.  Sec.06:55
stgrabercosmic has 3.0.2, 3.0 snap has 3.0.106:55
stgraberI'm about to promote 3.0.2 to stable06:55
infinityAhh.06:55
infinityOkay.06:55
infinityDo that.06:55
infinityI can try again in 10m.06:55
stgraberdone06:55
infinityOh, but now I need to refresh it manually, I tihnk.06:57
infinityThere we go.06:58
infinitystgraber: Better.06:58
infinitystgraber: But yeah, maybe helping the juju people with proper migration would be nice.06:58
infinitystgraber: (and maybe getting that SRUed back to bionic too...)06:58
stgraberyeah, an empty transitional package with a debconf message and no lxd depends would fix that particular issue and maybe un-confuse some users06:59
infinitystgraber: Something that actually installs the snap would be even better.06:59
stgraberhttps://bugs.launchpad.net/juju/+bug/179307407:14
ubot5Ubuntu bug 1793074 in juju "Leftover pre-snap Juju causing upgrade issues" [Undecided,New]07:14
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:21
infinitycjwatson: Wait, they still maintain the deb in a PPA, but not in the archive?07:23
infinitycjwatson: That's all kinds of special.07:23
infinityjuliank: 91.189.88.14907:32
sil2100Argh, the langpack instance is hanged07:33
cjwatsoninfinity: I think it's disrecommended, I just haven't migrated away yet (no doubt along with many others)07:35
tjaaltonarmhf 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 time08:15
apwstgraber, 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 resolving08:18
apwstgraber, i had to remove lxd to get the installation to complete08:18
stgraberapw: do you have a log of that apt session?08:30
stgraberapw: 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 into08:31
stgraberapw: you said the install completed after you removed lxd, did you mean lxd-client?08:31
apwstgraber, i removed both, and in error purged both, so that didn't do any of my containers any good08:59
apwi tried to remove just lxd-client and it wouldn't09:00
apwthe primary issue seemed to be related to09:00
apwerror: The following packages depend on [lxd lxd-client]: python3-libertine-lxd09:00
stgraberapw: ah, python3-libertine-lxd, wtf is that09:01
apwdunno but it was most unhappy to be removed09:02
stgraberrmadison can't even find any record of this thing09:02
stgraberlooks like a leftover xenial thing maybe09:02
apwnow that becomes a good question09:03
stgraberapw: so you tried removing python3-libertine-lxd manually and apt was pretty upset by that too?09:03
apwyeah i had to remove that, lxd and lxc-client together09:03
apwwhich is when i mad a sad a purged09:03
stgraberhmm, 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 it09:04
stgraberanyway, 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 anyway09:06
stgraberso 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 failures09:06
stgraberapw: do you still have anything under /var/lib/lxd post-purge?09:11
stgraberapw: 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 work09:12
apwstgraber, na, looks like you did an awsome job of cleaning up09:16
Odd_Blokestgraber: FWIW, juju-2.0 is still produced in the Juju PPA, which I'm using.09:47
stgraberOdd_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 least09:50
Odd_BlokeOK, cool.09:51
Odd_BlokeI just removed Juju. :p09:51
slangasekmfo: why does the new libuv1 fail its autopkgtest on armhf?11:35
mfoslangasek, 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
mfoslangasek, nice timing :)11:35
mfoslangasek, i'll check, one sec.11:35
slangasekmfo: nodejs/s390x retrying11:36
mfoslangasek, thanks.11:36
mfoslangasek, 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 version11: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
seb128doko, 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
ubot5Error: ubuntu bug 2 not found11:49
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
seb128looks like non trivial/bugfix changes11:50
ahasenackhi, do we know who synced tdb with debian today, or yesterday? tdb (1.3.15-4 to 1.3.16-1)11:56
cjwatsonahasenack: https://launchpad.net/ubuntu/+source/tdb/+publishinghistory does11:57
seb128ahasenack, I did11:57
cjwatson(answer: seb128)11:57
ahasenackcjwatson: it says "archive robot" sponsored it11:58
cjwatsonahasenack: second entry, not first11:58
cjwatsonthe second is the copy from -proposed to release11:58
ahasenackah, the deleted one11:58
cjwatson*the first is the ...11:58
ahasenackok, I was afraid it would trigger a rebuild of other packages like samba and sssd, but since it migrated, maybe not11:59
seb128ahasenack, no reason it would, there are little changes between the versions11:59
seb128ahasenack, also unsure why desktop owns that one, but if some other team has interest in it I would be happy to hand that one over12:00
ahasenackI think ldb is the one that retriggers many12:00
seb128we have no real interaction or knowledge of that one, but it's on our report which is why I updated it12:01
ahasenackbut was there a particular reason to do it after feature freeze?12:01
ahasenackI'm also not sure why it would be a desktop pkg12:02
seb128ahasenack, the changes looked like bugfixes only, which is good candidate to get post ff12:03
ahasenackok12:03
ahasenackrhythmbox, pulseaudio, are in the rdepends list, maybe that's why it's desktop12:05
seb128likely, I'm just unsure we are the ones knowing it best/using it most12:08
-queuebot:#ubuntu-release- Unapproved: rejected ubuntu-drivers-common [source] (bionic-proposed) [1:0.5.2.1]12:14
mfoslangasek, 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:25
ginggsmfo: i've triggered libuv1/1.22.0-313:30
mfoginggs, thanks!  it takes a while (maybe finish?) to show up in some page, like this one?13:32
mfohttps://autopkgtest.ubuntu.com/packages/libuv1/cosmic/armhf13:32
ginggsmfo: 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 page13:34
mfoginggs, 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:35
slangasekmfo: I've retriggered a test for the release version of libuv1 now13:38
slangasekginggs: 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:54
ginggsslangasek: :o - so how to do it then?13:56
slangasekginggs: see my faked-up trigger13:56
mfoslangasek, 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:56
slangasekginggs: and there may be some changes soon to make it easier to do this13: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:57
slangasekmfo: I will mark this as a badtest to let the package migrate13:58
ginggsslangasek: thanks, so what made you pick binutils, would glibc have worked too?13:58
mfoslangasek, ok, great. thank you.13:58
mfoginggs, thanks o/13:58
ginggsmfo: yw! not that i did anything useful13:59
mfoginggs, lol, i undertand, but no worries, thanks for being willing to help. that does count, i think :)14:00
slangasekginggs: I picked binutils as one that is unlikely to have a version in -proposed at any given time14:01
ginggsslangasek: ah, ok!14:02
tsimonq2I 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
tsimonq2Please voice objections soon if you have them.14:59
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [ppc64el] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)15:13
-queuebot:#ubuntu-release- New binary: linux-signed-hwe-edge [amd64] (bionic-proposed/universe) [4.18.0-8.9~18.04.1] (kernel)15:18
-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]15:19
-queuebot:#ubuntu-release- Unapproved: grub2 (bionic-proposed/main) [2.02-2ubuntu8.4 => 2.02-2ubuntu8.5] (core)21:00
-queuebot:#ubuntu-release- Unapproved: grub2-signed (bionic-proposed/main) [1.93.5 => 1.93.6] (core)21:01
mfoslangasek, 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
ubot5Launchpad 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/179322623:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!