[00:10] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-disconnect-wifi (eoan-proposed/universe) [21-1~exp1 => 21-1] (no packageset) (sync)
[00:11] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-disconnect-wifi [sync] (eoan-proposed) [21-1]
[00:12] -queuebot:#ubuntu-release- Unapproved: twitter-bootstrap4 (eoan-proposed/universe) [4.3.1+dfsg2-3 => 4.3.1+dfsg2-4] (no packageset) (sync)
[00:12] -queuebot:#ubuntu-release- Unapproved: accepted twitter-bootstrap4 [sync] (eoan-proposed) [4.3.1+dfsg2-4]
[05:03] -queuebot:#ubuntu-release- Unapproved: synaptic (eoan-proposed/universe) [0.84.6ubuntu2 => 0.84.6ubuntu3] (no packageset)
[05:04] -queuebot:#ubuntu-release- Unapproved: accepted synaptic [source] (eoan-proposed) [0.84.6ubuntu3]
=== andrewc is now known as Guest82583
=== andrewc_ is now known as acloke
[06:59] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (bionic-proposed/main) [2:10.3.10-1~ubuntu0.18.04.1 => 2:10.3.10-1~ubuntu0.18.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[07:00] -queuebot:#ubuntu-release- Unapproved: open-vm-tools (disco-proposed/main) [2:10.3.10-1 => 2:10.3.10-1ubuntu0.19.04.1] (edubuntu, ubuntu-cloud, ubuntu-desktop, ubuntu-server)
[07:37] -queuebot:#ubuntu-release- Unapproved: qrencode (eoan-proposed/universe) [4.0.2-1 => 4.0.2-2] (kubuntu) (sync)
[08:54] -queuebot:#ubuntu-release- Unapproved: openstack-trove (eoan-proposed/universe) [1:12.0.0~rc1-0ubuntu2 => 1:12.0.0~rc1-0ubuntu3] (no packageset)
[08:55] -queuebot:#ubuntu-release- Unapproved: accepted openstack-trove [source] (eoan-proposed) [1:12.0.0~rc1-0ubuntu3]
[08:58] <LocutusOfBorg> infinity, so I fixed it and uploaded on both Debian new queue and eoan
[09:01] <infinity> LocutusOfBorg: "It"?
[09:01] <infinity> Ahh, qr-tools.
[09:02] -queuebot:#ubuntu-release- Unapproved: qr-tools (eoan-proposed/universe) [1.4~bzr32-1 => 2.0~bzr33-1~build1] (no packageset)
[09:02] <LocutusOfBorg> it is a really nice package, I know why you wanted me to resurrect it
[09:03] -queuebot:#ubuntu-release- Unapproved: accepted qr-tools [source] (eoan-proposed) [2.0~bzr33-1~build1]
[09:03] <LocutusOfBorg> I think I'll use it :D
[09:03] <infinity> LocutusOfBorg: Of course, zbar is in a couple of images, so I won't be letting any of this migrate unless there's a respin trigger.
[09:04] <infinity> But at least we can let it build and test and it'll be ready in case.
[09:04] -queuebot:#ubuntu-release- New binary: qr-tools [amd64] (eoan-proposed/universe) [2.0~bzr33-1~build1] (no packageset)
[09:16] <infinity> LocutusOfBorg: Upstream bug, not yours, but they missed the 1.4->2.0 bump with /usr/lib/python3/dist-packages/qrtools-1.4.egg-info
[09:16] <infinity> LocutusOfBorg: Or maybe that's intentional until they do a real 2.0 release, I dunno.
[09:17] -queuebot:#ubuntu-release- New: accepted qr-tools [amd64] (eoan-proposed) [2.0~bzr33-1~build1]
[09:21] <LocutusOfBorg> infinity, is that important to bump?
[09:21] <LocutusOfBorg> I'll need a sourceful upload after debian clears new anyway...
[09:21] <LocutusOfBorg> let me open a merge request
[09:21] <infinity> LocutusOfBorg: Pretty sure it's mostly irrelevant, it's just clearly also not "correct".
[09:22] <LocutusOfBorg> thanks, will fix in a later upload then
[09:22] <LocutusOfBorg> DAMN MY FAULT
[09:25] -queuebot:#ubuntu-release- Unapproved: qr-tools (eoan-proposed/universe) [2.0~bzr33-1~build1 => 2.0~bzr33-1~build2] (no packageset)
[09:25] <LocutusOfBorg> ^^
[09:25] -queuebot:#ubuntu-release- Unapproved: accepted qr-tools [source] (eoan-proposed) [2.0~bzr33-1~build2]
[09:42] -queuebot:#ubuntu-release- Unapproved: python3.8 (eoan-proposed/universe) [3.8.0~rc1-3 => 3.8.0-1] (no packageset)
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted python3.8 [source] (eoan-proposed) [3.8.0-1]
[10:42] -queuebot:#ubuntu-release- Unapproved: node-clean-css (eoan-proposed/universe) [4.2.1+~4.2.1-2 => 4.2.1+~4.3.0-1] (no packageset) (sync)
[10:43] -queuebot:#ubuntu-release- Unapproved: accepted node-clean-css [sync] (eoan-proposed) [4.2.1+~4.3.0-1]
[10:55] -queuebot:#ubuntu-release- Unapproved: network-manager-applet (bionic-proposed/main) [1.8.10-2ubuntu2 => 1.8.10-2ubuntu3] (ubuntu-desktop)
[11:05] -queuebot:#ubuntu-release- Unapproved: diffoscope (eoan-proposed/universe) [125 => 126] (no packageset) (sync)
[11:06] -queuebot:#ubuntu-release- New sync: dleyna-renderer (eoan-proposed/primary) [0.6.0-1]
[11:06] -queuebot:#ubuntu-release- Unapproved: accepted diffoscope [sync] (eoan-proposed) [126]
[11:10] <rbalint> (ffe) can i sync wireshark 3.0.5-1 from unstable? it fixes one security issue and upstream microreleases are released to -security anyway http://metadata.ftp-master.debian.org/changelogs/main/w/wireshark/unstable_changelog
[11:15] <jbicha> rbalint: I'm not Release Team, but wireshark is unseeded universe so I'd probably go for it
[11:16] <rbalint> jbicha, me too, but i'd like to have an ack from the release team
[11:20] -queuebot:#ubuntu-release- Unapproved: sudo (eoan-proposed/main) [1.8.27-1ubuntu3 => 1.8.27-1ubuntu4] (core)
[11:21] <apw> rbalint, that it contains a security issue is pretty compelling
[11:25] <bdmurray> "pretty compelling" isn't an explict ack
[11:27] <sil2100> I'd say go for it
[11:29] <apw> bdmurray, no indeed, i was trying to read the Changelog diff since then
[11:37] <RikMills> iso respins for sudo cve?
[11:41] -queuebot:#ubuntu-release- Unapproved: wireshark (eoan-proposed/universe) [3.0.3-1 => 3.0.5-1] (no packageset) (sync)
[11:42] -queuebot:#ubuntu-release- Unapproved: accepted wireshark [sync] (eoan-proposed) [3.0.5-1]
[11:42] <apw> rbalint, from a naieve reading of the two version upstream changelogs I cannot see any features expressed of note either
[11:44] <rbalint> apw, there are some upstream changes which can be seen as features so i preferred asking https://www.wireshark.org/docs/relnotes/wireshark-3.0.4.html
[11:45] <rbalint> thanks for the accept!
[11:45] <apw> rbalint, most of the 'features' felt windoze-y ... anyhow i am happy with it ... and the bot was too
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted sudo [source] (eoan-proposed) [1.8.27-1ubuntu4]
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Final] has been updated (20191015)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Eoan Final] has been updated (20191015)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Eoan Final] has been updated (20191015)
[12:18] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Eoan Final] has been updated (20191015)
[12:20] <LocutusOfBorg> RikMills, why is a respin needed? sudo doesn't affect iso images...
[12:21] <LocutusOfBorg> its a corner condition cve in my opinion
[12:21] <RikMills> LocutusOfBorg: someone asked me to ask
[12:29] <infinity> RikMills: I'm going to shove it in -security for now, if there's call to respin for other reasons, I'll move it to release and include sudo in the respin.
[12:29] <RikMills> fair enough.
[12:42] <ahasenack> is there a known network issue with subiquity in the 20191014 iso by any change? I can't get wired networking up with that image
[12:44] <xnox> ahasenack:  in what sence?
[12:44] <xnox> ahasenack: is the network card appears on the netplan stage?
[12:44] <xnox> ahasenack:  did it try to dhcp and fail? did you setup vlan, etc?
[12:46] <ahasenack> dmesg reports ""A link change request failed with some changes committed already. Interface enp0s25 may have been left with an inconsistent configuration, please check""
[12:46] <ahasenack> booting the desktop pendrive works just fine
[12:46] <ahasenack> I'll try again now, I wrote the image to the pendrive one more time, but iso image checked out ok (md5/gpg)
[12:48] <xnox> ahasenack:  drop to shell, and fetch logs.
[12:48] <ahasenack> yeah
[12:48] <ahasenack> was just making sure it wasn't hardware related
[12:49] <xnox> ahasenack:  if you are booting off a usb, you can just unplug it after the install and plug into desktop, it should have all the logs stored ephemerally on the usb stick itself.
[12:50] <ahasenack> that's new, let me try
[12:50] <ahasenack> I was planning on sticking in another pendrive to save them
[12:50] <ahasenack> ok, booted up, same thing
[12:51] <ahasenack> xnox: in "casper-rw"?
[12:51] <xnox> yeah
[12:52] <ahasenack> yeah, got it
[12:52] <xnox> and then file a bug report
[12:54] <ahasenack> xnox: https://bugs.launchpad.net/subiquity/+bug/1848199 attaching files now, kern.log is there already
[12:54] <ubot5> Launchpad bug 1848199 in subiquity "iso 20191014: no wired network" [Undecided,New]
[12:55] -queuebot:#ubuntu-release- Unapproved: pyudev (eoan-proposed/main) [0.21.0-1ubuntu1 => 0.21.0-2] (ubuntu-desktop) (sync)
[12:55] -queuebot:#ubuntu-release- Unapproved: chromium-browser (eoan-proposed/universe) [76.0.3809.100-0ubuntu1~snap1 => 77.0.3865.120-0ubuntu1~snap1] (ubuntu-desktop)
[13:03] <xnox> ahasenack:  i think that's related
[13:03] <xnox> ahasenack:  we are respinning new iso
[13:04] <ahasenack> the 10291015 one from a few lines up?
[13:04] <ahasenack> er, 20191015
[13:04] <xnox> yes pleae
[13:04] <xnox> ahasenack:  use zsync to download it
[13:04] <xnox> should be quick
[13:04] -queuebot:#ubuntu-release- Unapproved: pyjwt (eoan-proposed/main) [1.7.0-2 => 1.7.0-2ubuntu1] (core)
[13:04] <ahasenack> it's not done yet, is it?
[13:04] <xnox> ahasenack:  it's there in pending
[13:05] <xnox> ahasenack:  http://cdimage.ubuntu.com/ubuntu-server/daily-live/20191015/
[13:05] <ahasenack> http://cdimage.ubuntu.com/daily-live/pending/ has the 20191014 date
[13:05] <infinity> ahasenack: That's desktop
[13:05] <ahasenack> ah right
[13:08] <ahasenack> ok, writing
[13:10] <sil2100> infinity, bdmurray: https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1848001
[13:10] <ubot5> Launchpad bug 1848001 in steam (Ubuntu) "libnvidia-gl-435:i386 not installed from Ubiquity checkbox in 19.10 beta" [Undecided,Confirmed]
[13:13] <ahasenack> xnox: same thing with 20191015
[13:14] <ahasenack> if I run dhclient enp0s25 manually, it gets an ip
[13:15] <ahasenack> but a bit ugly, it has an md5sum error on a non-existent file in /run/systemd/....... (I've seen that before, a long time ago...)
[13:15] <bdmurray> in a galaxy far far away
[13:32] <sil2100> plars, cwayne: hey! Was just wondering how the current candidate images are looking from the pi POV - since the image testing board results look a bit worrying
[13:33] <sil2100> plars, cwayne: since I'm seeing some issues in fetching CM3 and CM3+ test results for both armhf and arm64, even after re-runs I suppose
[13:33] <sil2100> plars, cwayne: I mean, we didn't have any changes landing yesterday that could affect those devices
[13:33] <plars> sil2100: I'm working on that now, don't be alarmed. The images should look just fine for everything except cm3, but that's something I need to fix on our side. I need to try pi4 too, but so far it's looking fine
[13:34] <sil2100> plars: phew, thank you!
[13:34] <sil2100> plars: what's up with cm3?
[13:34] <xnox> ahasenack:  is that a virtual machine?
[13:34] <xnox> ahasenack:  can you dump your config for me?
[13:34] <xnox> ahasenack:  which hypervisor are you using?
[13:35] <plars> sil2100: sorry for the noisy results on cm3 - it's just the forced password change thing. The way the default user gets created on those was not the greatest, but I'd rather not fix it until after we are done with the release. I can force it if I catch it at the right moment, and it works fine if I do it the same way as the others.  Just something to clean up post-eoan
[13:35] <sil2100> Ok, no worries!
[13:36] <xnox> ahasenack:  your screenshot doesn't match your old logs?
[13:36] <sil2100> Thanks again
[13:36] <xnox> ahasenack:  do you have new logs?
[13:36] <sil2100> plars: once you confirm all the devices work, could you mark the pi images as 'passing' on the isotracker?
[13:36] <sil2100> http://iso.qa.ubuntu.com/qatracker/milestones/407/builds
[13:37] <plars> sil2100: I will - I did for the previous image too. There's the one known bug with rpi3ap noted but I know that was already discussed. Otherwise it's looking good
[13:39] <sil2100> plars: sweet, yes, we mentioned the A+ boot issues on the release notes already
[13:41] <ahasenack> xnox: screenshot was with 20191015 in a vm
[13:41] <ahasenack> xnox: logs are from a t420 with 20191014
[13:42] <ahasenack> xnox: since the same thing happene, I didn't attach logs again. And since it happens in a normal vm, you should be able to reproduce it?
[13:45] <ahasenack> xnox: but if you prefer, I can for sure attach 20191015 logs
[13:58] <xnox> ahasenack:  we are all good
[13:58] <xnox> ahasenack:  i think we know what's broken
[13:58] <ahasenack> ok
[13:58] <xnox> /etc/machine-id is broken, meaning that networkd dhcp client id is impossible to generate
[13:59] <ahasenack> ah, that was the other bug that I think paride filed
[13:59] <ahasenack> he hit that with preseeding
[14:03] <paride> ahasenack, yeah fixing machine-id seems to have fixed the networking issue too
[14:03] <ahasenack> so, new iso later today?
[14:03] <paride> ahasenack, for sure
[14:10] <Wimpress> sil2100: Ubuntu is also affected by nvidia driver issue. No i386 drivers installed by default.
[14:11] <Wimpress> This is a regression from 19.04.
[14:13] -queuebot:#ubuntu-release- Unapproved: casper (eoan-proposed/main) [1.425 => 1.426] (desktop-core, ubuntu-server)
[14:15] <Wimpress> tseliot: see above regarding nvidia drivers
[14:15] -queuebot:#ubuntu-release- Unapproved: accepted casper [source] (eoan-proposed) [1.426]
[14:16] <infinity> Wimpress: How is it a regression?
[14:17] <tseliot> Wimpress, do you mean, "installed" by ubiquity? As the nvidia-driver-$flavour metapackage recommends the i386 libraries on amd64
[14:17] <Wimpress> The i386 nvidia were installed by default on 19.04 is 3rd party drivers were selected in Ubiquity.
[14:18] <infinity> Are you... Sure?  That doesn't sound like a sane default behaviour.
[14:18] <Wimpress> Excuse typos. Using my phone while testing.
[14:19] <tseliot> if ubiquity calls the ubuntu-drivers tool, that will install the metapackage. Maybe the i386 recommended dependencies don't get installed
[14:20] <Wimpress> There are no i386 nvidia libraries seeded on the iso.
[14:21] <tseliot> were they ever?
[14:21] <infinity> No.
[14:21] <infinity> We didn't used to have nvidia drivers on the ISO at all.
[14:22] <tseliot> Wimpress, is this about Steam?
[14:22] <infinity> So you HAD to have internet to install 3rd party drivers.
[14:22] <Wimpress> Yep
[14:22] <infinity> Wimpress: Are you installing without a network?
[14:23] <Wimpress> Installing with network.
[14:24] <infinity> So, tseliot isn't wrong that the metapackage recommends cross-arch deps.
[14:24] <tseliot> Wimpress, then we should just fix steam (if that yes was in reply to my question)
[14:24] <Wimpress> Just testing Xubuntu, which does not seed nvidia drivers.
[14:24] <Wimpress> My yes reply, was regarding Steam.
[14:25] <Wimpress> Steam in Debian appears to have logic to conditionally install nvidia libs.
[14:25] <Wimpress> Haven't tested it. Just read the changelogs.
[14:25] <Wimpress> OK. This issue is not present on Xubuntu 19.10
[14:26] -queuebot:#ubuntu-release- Unapproved: ubuntu-meta (eoan-proposed/main) [1.439 => 1.440] (core)
[14:26] <Wimpress> Ubiquity installs i386 nvidia libs by default.
[14:26] <infinity> So, seeding it has broken it, due to only having one arch available?
[14:26] <Wimpress> Yep
[14:26] <infinity> Well done.
[14:26] <Wimpress> I'll come down.
[14:31] <tseliot> hmm... well, I can't do much about that (the problem caused by seeding nvidia), but I can have a look at Steam, and see if I can make it behave
[14:32] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.440]
[14:32] <Wimpress> tseliot: We're discussing options.
[14:34] <tseliot> ok
[14:36] -queuebot:#ubuntu-release- Unapproved: pyudev (eoan-proposed/main) [0.21.0-1ubuntu1 => 0.21.0-2] (ubuntu-desktop) (sync)
[15:29] -queuebot:#ubuntu-release- Unapproved: python3.7 (eoan-proposed/main) [3.7.5~rc1-2 => 3.7.5-1] (core)
[15:38] -queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (eoan-proposed/main) [3.7.5~rc1-1 => 3.7.5-1] (core)
[15:44] <jamespage> infinity: hi
[15:45] <jamespage> infinity: as openstack release is this week alongside eoan, would you prefer we SRU the RC-> release versions rather than generating a load of upload noise this week?
[15:45] -queuebot:#ubuntu-release- Unapproved: pyudev (eoan-proposed/main) [0.21.0-1ubuntu1 => 0.21.0-2] (ubuntu-desktop) (sync)
[15:45] -queuebot:#ubuntu-release- Unapproved: dell-recovery (eoan-proposed/universe) [1.62 => 1.63] (no packageset)
[15:46] <infinity> jamespage: I don't *mind* uploads this week, per se, but they need to be in unseeded packages or you won't get love.
[15:46] -queuebot:#ubuntu-release- Unapproved: accepted dell-recovery [source] (eoan-proposed) [1.63]
[15:56] <jamespage> infinity: ok might make a call on that late depending on how much release has been produced by openstack
[16:01] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (eoan-proposed/main) [1:3.34.1-1ubuntu1 => 1:3.34.1-1ubuntu2] (ubuntu-desktop)
[16:13] <vorlon> jibel: LP: #1848142 - there have been other reports of this but I haven't had a chance to try to reproduce it myself on hardware requiring dkms modules.  The apt term.log has been useless, it doesn't show any trigger activity at all
[16:13] <ubot5> Launchpad bug 1848142 in shim-signed (Ubuntu) "package shim-signed 1.39+15+1533136590.3beb971-0ubuntu1 failed to install/upgrade: installed shim-signed package post-installation script subprocess returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/1848142
[16:16] <vorlon> jibel: so if you can help me pin down what is the state of the package when this is happening, I would appreciate it.  (what's dpkg -l shim-signed, does it show the package in trigger-pending state?  What is the state of the debconf questions for the package? etc
[16:16] <vorlon> )
[16:16] <xnox> vorlon:  see cking words on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1840934
[16:16] <ubot5> Launchpad bug 1840934 in linux (Ubuntu) "Change kernel compression method to improve boot speed" [Medium,Fix released]
[16:19] <plars> sil2100: bdmurray: waveform: do you know if the wifi problems on rpi4 were fixed? Is there a bug for tracking that? I know the memory thing was fixed but wasn't sure about this yet
[16:20] <sil2100> plars: it should be fixed, yes
[16:20] <sil2100> plars: I did sponsor a linux-firmware-raspi2 upload for that last week, are you seeing something different?
[16:21] -queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (eoan-proposed/main) [3.7.5~rc1-1 => 3.7.5-1ubuntu1] (core)
[16:21] -queuebot:#ubuntu-release- Unapproved: python3.7 (eoan-proposed/main) [3.7.5~rc1-2 => 3.7.5-1ubuntu1] (core)
[16:21] <plars> sil2100: hmm, ok I hadn't heard that yet. I'm still seeing some problems I think. It works on rpi4 when I use NM, but not when I use netplan. With netplan it just goes into "configuring" state with networkctl but never finishes. Using the same exact environment/netplan yaml on a rpi3b+, it works though
[16:21] <bdmurray> plars: bug 1847782
[16:21] <ubot5> bug 1847782 in linux-firmware-raspi2 (Ubuntu) "Wifi absent on Pi 4" [Undecided,Fix released] https://launchpad.net/bugs/1847782
[16:22] <plars> bdmurray: ok, that's not the case here - it's not that it's absent, it's just that netplan doesn't seem to succeed in configuring it
[16:22] <doko> vorlon: fyi, ^^^ there are the two python3.7 and python3-stdlib-extensions uploads, as requested. is python3-stdlib-extensions really on any image?
[16:22] <bdmurray> plars: it'd be helpful if you reported that as a bug.
[16:23] <plars> bdmurray: in the middle of doing that now, just wanted to make sure that wasn't the same thing you already knew had been broken
[16:23] <bdmurray> plars: great, thanks!
[16:24] <cjwatson> doko: "seeded-in-ubuntu python3-stdlib-extensions" says that e.g. python3-gdbm and python3-lib2to3 are on several images (I haven't double-checked that)
[16:24] -queuebot:#ubuntu-release- Unapproved: rejected pyudev [sync] (eoan-proposed) [0.21.0-2]
[16:24] -queuebot:#ubuntu-release- Unapproved: rejected pyudev [sync] (eoan-proposed) [0.21.0-2]
[16:25] <doko> it's a pity about python3-lib2to3
[16:25] <doko> though not directly seeded
[16:26] <sil2100> plars: thanks! Hopefully waveform can take a look and maybe see what's happening
[16:32] -queuebot:#ubuntu-release- Unapproved: python3.8 (disco-proposed/universe) [3.8.0~a3-2 => 3.8.0-1~19.04] (no packageset)
[16:32] -queuebot:#ubuntu-release- New source: python3.8 (bionic-proposed/primary) [3.8.0-1~18.04]
[16:33] <xnox> infinity: Laney: https://paste.ubuntu.com/p/5JG5p7dqdw/
[16:49] <plars> sil2100: bdmurray: ok still investigating but it could just be due to the order some tests ran in. It looks like some earlier nm tests created a socket used by wpa-supplicant and left it there after the connection was removed. When netplan tried to configure things, it caused problems though. It looks like it might not be isolated to rpi4 and may just be an interaction between nm and netplan
[16:49] -queuebot:#ubuntu-release- Unapproved: python3-stdlib-extensions (disco-proposed/main) [3.7.3-1ubuntu1 => 3.7.5-1~19.04] (core)
[16:55] <sil2100> plars: that sounds better, phew, was worried for a moment
[16:56] <xnox> infinity:  https://paste.ubuntu.com/p/zkH4mwbzkz/
[17:10] <bdmurray> sil2100: bug 1847628
[17:10] <ubot5> bug 1847628 in ubiquity (Ubuntu) "When using swap in ZFS, system stops when you start using swap" [High,Confirmed] https://launchpad.net/bugs/1847628
[17:17] <jibel> vorlon, I haven't seen any other report. I'll try to reproduce it and provide more details.
[17:19] <bdmurray> jibel: we are looking into the above bug now
[17:19] <jibel> bdmurray, which one shim or swap?
[17:19] <bdmurray> jibel: swap
[17:21] <vorlon> jibel: there's a string of 3 recent bugs on shim, marked incomplete, all with the same symptom
[17:34] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Eoan Final] has been updated (20191015.1)
[17:34] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Eoan Final] has been updated (20191015.1)
[17:34] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Eoan Final] has been updated (20191015.1)
[17:34] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Eoan Final] has been updated (20191015.1)
[17:37] <jibel> bdmurray, you want the swap fixed for this release?
[17:39] <jibel> meaning switching to a swap partition
[17:40] <cyphermox> bdmurray: vorlon: sorry; what shim bugs?
[17:42] <bdmurray> jibel: Wimpress said that its an experimental option which will reveal things like this. I think its worth release noting though.
[17:43] <bdmurray> cyphermox: idk looking
[17:44] <bdmurray> cyphermox: maybe the ones in shim-signed
[17:45] <cyphermox> yeah, that's what I think too; just making sure
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted chromium-browser [source] (eoan-proposed) [77.0.3865.120-0ubuntu1~snap1]
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted qrencode [sync] (eoan-proposed) [4.0.2-2]
[17:50] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (eoan-proposed) [1:3.34.1-1ubuntu2]
[17:51] <cyphermox> I wonder why the logs never include the actual part where shim gets installed
[17:54] <vorlon> cyphermox: likely because the actual failure is in a trigger rather than a package installation and something something gazpacho.  The one bug where a submitter submitted his whole apt term.log still didn't provide any useful output from shim
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Eoan Final] has been updated (20191015)
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Eoan Final] has been updated (20191015)
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Eoan Final] has been updated (20191015)
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base i386 [Eoan Final] has been updated (20191015)
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Eoan Final] has been updated (20191015)
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Eoan Final] has been updated (20191015)
[18:04] <cyphermox> vorlon: nope
[18:05] <cyphermox> one would think you'd still have some parts of the shim-signed install logs, since it's present in history.log at the end (and the start timestamp is present for term.log)
[18:05] <cyphermox> I would have expected to see the unpacking phase even if it's a triger
[18:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server amd64 [Eoan Final] has been updated (20191015)
[18:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64 [Eoan Final] has been updated (20191015)
[18:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server ppc64el [Eoan Final] has been updated (20191015)
[18:11] -queuebot:#ubuntu-release- Builds: Ubuntu Server s390x [Eoan Final] has been updated (20191015)
[18:18] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Eoan Final] has been updated (20191015)
[18:24] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Eoan Final] has been updated (20191015)
[18:29] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Eoan Final] has been updated (20191015)
[18:29] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Eoan Final] has been updated (20191015)
[18:32] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Eoan Final] has been updated (20191015)
[18:33] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Eoan Final] has been updated (20191015)
[18:34] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Eoan Final] has been updated (20191015)
[18:34] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Eoan Final] has been updated (20191015)
[18:38] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi3 [Eoan Final] has been updated (20191015)
[18:38] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi3 [Eoan Final] has been updated (20191015)
[20:10] -queuebot:#ubuntu-release- Unapproved: networking-arista (eoan-proposed/universe) [2019.1.1~b2~git2019080858.d7d6ffa-0ubuntu1 => 2019.1.2~git2019101515.025569e-0ubuntu1] (no packageset)
[20:11] -queuebot:#ubuntu-release- Unapproved: accepted networking-arista [source] (eoan-proposed) [2019.1.2~git2019101515.025569e-0ubuntu1]
[20:32] <mwhudson> xnox: latest server image seems to mostly work??
[20:48] <ahasenack> networking is back, installation finished, in my case
[20:48] <ahasenack> 20191015.1
[20:53] <bittin_> https://www.jupiterbroadcasting.com/1030/jblive/ Review of Ubuntu 19.10 tonight
=== kees__ is now known as kees
[21:21] <bittin_>  burning the iso with fixed sudo now :)
[21:38] <sil2100> infinity: hey! Are the current images final, or are you still hacking on that darn debian-cd?
[21:44] <bittin_> Now there is 19.10 time in this weeks LUP
[22:09] <vorlon> LocutusOfBorg: if you're going to be syncing packages 2 days before release that are seeded on install images, you REALLY need to be communicating here about what you're doing and why (qrencode 4.0.2-2)
[22:15] <xnox> mwhudson: yes.... Just had to force delete /etc/machine-id from top layer to prevent it from becoming invalid file. Maybe we should fix kernel.
[22:15] <xnox> See Casper upload
[22:15] <mwhudson> xnox: yeah i saw that
[22:16] <mwhudson> xnox: wtf
[22:20] <xnox> mwhudson: you know the SWUASHFS error 💩?!
[22:20] <xnox> Yeah those can become corrupted unreadable files.
[22:20] <mwhudson> xnox: the kernel messages?
[22:20] <xnox> Yes
[22:20] <mwhudson> xnox: are you saying squashfs support in the kernel sucks?
[22:20] <mwhudson> or is it some kind of squashfs + overlay that sucks?
[22:21] <xnox> mwhudson: I am saying overlayfs multilowerdir on top of squashfs is shit.
[22:21] <xnox> mwhudson: desktop images are fine.
[22:21] <mwhudson> xnox: oh good
[22:21] <xnox> (single lower sir)
[22:22] <mwhudson> xnox: the desktop images had similar messages on shutdown but that was umounting things too early etc?
[22:22] <mwhudson> xnox: i release subiquity 19.10.2 to stable btw
[22:23] <mwhudson> +d
[22:23] <xnox> mwhudson: yes & yes
[22:24] <mwhudson> xnox: i guess we need to bug the kernel team about this then
[22:24] <mwhudson> xnox: i don't suppose you have a simple testcase?
[22:27] <xnox> mwhudson: we do not. But I think it should be ok to loop mount iso, loop mount squashfs overlayfs, and show that doing things to /etc/machine-id what systemd does breaks things. It does open, seek, truncate, write. And then trying to cat it results in I/O error.
[22:27] <mwhudson> xnox: yeah
[22:28] <xnox> mwhudson: https://github.com/systemd/systemd/blob/master/src/core/machine-id-setup.c#L102
[22:29] <mwhudson> xnox: doesn't look extremely exotic
[22:31] <xnox> I do suspect that that open, lseek, truncate matter. In that order with those flags, when it is zero length file on bottom layer, etc exists on middle layer but not machine-id, and we are doing this on top layer. With things failing to transverse stuff right.