[00:08] <arraybolt3[m]> sarnold: The only reason it's really important that I can see is that it does possibly leave a user without Wi-Fi if they intuitively decide to go back and enable update installation rather than doing it after the install. It's not as big a deal as I initially thought, thankfully, and it may not even be a release blocker, though I can see this biting quite a few individuals (myself included, I found it by accident!).
[00:08] <sarnold> arraybolt3[m]: it comes up often enough that *clearly* people use it :)
[00:09] <vorlon> arraybolt3[m]: is it a regression? :)
[00:09] <sarnold> we should put a transcript of using the installer in the CD liner notes, like the openbsd folks do :) then people would know what stages do what things, where to look for specific things, and they might not need to spend time exploring!
[00:10] <arraybolt3[m]> vorlon: I don't know, I can check the focal.4 ISO to find out (and since it's Ubuntu Desktop I can probably grab older ones).
[00:10] <vorlon> arraybolt3[m]: seems like it's unlikely to be a regression and therefore not a release blocker; but it would be good to know for sure
[00:11] <arraybolt3[m]> I remember it worked in Kubuntu, but it uses a slightly different Ubiquity thingy.
[00:38] <arraybolt3[m]> OK, not a regression. Focal.4 Ubuntu has the same problem.
[00:40] <vorlon> arraybolt3[m]: thanks for checking
[01:09] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (jammy-proposed) [1:41.7-0ubuntu0.22.04.5]
[06:46] -queuebot:#ubuntu-release- New: accepted haskell-what4 [amd64] (kinetic-proposed) [1.3-2]
[07:58] <xnox> vorlon:  basically at this point i'm not sure if we want to demote-to-proposed the linux-restricted-[modules|signatures]-[oem-5.17|intel-iotg] or if we should respin them alone, or if we should remove them.
[07:59] <xnox> and some people were not sure about iotg kernel roadmap for kinetic
[09:17] <sil2100> Whoops
[09:24] <sil2100> Everyone! There will most probably be a respin of 20.04.5. Apparently we're pulling in quite a bit of the 5.13 kernel into the images, mostly becasue of the nvidia-390 driver (which is not available for 5.15 from what I see)
[09:25] <sil2100> apw, klebers: ^ asking the kernel team if I can simply rip out the 390 bits from debian-cd
[09:33] <schopin> ubuntu-release: could I get an ACK on LP: #1986984 (tzdata) please?
[09:34] <xnox> sil2100:  we have done fudging with regexp which version numbers of nvidia stuff to include in CDs before. When we had too few / too many nvidias.
[09:35] <xnox> sil2100:  doko: may i request assistance with v5.19 kernel migration in kinetic with $ ./demote-to-proposed --dry-run -d ubuntu -s kinetic -m "v5.19 kernel migration LP:#1987870 and LP:#1987869" linux-restricted-modules-oem-5.17 linux-restricted-signatures-oem-5.17 linux-restricted-modules-intel-iotg linux-restricted-signatures-intel-iotg
[09:36] <xnox> all v5.19 kernels are ready to migrate; but are entagled via LRM / nvidia with the two kernels that are not ready. Demoting prebuilt LRM for those two kernels, will enable all other kernels to migrate, and we will resolve LRM status of these two kernels a bit later. In the mean time they will simply use dkms.
[09:38] <xnox> cc: vorlon ^^^^
[09:41] <doko> xnox: apw not online?
[09:43] <xnox> doko: on holidays
[10:10] <lan3y> anyone know if someone's looking into this issue which Azure are raising? https://status.azure.com/en-gb/status // https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119
[10:10] <laney> bah stupid nick
[10:20] <laney> sil2100: ^- sorry to invoke you as the 'human router' :D getting some slight heat due to this and I don't know Nishit Majithia's nick to find them on irc
[10:21] <LocutusOfBorg> migrating libghc-diagrams-core-dev/1.5.0-1/amd64 to testing makes libghc-diagrams-dev/1.4-5/amd64 uninstallable
[10:22] <LocutusOfBorg> vorlon, ^^ this is quite strange, not shown on tracker
[10:22] <LocutusOfBorg> but on excuses
[10:22] <LocutusOfBorg> rebuilding it
[10:23] <laney> (happy to execute a rollback to the previous version)
[10:28] <sil2100> laney: hey! Lemme look ;)
[10:28] <laney> ♥
[10:30] <sil2100> laney: so Nishit's IRC handle is nishit_, I see him on #ubuntu-devel
[10:30] <sil2100> I think I even chatted with him today!
[10:31] <laney> cheers, let's move over there
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Focal 20.04.5] (2955461583) has been added
[10:57] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.54 => 237-3ubuntu10.54] (core) (sync)
[11:38] <laney> ^- going to accept that systemd sync, it's part of what we discussed above
[11:38] <laney> I did my copies with --auto-approve :-)
[11:39] -queuebot:#ubuntu-release- Unapproved: accepted systemd [sync] (bionic-proposed) [237-3ubuntu10.54]
[12:02] <sil2100> laney: hahah! Yes, thanks ;)
[12:17] <icey[m]> hey sil2100 - not sure what the best way to move https://bugs.launchpad.net/ubuntu/+source/ceph/+bug/1967139 forward; there seem to be bugs already filed to deal with the translate-toolkit issue breaking the autopkgtest
[13:41] <xnox> doko:  thank you for demotion; but it made intel-iotg LRM migrate back straight away because you closed the bug; which has the block-proposed-kinetic set on it.
[13:41] <xnox> doko:  reopened the bug report, can you please demote intel-iotg again please?
[13:41] <xnox> and do not close the bug report, such that it stays in -proposed =)
[14:36] <schopin> Could someone from the release team grant the FFe for tzdata? LP: #1986984
[14:37] <schopin> sil2100: ^
[14:39] <LocutusOfBorg> do we really need FFe for tzdata?
[14:40] <LocutusOfBorg> btw why do we need such icu autogenerated files?
[14:41] <tumbleweed> yes, but you'll get it easily :)
[14:42] <sil2100> schopin: dune!
[14:42] <sil2100> Dune™
[14:44] <schopin> thanks :)
[14:49] <schopin> LocutusOfBorg: from what I gathered, it has something to do with PHP? The version introducing them wasn't mentioned in the changelog, and I didn't look much further.
[15:00] <fnordahl> Our latest kinetic openvswitch upload is stuck on the netplan.io autopkgtest for armhf. When running this test on a armhf system manually it succeeds. Is there any way to enable debug in the CI so that we can see what's going on in there? The artifacts provided does not provide enlightenment https://autopkgtest.ubuntu.com/packages/n/netplan.io/kinetic/armhf
[15:04] <slyon> fnordahl: I think it's missing the OVS kernel module on the LXD container host inside the autopkgtest infrastructure: https://launchpad.net/ubuntu/+source/netplan.io/0.105-0ubuntu2
[15:04] <slyon> unfortunately that netplan update is stuck behind the pandoc build
[15:04] <slyon> (on armhf)
[15:07] <vorlon> LocutusOfBorg: haskell-diagrams removed
[15:08] <fnordahl> slyon thx alot for that, I did indeed load the module prior to running the test. So I guess we just have to wait until the netplan 0.105-0ubuntu2 package comes through then?
[15:21] <slyon> fnordahl: yes, that's why the test passes on all architectures but armhf. The module can be loaded inside the test on qemu (all but armhf), but the test doesn't have controll over the LXD container host (armhf)
[15:22] <slyon> fnordahl: that new upload should most probably resolve that situation, by skipping the test if OVS is not ready on the host
[15:26] <LocutusOfBorg> sigh pandoc
[15:29] <slyon> LocutusOfBorg: ^ indeed! I think that pandoc armhf build is running in cycles.... I saw it reaching "[214 of 214]" this morning and then starting over at "[  1 of 214]" :/
[15:29] <slyon> cc vorlon ^
[15:29] <LocutusOfBorg> slyon, its normal
[15:30] <LocutusOfBorg> it does two runs from 1 to 214
[15:30] <slyon> ohh, OK
[15:30] <LocutusOfBorg> one is foo the other is bar don't remember the differences
[15:30] <vorlon> slyon: right, it's annoying
[15:30] <LocutusOfBorg> annoying is an euphemism :)
[15:30] <vorlon> but more annoying, it turns out the armhf ghc is WAY slower in Ubuntu than in Debian
[15:30] <LocutusOfBorg> somewhere it regressed on armhf only
[15:30] <slyon> so maybe one more day to get it resolved :)
[15:30] <LocutusOfBorg> ^^ yes that one I was mentioning
[15:31] <LocutusOfBorg> I tried hard to understand why and I badly failed
[15:31] <LocutusOfBorg> looks like it slowly regressed during build, not that much
[15:32] <LocutusOfBorg> btw pandoc failed in Debian on armhf... :)
[15:33] <LocutusOfBorg> haddock: panic! (the 'impossible' happened)
[15:33] <LocutusOfBorg> Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
[15:33] <LocutusOfBorg> so it would be *really* funny to wait a couple of days and see it fail
[15:34] <LocutusOfBorg> vorlon, what about, restore old pandoc, build what needed and put this one back?
[15:35] <vorlon> I would like this current pandoc build to get to the end, maybe it succeeds for us
[15:35] <LocutusOfBorg> vorlon, you have time to remove/copy/restore before the build finishes :D
[15:35] <LocutusOfBorg> in one hour we can retry what needs pandoc on armhf and restore
[15:36] <LocutusOfBorg> and yes, that "the impossible happened" is probably some ENOMEM
[15:36] -queuebot:#ubuntu-release- Unapproved: wireguard-linux-compat (bionic-proposed/universe) [1.0.20201112-1~18.04.1 => 1.0.20201112-1~18.04.4] (kernel-dkms)
[15:38] <LocutusOfBorg> last pandoc took 8h to build on armhf
[16:17] <vorlon> mwhudson: did a gir-to-d fix ever happen?
[16:18] <vorlon> mwhudson: there was a new upload the same day as your last mailing list post but, er, the built package still depends on the old libphobos2
[16:20] <vorlon> oh! no, this is because we bumped again from libphobos2-ldc-shared99 to libphobos2-ldc-shared100
[16:24] -queuebot:#ubuntu-release- New binary: openvdb [armhf] (kinetic-proposed/universe) [9.1.0-7ubuntu1] (ubuntustudio)
[16:46] -queuebot:#ubuntu-release- New binary: openvdb [riscv64] (kinetic-proposed/universe) [9.1.0-7ubuntu1] (ubuntustudio)
[16:46] <bdmurray> schopin, LocutusOfBorg the icu information in tzdata is sort of documented here https://wiki.ubuntu.com/StableReleaseUpdates#tzdata it was something xnox added IIRC
[17:06] <vorlon> https://launchpad.net/ubuntu/+source/gir-to-d/0.22.0-3build1/+build/24325999 lovely, the whole ldc stack is broken again
[17:07] <vorlon> looks like dh-dlang may have changed to pull in DEB_BUILD_CFLAGS and isn't filtering out bits unknown to ldc
[17:28] <bdmurray> sil2100: Is there somewhere in the ISO tracker you'd expect ISO test results for an offline install of Ubuntu with nvidia drivers? I'm not seeing an obvious test case for that.
[19:00] <sil2100> bdmurray: huh? What about this? http://iso.qa.ubuntu.com/qatracker/milestones/438/builds/257539/testcases/1718/results
[19:01] <bdmurray> sil2100: I was not using UEFI but did that test now
[19:01] <sil2100> I think we really need to update the description of that test case, since it confuses people
[19:01] <bdmurray> I plan to review the test cases before 22.10.
[19:02] <bdmurray> s/review/review and update/
[19:02] <sil2100> Thanks!
[19:04] <sil2100> Hey everyone! I'll be doing a one-off test image build of Ubuntu Desktop with -proposed enabled in a moment. I'll switch the tracker to point to the previous image once it's built
[19:04] <sil2100> I want this test image  to see if the kernel spin fixed the situation or not
[20:10] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.5] has been updated (20220830)
[20:12] -queuebot:#ubuntu-release- New binary: mir-core [amd64] (kinetic-proposed/universe) [1.1.111-1] (no packageset)
[20:13] -queuebot:#ubuntu-release- New binary: mir-core [arm64] (kinetic-proposed/universe) [1.1.111-1] (no packageset)
[20:55] -queuebot:#ubuntu-release- New: accepted mir-core [amd64] (kinetic-proposed) [1.1.111-1]
[20:55] -queuebot:#ubuntu-release- New: accepted mir-core [arm64] (kinetic-proposed) [1.1.111-1]
[21:11] <mwhudson> vorlon: oh no, the debian maintainer promised an upload but i don't know if it happened
[21:11] <mwhudson> (following up on +1 things is apparently not my strongest ability currently :-/)
[21:26] <arraybolt3> Just popped in, any testing in specific that needs done?
[21:30] -queuebot:#ubuntu-release- Unapproved: cloud-init (jammy-proposed/main) [22.2-0ubuntu1~22.04.3 => 22.3-13-g70ce6442-0ubuntu1~22.04.1] (core, ubuntu-cloud)
[21:30] -queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [22.2-0ubuntu1~20.04.3 => 22.3-13-g70ce6442-0ubuntu1~20.04.1] (core, edubuntu, ubuntu-cloud)
[21:31] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [22.2-0ubuntu1~18.04.3 => 22.3-13-g70ce6442-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:37] <vorlon> mwhudson: yeah it apparently did happen, same day as your message - but I never noticed because then also another ldc lib transition happened
[21:37] <mwhudson> vorlon: ah
[22:33] <blackboxsw> bdmurray: not sure how your SRU vanfuage afternoon is looking. We've queued a cloud-init SRU upload in response to RAOF's review on Friday (needing to include a postinst script) and we've sync'd changes for two potential bug fixes found and fixed before our SRU unapproved upload was accepted https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1987318
[22:33] <blackboxsw> *SRU vanguard*. /me tries facing the keyboard before typing
[22:36] <bdmurray> I have an appointment this afternoon but will try and look at it when I return
[22:43] <vorlon> haskell-abstract-par/armhf: 40 minutes to build on the buildd.  2 minutes to build in a lxd container in canonistack :/
[22:59] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Focal 20.04.5] has been updated (20220829.1)
[23:00] <mwhudson> vorlon: wait what
[23:00] <vorlon> yeah
[23:00] <vorlon> so what's different
[23:01] <mwhudson> well container vs schroot but well
[23:01] <mwhudson> kernel version?
[23:01] <mwhudson> RAM available?
[23:01] <vorlon> yeah not sure
[23:02] <vorlon> the canonistack instance has 4GiB RAM but I thought that's what launchpad is running also
[23:03] <mwhudson> i think buildd vms have 8GiB
[23:03] <vorlon> well then low memory on the buildds shouldn't be the cause
[23:03] <mwhudson> indeed
[23:04] <mwhudson> and if having more memory is making the build slower ...
[23:05] <sarnold> I thought builders had 16 gigs but I can't remember the name of the package that dumps information about its runtime environment in its build logs..
[23:05] <vorlon> procenv?
[23:05] <sarnold> YAY that sounds right!
[23:05] <vorlon> last uploaded in 2020 though :)
[23:05] <sarnold> oh dagnabbit
[23:06] <sarnold> MemTotal:        8167540 kB
[23:06] <mwhudson> well 10 minutes of the build on launchpad is installing build deps
[23:06]  * vorlon nods
[23:07] <mwhudson> 23 Aug 03:39:09 ntpdate[1947]: adjust time server 10.211.37.1 offset 0.004258 sec
[23:07] <mwhudson> | haskell-abstract-par 0.3.3-11build1 (armhf)  Tue, 23 Aug 2022 03:48:31 +0000 |
[23:07] <sarnold> *this* time I'm writing procenv down. Wish me luck next time I want it :)
[23:07] <mwhudson> oh wait no that's just updating the chroot
[23:07] <vorlon> that's still 30m vs 2
[23:08] <mwhudson> yeah
[23:11] <mwhudson> do these machines just have really slow disk?
[23:11] <mwhudson> but it's similar hardware to canonistack aiui
[23:12] <vorlon> https://launchpadlibrarian.net/619656500/buildlog_ubuntu-kinetic-armhf.haskell-abstract-par_0.3.3-11build1_BUILDING.txt.gz shows 5.4.0-124-generic and I'm running 5.4.0-125-generic
[23:12] <mwhudson> probably should get someone launchpaddy involved
[23:12] <vorlon> disk slowness doesn't explain it being a ghc-specific problem
[23:12] <mwhudson> rather than us just guessing
[23:13] <vorlon> yeah I've asked in MM ~Launchpad
[23:13] <mwhudson> true and it definitely seems mich worse with haskell stuff
[23:13] <vorlon> the entire haskell-abstract-par build tree is 27M
[23:23] <vorlon> and glib-d ftbfs because gir-to-d is emitting non-unique constructors, hurray
[23:43] -queuebot:#ubuntu-release- New sync: appstream-generator (kinetic-proposed/primary) [0.8.8-1]
[23:47] -queuebot:#ubuntu-release- New: rejected appstream-generator [sync] (kinetic-proposed) [0.8.8-1]