[00:45] vorlon: and, should be running again. ubuntuwire was a little short of disk space [01:17] tumbleweed: ta [01:18] ginggs: I can reproduce the pandas failure, will try to isolate [04:59] vorlon: thanks. i tried reducing the size of the arange, and have just triggered the tests [05:28] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Xenial 16.04.6] has been marked as ready [05:31] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Xenial 16.04.6] has been marked as ready [05:49] vorlon: that didn't work :( i have a tested patch to disable only the failing test, only on python2 and only on ppc64el, which does the trick (nothing else fails) - shall i upload that so long? [06:16] ginggs: well, it is definitely an oom. I think I should probably dig a little further to see why it ooms, as that might be real bug [06:18] vorlon: ack [07:03] ginggs: oh but it's only an oom with python2, isn't it, could we skip the test on python2 but not python3? [07:04] ginggs: ah you said that already - yeah, I think you should upload [07:05] whatever's going on seems to be a memory leak though, because running that test on its own doesn't trigger it [07:16] -queuebot:#ubuntu-release- New source: libsodium (trusty-proposed/primary) [1.0.8-5~ubuntu14.04.1] [07:16] -queuebot:#ubuntu-release- New source: python-libnacl (trusty-proposed/primary) [1.4.5-0ubuntu1~ubuntu14.04.1] [07:16] -queuebot:#ubuntu-release- New source: pymacaroons (trusty-proposed/primary) [0.9.2-0ubuntu1~ubuntu14.04.1] [07:55] vorlon: yeah can skip on py2 only. uploading shortly [08:13] livecd-rootfs 3.566 just landed in disco. builds using it will see direct dependencies of ubiquity not marked as automatically anymore [08:14] in an attempt to fix #1801629 [09:08] ginggs: and if I run the testsuite under valgrind, it uses ridiculous amounts of memory just to collect the tests without ever running them, so I think ignoring is the right answer [09:11] vorlon: ack [09:12] I do wonder if this is a memory leak in pandas however, since memory usage creeps up over time while running the other tests (when not under valgrind) [09:13] * vorlon checks memory usage under python3 [09:15] similar behavior under python3, it just manages not to hit the ceiling [09:15] ginggs: do you want to check if memory grows over time on other archS? [09:18] vorlon: sure, i can check amd64 now [09:38] sorry for the nodejs rebuild, but I discovered an unicode bug, I'm doing some rebuilds to be sure rollup is now correctly bootstrapped [09:39] we were not correctly building node-unicode, that has been an hack to bootstrap acorn/rollup, and now we should remove that hack... [09:41] vorlon: memory usage grows over time on amd64, but only by about 1.1GB - how much are you seeing? [10:45] -queuebot:#ubuntu-release- Unapproved: gettext (bionic-proposed/main) [0.19.8.1-6ubuntu0.1 => 0.19.8.1-6ubuntu0.2] (core) (sync) [10:45] -queuebot:#ubuntu-release- Unapproved: insubstantial (bionic-proposed/universe) [7.3+dfsg3-3 => 7.3+dfsg3-4~18.04.1] (no packageset) (sync) [10:45] -queuebot:#ubuntu-release- Unapproved: java-common (bionic-proposed/main) [0.63ubuntu1~02 => 0.68ubuntu1~18.04.1] (core) (sync) [10:46] -queuebot:#ubuntu-release- Unapproved: javatools (bionic-proposed/universe) [0.63ubuntu1 => 0.72.1~18.04.1] (no packageset) (sync) [10:46] -queuebot:#ubuntu-release- Unapproved: jnr-posix (bionic-proposed/universe) [3.0.42-1 => 3.0.45-2~18.04] (no packageset) (sync) [10:46] -queuebot:#ubuntu-release- Unapproved: jruby (bionic-proposed/universe) [9.1.13.0-1 => 9.1.17.0-1~18.04] (no packageset) (sync) [10:47] -queuebot:#ubuntu-release- Unapproved: jython (bionic-proposed/universe) [2.7.1+repack-3 => 2.7.1+repack-5~18.04] (no packageset) (sync) [10:47] -queuebot:#ubuntu-release- Unapproved: libgpars-groovy-java (bionic-proposed/universe) [1.2.1-7 => 1.2.1-10~18.04.1] (no packageset) (sync) [10:50] -queuebot:#ubuntu-release- Unapproved: logback (bionic-proposed/universe) [1:1.2.3-2 => 1:1.2.3-2ubuntu1~18.04.1] (no packageset) (sync) [10:51] -queuebot:#ubuntu-release- Unapproved: maven-javadoc-plugin (bionic-proposed/universe) [3.0.0-4 => 3.0.1-3~18.04.1] (no packageset) (sync) [10:51] -queuebot:#ubuntu-release- New sync: openjdk-11-jre-dcevm (bionic-proposed/primary) [11.0.1+8-1~18.04] [10:52] -queuebot:#ubuntu-release- Unapproved: openjdk-lts (bionic-proposed/main) [10.0.2+13-1ubuntu0.18.04.4 => 11.0.2+9-3ubuntu1~18.04.1] (ubuntu-desktop) (sync) [10:54] -queuebot:#ubuntu-release- Unapproved: openjfx (bionic-proposed/universe) [8u161-b12-1ubuntu2 => 11.0.2+1-1~18.04.1] (no packageset) (sync) [10:54] -queuebot:#ubuntu-release- New sync: saaj (bionic-proposed/primary) [1.4.0-3~18.04.1] [10:55] -queuebot:#ubuntu-release- Unapproved: scala (bionic-proposed/universe) [2.11.12-2 => 2.11.12-4~18.04] (no packageset) (sync) [10:57] -queuebot:#ubuntu-release- Unapproved: accepted gettext [sync] (bionic-proposed) [0.19.8.1-6ubuntu0.2] [10:58] -queuebot:#ubuntu-release- Unapproved: accepted insubstantial [sync] (bionic-proposed) [7.3+dfsg3-4~18.04.1] [11:00] -queuebot:#ubuntu-release- Unapproved: accepted java-common [sync] (bionic-proposed) [0.68ubuntu1~18.04.1] [11:01] -queuebot:#ubuntu-release- Unapproved: accepted javatools [sync] (bionic-proposed) [0.72.1~18.04.1] [11:03] -queuebot:#ubuntu-release- Unapproved: accepted jnr-posix [sync] (bionic-proposed) [3.0.45-2~18.04] [11:05] -queuebot:#ubuntu-release- Unapproved: accepted jruby [sync] (bionic-proposed) [9.1.17.0-1~18.04] [11:06] -queuebot:#ubuntu-release- Unapproved: accepted jython [sync] (bionic-proposed) [2.7.1+repack-5~18.04] [11:07] -queuebot:#ubuntu-release- Unapproved: accepted libgpars-groovy-java [sync] (bionic-proposed) [1.2.1-10~18.04.1] [11:08] -queuebot:#ubuntu-release- Unapproved: accepted logback [sync] (bionic-proposed) [1:1.2.3-2ubuntu1~18.04.1] [11:09] -queuebot:#ubuntu-release- Unapproved: accepted maven-javadoc-plugin [sync] (bionic-proposed) [3.0.1-3~18.04.1] [11:10] -queuebot:#ubuntu-release- Unapproved: accepted openjdk-lts [sync] (bionic-proposed) [11.0.2+9-3ubuntu1~18.04.1] [11:12] -queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (bionic-proposed) [11.0.2+1-1~18.04.1] [11:13] -queuebot:#ubuntu-release- Unapproved: accepted scala [sync] (bionic-proposed) [2.11.12-4~18.04] [11:14] willcooke, sil2100 bug 1817689 [11:14] bug 1817689 in ubiquity (Ubuntu) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Undecided,New] https://launchpad.net/bugs/1817689 [11:14] -queuebot:#ubuntu-release- New: accepted openjdk-11-jre-dcevm [sync] (bionic-proposed) [11.0.1+8-1~18.04] [11:14] reproduced on both archs [11:16] jibel, my install just finished, and I *can* log in [11:16] lemme read the bug, make sure I did it right [11:16] yeah, that's what I did [11:16] jibel, did you install in French? [11:17] I will try a different language [11:17] ugh [11:17] -queuebot:#ubuntu-release- New: accepted saaj [sync] (bionic-proposed) [1.4.0-3~18.04.1] [11:18] willcooke, 16.04.6 ? [11:18] http://cdimage.ubuntu.com/xenial/daily-live/20190222/ [11:19] jibel, yeah, md5 matches [11:20] I did an installation in english [11:21] jibel, uefi? [11:21] no, bios in a vm [11:21] i'll try on bare metal [11:22] jibel: can you also try .5 later? [11:22] I'll try to reproduce here [11:22] sure [11:39] jibel, 2nd install on metal - worked [11:41] well, 2 install and both failed [11:41] As you might expect, I'm doing my testing on the haunted laptop [11:45] I seem to be able to reproduce it here [11:47] The system boots but on the login screen I can't log into my user [11:47] sil2100, switch to a tty, log in and check if there are permission denied in the journal [11:48] sil2100, on a vm? [11:50] willcooke: yeah, kvm [11:50] * willcooke tries on vbox [11:52] jibel: yes, the same error as you have [11:54] meh, I can't recreate on vbox either [11:55] what password are you using for encrypting the disk? [11:55] willcooke: so you have ecryptfs home working? [11:55] willcooke: it's not about disk encryption, but home encryption if anything [11:55] ohhhhhh [11:55] man [11:55] I cant read [11:56] at least now we know that disk encryption is working ;) [11:56] Let's try that again [11:56] jibel, ha [11:56] hm, changing file owner didn't help either [11:58] After changing the owner of .ecryptfs, I'm getting "No such file or directory" errors while detecting wrapped passphrase version [11:58] * jibel syncs 16.04.5 [11:58] I do see pam_kwallet*.so load errors earlier [11:58] Maybe those are somehow needed for that? [11:58] Anyway, I need to go prep lunch now, will dig in further when back [11:59] jibel, so are you doing a "something else" install, creating a /home and then encrypting that (and using lvm)? [12:00] willcooke, no, you select 'install ubuntu on entire disk' then in the 'Who are you' page, you check 'encrypt home' [12:01] -queuebot:#ubuntu-release- Unapproved: glib2.0 (bionic-proposed/main) [2.56.3-0ubuntu0.18.04.1 => 2.56.4-0ubuntu0.18.04.1] (core) [12:01] jibel, gotit [12:01] thx [12:01] then it uses ecryptfs to encrypt $HOME [12:05] and this is a reproducible on hw so not a problem of vm vs hw [12:08] jibel, ok, yeah, confirmed on vbox and real hardware. Sorry for the confusion [12:09] Thanks for the confirmation, I should have make the test case more clear [12:42] sil2100, it's a regression in 16.04.6. [13:08] (confirmed as well) [13:10] what would be a release without a respin [13:10] that's where the fun is, obviously :) [13:11] I actually feel frustrated when I don't find a bug that requires a respin ;) [13:12] maybe it's all done on purpose then! :) [13:12] people care of you being happy :p [13:16] :| === jbicha_ is now known as jbicha [13:40] I can help on that bug if people want (will be back in 1 hour ish) [13:55] I'm back now so I'll try looking into this a bit more === alan_g_ is now known as alan_g [13:57] sil2100, there is this in the logs [13:57] Feb 26 10:58:21 ubuntu user-setup: Error: Your kernel does not support filename encryption [13:57] Feb 26 10:58:21 ubuntu user-setup: ERROR: Could not add passphrase to the current keyring [13:57] Feb 26 10:58:21 ubuntu user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u u' returned error code 1. Exiting. [13:57] installation logs [13:58] looks like a kernel issue [13:59] apw, ^ any idea? it's bug 1817689 [13:59] bug 1817689 in ubiquity (Ubuntu) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Undecided,New] https://launchpad.net/bugs/1817689 [13:59] jibel, which kernel is that [13:59] 4.15.0-45-generic [14:01] and this was not in .5; do we know ? [14:01] it works fine on .5 [14:02] jibel: and there was no message like that in the logs, right? [14:02] it worked so I did 't check the logs [14:05] no such message in .5 which has kernel 4.15.0-29-generic [14:08] jibel, i assume you are able to install kernels and test ? [14:08] apw, yes, I should be able to do that. which kernel do you want to test? [14:08] jibel, i am suspicious this of -37 as being when it changed, are you able to check -36 and -37 [14:09] sure [14:09] jibel, you are a star [14:13] Interesting fact is that if I boot a xenial .6 system, switch to a tty, create a new user, run ecryptfs-setup-private -b -u user - all is good [14:13] So I would personally doubt it's kernel? [14:14] Since if I do it like this and manually encrypt home for a new user, I can log in normally and from what I see the home dir of that user is encrypted [14:16] jibel, apw: ^ [14:17] sil2100, hmmmm [14:26] sil2100, and filename encryption appears to be on as far as i can tell [14:27] sil2100, i wonder how that thing decides it is not [14:27] ah, hmmm [14:28] Ok, so apparently after reboot I can't log in into the new user as well [14:33] So yeah, something's busted, but not sure how [14:34] sil2100, if it helps here is the diff of the manifests with .5 http://paste.ubuntu.com/p/pfBQ6Wk924/ [14:47] apw: so maybe there's indeed something kernel-related, since as mentioned after reboot it doesn't work again [14:47] I also test installed .5 and I didn't see any messages like this, everything just works [14:48] sil2100, so i think we wait on the jibel testing, if that shows a boundary there, we may have a likely culprit ... though that change sounds sane, so it might be userspace related [14:48] sil2100, still userspace related, as in the test might be invalid [14:48] anyhow, lets see [14:49] is the archive not frozen for xenial? I've updates of ghostscript and gnome-keyring after a fresh installation [14:50] That's security [14:51] Not much I can do about that [15:19] jdstrand: hey! Could you maybe take a look at our xenial issues as well? ^ [15:37] Strange that in the installer logs one can see the 'Your kernel does not support filename encryption', but then on the running system when you check /sys/fs/ecryptfs/version, it seems to have the flag for kernel encryption set [15:37] Both seem to be running the same kernel? [15:38] Oh, wait [15:39] Yeah, that's correct [15:40] So hmmm, I wonder what's going on during the install [15:40] I cannot reproduce with -45 on an installed system [15:49] jibel: can you share the /var/log/installer/syslog from the .5 install? [15:52] ginggs: well, the autopkgtest runners only have 1.5GiB of RAM altogether, so any little bit above that is enough to top out on the runners. But also, my expectation is that memory usage doesn't grow over time at all, that certainly sounds like a leak to me. I'll rerun under valgrind in an env with more memory. === ErichEickmeyer is now known as Eickmeyer [15:53] Laney, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1817689/+attachment/5241810/+files/syslog.16.04.5 [15:53] Launchpad bug 1817689 in ubiquity (Ubuntu Xenial) "[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled" [Critical,Confirmed] [15:54] thx [15:54] so you can see a difference there when it does the thing in user-setup [15:55] yes, when it's successful is says "Done configuring" and when it fails it says [15:55] Feb 26 10:58:21 ubuntu user-setup: Error: Your kernel does not support filename encryption [15:55] Feb 26 10:58:21 ubuntu user-setup: ERROR: Could not add passphrase to the current keyring [15:55] Looks like this is an issue only during install [15:55] Feb 26 10:58:21 ubuntu user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u u' returned error code 1. Exiting. [15:55] yup [15:56] and I cannot boot with another kernel, I've boot loop for some reason [15:56] boot the live session [15:57] Oh, right, I can experiment in the live session [16:06] On the live session on .6 /sys/fs/ecryptfs/version seems to support encrypted filenames, and doing adduser --encrypt-home seems to succeed [16:09] I'll try to see what happens if I try installing from the live session [16:17] can't make this error happen myself, weird one [16:19] Ok, strange, when running ubiquity installer from the live session, I still see it failing in user-setup, wtf [16:21] Laney: like, you can't get ecryptfs to fail during install for you? [16:21] nah [16:21] I can't do it outside of ubiquity [16:21] Yeah, same here [16:21] My earlier case was invalid [16:22] So the only place where it fails is during ubiquity install [16:23] bdmurray: remember not to release any xenial packages into -updates o/ [16:24] RAOF: ^ [16:25] Laney: maybe ubiquity needs a rebuild? I didn't think that was necessary [16:28] what for? [16:29] I don't know, if I knew I'd rebuild it ;) [16:30] It's really intriguing, user-setup fails during install with the unsupported filename encryption thing, but even when I check /target/sys/fs/ecryptfs/version etc. it all looks like this error shouldn't have been printed [16:30] The right flags are in the version number [16:31] yeah I wrote a program to call that same function and it works :< [16:31] maybe the error message is misleading did you check in which case it's displayed? [16:32] jibel: it's displayed by the ecryptfs tools only in this particular case, I checked the code [16:33] The string is in ECRYPTFS_ERROR_FNEK_SUPPORT and it's only printed in ecryptfs_add_passphrase.c, which checks for the existance of the flag in version [16:33] Oh, wait [16:34] It can also print it out with ecryptfs_get_version() returns non-zero, so maybe somehow sysfs is not mounted on /target yet? Doesn't make sense though [16:35] Or maybe some permission problems accessing sysfs, but that also doesn't make sense [16:37] systemd? [16:44] seb128: do you know why the disco desktop image is now 300MB bigger than it was at the beginning of the month? (and > 2GB) [16:44] no idea, but that's interesting [16:44] thanks for pointing it out, I'm going to poke [16:45] last cycle we had the issue and it was some toolchain thing having debug by default during the unstable cycle iirc [16:45] but I don't remember the specifics now [16:45] I have a look a bit later and let you know [16:45] seb128: the count of packages has also increased sustantially, 1657 -> 1805 [16:46] sil2100, /target/sys is populated and ecryptfs/version exists [16:47] Yeah, I know, I saw that during the install [16:47] But maybe not before user-setup was called? [16:47] Like, it's mounted later or something? [16:48] seb128: mostly a lot of locale stuff that previously wasn't on the CD, so maybe someone fixed something that was previously broken? Also curl is being pulled in which sounds like a bug (we have wget) [16:48] jibel: ok, I think that's the case [16:49] jibel, Laney: if you check the logs, first user-setup runs and only later in the logs I see `chroot /target mount -t sysfs sysfs /sys [16:49] ` [16:49] seb128: list of newly added packages in the manifest: https://paste.ubuntu.com/p/9gv6knNrZ6/ [16:49] * sil2100 checks the .5 sysfs logs [16:50] huh [16:50] Laney, jibel: that's it [16:50] Laney, jibel: if you check the .5 logs, there sysfs is first mounted in /target and only then user-setup runs [16:50] Laney, jibel: but now it's the other way around! [16:50] Laney: hmm, did your change for the move-the-keyboard-setup-earlier go into xenial-updates? [16:51] Laney: did you SRU those changes? [16:51] Laney: since to me it seems that the order in ubiquity somehow changed and now user-setup runs earlier due to that [16:52] eh, darn ubiquity [16:53] So now someone just needs to figure out why we now have user-setup running earlier and done [16:54] uh, wait [16:54] don't think so, user-setup mounts /sys itself [16:54] -queuebot:#ubuntu-release- New source: waylandpp (disco-proposed/primary) [0.2.5-0ubuntu1] [16:56] Yeah... [16:56] Guess you're right [16:58] But at least I have a few other ideas to debug this [17:32] Laney: so strange, I didn't get much more info, but when user-setup runs ecryptfs/version seems readable and has correct contents, I was checking it right before adduser runs, no idea why it fails there [17:32] Even from inside the chroot [17:33] sil2100: you hacked the script or? [17:33] Laney: yeah, I hacked user-setup-apply in ubiquity/user-setup [17:34] Right before adduser is called that does all the setup I added some catting and statting of the ecryptfs version path, from outside and inside the chroot - all looked correct [17:46] sil2100: HMMMMMMMMMMMMMMMMMM ok [17:46] I put a "sleep infinit_y" right after the call and now I can poke in there [17:46] and I checked that sysfs is mounted right before calling adduser [17:47] the version is coming out weird [17:48] Laney: what version number do you see? [17:48] 611346400 [17:48] -queuebot:#ubuntu-release- New sync: gmbal-commons (bionic-proposed/primary) [3.2.1-b003-1~18.04] [17:48] but the call errors [17:48] Since in cat from before adduser in the chroot I'm getting 375, which is correct [17:48] rc != 0 [17:48] -queuebot:#ubuntu-release- New sync: gmbal (bionic-proposed/primary) [4.0.0-b002-1~18.04] [17:48] -queuebot:#ubuntu-release- New sync: gmbal-pfl (bionic-proposed/primary) [4.0.1-b003-2~18.04] [17:48] uh [17:48] wow [17:48] -queuebot:#ubuntu-release- Unapproved: istack-commons (bionic-proposed/universe) [3.0.6-1 => 3.0.6-3~18.04] (no packageset) (sync) [17:48] -queuebot:#ubuntu-release- Unapproved: jaxb (bionic-proposed/universe) [2.3.0-3 => 2.3.0.1-7~18.04] (no packageset) (sync) [17:48] so that's just whatever the memory had before [17:48] -queuebot:#ubuntu-release- Unapproved: jaxb-api (bionic-proposed/universe) [2.2.9-1 => 2.3.1-1~18.04] (no packageset) (sync) [17:49] Laney: right after the call - you mean, right after adduser? [17:49] -queuebot:#ubuntu-release- Unapproved: jaxe (bionic-proposed/universe) [3.5-9 => 3.5-11~18.04] (no packageset) (sync) [17:49] yeah [17:49] (sorry for the noise guys ^) [17:49] the one that dies [17:49] add a sleep there, then you can get in the chroot and mess around [17:49] -queuebot:#ubuntu-release- Unapproved: jaxrs-api (bionic-proposed/universe) [2.1-1 => 2.1.2-2~18.04] (no packageset) (sync) [17:49] -queuebot:#ubuntu-release- Unapproved: libwoodstox-java (bionic-proposed/universe) [1:4.1.3-1 => 1:5.1.0-2~18.04] (no packageset) (sync) [17:49] Laney: wow, so it's like something in adduser (the ecryptfs tools) breaks ecryptfs? [17:49] -queuebot:#ubuntu-release- Unapproved: libstax2-api-java (bionic-proposed/universe) [3.1.1-1 => 4.1-1~18.04] (no packageset) (sync) [17:49] -queuebot:#ubuntu-release- Unapproved: maven-bundle-plugin (bionic-proposed/universe) [3.5.0-1 => 3.5.1-2~18.04.1] (no packageset) (sync) [17:49] -queuebot:#ubuntu-release- New sync: jaxrpc-api (bionic-proposed/primary) [1.1.2-2~18.04] [17:49] -queuebot:#ubuntu-release- New sync: jaxws (bionic-proposed/primary) [2.3.0.2-1~18.04.1] [17:49] -queuebot:#ubuntu-release- New sync: jaxws-api (bionic-proposed/primary) [2.3.0-1~18.04] [17:49] -queuebot:#ubuntu-release- New sync: jws-api (bionic-proposed/primary) [1.1-1~18.04] [17:49] dunno, I'm seeing what get_version does [17:50] -queuebot:#ubuntu-release- New sync: maven-jaxb2-plugin (bionic-proposed/primary) [0.14.0-1~18.04.1] [17:50] -queuebot:#ubuntu-release- New sync: mimepull (bionic-proposed/primary) [1.9.7-1~18.04] [17:50] -queuebot:#ubuntu-release- New sync: metro-policy (bionic-proposed/primary) [2.7.2-3~18.04] [17:50] -queuebot:#ubuntu-release- Unapproved: maven-enforcer (bionic-proposed/universe) [1.4.2-1 => 3.0.0~M2-1~18.04.1] (no packageset) (sync) [17:50] -queuebot:#ubuntu-release- Unapproved: maven-dependency-plugin (bionic-proposed/universe) [3.0.1-3 => 3.1.1-1~18.04] (no packageset) (sync) [17:50] -queuebot:#ubuntu-release- Unapproved: maven-plugin-tools (bionic-proposed/universe) [3.5-6 => 3.5-6ubuntu1~18.04.1] (no packageset) (sync) [17:50] -queuebot:#ubuntu-release- New sync: saaj-ri (bionic-proposed/primary) [1.4.1-1~18.04] [17:50] -queuebot:#ubuntu-release- Unapproved: accepted gnome-desktop3 [source] (cosmic-proposed) [3.30.2.1-0ubuntu1] [17:50] -queuebot:#ubuntu-release- Unapproved: stax-ex (bionic-proposed/universe) [1.7.8-1 => 1.7.8-3~18.04.1] (no packageset) (sync) [17:50] the file in /sys *is* right [17:51] forgot to say that, that's important ;-) [17:52] Ah, so in the chroot, /sys/fs/ecryptfs/version has a sane version when you cat it directly? [17:52] ye [17:52] wow [17:53] ecryptfs-utils does some weird stuff to get it [17:54] * sil2100 needs to take care of the openjdk packages [17:58] -queuebot:#ubuntu-release- Unapproved: accepted istack-commons [sync] (bionic-proposed) [3.0.6-3~18.04] [18:00] -queuebot:#ubuntu-release- Unapproved: accepted jaxb [sync] (bionic-proposed) [2.3.0.1-7~18.04] [18:03] -queuebot:#ubuntu-release- Unapproved: accepted jaxb-api [sync] (bionic-proposed) [2.3.1-1~18.04] [18:04] -queuebot:#ubuntu-release- Unapproved: accepted jaxe [sync] (bionic-proposed) [3.5-11~18.04] [18:06] -queuebot:#ubuntu-release- Unapproved: accepted jaxrs-api [sync] (bionic-proposed) [2.1.2-2~18.04] [18:07] sil2100: there's no mtab, so the function bails out [18:08] -queuebot:#ubuntu-release- Unapproved: accepted libstax2-api-java [sync] (bionic-proposed) [4.1-1~18.04] [18:09] because /proc isn't mounted [18:10] -queuebot:#ubuntu-release- Unapproved: accepted libwoodstox-java [sync] (bionic-proposed) [1:5.1.0-2~18.04] [18:12] -queuebot:#ubuntu-release- Unapproved: accepted maven-bundle-plugin [sync] (bionic-proposed) [3.5.1-2~18.04.1] [18:13] -queuebot:#ubuntu-release- Unapproved: accepted maven-dependency-plugin [sync] (bionic-proposed) [3.1.1-1~18.04] [18:15] -queuebot:#ubuntu-release- Unapproved: accepted maven-enforcer [sync] (bionic-proposed) [3.0.0~M2-1~18.04.1] [18:16] -queuebot:#ubuntu-release- Unapproved: accepted maven-plugin-tools [sync] (bionic-proposed) [3.5-6ubuntu1~18.04.1] [18:16] * Laney tries ... [18:19] uh oh [18:19] -queuebot:#ubuntu-release- Unapproved: accepted stax-ex [sync] (bionic-proposed) [1.7.8-3~18.04.1] [18:22] Laney: wonder what happened that /proc is not available now [18:22] Laney: did you manage to get it working after mounting /proc ? [18:22] dunno [18:22] not got that far yet [18:22] I should disconnect the network, it spends ages downloading stuff each time [18:23] -queuebot:#ubuntu-release- New: accepted gmbal [sync] (bionic-proposed) [4.0.0-b002-1~18.04] [18:26] -queuebot:#ubuntu-release- New: accepted gmbal-commons [sync] (bionic-proposed) [3.2.1-b003-1~18.04] [18:28] -queuebot:#ubuntu-release- New: accepted gmbal-pfl [sync] (bionic-proposed) [4.0.1-b003-2~18.04] [18:31] AHHHHHHHH YEAHHHHHHHHHHHHHHHHH [18:31] o.O [18:32] -queuebot:#ubuntu-release- New: accepted jaxrpc-api [sync] (bionic-proposed) [1.1.2-2~18.04] [18:32] sil2100, doko: do you need anything from me wrt the openjdk-11 SRUs? I could spend a little time on it this afternoon if needed, but I don't know what's next [18:33] -queuebot:#ubuntu-release- New: accepted jaxws [sync] (bionic-proposed) [2.3.0.2-1~18.04.1] [18:34] vorlon: I'm currently finishing copying the stage4 packages, rest has not yet been reviewed by security [18:35] vorlon, sil2100: tiago wanted to identify the leaf apps, but didn't send me an update as promised [18:35] Laney: works?! [18:35] -queuebot:#ubuntu-release- New: accepted jaxws-api [sync] (bionic-proposed) [2.3.0-1~18.04] [18:35] sbeattie will review the apps, tomcat and stage5 PPAs [18:35] Laney: did you figure out why /proc was not mounted, or not yet? [18:36] cpaelzer: I don't understand https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1812384/comments/20 I see no autopkgtest failures related to this SRU [18:36] Launchpad bug 1812384 in Ubuntu on IBM z Systems "[Ubuntu] qemu - backport diag308 stable exception fix" [Medium,Fix committed] [18:36] sil2100: I dunno what changed, but I know that user-setup doesn't mount it [18:36] cpaelzer: (http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#qemu is clean) [18:36] so I'll upload a fix to do that directly, but if someone wants to find out why the order changed they can [18:37] I just upload user-setup and then we rebuild ubiquity to get it, right? [18:37] Laney: excellent! +1 on that [18:37] vorlon: and we have some autopkg test failures, but EOD for me now [18:37] Laney: yeah [18:37] -queuebot:#ubuntu-release- New: accepted jws-api [sync] (bionic-proposed) [1.1-1~18.04] [18:37] Laney: upload it then I can review/accept it, at least the user-setup one [18:38] okey [18:38] test/review/accept? ;-) [18:38] HOTFIX FOR THE WIN [18:38] I'll have to go straight after (pub quiz) so won't be around to fix stuff up unfortunately [18:39] -queuebot:#ubuntu-release- New: accepted maven-jaxb2-plugin [sync] (bionic-proposed) [0.14.0-1~18.04.1] [18:39] Laney: no worries, thanks for the help with the investigation and the 'fixation' (wanted it to rhyme)! [18:39] nice one Laney, thank you! [18:39] cpaelzer: oh, I guess bdmurray already merged, n/m [18:42] -queuebot:#ubuntu-release- New: accepted metro-policy [sync] (bionic-proposed) [2.7.2-3~18.04] [18:43] Laney: in case you won't manage to do the ubiquity rebuild, I can do that as well [18:43] Laney: don't want you to miss the pub action [18:43] :) [18:44] -queuebot:#ubuntu-release- New: accepted mimepull [sync] (bionic-proposed) [1.9.7-1~18.04] [18:45] doko, vorlon: all stage4 packages should be copied and accepted now, phew [18:45] -queuebot:#ubuntu-release- New: accepted saaj-ri [sync] (bionic-proposed) [1.4.1-1~18.04] [18:45] sil2100: stage5 has 60 ... [18:46] sil2100: definitely won't [18:46] especially if you want to test before :> [18:46] Indeed [18:46] That's cool [18:47] Laney: just give me a poke once you upload user-setup [18:47] doko: ...lovely [18:47] will be in one minute [18:49] -queuebot:#ubuntu-release- Unapproved: user-setup (xenial-proposed/main) [1.63ubuntu4 => 1.63ubuntu4.1] (core) [18:50] damn it, make that two [18:50] I haven't done anything else, like fix devel (although this option is hidden in all other supported releases AFAIK) or SRUify the bug I'm afraid [18:50] o/ [18:51] o/ [18:51] That's ok [18:51] It's a release critical bug, it'll be fast-tracked anyway [18:51] Laney: thanks and have fun! [18:51] thx [18:51] will follow up tomorrow if anything needs doing [18:51] goodnight [18:51] see you Laney [18:53] * sil2100 prepares his kvm for testing [18:53] sil2100, let me know when you have a package to verify [18:53] jibel: will do [18:53] I'll test the code changes before accepting [19:03] Code-wise looks good, testing looks promising as well [19:04] \o/ [19:04] Accepting [19:06] -queuebot:#ubuntu-release- Unapproved: accepted user-setup [source] (xenial-proposed) [1.63ubuntu4.1] [19:06] jibel: user-setup is building in xenial-proposed now, once that's built you can give it a spin - I'll also prepare ubiquity then [19:10] -queuebot:#ubuntu-release- Unapproved: accepted lldpd [source] (cosmic-proposed) [1.0.1-1ubuntu0.1] [19:12] -queuebot:#ubuntu-release- Unapproved: accepted lldpd [source] (bionic-proposed) [0.9.9-1ubuntu0.1] [19:24] sil2100, k [19:45] vorlon, the current disco iso is about the same size as the bionic/cosmic ones and your list of new packages look like thing that are usually on the iso, so I guess it's the earlier one you had which was buggy [19:45] ok [19:46] jibel: ...still waiting for the mirrors to catch up [19:52] sil2100, I downloaded the version from lp [19:57] * sil2100 is still waiting for it to pop up in the the main archive mirror to pull it into ubiquity [19:57] sil2100, user-setup 1.63ubuntu4.1 fixes the problem now i'd like to know why it is not happening previously. This package didn't change since the initial release of xenial [19:58] jibel: yeah, we will investigate that for sure, but we should prioritize landing this anyway [19:59] indeed [20:00] vorlon: is there a way to sync archive mirrors somehow? [20:00] mm? [20:00] vorlon: like, I'm waiting and waiting for user-setup to appear in archive.ubuntu.com but it's not happening! [20:00] you should check with IS [20:01] there is no manual process for triggering a sync because it's supposed to always sync asap [20:04] I think there've just been a couple of big publisher runs [20:04] vorlon, cjwatson: thanks [20:04] Sorry for being impatient [20:05] Not seeing anything actually wrong [20:28] vorlon: Do you think you might be able to merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-disco-vagrant-mutate/+merge/363463 ? [20:34] Odd_Bloke: I don't understand the rationale here; the only current failure I see of vagrant-mutate is one that blocks an update of vagrant, but I see two recent successes of the autopkgtest with other triggers since the last time it was retried with -proposed vagrant [20:35] so can you ++verbose on what 'network issues' means? is this actually a flaky test? [20:37] vorlon: Yeah, we're seeing flakiness (which appears to be network related); I hadn't seen that Christian had managed to get a qemu pass, so I'm retrying now to see if it works for vagrant too. [20:37] Odd_Bloke: already retried it fwiw [20:38] Cool, I'll keep an eye out; thanks! [20:59] -queuebot:#ubuntu-release- Unapproved: ubiquity (xenial-proposed/main) [2.21.63.9 => 2.21.63.10] (core) [21:03] jibel: accepted ubiquity [21:03] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (xenial-proposed) [2.21.63.10] [21:03] jibel: once that builds would be nice to sanity-test it, release and re-spin the world! [21:18] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [s390x] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:19] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [amd64] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:19] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [ppc64el] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:19] Odd_Bloke: both of our retries failed [21:20] -queuebot:#ubuntu-release- New sync: rust-ascii (disco-proposed/primary) [0.9.1-1] [21:20] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [i386] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:20] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [arm64] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:20] vorlon: ;.; [21:20] merging hint [21:21] -queuebot:#ubuntu-release- New binary: rust-rusty-fork [armhf] (disco-proposed/universe) [0.2.1-1] (no packageset) [21:22] Thanks! [21:29] -queuebot:#ubuntu-release- Unapproved: rejected skiboot [source] (cosmic-proposed) [6.1-2ubuntu0.1] [21:45] ginggs: well, running to completion under valgrind, valgrind only finds 332k of memory leaking [21:45] ginggs: so it's possibly deferred gc but not leaks per se :/ [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [armhf] (disco-proposed) [0.2.1-1] [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [i386] (disco-proposed) [0.2.1-1] [21:47] -queuebot:#ubuntu-release- New: rejected rust-ascii [sync] (disco-proposed) [0.9.1-1] [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [arm64] (disco-proposed) [0.2.1-1] [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [s390x] (disco-proposed) [0.2.1-1] [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [amd64] (disco-proposed) [0.2.1-1] [21:47] -queuebot:#ubuntu-release- New: accepted rust-rusty-fork [ppc64el] (disco-proposed) [0.2.1-1] [21:49] ==124425== still reachable: 413,357,685 bytes in 789,082 blocks [22:06] -queuebot:#ubuntu-release- New binary: rust-proptest [amd64] (disco-proposed/universe) [0.8.7-1] (no packageset) [22:06] -queuebot:#ubuntu-release- New binary: rust-proptest [s390x] (disco-proposed/universe) [0.8.7-1] (no packageset) [22:06] -queuebot:#ubuntu-release- New binary: rust-proptest [i386] (disco-proposed/universe) [0.8.7-1] (no packageset) [22:06] -queuebot:#ubuntu-release- New binary: rust-proptest [ppc64el] (disco-proposed/universe) [0.8.7-1] (no packageset) [22:07] -queuebot:#ubuntu-release- New: accepted rust-proptest [i386] (disco-proposed) [0.8.7-1] [22:08] -queuebot:#ubuntu-release- New: accepted rust-proptest [amd64] (disco-proposed) [0.8.7-1] [22:08] -queuebot:#ubuntu-release- New: accepted rust-proptest [s390x] (disco-proposed) [0.8.7-1] [22:08] -queuebot:#ubuntu-release- New: accepted rust-proptest [ppc64el] (disco-proposed) [0.8.7-1] [22:11] * sil2100 tests the new ubiquity [22:20] eh, ok, still not there [22:39] Usually when rmadison was giving me a +1 that a package is published, this meant it was available [22:39] But today there seems to be some lag [23:10] Looks good, releasing [23:18] vorlon, infinity: I guess I need to go to sleep now [23:19] vorlon, infinity: can one of you re-spin all the 16.04.6 images once ubiquity and user-setup get fully published in xenial-updates? [23:19] You can use the isotracker for that [23:20] Just remember, today it seems to take a bit for the package to publish and actually appear on the archive mirrors [23:26] sil2100: and I think we need to resnapshot the point release? [23:27] vorlon: yes, that too [23:27] + source iso's as well [23:28] (once it's all published) [23:28] vorlon: would be grateful o/ [23:28] ok, I'll take it [23:29] Thank you! [23:29] * sil2100 off to sleep [23:29] Goodnight [23:44] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (cosmic-proposed) [18.09.2-0ubuntu1~18.10.1] [23:50] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (bionic-proposed) [18.09.2-0ubuntu1~18.04.1] [23:53] -queuebot:#ubuntu-release- Unapproved: accepted docker.io [source] (xenial-proposed) [18.09.2-0ubuntu1~16.04.1] [23:54] infinity: both python-biopython and postgresql-hll regressions w/ glibc 2.29 look to me like fp behavior changes that need someone to understand