[00:32] -queuebot:#ubuntu-release- New: accepted pmdk [source] (cosmic-proposed) [1.4-0ubuntu1]
[00:43] -queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2.18.04.1]
[00:49] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33.1+18.04ubuntu1]
[00:50] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.33.1+17.10ubuntu1]
[01:07] -queuebot:#ubuntu-release- New binary: pmdk [amd64] (cosmic-proposed/universe) [1.4-0ubuntu1] (no packageset)
=== maclin1 is now known as maclin
[04:36] <tsimonq2> Harumph.
[04:36] <tsimonq2> https://launchpadlibrarian.net/376840028/buildlog_ubuntu_cosmic_amd64_lubuntu_BUILDING.txt.gz
[04:39] <tsimonq2> xnox: Your rsyslog update likely broke this.
[04:39] <tsimonq2> er
[04:39] <tsimonq2> I can't read dates, apparently.
[04:39] <tsimonq2> Nevermind, although your help in figuring this out would be appreciated.
[04:41] <flocculant> appears to be affecting Xubuntu as well
[04:41] <tsimonq2> It should, theoretically, affect all images 20180702 and on.
[04:41] <flocculant> yea
[04:42] <flocculant> mate failed an hour ago
[04:44] <tsimonq2> Theoretically, Cosmic debootstraps should also fail.
[04:44] <tsimonq2> Trying to repro now.
[04:53] <tsimonq2> Oh, that worked.
[05:08] <slangasek> tsimonq2, flocculant: I poked at it all afternoon and haven't managed yet to reproduce it locally.  A debootstrap doesn't fail in a normal environment, including using a fully up-to-date cosmic to debootstrap cosmic.
[05:10] <slangasek> maybe it's reproducible specifically in the container environment used in launchpad; I am lacking documentation on how to reproduce that environment locally
[05:11] <slangasek> cjwatson: ^^ I missed your presentation at the sprint, so I don't know how to reproduce the current failures affecting all cosmic livefs builds
[05:12] <flocculant> slangasek: thanks for the info :)
[05:37] <tsimonq2> slangasek: Thanks
[06:35] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33.1ubuntu1]
[06:45] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.2.0~bionic]
[06:57] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.2]
[08:13] <LocutusOfBorg> can we please blacklist this test? http://autopkgtest.ubuntu.com/packages/p/pinentry/cosmic/i386
[08:13] <LocutusOfBorg> it passed once, I don't know why, but it is obviously flaky
[08:50] -queuebot:#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-3~bionic1] (no packageset)
[09:22] <xnox> tsimonq2, it was failing for a while (debootstrap, under live build)
[09:23] <xnox> tsimonq2, i've seen that before, but never managed to reproduce, or figure out what's wrong with rsyslog =/
[09:31] <xnox> tsimonq2, i can upload a better bootstrapable rsyslog anyway, just in case.
[09:33] <LocutusOfBorg> [10:50:05] -queuebot/#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-3~bionic1] (no packageset)
[09:33] <LocutusOfBorg> who is doing this stuff?
[09:34] <LocutusOfBorg> seb128, ^^ isn't such versioning wrong?
[09:34] <LocutusOfBorg> why did we stop using release numbers (that are guaranteed to be incremental)?
[09:34] <LocutusOfBorg> tsimonq2, ^^ this was also your question :)
[10:06] <cjwatson> slangasek,tsimonq2,xnox: I've reproduced it locally
[10:07] <cjwatson> https://paste.ubuntu.com/p/DdsyhR4DvD/
[10:09] <xnox> cjwatson, thanks.
[10:09] <xnox> it is coming from systemd-tmpfiles.
[10:10] <cjwatson> I was just about to say
[10:10] <cjwatson> I have the debootstrap wreckage here if you want me to investigate anything
[10:10] <xnox> cjwatson, well, does /var/spool/rsyslog exist =) and would running the upgraded postinst, closer to the old one work? this one:
[10:11] <xnox> cjwatson, http://paste.ubuntu.com/p/TnGw7QxdwF/
[10:11] <cjwatson> Both of the directories it's complaining about exist.  I suspect that the ENOENT is on /proc/self/fd/5, not those directories
[10:11] <xnox> ack, so the fix i uploaded now, should "work".
[10:12] <xnox> because proc is not mounted?!
[10:14] <xnox> reading tmpfiles.c in systemd it is.... odd....
[10:14] <xnox> open an fd with fancy flags; and then chmod not the path we ask... but /proc/self/fd/$fd .... why it does it that way, i don't know.
[10:15] <cjwatson> I think /proc must indeed be unmounted, but why
[10:15] <cjwatson> debootstrap bug maybe?
[10:16] <cjwatson> debootstrap changed 22 hours ago in cosmic
[10:16] <cjwatson> I don't really feel that working around a debootstrap bug in rsyslog is likely to be correct
[10:17] <xnox> cjwatson, i've seen this sort of failure, on and off, ever since trying to migrate the new debootstrap in cosmic.
[10:17] <cjwatson> p.s. "paper over" not "pepper over" :)
[10:18] <xnox> e.g. livecd-rootfs autopkgtest, triggered by new debootstrap, was showing above symptoms (failing to configure rsyslog a few times in a row, until fail)
[10:18] <cjwatson> hmm, there's stuff in the diff about lxc detection
[10:18] <xnox> cjwatson, =)))) oh really, world changed here. I thought everybody loves italian ground pepper =)
[10:19] <cjwatson> debootstrap 1.0.105 just doesn't mount /proc and /sys if it's running inside lxc, wtf
[10:20] <cjwatson> so you should be able to reproduce this simply by running debootstrap on cosmic inside a lxd container
[10:20] <xnox> fun
[10:20]  * cjwatson tries to work out what henrich@ was thinking
[10:22] <cjwatson> maybe something about unprivileged containers
[10:22] <xnox> well, in schroot = apt install rsyslog systemd; umount /proc; dpkg-reconfigure rsyslog => does the fail too. Imho it is valid for rsyslog to be configurable without /proc mounted.
[10:22] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731802
[10:22] <ubot5> Debian bug 731802 in debootstrap "debootstrap: Doesn't work in LXC containers" [Normal,Fixed]
[10:27] <cjwatson> let's see if I can reproduce it with a plain unstable container and debootstrapping sid, 'cause then I can file it as a Debian bug and make it henrich@'s problem :P
[11:03] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (cosmic-proposed/main) [4.17.0-4.5] (core, kernel)
[11:03] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (cosmic-proposed/main) [4.17.0-4.5] (core, kernel)
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (cosmic-proposed) [4.17.0-4.5]
[11:04] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (cosmic-proposed) [4.17.0-4.5]
[11:09]  * Ukikie looks at https://salsa.debian.org/installer-team/debootstrap/merge_requests/13
[11:09] <gitlab-bot> Debian Installer issue (Merge request) 13 in debootstrap "Use $container to detect systemd-nspawn and lxc-libvirt (Closes: #902350)" (comments: 5) [Merged]
[11:13] <cjwatson> it's in that general area, yes
[11:21] <seb128> LocutusOfBorg, no, the version is not wrong, the only requirement afaik is that "bionic_version < bionic_sru_version <= cosmic_version"
[11:21] <seb128> LocutusOfBorg, you can argue that ~artful < ~zesty and such codenames are not the best
[11:21] <seb128> LocutusOfBorg, but for that bionic specific SRU I don't think there is any issue, out of trying to be pedentic
[11:41] <LocutusOfBorg> seb128, I'm not arguing this works in this case, but better not "advertise" such choices, because they won't work with LTS (e.g. trusty, xenial)
[11:42] <LocutusOfBorg> so, better avoid them and use the general versioning that always works :)
[11:42] <seb128> LocutusOfBorg, you use the versions you want, it's your choice :)
[11:43] <LocutusOfBorg> sure :)
[11:44] -queuebot:#ubuntu-release- Unapproved: unity-settings-daemon (bionic-proposed/universe) [15.04.1+18.04.20180413-0ubuntu1 => 15.04.1+18.04.20180413-0ubuntu1.1] (mythbuntu)
[11:46] <seb128> LocutusOfBorg, if you think a consistent versioning should be enforced for SRU I'm not against it, but the correct people to talk about that is the SRU team to get them to agree and update the SRU guidelines
[11:54] <rbasak> Personally I'd prefer to always be followed except when an exception is really required. For consistency.
[11:54] <rbasak> Uh, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging to always be followed
[11:54] <rbasak> Consistency = easier onboarding for new developers
[11:56] <rbasak> Not sure if this case is exactly on that page, but for the same principle of consistency, I much prefer using release numbers instead of codenames because release names always work and are therefore more consistent.
[11:56] <seb128> wfm and makes sense, but ideally it should be documented as the preferred option on the SRU documentation
[11:56] <seb128> otherwise you can't expect people to follow it
[11:56] <rbasak> My plan is to push on this more once "git ubuntu lint" reaches 1.0, since then people will have tooling to help them follow it.
[11:57] <rbasak> because release _numbers_ always work
[11:58] <rbasak> Yeah - right now I'm not particularly enforcing anything. I reluctantly accept version strings I'm not particularly happy with but that have been acceptable historically.
[11:59] <seb128> well, it would hurt to hint on the recommend/preferred versioning on the wiki
[11:59] <seb128> you would probably have more uploads in line with what you prefer
[12:00] <rbasak> I agree, but it's effort to drive consensus within the SRU team on that before I can edit the page.
[12:00] <seb128> I pick randomnly because we don't have a documented preferred way but I would follow it if we had one
[12:00] <rbasak> I want to expend that effort, but I was deferring it to do it when I can recommend a lint tool to go along with it.
[12:00] <rbasak> The SRU page does recommend https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging, no?
[12:01] <seb128> rbasak, that's SecurityTeam
[12:01] <rbasak> It's linked from the SRU procedure.
[12:01] <rbasak> IMHO, that's a recommendation
[12:02] <seb128> "which can be used for SRUs." doesn't really hint it's one
[12:02] <seb128> or maybe it's just my english not being good
[12:03] <seb128> to me it sounds more like a "btw, that's one option which some people are using"
[12:03] <seb128> not "that's the one we would prefer you to use"
[12:04] <rbasak> Hmm, OK.
[12:04] <rbasak> Perhaps asking the SRU team to make it more obviously and formally a recommendation would be easier to drive.
[12:09] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (bionic-proposed) [2.02-2ubuntu8.1]
[12:09] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (bionic-proposed) [2.02-2ubuntu8.1]
[12:14] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [amd64] (xenial-proposed/main) [4.15.0-25.27~16.04.1] (kernel)
[12:14] -queuebot:#ubuntu-release- New binary: linux-signed-hwe [ppc64el] (xenial-proposed/main) [4.15.0-25.27~16.04.1] (kernel)
[12:30] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [amd64] (xenial-proposed) [4.15.0-25.27~16.04.1]
[12:30] -queuebot:#ubuntu-release- New: accepted linux-signed-hwe [ppc64el] (xenial-proposed) [4.15.0-25.27~16.04.1]
[12:51] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (bionic-proposed/main) [4.15.0-25.27] (core, kernel)
[12:51] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (bionic-proposed/main) [4.15.0-25.27] (core, kernel)
[12:59] <Trevinho> sru team, could you please check the SRU queue for nux + xorg packages please? :)
=== freyes__ is now known as freyes
[14:13] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (bionic-proposed) [4.15.0-25.27]
[14:13] -queuebot:#ubuntu-release- New: accepted linux-signed [ppc64el] (bionic-proposed) [4.15.0-25.27]
[14:51] -queuebot:#ubuntu-release- Unapproved: keepalived (bionic-proposed/main) [1:1.3.9-1build1 => 1:1.3.9-1ubuntu0.18.04.1] (ubuntu-server)
[15:10] <slangasek> xnox: "livecd-rootfs autopkgtest triggered by new debootstrap was showing above symptoms" so the new debootstrap was fixed enough to make the autopkgtests pass, but nothing else? cute.
[15:13] <Laney> I thought the livecd-rootfs tests were all isolation-machine?
[15:14] <cjwatson> I just filed the debootstrap bug upstream - will give you the bug number once I have it
[15:14] <cjwatson> Laney: that wouldn't be LXD, right?
[15:15] <Laney> No but maybe they set up a container or something on their own
[15:15] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/l/livecd-rootfs/20180623_123249_4c7a4@/log.gz xnox is probably referring to e.g. this one
[15:16] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902924
[15:16] <ubot5> Debian bug 902924 in debootstrap "debootstrap: doesn't mount /proc when building chroot inside LXD container" [Important,Open]
[15:16] <cjwatson> I'll leave any mitigation up to other people - that's hopefully enough analysis to be going on with
[15:17] <Laney> 1.104 was enough to fix the tests anyway
[15:40] <slangasek> infinity: where are you at with LP: #1766513?
[15:40] <ubot5> Launchpad bug 1766513 in ubuntu-dev-tools (Ubuntu Artful) "RM: pkg-create-dbgsym: obsolete, debhelper conflicts" [High,Triaged] https://launchpad.net/bugs/1766513
[15:48] <xnox> slangasek, basically systemd-tmpfiles is stupid, and fails without /proc mounted.
[15:48] <xnox> slangasek, is alternative explanation =)
[15:49] <slangasek> right, well, /proc should not be un-mounted
[16:10] <sil2100> infinity: hey! The bionic images seem to fail to build due to the initrd being busted - could you get the same fixes that you did for cosmic into bionic as well?
[16:10]  * sil2100 has bad luck and everytime he needs a new image for testing it just fails to build
[16:23] <acheronuk> sil2100: is the live-build in the bionic unapproved queue not said fix?
[16:24] <sil2100> acheronuk: good catch o/
[16:24] <sil2100> I guess I'll review that
[16:25] <acheronuk> :)
[16:25] <sil2100> infinity: ^
[16:26] -queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.5-0ubuntu1 => 2:17.0.5-0ubuntu2] (openstack, ubuntu-server)
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (bionic-proposed) [3.0~a57-1ubuntu34.1]
[16:46] <sil2100> infinity: approved if anything
[16:46] <sil2100> o/
[17:18] -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.5 => 0.32~16.04.6] (no packageset)
[17:23] -queuebot:#ubuntu-release- Unapproved: lxd (xenial-backports/main) [3.0.1-0ubuntu1~16.04.1 => 3.0.1-0ubuntu1~16.04.2] (edubuntu, ubuntu-server)
[17:25] -queuebot:#ubuntu-release- New binary: cakephp [amd64] (cosmic-proposed/universe) [2.10.11-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- Unapproved: accepted lxd [source] (xenial-backports) [3.0.1-0ubuntu1~16.04.2]
[18:52] -queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.2 => 2:13.1.4-0ubuntu4.3] (openstack, ubuntu-server)
[18:53] <m0x90> Hello, I noticed that the amd64 package linux-image-4.15.0-24-generic-dbgsym is not in http://ddebs.ubuntu.com/pool/main/l/linux-hwe/. Instead only an unsigned one is present.
[18:55] <sarnold> thishttp://ddebs.ubuntu.com/pool/main/l/linux-hwe/linux-image-4.15.0-24-generic-dbgsym_4.15.0-24.26~16.04.1_arm64.ddeb ?
[18:57] <m0x90> sarnold: that's arm64, not amd64
[18:57]  * sarnold fails
[18:57] <m0x90> :)
[18:57] <sarnold> well... buy a cavium? :D
[18:57] <sarnold> (hahaha yeah, right, like they'd make it easy to buy one ..)
[19:03] <infinity> m0x90: http://ddebs.ubuntu.com/pool/main/l/linux-signed-hwe/
[19:05] <sarnold> 2.8KB? seems kinda smallish for debug symbols
[19:06] <infinity> sarnold: It almost certainly just depends on the -unsigned one. :P
[19:06] <infinity> Since signed/unsigned are the same binary, modulo attached signature.
[19:06] <sarnold> aha :) thanks infinity :)
[19:38] -queuebot:#ubuntu-release- Unapproved: installation-guide (bionic-proposed/main) [20160121ubuntu4 => 20160121ubuntu4.1] (core)
[19:40] -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.6]
[20:05] <m0x90> infinity: thanks! do you know why it would be released unsigned just for amd64? trying to understand the rational so I can break some install scripts consistently :)
[20:06] <infinity> m0x90: All the kernels built from the linux (or, in this case, linux-hwe) source are unsigned.  They're only labelled "unsigned" if there's also a "signed" version produced from linux-signed.
[20:08] <infinity> Although, I thought we changed that entirely...
[20:08] <infinity> Now that I think about it.
[20:09] <infinity> Ahh, yeah, the placement of those files on ddebs is just a server side archive bug. :P
[20:09] <infinity> I think.
[20:09] <infinity> m0x90: Really, relying on file paths is your bug, though.
[20:10] <infinity> m0x90: There's a reason this stuff is accessible via apt.
[20:10] <infinity> m0x90: File paths shouldn't be a thing you assume.
[20:12] <infinity> m0x90: Also, if you're hardcoding paths, I assume you're also doing something evil with wget/curl, which means you're not verifying signatures and could be MITMed.
[20:13] <infinity> m0x90: Always better to fetch your packages via apt.
[20:13] <m0x90> infinity: fair, just wanted to understand the difference between archs
[23:14] -queuebot:#ubuntu-release- New binary: libnumbertext [s390x] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: libnumbertext [ppc64el] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: zoneminder [s390x] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: zoneminder [ppc64el] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: libnumbertext [i386] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:17] -queuebot:#ubuntu-release- New binary: libnumbertext [amd64] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:18] -queuebot:#ubuntu-release- New binary: libnumbertext [arm64] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: zoneminder [arm64] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: zoneminder [armhf] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: libnumbertext [armhf] (cosmic-proposed/universe) [1.0-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: zoneminder [i386] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: zoneminder [amd64] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)