/srv/irclogs.ubuntu.com/2018/07/03/#ubuntu-release.txt

-queuebot:#ubuntu-release- New: accepted pmdk [source] (cosmic-proposed) [1.4-0ubuntu1]00:32
-queuebot:#ubuntu-release- Unapproved: accepted packagekit [source] (bionic-proposed) [1.1.9-1ubuntu2.18.04.1]00:43
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (bionic-proposed) [2.33.1+18.04ubuntu1]00:49
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (artful-proposed) [2.33.1+17.10ubuntu1]00:50
-queuebot:#ubuntu-release- New binary: pmdk [amd64] (cosmic-proposed/universe) [1.4-0ubuntu1] (no packageset)01:07
=== maclin1 is now known as maclin
tsimonq2Harumph.04:36
tsimonq2https://launchpadlibrarian.net/376840028/buildlog_ubuntu_cosmic_amd64_lubuntu_BUILDING.txt.gz04:36
tsimonq2xnox: Your rsyslog update likely broke this.04:39
tsimonq2er04:39
tsimonq2I can't read dates, apparently.04:39
tsimonq2Nevermind, although your help in figuring this out would be appreciated.04:39
flocculantappears to be affecting Xubuntu as well04:41
tsimonq2It should, theoretically, affect all images 20180702 and on.04:41
flocculantyea04:41
flocculantmate failed an hour ago04:42
tsimonq2Theoretically, Cosmic debootstraps should also fail.04:44
tsimonq2Trying to repro now.04:44
tsimonq2Oh, that worked.04:53
slangasektsimonq2, 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:08
slangasekmaybe it's reproducible specifically in the container environment used in launchpad; I am lacking documentation on how to reproduce that environment locally05:10
slangasekcjwatson: ^^ I missed your presentation at the sprint, so I don't know how to reproduce the current failures affecting all cosmic livefs builds05:11
flocculantslangasek: thanks for the info :)05:12
tsimonq2slangasek: Thanks05:37
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (xenial-proposed) [2.33.1ubuntu1]06:35
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-report [source] (bionic-proposed) [1.2.0~bionic]06:45
-queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (bionic-proposed) [237-3ubuntu10.2]06:57
LocutusOfBorgcan we please blacklist this test? http://autopkgtest.ubuntu.com/packages/p/pinentry/cosmic/i38608:13
LocutusOfBorgit passed once, I don't know why, but it is obviously flaky08:13
-queuebot:#ubuntu-release- Unapproved: gnome-twitch (bionic-proposed/universe) [0.4.1-2 => 0.4.1-3~bionic1] (no packageset)08:50
xnoxtsimonq2, it was failing for a while (debootstrap, under live build)09:22
xnoxtsimonq2, i've seen that before, but never managed to reproduce, or figure out what's wrong with rsyslog =/09:23
xnoxtsimonq2, i can upload a better bootstrapable rsyslog anyway, just in case.09:31
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
LocutusOfBorgwho is doing this stuff?09:33
LocutusOfBorgseb128, ^^ isn't such versioning wrong?09:34
LocutusOfBorgwhy did we stop using release numbers (that are guaranteed to be incremental)?09:34
LocutusOfBorgtsimonq2, ^^ this was also your question :)09:34
cjwatsonslangasek,tsimonq2,xnox: I've reproduced it locally10:06
cjwatsonhttps://paste.ubuntu.com/p/DdsyhR4DvD/10:07
xnoxcjwatson, thanks.10:09
xnoxit is coming from systemd-tmpfiles.10:09
cjwatsonI was just about to say10:10
cjwatsonI have the debootstrap wreckage here if you want me to investigate anything10:10
xnoxcjwatson, well, does /var/spool/rsyslog exist =) and would running the upgraded postinst, closer to the old one work? this one:10:10
xnoxcjwatson, http://paste.ubuntu.com/p/TnGw7QxdwF/10:11
cjwatsonBoth of the directories it's complaining about exist.  I suspect that the ENOENT is on /proc/self/fd/5, not those directories10:11
xnoxack, so the fix i uploaded now, should "work".10:11
xnoxbecause proc is not mounted?!10:12
xnoxreading tmpfiles.c in systemd it is.... odd....10:14
xnoxopen 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:14
cjwatsonI think /proc must indeed be unmounted, but why10:15
cjwatsondebootstrap bug maybe?10:15
cjwatsondebootstrap changed 22 hours ago in cosmic10:16
cjwatsonI don't really feel that working around a debootstrap bug in rsyslog is likely to be correct10:16
xnoxcjwatson, i've seen this sort of failure, on and off, ever since trying to migrate the new debootstrap in cosmic.10:17
cjwatsonp.s. "paper over" not "pepper over" :)10:17
xnoxe.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
cjwatsonhmm, there's stuff in the diff about lxc detection10:18
xnoxcjwatson, =)))) oh really, world changed here. I thought everybody loves italian ground pepper =)10:18
cjwatsondebootstrap 1.0.105 just doesn't mount /proc and /sys if it's running inside lxc, wtf10:19
cjwatsonso you should be able to reproduce this simply by running debootstrap on cosmic inside a lxd container10:20
xnoxfun10:20
* cjwatson tries to work out what henrich@ was thinking10:20
cjwatsonmaybe something about unprivileged containers10:22
xnoxwell, 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
cjwatsonhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=73180210:22
ubot5Debian bug 731802 in debootstrap "debootstrap: Doesn't work in LXC containers" [Normal,Fixed]10:22
cjwatsonlet'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 :P10:27
-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:03
-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:04
* Ukikie looks at https://salsa.debian.org/installer-team/debootstrap/merge_requests/1311:09
gitlab-botDebian Installer issue (Merge request) 13 in debootstrap "Use $container to detect systemd-nspawn and lxc-libvirt (Closes: #902350)" (comments: 5) [Merged]11:09
cjwatsonit's in that general area, yes11:13
seb128LocutusOfBorg, no, the version is not wrong, the only requirement afaik is that "bionic_version < bionic_sru_version <= cosmic_version"11:21
seb128LocutusOfBorg, you can argue that ~artful < ~zesty and such codenames are not the best11:21
seb128LocutusOfBorg, but for that bionic specific SRU I don't think there is any issue, out of trying to be pedentic11:21
LocutusOfBorgseb128, 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:41
LocutusOfBorgso, better avoid them and use the general versioning that always works :)11:42
seb128LocutusOfBorg, you use the versions you want, it's your choice :)11:42
LocutusOfBorgsure :)11:43
-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:44
seb128LocutusOfBorg, 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 guidelines11:46
rbasakPersonally I'd prefer to always be followed except when an exception is really required. For consistency.11:54
rbasakUh, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging to always be followed11:54
rbasakConsistency = easier onboarding for new developers11:54
rbasakNot 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
seb128wfm and makes sense, but ideally it should be documented as the preferred option on the SRU documentation11:56
seb128otherwise you can't expect people to follow it11:56
rbasakMy 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:56
rbasakbecause release _numbers_ always work11:57
rbasakYeah - 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:58
seb128well, it would hurt to hint on the recommend/preferred versioning on the wiki11:59
seb128you would probably have more uploads in line with what you prefer11:59
rbasakI agree, but it's effort to drive consensus within the SRU team on that before I can edit the page.12:00
seb128I pick randomnly because we don't have a documented preferred way but I would follow it if we had one12:00
rbasakI 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
rbasakThe SRU page does recommend https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging, no?12:00
seb128rbasak, that's SecurityTeam12:01
rbasakIt's linked from the SRU procedure.12:01
rbasakIMHO, that's a recommendation12:01
seb128"which can be used for SRUs." doesn't really hint it's one12:02
seb128or maybe it's just my english not being good12:02
seb128to me it sounds more like a "btw, that's one option which some people are using"12:03
seb128not "that's the one we would prefer you to use"12:03
rbasakHmm, OK.12:04
rbasakPerhaps asking the SRU team to make it more obviously and formally a recommendation would be easier to drive.12:04
-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:09
-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:14
-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:30
-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:51
Trevinhosru team, could you please check the SRU queue for nux + xorg packages please? :)12:59
=== freyes__ is now known as freyes
-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:13
-queuebot:#ubuntu-release- Unapproved: keepalived (bionic-proposed/main) [1:1.3.9-1build1 => 1:1.3.9-1ubuntu0.18.04.1] (ubuntu-server)14:51
slangasekxnox: "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:10
LaneyI thought the livecd-rootfs tests were all isolation-machine?15:13
cjwatsonI just filed the debootstrap bug upstream - will give you the bug number once I have it15:14
cjwatsonLaney: that wouldn't be LXD, right?15:14
LaneyNo but maybe they set up a container or something on their own15:15
Laneyhttps://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 one15:15
cjwatsonhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=90292415:16
ubot5Debian bug 902924 in debootstrap "debootstrap: doesn't mount /proc when building chroot inside LXD container" [Important,Open]15:16
cjwatsonI'll leave any mitigation up to other people - that's hopefully enough analysis to be going on with15:16
Laney1.104 was enough to fix the tests anyway15:17
slangasekinfinity: where are you at with LP: #1766513?15:40
ubot5Launchpad bug 1766513 in ubuntu-dev-tools (Ubuntu Artful) "RM: pkg-create-dbgsym: obsolete, debhelper conflicts" [High,Triaged] https://launchpad.net/bugs/176651315:40
xnoxslangasek, basically systemd-tmpfiles is stupid, and fails without /proc mounted.15:48
xnoxslangasek, is alternative explanation =)15:48
slangasekright, well, /proc should not be un-mounted15:49
sil2100infinity: 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 build16:10
acheronuksil2100: is the live-build in the bionic unapproved queue not said fix?16:23
sil2100acheronuk: good catch o/16:24
sil2100I guess I'll review that16:24
acheronuk:)16:25
sil2100infinity: ^16:25
-queuebot:#ubuntu-release- Unapproved: nova (bionic-proposed/main) [2:17.0.5-0ubuntu1 => 2:17.0.5-0ubuntu2] (openstack, ubuntu-server)16:26
-queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (bionic-proposed) [3.0~a57-1ubuntu34.1]16:32
sil2100infinity: approved if anything16:46
sil2100o/16:46
-queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.32~16.04.5 => 0.32~16.04.6] (no packageset)17:18
-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:23
-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]17:25
-queuebot:#ubuntu-release- Unapproved: nova (xenial-proposed/main) [2:13.1.4-0ubuntu4.2 => 2:13.1.4-0ubuntu4.3] (openstack, ubuntu-server)18:52
m0x90Hello, 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:53
sarnoldthishttp://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:55
m0x90sarnold: that's arm64, not amd6418:57
* sarnold fails18:57
m0x90:)18:57
sarnoldwell... buy a cavium? :D18:57
sarnold(hahaha yeah, right, like they'd make it easy to buy one ..)18:57
infinitym0x90: http://ddebs.ubuntu.com/pool/main/l/linux-signed-hwe/19:03
sarnold2.8KB? seems kinda smallish for debug symbols19:05
infinitysarnold: It almost certainly just depends on the -unsigned one. :P19:06
infinitySince signed/unsigned are the same binary, modulo attached signature.19:06
sarnoldaha :) thanks infinity :)19:06
-queuebot:#ubuntu-release- Unapproved: installation-guide (bionic-proposed/main) [20160121ubuntu4 => 20160121ubuntu4.1] (core)19:38
-queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.32~16.04.6]19:40
m0x90infinity: 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:05
infinitym0x90: 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:06
infinityAlthough, I thought we changed that entirely...20:08
infinityNow that I think about it.20:08
infinityAhh, yeah, the placement of those files on ddebs is just a server side archive bug. :P20:09
infinityI think.20:09
infinitym0x90: Really, relying on file paths is your bug, though.20:09
infinitym0x90: There's a reason this stuff is accessible via apt.20:10
infinitym0x90: File paths shouldn't be a thing you assume.20:10
infinitym0x90: 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:12
infinitym0x90: Always better to fetch your packages via apt.20:13
m0x90infinity: fair, just wanted to understand the difference between archs20:13
-queuebot:#ubuntu-release- New binary: libnumbertext [s390x] (cosmic-proposed/universe) [1.0-2] (no packageset)23:14
-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:15
-queuebot:#ubuntu-release- New binary: libnumbertext [i386] (cosmic-proposed/universe) [1.0-2] (no packageset)23:16
-queuebot:#ubuntu-release- New binary: libnumbertext [amd64] (cosmic-proposed/universe) [1.0-2] (no packageset)23:17
-queuebot:#ubuntu-release- New binary: libnumbertext [arm64] (cosmic-proposed/universe) [1.0-2] (no packageset)23:18
-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:19
-queuebot:#ubuntu-release- New binary: libnumbertext [armhf] (cosmic-proposed/universe) [1.0-2] (no packageset)23:20
-queuebot:#ubuntu-release- New binary: zoneminder [i386] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)23:21
-queuebot:#ubuntu-release- New binary: zoneminder [amd64] (cosmic-proposed/universe) [1.30.4+dfsg1-4] (no packageset)23:22

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