[00:16] apw: if you are up, feel free to just dial my mobile if you want to chat aobut what we should rebuild to make provides & depends to align [00:16] or maybe try to catch steve if he is about [02:12] xnox: ah. No, just need to reupload nvidia to adjust the hard-coded version in the | branch [02:13] vorlon: please do that. cause otherwise our testing of fixed up ubuntu-drivers-common goes astray and we install both lrm & dkms [03:19] xnox: uploaded [03:20] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-440 (focal-proposed/restricted) [440.82+really.440.64-0ubuntu5 => 440.82+really.440.64-0ubuntu6] (i386-whitelist) [03:33] apw: Laney: verified that ^ matches the depends provides of the linux-restricted-modules package. [03:33] * xnox runs queue accept to be told denied [05:03] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-440 [source] (focal-proposed) [440.82+really.440.64-0ubuntu6] [05:06] xnox: ^^ [05:13] -queuebot:#ubuntu-release- Unapproved: pypy3 (focal-proposed/universe) [7.3.1+dfsg-3 => 7.3.1+dfsg-4] (no packageset) [05:13] ^ that's a fakesync because time is getting tight and I found *another* RC bug [05:14] -queuebot:#ubuntu-release- Unapproved: accepted pypy3 [source] (focal-proposed) [7.3.1+dfsg-4] [05:15] ta [05:57] releasing another subiquity to stable/ubuntu-20.04, hopefully the last one [05:57] but i hoped that yesterday too! [06:40] Hi release team, I wanted to ping and ask for spice in focal-unapproved [06:40] I'm unaware of the current state of the release (re)spinnign, so itf it doesn't fit it is fine to postpone [06:41] it could to some extend be an SRU, but if the times are good to get such a set of fixes in I'd appreciate if we could do so now [06:45] -queuebot:#ubuntu-release- Unapproved: 389-ds-base (focal-proposed/universe) [1.4.3.6-1 => 1.4.3.6-2] (no packageset) (sync) [06:45] -queuebot:#ubuntu-release- Unapproved: accepted 389-ds-base [sync] (focal-proposed) [1.4.3.6-2] [06:50] o/ [07:40] cpaelzer: what kind of autopkgtests get triggered by spice, how long would they all take to run? because it looks to me like openssl has migrated now, so there are no other blockers that I know of for the respin. OTOH spice is only seeded on the d-i images so it could be possible to respin only those [07:42] hi vorlon, I'm checking which would be triggered [07:42] ... [07:45] vorlon: the rev-deps only hold src:qemu and src:xserver-xorg-video-qxl which both have no debian/test/... dir - spice itself has d/t/control [07:45] so its own tests would run [07:45] but I see no "others" that would be triggered [07:46] cpaelzer: ok. I'll turn you over to sil2100 for the actual decision, I was just asking the question :) [07:46] but really I don't want to be blocking anything, if the spin is ready pelase postpone spice [07:47] we can make it a zero day SRU at almost no difference [07:47] I say almost for the few people that test focal on a focal host [07:48] vorlon: so if you can release the respin please do not think about spice and do the spin :-) [07:48] we can work the spice fixes in later on ... [08:05] Let me get back to you in a minute [08:12] cpaelzer: hey! I see the targeted but is set to 'Critical' - when did those crashes start? Were those always around, or did kernel/other-dep-package changes suddenly cause this to get worse? [08:13] Just trying to understand the severity better, since we had the same version in eoan as well [08:14] hi sil2100 [08:14] the crashes are potentially in there since forever but at least since the last merge (June 2019) [08:14] they exist but are not common [08:14] the resize issue is more likely to happen [08:14] as using spice isn't an uncommon setup [08:15] sil2100: are I told vorlon don't spend too mcuh time on it for the spin, do the spin and accept it afterwards as a zero-day SRU - that would be fine for me as well if that works for you [08:17] sil2100: lets drop the sev to high [08:18] initially I was unsure how liekly the crashes would be and set it to crti, but since then I have checked a bit and found no real report for them outside of the bugs linked in the commits [08:27] cpaelzer: yeah, so to minimize the risk of things going crazy during release, I'd opt for this to be a 0-day SRU [08:27] ack [08:28] -queuebot:#ubuntu-release- Unapproved: rejected nginx [source] (focal-proposed) [1.18.0-0ubuntu1] [08:28] sil2100: what do we do to make this happen for now? [08:28] keep i tin unapproved and revisting ... ?when? [08:28] or rather "revisiting" [08:29] sil2100, i have two small fixes for systemd's LP: #1870930 and LP: #1870410 [08:29] Launchpad bug 1870930 in systemd (Ubuntu Focal) "systemctl crashed with SIGSEGV" [High,Confirmed] https://launchpad.net/bugs/1870930 [08:29] Launchpad bug 1870410 in systemd (Ubuntu Focal) "wireless does not work on boot on RPi 3s" [Undecided,In progress] https://launchpad.net/bugs/1870410 [08:29] sil2100: Since we're going to respin, thoughts on letting zeromq3 through? It's all good to migrate, except for the block. [08:30] sil2100, could they go in? working wifi on rpi2/3 would be nice out of the box [08:33] cpaelzer: we'll track it as a 0-day SRU, so I'll accept it into -proposed but we'll only release it after release [08:34] rbalint: hm, I would really like to say 'no' for now [08:35] Since this is systemd, this is the last thing we'd want to release right now - then again, no wifi on the Pi3's sucks [08:35] rbalint: do you have it staged somewhere? [08:35] sil2100, i'm about o upload to bileto [08:35] sil2100, but not yet [08:36] sil2100, i'm stating it and we can decide later? [08:36] staging [08:37] rbalint: yes, please [08:37] sil2100, 0-day sru can also be the target [08:37] eh [08:39] rbalint: I think we either take it for release or do a usual SRU, since I don't think there's much merit of it going as an 0-day SRU, since if you're affected by no-wifi, you anyway have to workaround it to get the update (if there's no ethernet) [08:39] rbalint: so yes, please stage it in bileto, and we then can pull it in [08:39] (don't run the ADT tests on it though via bileto yet) [08:39] sil2100, ack, i was about to ask :-) [08:44] -queuebot:#ubuntu-release- Unapproved: accepted spice [source] (focal-proposed) [0.14.2-4ubuntu3] [08:47] sil2100, building in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3801 [08:48] Thanks [08:50] sil2100, there is also LP: #1872902 with 4 different solutions proposed but without any of them landed [08:50] Launchpad bug 1872902 in ubuntu-release-upgrader (Ubuntu Focal) "Upgrade to Focal now removes chrony" [Critical,Triaged] https://launchpad.net/bugs/1872902 [08:51] rbalint: yeah, that is an upgrade issue so we can solve it later [08:58] rbalint: ok, so now I finally sat down on this bug and I did remember correctly this being fixed! So apparently you mention that the previous fix didn't fix all the configurations? [08:58] In which cases is it still broken with the current systemd? [09:24] sil2100, yes, wifi still fails on boot on specific boards [09:27] sil2100, on slow rpi3s and rpi2s [09:28] What are the criteria for that? Like, how many boards would be affected? Which pi3 boards are slow? Pi2 is not ciritcal as this is not a 'default' setup, since you need to have a wifi dongle or similar [09:28] Asking since we did not see this issue in the lab [09:29] i think waveform could give much better estimates than me [09:30] Since there is a difference between: a) wifi doesn't work on all pi3's, b) wifi doesn't work for some pi3's, c) wifi doesn't work on a few selected pi3 revisions [09:30] sil2100, i guess there are way more slow boards in use out there than fast ones [09:45] sil2100, rbalint is correct there's more 3s out there than 4s, but I *suspect* (purely anecdotally, just going by what I've seen on forums and IRC) that the mix of ubuntu users on the pi skews towards people with 4s. Still, it's a serious issue for anyone wanting to use a 3B as a wifi-headless box [09:46] so if there's a possibility of getting the fix in there, I'd like it in there [09:47] I guess we'll have to take it then [09:47] but this is really not ideal, it's delaying our final builds on the day before release [09:48] Yeah [09:48] We have to take it, but this being systemd we also wouldn't want to fast-track it [09:49] It really really sucks because systemd always introduces huge issues [09:49] (when things go down) [09:50] rbalint, waveform: once systemd builds, could you both give it a quick test? We'd want to bin-copy it ASAP when we know it's fixing all the issues [09:50] Laney, sil2100 is doing a respin for rpi only with only systemd 0-day let in an option? [09:51] sil2100, will do - I'll test it on everything :) [09:51] sil2100, hey, any ideas why my focal installation doesn't see nvidia-driver-440 440.82+really.440.64-0ubuntu6 . My sources.list https://pastebin.ubuntu.com/p/8dkwbgnkc3/ [09:52] sil2100, Laney, and my apologies for the last minute horror! [09:53] sil2100, Laney, mine, too [09:53] rbalint: all images need to be in-sync, so every image that we publish that has systemd needs to have the same version [09:54] tseliot: hm, so you don't see it when trying to install with apt? I see it via rmadison, and I geuss your sources are correct [09:55] hm, archive mirroring issues perhaps? I guess not [09:55] sil2100, no, I can only see 440.82+really.440.64-0ubuntu5, no matter how often I apt-get update [10:04] waveform, sil2100 the package is ready in ppa:ci-train-ppa-service/3801 (riscv64 is still building) [10:07] tseliot: really weird! Even with the same sources I can still see ubuntu6 [10:08] sil2100, yes, my chroot sees the update too [10:13] rbalint, already downloading :) [10:23] tseliot: this is weird, last time I had issues like that was due to the mirror, but here it shouldn't be like that - feels like it's cached with an older version? [10:23] Not sure if anyone else has any ideas [10:24] sil2100, yes, I'm going to reinstall. My other testing box works fine, so I'm going to use that for now [10:24] Status update for the release: we have the ubuntu-drivers-common in testing, but we're also working on getting the Pi3 WiFi issue sorted - we're currently waiting for the riscv64 build to finish, but we're looking at ways to speed up the process and run archive ADT tests already [10:24] sil2100: You could just copy it in and let the riscv64 binary rebuild in the primary archive [10:25] Since that won't block autopkgtests [10:25] (will block migration unless overridden, though) [10:25] That's what we're considering [10:27] wgrant: yep! [10:28] -queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu1 => 245.4-4ubuntu3] (core, i386-whitelist) (sync) [10:29] -queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (focal-proposed) [245.4-4ubuntu3] [10:30] rbalint, waveform: we have already bin-copied systemd from the silo (without waiting for riscv64, we'll make it build in the archive) - so that we can get the tests running early [10:30] sil2100, same here: https://launchpad.net/~waveform/+archive/ubuntu/systemd/+packages :) [10:35] sil2100, waveform my rpi's wifi is fixed with 245.4-4ubuntu3, thanks for copying it in! [10:38] rbalint, sil2100, confirmed the fix on arm64 on 3B and 3B+, just waiting for an armhf card to flash while I test it on 4B too (just to make sure it doesn't break anything on there) [10:41] sil2100, xnox u-d-c will try to install linux-modules-nvidia-440-generic-hwe-20.04 even though linux-generic-hwe-20.04, which should still be correct, since linux-generic-hwe-20.04 depends on linux-image-5.4.0-26-generic (through linux-image-generic-hwe-20.04). What happens if, in the future, linux-image-generic-hwe-20.04 moves to a different major version? [10:46] tseliot: linux-modules-nvidia-440-generic-hwe-20.04 is the right package to install, because it is also a metapackage [10:46] sil2100, the crash with Unity is also gone [10:46] tseliot: and it moves with linux-image-generic-hwe-20.04 in tandem [10:47] tseliot: because the actual package that provides modules is what linux-modules-nvidia-440-generic-hwe-20.04 depends on, i.e. -5.4.0-ABI-..... [10:47] xnox, right, but I only have linux-generic installed here: https://pastebin.ubuntu.com/p/JczMkW6rFK/ [10:47] tseliot: your system is missconfigured. [10:48] tseliot: you should either have: linux-generic manually installed, with everything else as automatic. [10:48] tseliot: of you should have linux-generic-hwe-20.04 installed, with everything else as automatic [10:49] tseliot: if you have _multiple_ kernel flavours installed (i.e. both linux-generic and linux-lowlatency) i think the right thing is to install modules for _all_ metas, as one can boot all of them [10:49] tseliot: but our support is bad, when people have multiple kernel flavours installed (i.e. a random one becomes the default boot entry) [10:52] xnox, this is an upgrade from Eoan, and linux-generic was the default flavour there. This is what we should expect in most dist-upgrades === cpaelzer__ is now known as cpaelzer [11:05] tseliot: upgraded systems will all have linux-generic [11:05] tseliot: nothing on upgrade installs linux-generic-hwe-20.04 [11:05] tseliot: only fresh focal installs with latest focal daily install linux-generic-hwe-20.04 [11:05] apw: cjwatson: http://paste.ubuntu.com/p/YzQ7rqScXg/ [11:06] xnox, right. So, in that case, ubuntu-drivers should install linux-modules-nvidia-440-generic instead [11:06] injected set -x into postinst, and running it under ubiquity, which runs under ubiquity managed debconf, which runs ubuntu-drivers, which subprocess.calls() apt-get install modules and eventually l-r-m postinst which fails [11:07] tseliot: what's your systems $ dpkg-query -W 'linux-image-*' | pastebinit ? [11:07] tseliot: also kind of at the moment trying to debug debconf postinst issue, unrelated to what ubuntu-drivers-common picks to install. [11:08] apw: cjwatson: i guess i should try to strace all of that as well, to see what filedescriptor 3 should be..... [11:08] xnox, https://paste.ubuntu.com/p/wwchyTBd3f/ [11:09] sil2100, rbalint, confirmed systemd fix works nicely on armhf and arm64 on pi 3b, 3a+, 3b+, and 4b - I'd say it's good to go [11:09] tseliot: this is odd, you don't have secureboot on? [11:09] tseliot: because we never install unsigned kernel images. [11:10] if ubiquity is asking the question in advance, it could seed the answer right? [11:11] xnox, yes, it's off. I can enable it [11:12] xnox: OK, so that definitely doesn't look like a bug in the postinst [11:13] xnox: Looks like DEBIAN_HAS_FRONTEND=1 was probably set in the environment but in fact fd 3 was closed [11:13] or DEBCONF_REDIR or whatever it is, I forget and am in a meeting [11:17] waveform, rbalint: thanks for the testing! [11:32] cjwatson: we do have those two variables set in the environmet..... and debconf database is locked, and we still can't add a new template, to then query it. [11:32] so we need to ensure that fds don't get closed [11:54] please accept the Sugar packages from the NEW queue. They were removed earlier because of pygtk/python2 but they have switched to python3 now [11:57] -queuebot:#ubuntu-release- Unapproved: codespell (focal-proposed/universe) [1.16.0-1ubuntu1 => 1.16.0-2] (no packageset) (sync) [11:57] -queuebot:#ubuntu-release- Unapproved: accepted codespell [sync] (focal-proposed) [1.16.0-2] [11:59] sil2100: will we have images today? [11:59] fsvo [12:05] mwhudson: ...hopefully? ;) [12:06] sil2100: :) [12:06] sil2100: good luck [12:06] * mwhudson is going to bed [12:06] mwhudson: so we're still working on the ubuntu-drivers-common, and we need to wait for ALL the systemd triggered tests to finish [12:06] (having had an unexpected nap on the sofa already...) [12:09] mwhudson: thanks, goodnight! [12:22] locutus__: re ruby2.7: the symbols file is correct, there is no duplicated entry for rb_num2int. However, my text editor config did not help me and there is an extra space in that line in d/rules indeed. I am fixing it. [12:27] apw, xnox, let's say that, in the future, linux-generic-hwe-20.4 moves to a different kernel version e.g. 5.6, then what is the linux-image going to be called? Currently it's linux-image-5.4.0-26-generic. [12:27] tseliot: please not now [12:27] tseliot: we are currently experience severe brakage in ubiquity [12:27] apw: cjwatson: are you available in the hangout please? [12:28] ok, I'll leave things as they are then. I'm definitely not going to work over time today though. [12:28] tseliot: linux-generci-hwe-20.04 moving to 5.6, is no different of -25- to -26- abi change. because meta's are still going to be called the same. [12:29] will it be "-generic" though? [12:29] and linux-image-generic-hwe-20.04 will depend on linux-image-5.6.0-9999-geneirc, and so will linux-modules-nvidia-4440-$flavour etc. [12:29] tseliot: see bionic, yes. [12:30] ok, that's all I needed to know [12:30] .. [12:30] apw: i think i need l-r-m upload with db_get || true [12:30] apw: or explain to me why linux/nvidia/latelink does not exist [12:31] I think linux/nvidia/latelink was supposed to be created by the user. If that doesn't exist, then debconf will ask the question [12:35] xnox: which is how debconf works as far as I understand [12:35] apw: please join the hangout [12:35] I cannot right now, i am afk, covering kiddies due to covid [12:36] apw: ack [12:43] tseliot: it is allowed.to be made in advance, if not debconf is used to ask the question and fill in that file the first time you install, from then on it is fillee [12:43] xnox: ^ [12:43] you can also seed over the default if the file exists I believe [12:54] xnox: not for at least an hour [12:54] xnox: what is the specific unabbreviated package name here please? === s8321414_ is now known as s8321414 [13:08] cjwatson: so the .postinst that fails because of debconf is in linux-restricted-modules [13:09] cjwatson: so far we're investigating what's up, since when we execute `ubuntu-drivers install` directly, we see both the debconf .config is being executed before the .postinst and then everything works [13:10] But when executed via ubiquity in its environment, it's only the .postinst that runs and fails as the linux/nvidia/latelink is not set up [13:10] N: Unable to locate package linux-restricted-modules [13:13] linux-restricted-modules seems like a source package - what's the binary package name? [13:14] I guess it's linux-modules-nvidia-440-5.4.0-26-generic ? Let me just double check [13:16] That binary package has the linux/nvidia/latelink template in DEBIAN/templates [13:16] Which means that debconf registers the template before the postinst gets as far as trying to ask the question [13:16] It is emphatically wrong to need to guard the db_get in that situation [13:16] Something else is wrong if you find that you have to [13:17] I disagree with tseliot that it is supposed to be created by the user. That is not what the package metadata I see here does [13:17] (I mean, sure, perhaps it may be preseeded, but it doesn't have to be [13:17] 0 [13:18] cjwatson, right the assumption is not that the user fills it; my understanding of what i created was it will use the last answer if there was one, else it will ask [13:18] That is correct but not really what's at issue here [13:19] cjwatson, right, if you think it does that, all is well on that side of the plate [13:19] The point is that the question should *exist* in the debconf db (regardless of its value) by the time that code runs [13:19] The code is a bit complex and I don't want to say that it's definitely correct at this point, but it's not incorrect in this particular way as far as I can see :) [13:20] yes, I didn't really phrase it correctly. apw already said what I wanted to say [13:20] We've added some tracing and the .config file isn't being executed in the 'bad' case [13:20] not quite sure why [13:22] thanks kanashiro ! [13:31] rbalint: thanks for retriggering some of the flacky tests! I retriggered the ones that had testbed issues [13:31] (didn't see them running yet) [13:34] Also unblocked systemd in case the tests finish, so far looking good [13:45] Ok, systemd testing looks good, I think everything finished running besides systemd's own tests and the 2 testbed failures I retried - riscv64 build also finished and will be published soon [13:48] Laney, xnox: crap, just looked at the bug paride poked us about LP: #1874243 [13:48] Launchpad bug 1874243 in subiquity " An error occured handling 'dm_crypt-0': TypeError - join() argument must be str or bytes, not 'NoneType'" [Undecided,New] https://launchpad.net/bugs/1874243 [13:49] This really feels release critical, especailly if the test case here is using LVM with encryption [13:49] mwhudson: (fyi once you're up ^) [13:50] sil2100, yes the case here is just using lvm with encryption [13:50] I'm not sure that's more subiquity or more curtin [13:50] rharper, ^^ [13:51] paride: do you know if it was the case with older images? Is there a way we could pin-point when it all got bad? [13:51] sil2100, I can't tell exactly when it regressed, as we don't have an automated test for enrypted lvm [13:53] and I don't have older images around [13:54] you could try the beta [13:54] paride: ^ [13:55] bdmurray, it's gone :/ [13:56] http://releases.ubuntu.com/20.04/ <- will those auto-refresh subiquity? [13:56] I'm going to test 20200417 without refreshing subiquity [13:56] ah thanks sil2100, there's the beta [13:56] bdmurray, I did look only on cdimage.ubuntu.com [13:57] paride: it is confusing yes! [13:57] ;) [13:58] bdmurray, I've another issue with upgrades from 18.04 to focal. The task "Searching for obsolete software" never ends. It's is not a loop, it's like it's trying to MarkDelete all the packages 1 by 1 and fail. [13:58] bdmurray, I'll paste the logs somewhere [13:59] OTOH no crash of gtk-perl [13:59] jibel: hunh, that worked for me yesterday [13:59] yes it did [14:00] same base VM [14:00] standard bionic install, with all updates applied [14:03] bdmurray, main.log https://paste.ubuntu.com/p/sb5YmkQ9RS/ [14:06] bdmurray, apt.log https://people.canonical.com/~j-lallement/apt.log [14:07] can you try to reproduce it? [14:07] yes, rebooting my vm now [14:08] sil2100, bdmurray, the beta was failing already [14:11] Holy shit, how did we not notice [14:11] Do we have encrypted LVM in the test cases? [14:17] Guess we'll have to fill in this gap, since I don't see it on the isotracker [14:18] sil2100, there is one but only for the legacy d-i installer [14:19] the subiquity test cases really need to be expanded [14:20] jibel: I always forget to use eatmydata [14:22] -queuebot:#ubuntu-release- Unapproved: libvirt (bionic-proposed/main) [4.0.0-1ubuntu8.15 => 4.0.0-1ubuntu8.16] (ubuntu-server, virt) [14:22] -queuebot:#ubuntu-release- Unapproved: qemu (eoan-proposed/main) [1:4.0+dfsg-0ubuntu9.4 => 1:4.0+dfsg-0ubuntu9.5] (ubuntu-server, virt) [14:23] -queuebot:#ubuntu-release- Unapproved: qemu (bionic-proposed/main) [1:2.11+dfsg-1ubuntu7.23 => 1:2.11+dfsg-1ubuntu7.24] (ubuntu-server, virt) [14:23] -queuebot:#ubuntu-release- Unapproved: libvirt (eoan-proposed/main) [5.4.0-0ubuntu5.2 => 5.4.0-0ubuntu5.3] (ubuntu-server, virt) [14:28] paride: ok, so just-in-case I checked 19.10, but we didn't actually support encrypted LVM back then - and a regular LVM install seems to work there [14:31] sil2100, wait 19.10 did support encrypted lvm [14:32] and it works [14:33] paride: oh, it did? I didn't see the option [14:34] you have to choose manual partitioning and it's there when you create the VG [14:34] I just re-tested it just to be sure [14:36] Ah, manual, ok [14:41] rharper, powersj: hey! We seem to be having issues with subiquity/curtin right now, looks like curtin is the one dying here - LP: #1874243 [14:41] Launchpad bug 1874243 in subiquity " An error occured handling 'dm_crypt-0': TypeError - join() argument must be str or bytes, not 'NoneType'" [Undecided,New] https://launchpad.net/bugs/1874243 [14:41] Can we get some of your eyeballs on it? It's a severe issue which we wouldn't want to release with [14:42] sil2100: yes [14:43] jibel: My upgrade made it to the "remove obsolete packages" dialog and gnome-software-plugin-snap is in the list of things to remove. [14:44] rharper: thanks o/ [14:48] bdmurray, re-running to check if it's a one time thing [14:50] lvm bug is subiquity only? [14:50] I assume [14:51] paride: Is the updated systemd installed? [14:52] not the version that just migrated [15:03] tseliot: hello! Can you by any chance upload your ubuntu-drivers-common? I think we have a workaround for all the issues we've been seeing [15:04] sil2100, sure [15:06] sil2100, uploaded [15:06] -queuebot:#ubuntu-release- Unapproved: ubuntu-drivers-common (focal-proposed/main) [1:0.8 => 1:0.8.1] (desktop-core, ubuntu-server) [15:13] tseliot: thank you! \o/ [15:13] * sil2100 hugs tseliot [15:13] :) [15:20] sil2100: are you reviewing or should I? [15:31] sil2100: vo [15:31] vorlon: [15:31] I think that's incomplete [15:31] rbasak, can you check/promote an SRU upload for me? linux-firmware for xenial and bionic should be in the upload queue. [15:32] xnox: details? [15:36] paride, rharper: I think I have a fix for the dm_crypt thing, have a MP but testing it now actually [15:36] Laney: ^ [15:36] bdmurray: ^ (thanks for your help in debugging!) [15:36] juergh: sorry, I don't think I'm going to have time today. [15:37] cpaelzer, wgrant: do we really want qemu-sparc in main? [15:38] same for mips [15:38] vorlon: join virtual release sprint call [15:38] vorlon: we are pondering if we need more than that, or not [15:38] xnox: not available [15:39] and I don't have a link to this call anyway :P [15:40] juergh: from a quick glance, you're missing bug references in your Bionic upload at least. And shouldn't these be going in via the security pocket? [15:41] sil2100: did you up a PR ? I can review, and I'm working on a unittest for my bersion [15:42] rbasak, it's a CVE update. does it need buglinks? [15:42] juergh: see my second question [15:43] Shouldn't these be going in via the security pocket? [15:43] Normally all SRUs would have a buglink with SRU information, or the security team would arrange a security upload through the security pocket which is outside the SRU process. Is this upload exceptional somehow? [15:48] rharper: yes! https://code.launchpad.net/~sil2100/curtin/+git/curtin/+merge/382768 [15:48] rharper: it seems to work, but I'm finishing a test install now [15:49] rharper: want to see if it's bootable [15:49] -queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (bionic-proposed) [1.173.18] [15:49] -queuebot:#ubuntu-release- Unapproved: rejected linux-firmware [source] (xenial-proposed) [1.157.23] [15:49] rharper: so it's not adding any new workarounds but 'fixing' an existing workaround (or maybe an actual spec assumption? Not sure!) [15:49] rbasak, dunno. I've been told 'do this' then 'upload there' :-) it's an old CVE, nothing critical. sorry, we're trying to delegate the maintenance of linux-firmware and it's my first non-kernel SRU upload so I'm still learning. [15:50] rharper: ok, installation works, boots and is encrypted [15:50] Can you take a look at the MP? [15:50] juergh: read up on https://wiki.ubuntu.com/StableReleaseUpdates and https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures please [15:51] juergh: you need to pick which process you want to follow. Maybe talk to the security team if you're unsure. But if you want to land this through the SRU process, you need to link a bug with details. [15:51] (as per the documented SRU process) [15:52] juergh: and I'd want an explanation of why this is not appropriate for security. Because people selecting to receive security updates only won't get a regular SRU. [15:53] sil2100: ohn you're working around in curtin [15:54] this should get fixed in subiquity [15:54] i'll look at your MP though [15:54] sil2100: so is there an ongoing conversation about nvidia? since apparently xnox won't type :) [15:55] vorlon: I sent you an email to the hangout, come play with us [15:55] at least I think it's an email [15:55] Laney: I'm not available [15:55] I did the invite user thing [15:55] oh [15:55] I'm in a meeting and then I'm afk for an hour [15:55] well there's about to be an LRM [15:55] which we think / hope will work around the problemo [15:55] rharper: I am *not* working around anything, this is an existing workaround - I am not adding anything new, this is existing curtin code and curtin expectations? ;) [15:56] what? [15:56] rharper: I mean, this has been like that in curtin from the start, from when it worked. From long curting just assumed to use 'id' when 'dm_name' was not available, so I'm not adding any new 'guessing' here [15:56] apw: Laney: https://paste.ubuntu.com/p/ggY2bTJxSf/ [15:56] no no no [15:56] please; there's a schema and it's a required field for type: dm_crypt [15:57] the dm_name needs to be present [15:57] rharper: so why did curtin not care previously? [15:57] rharper: talk to me. [15:57] it's always required it [15:57] rharper: and why are there exsiting lines that default to 'id'? [15:57] what ? [15:57] rharper: i believe that what we did was a guess, we didn't know what we were supposed to pass. [15:58] xnox: does we in the context = curtin? [15:58] sil2100: I see your patch [15:58] rbasak: do you have a patch? [15:58] rbasak: unping [15:58] rharper: do you have a patch or suggestion? [15:58] rharper: cause most likely both code paths are broken. "manually configure encrypted lvm" and "do guided encrypted lvm" [15:58] rharper: look at the code, existing code - look at lines 492 [15:58] sil2100: has one for curtin, which is a solid fix [15:59] rharper: and the two lines that I moved [15:59] Just saying, I'm not proposing any new workarounds! We don't want new workarounds ;p [15:59] xnox: I do have a patch for subiquity but it was going to use the id of the element anyhow unless someone set a value [15:59] I'm not proposing a workaround either [16:00] in any case, I'll review the curtin bits , and put up the subiquity PR and we can decide from there [16:00] rharper: would you rather for us to always pass the dm_name & id? [16:01] xnox: I think the best course of action now is to go back to the previous curtin behavior and fix it right for .1 [16:01] vorlon: sorry, ubuntu-driver-common is good, please review & accept [16:01] review done, accepting now [16:02] bdmurray: subiquity is the only one that provides the values, but in the future maas & desktop will too. So i do want to ensure that schema is right (of things that it should accept) [16:02] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-drivers-common [source] (focal-proposed) [1:0.8.1] [16:02] vorlon: please also unblock [16:02] ack [16:03] rharper: sil2100: so i'll take sil's branch and vendorize it in the subiquity snap and prepare a release [16:03] bdmurray: ^ [16:04] because at this point i'm cherrypicking minimal curtin patch against the commit-id we have [16:04] ah [16:06] xnox: +1 [16:06] sil2100: I added a unittest in the review, if you add that, I can approve and land it [16:07] rharper: \o/ thanks, looking [16:08] -queuebot:#ubuntu-release- Unapproved: linux-restricted-modules (focal-proposed/restricted) [5.4.0-26.30 => 5.4.0-26.30+1] (core, kernel) [16:09] jibel: any word on your latest upgrade test? [16:14] -queuebot:#ubuntu-release- Unapproved: accepted linux-restricted-modules [source] (focal-proposed) [5.4.0-26.30+1] [16:15] rharper: pushed, thanks! I think I applied it correctly, since the tests seem to be passing here [16:16] cool [16:25] xnox: https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/382776 [16:25] for jfh 's current multipath hangup [16:28] rharper: looks reasonable ... [16:28] rharper: are you asking to include that in the respin? [16:28] xnox: yes [16:28] rharper: you need sign off from bdmurray Laney apw https://code.launchpad.net/~raharper/curtin/+git/curtin/+merge/382776 [16:29] xnox: out side of approval of that, if you know any more about the RHBZ where I found the details if our multipath-tools uses the disable flag or not, woudl be interesting [16:29] https://bugzilla.redhat.com/show_bug.cgi?id=869253 [16:29] bugzilla.redhat.com bug 869253 in device-mapper-multipath "/dev/mapper/mpathX is block device not symbolic link" [Medium,Closed: errata] [16:35] rharper: well, that also 'explains' a bit why that at the beginning mostly happened on (low perf) zvm and later in the days (when the system utilization starts) also on LPAR - I guess ... [16:35] bdmurray: Laney: sil2100: please review / approve https://github.com/CanonicalLtd/subiquity/pull/731 [16:35] CanonicalLtd issue (Pull request) 731 in subiquity "Ship rharper hotfix for dm-name" [Open] [16:36] oh hello gitbot [16:38] jfh: right ... Odd_Bloke was asking about the "sometimes" and my read of the RHBZ mention the number of paths and load of the system, so sometimes the library beat udev to creating an entry [16:40] rharper: yepp - drove me nearly crazy... [16:45] rharper, oh, so it was quite a racy issue then [17:04] cking: I never knew that until today ... never had I seen a block device in /dev/mapper, only ever symlinks ... I was quite confused =/ [17:08] it's certainly a complex bit of plumbing down there [17:25] -queuebot:#ubuntu-release- Builds: Upgrade Kubuntu amd64 [Focal Final] has been updated (20200421) [17:25] -queuebot:#ubuntu-release- Builds: Upgrade Ubuntu MATE amd64 [Focal Final] has been updated (20200421) [17:25] -queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Server amd64 [Focal Final] has been updated (20200421) [17:25] -queuebot:#ubuntu-release- Builds: Upgrade Ubuntu Studio amd64 [Focal Final] has been updated (20200421) [17:25] -queuebot:#ubuntu-release- Builds: Upgrade Ubuntu amd64 [Focal Final] has been updated (20200421) [17:26] -queuebot:#ubuntu-release- Builds: Upgrade UbuntuKylin amd64 [Focal Final] has been updated (20200421) [17:26] -queuebot:#ubuntu-release- Builds: Upgrade Xubuntu amd64 [Focal Final] has been updated (20200421) [17:26] -queuebot:#ubuntu-release- Builds: Upgrade Lubuntu amd64 [Focal Final] has been updated (20200421) [17:40] xnox, sil2100, rharper: sil2100's curtin branch has landed. Any others? [17:41] powersj: don't care aobut curtin branches. I'm building from commit ids. [17:41] powersj: new subiquity with all curtin hotfixes is in edge already [17:41] xnox, ok thank you [17:41] powersj: but good to know that we can revert back to using curtin master when we open gutsy [17:42] thank you [17:44] apw: it's amazing and works correctly, for real.. [17:47] xnox, Laney: isn't this what the debconf passthrough frontend is supposed to be for? did we regress something? [17:47] howdy :-) [17:47] * vorlon waves [17:49] vorlon: we try to use passthrough, we are not sure if passthrough was ever used on the host with host's debconf locked. when passthrough is used for in-target, in-targets' debconf is not locked by hosts ubiquity [17:49] bdmurray! [17:50] vorlon: we have opened a task to make that work / doublecheck later, as we failed to make it work (we can talk to debconf, yet can't read/write to the ubiquity locked config.dat [17:50] xnox: so "host" here means "live environment" rather than target? [17:50] (that was unclear to me) [17:50] vorlon: yes [17:50] ok [17:50] for that, it probably shouldn't use passthrough but should instead inherit the environment [17:51] why doesn't it inherit the environment [17:51] vorlon: with the current l-r-m fix, we skip latelink in the live envrionment, but do attempt it in-target and it works correctly in-target (whilst being passthroughted progress to ubiquity, as i can see status messages configuring linux-moudle.s.....) [17:51] right [17:51] why do we install lrm in the host environment at all? [17:51] ... because ubuntu-drivers shouldn't encode special knowledge about which drivers are loadable in the live env or not [17:52] vorlon: so ubuntu-drivers calls apt-get install => but it calls it without setting close_fds=False & apt-get itself closes fds, thus it needs like extra -o APT::Keep-Fds::=3 or somesuch. [17:52] vorlon: the why do we install lrm in the host envrionment is a good question. [17:53] vorlon: i think we do it, to enable any hard-drives which ubuntu-drivers might create [17:53] vorlon: and it only gives us a package list of things to install in-target, if we do execute install [17:53] or network devices [17:53] right [17:54] xnox: apt-get closes fds> ugh [17:54]