[00:31] <sarnold> hello release team, this bug looks like it could make for an unhappy release day
[00:32] <sarnold> gee thanks firefox
[00:32] <sarnold> https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1968845
[00:32] <ubottu> Launchpad bug 1968845 in dbus (Ubuntu) "Upgrade to 22.04 from 20.04 ends with dbus installation asking for a reboot" [Undecided, New]
[01:00] -queuebot:#ubuntu-release- Unapproved: accepted gvfs [source] (focal-proposed) [1.44.1-1ubuntu1.1]
[01:08] <vorlon> sarnold: I think that's probably LP: #1969162, which "only" hangs for 10 minutes?
[01:08] <ubottu> Launchpad bug 1969162 in snapd (Ubuntu) "bad interaction between snapd and update-notifier when snapd package is being upgraded" [High, In Progress] https://launchpad.net/bugs/1969162
[01:09] <sarnold> vorlon: aha! that sure sounds plausible. Bummer I guessed wrong on the cause... ten minutes is an absolute eternity though, I can't imagine having that kind of patience myself :)
[01:10] <vorlon> short enough that the hang cleared while I was debugging it
[01:10] <sarnold> lol
[01:10] <sarnold> "come back I wasn't done yet!"
[01:43] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-12 [source] (focal-proposed) [12.10-0ubuntu0.20.04.1]
[06:30] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Jammy Final] has been updated (2193855367)
[07:27] <GunnarHj> Since bug #1875062 is fixed, I suppose that the release notes caveat under "Known Issues -> Ubuntu Desktop" about keyboard layout can be dropped.
[07:27] <GunnarHj> https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
[07:27] <ubottu> Bug 1875062 in ubiquity (Ubuntu Focal) "[20.04] Keyboard layout changes during installation before typing username/password" [High, Triaged] https://launchpad.net/bugs/1875062
[07:38] <LocutusOfBorg> vorlon, actually a regina fault
[07:38] <LocutusOfBorg> please accept, or hint it
[07:38] <LocutusOfBorg> I uploaded regina-normal with upstream fix
[07:40] -queuebot:#ubuntu-release- Unapproved: regina-normal (jammy-proposed/universe) [7.0-2build1 => 7.0-2ubuntu1] (no packageset)
[07:40] <LocutusOfBorg> ^^ vorlon
[07:40] -queuebot:#ubuntu-release- Unapproved: accepted regina-normal [source] (jammy-proposed) [7.0-2ubuntu1]
[07:59] <bdmurray> GunnarHj: I'll remove it
[08:02] -queuebot:#ubuntu-release- Unapproved: shotwell (jammy-proposed/main) [0.30.14-1ubuntu5 => 0.30.14-1ubuntu6] (ubuntu-desktop)
[08:14] -queuebot:#ubuntu-release- Unapproved: firmware-sof (jammy-proposed/restricted) [2.0-1ubuntu2 => 2.0-1ubuntu3] (no packageset)
[08:14] -queuebot:#ubuntu-release- Unapproved: wine-development (jammy-proposed/universe) [6.20~repack-1 => 6.22~repack-1] (i386-whitelist) (sync)
[08:16] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [sync] (jammy-proposed) [6.22~repack-1]
[08:16] -queuebot:#ubuntu-release- Unapproved: halide (jammy-proposed/universe) [13.0.4-1ubuntu2 => 14.0.0-1] (no packageset) (sync)
[08:16] -queuebot:#ubuntu-release- Unapproved: accepted halide [sync] (jammy-proposed) [14.0.0-1]
[08:16] <seb128> vorlon, bug #1969464 as a FYI, unsure why that user installed casper on an installed system but it seems to indicate there is a C/R needed there?
[08:16] <ubottu> Bug 1969464 in casper (Ubuntu) "Ubuntu 22.04 fails update Unpacking casper (1.470) over (1.468)" [Undecided, New] https://launchpad.net/bugs/1969464
[08:17] <seb128>  trying to overwrite '/usr/share/initramfs-tools/scripts/casper-premount/20iso_scan', which is also in package lupin-casper 0.57build1
[08:17] <seb128>  
[08:18] <seb128> bug #1969357 is a gnome-session issue which makes unity sessions not work
[08:18] <ubottu> Bug 1969357 in unity (Ubuntu) "Unity7 crashes on Jammy with 22.04's gnome-session version" [Undecided, Confirmed] https://launchpad.net/bugs/1969357
[08:18] <GunnarHj> Thx bdmurray
[08:18] <seb128> unsure what's the status of the unity support nowadays but I'm mentioning it because that sounds like an issue that might trigger a respin if we want to fix it for them...
[08:24] -queuebot:#ubuntu-release- Unapproved: ganeti (jammy-proposed/universe) [3.0.2-1 => 3.0.2-1ubuntu1] (no packageset)
[08:25] -queuebot:#ubuntu-release- Unapproved: accepted ganeti [source] (jammy-proposed) [3.0.2-1ubuntu1]
[08:31] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (focal-proposed) [1.187.30]
[09:35] -queuebot:#ubuntu-release- Unapproved: virtualbox-hwe (jammy-proposed/multiverse) [6.1.32-dfsg-2ubuntu1.22.04.1build1 => 6.1.34-dfsg-1ubuntu1.22.04.1] (kernel-dkms)
[09:47] -queuebot:#ubuntu-release- Unapproved: halide (jammy-proposed/universe) [14.0.0-1 => 14.0.0-1ubuntu1] (no packageset)
[09:48] -queuebot:#ubuntu-release- Unapproved: accepted halide [source] (jammy-proposed) [14.0.0-1ubuntu1]
[10:29] <sil2100> Everyone! Please be sure to pick up your favorite flavor iso/img and do some testing for the 22.04 release!
[10:29] <sil2100> http://iso.qa.ubuntu.com/qatracker/milestones/432/builds
[10:29] -queuebot:#ubuntu-release- Unapproved: walinuxagent (bionic-proposed/main) [2.2.45-0ubuntu1~18.04.1 => 2.2.45-0ubuntu1~18.04.2] (ubuntu-cloud)
[10:45] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Jammy Final] has been updated (2195086996)
[10:56] <bdmurray> waveform: Do you have any more info about bug 1969529?
[10:56] <ubottu> Bug 1969529 in snapd (Ubuntu) "snapd failing to seed firefox on Pi 400" [Undecided, New] https://launchpad.net/bugs/1969529
[10:58] <waveform> bdmurray, not yet -- I've now seen similar OOPS reported in several first-boot situations while it's trying to install firefox (presumably from the seed) but it typically resolves itself within a couple of minutes (playing "where's my browser" for a couple of minutes still isn't a *great* user experience IMO, but better than the near ~15 minutes it took on that pi400 run last night). It's definitely *not* specific to the 400 though
[10:59] <waveform> not down to lack of memory either -- appeared pretty rapidly on the Pi4 2GB run I did earlier in the evening, and then took a while (~3-4 minutes) on an 8GB. Both were booting off SD card as well
[11:06] <sil2100> It feels a bit bad
[11:09] -queuebot:#ubuntu-release- Unapproved: backport-iwlwifi-dkms (jammy-proposed/universe) [9858-0ubuntu2 => 9858-0ubuntu3] (no packageset)
[11:10] -queuebot:#ubuntu-release- Unapproved: accepted backport-iwlwifi-dkms [source] (jammy-proposed) [9858-0ubuntu3]
[11:11] <xnox> backport-iwlwifi-dkms above is just an sru/0-day-sru thing
[11:11] <xnox> (unseeded)
[11:13] -queuebot:#ubuntu-release- New binary: halide [amd64] (jammy-proposed/universe) [14.0.0-1ubuntu1] (no packageset)
[11:31] -queuebot:#ubuntu-release- Unapproved: json-c (jammy-proposed/main) [0.15-2build4 => 0.15-3] (core, i386-whitelist) (sync)
[11:43] -queuebot:#ubuntu-release- New binary: halide [riscv64] (jammy-proposed/universe) [14.0.0-1ubuntu1] (no packageset)
[11:44] -queuebot:#ubuntu-release- Unapproved: screentest (jammy-proposed/universe) [2.0-2.2build1 => 2.1-1] (no packageset) (sync)
[11:45] -queuebot:#ubuntu-release- Unapproved: accepted screentest [sync] (jammy-proposed) [2.1-1]
[11:52] <seb128> is the oem setup mode supposed to pull in langpacks post install if needed?
[11:52] <seb128> I tried to do a french install and then selected netherlands as language for the user during the setup
[11:53] <seb128> after restart the session was with a LANG=nl_NL lC_.. as fr_FR and strings displayed in english because the nl langpacks aren't installed
[11:53] <seb128> I didn't try oem installs for a while and last time I did I probably picked the same language for the install and for the user to configure so I've no idea if that's a known limitation
[11:54] <seb128> or if that's maybe a regression
[11:56] <seb128> I'm unsure how to flag that on the tracker, that seems a rather import issue since I expect oem factory is going to produce config for several country and we expect the users to be able to get their language working after setup in any of those?
[12:19] <ahasenack> is there a way to identify the "version" of the iso that was used in the install, on the installed system?
[12:20] <ahasenack> the "welcome" window has no content, just the language selections on the left and the buttons, but no text in the middle
[12:24] <ahasenack> tbh, I don't remember if that was always empty, or if it had a welcome text (this is after "try ubuntu" and clicking on the installer app)
[12:25] <seb128> ahasenack, are you talking about the installer or the installed system? if that's the installed system I'm unsure what UI you are refearing to there
[12:26] <seb128> ahasenack, on the installed system you can check /var/log/installer/media-info
[12:26] <ahasenack> installer, sorry, there were two points
[12:26] <jbicha> sil2100: we are looking into LP: #1969619
[12:26] <ubottu> Launchpad bug 1969619 in gnome-control-center (Ubuntu Jammy) "RDP Sharing appears on by default in jammy" [High, Triaged] https://launchpad.net/bugs/1969619
[12:31] <seb128> ahasenack, the right side should have some text with a reference to the release notes
[12:32] <ahasenack> yeah, that was empty
[12:32] <ahasenack> ah, maybe because network wasn't enabled yet?
[12:32] <ahasenack> does it fetch that content from the network, all of it?
[12:33] <seb128> yes
[12:34] <ahasenack> not just release notes?
[12:34] <seb128> I'm unsure what's the logic, but the text is basically an url to click to open the release note on internet
[12:34] <seb128> if you are not online that has no point so maybe we just don't display it in that case?
[12:35] <ahasenack> I'll double check once this install finishes
[12:35] <seb128> it's not a regression afaik
[12:35] <seb128> ack
[12:35] <ahasenack> actually, I can just launch the installer again
[12:36] <ahasenack> ok, with networking enabled, there is one phrase that shows up: "You may wish to read the release notes", and "release notes" is a link
[12:36] <seb128> right, that's the expected behaviour
[12:37] <ahasenack> I think that should show up always, even without network, as it will launch firefox, and if you are not connected, it will be obvious, but ok
[12:41] <seb128> ahasenack, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/856213 for reference
[12:41] <ubottu> Launchpad bug 856213 in ubiquity (Ubuntu) "Links 'Release notes' and 'Update this installer' shouldn't be displayed without network connection" [Undecided, Fix Released]
[12:42] <seb128> ahasenack, I agree it wouldn't hurt to always display the text probably but that's minor and not new, probably not worth bothering about now
[12:43] <LocutusOfBorg> I just found libjson-c-dev is not marked as M-A: same
[12:43] <LocutusOfBorg> I think we might want to accept json-c
[12:49] <ricotz> seb128, if there is going to be another iso build then accepting shotwell might be a good idea?
[12:50] <cpaelzer> ubuntu-release: I have reviewed network-manager-sstp in jammy-NEW and TL;DR it LGTM. AFAICS it is not blocked by the final-freeze constraints (unseeded, universe), nor did I find quality or license issues. But since in this week you kind of own the jammy-queue I wanted to ask for an ack before I'd accept that.
[12:50] <cpaelzer> rbasak: ^^ FYI
[12:54] <seb128> ricotz, it's rather a minor issue so probably fine for a SRU but I'm not release team member
[12:58] <bdmurray> shotwell seems appropriate for an SRU
[12:59] <ricotz> alright, thanks for checking
[13:05] -queuebot:#ubuntu-release- Unapproved: accepted gallery-dl [source] (focal-backports) [1.21.1-1~bpo20.04.1]
[13:05] <seb128> bdmurray, could anyone read what I wrote about oem config a bit over an hour ago? I don't know how problematic that is and would like feedback from you guys if possible
[13:26] <bdmurray> seb128: Do you know what the behavior was in 20.04 or 21.10?
[13:27] <xnox> seb128:  so, we were out having japanese bento boxes at the borough market, with fruity beers from the rake, and italian gelato ice cream. it was lovely. thanks for asking
[13:27] <seb128> bdmurray, no, which is basically what I was writting
[13:27] <xnox> seb128:  about logic.
[13:27] <seb128> 'I didn't try oem installs for a while and last time I did I probably picked the same language for the install and for the user to configure so I've no idea if that's a known limitation'
[13:27] <xnox> seb128:  oem-config setup by the user is effectively local-only and offline-only.
[13:28] <xnox> seb128:  what should happen next, is that after user logs in, and configures network, eventually update-manager should run, and eventually one should get a popup
[13:28] <seb128> xnox, so not getting the langpacks for the language you picked even if you are online is expected?
[13:28] <seb128> k, maybe I didn't wait enough for that
[13:28] <xnox> seb128:  "incomplete language support, would you like to install it?" and if one clicks that, it should take one to the language support app to install that.
[13:28] <xnox> seb128:  i think it is a daily timer unit thing?! =/
[13:28] <seb128> I will mark it as a pass if that's the expected behaviour, it's quite a crappy user experience though
[13:29] <xnox> seb128:  or like aptupdate triggered hook, i think, if one does `sudo apt update` in the terminal, it should cause the popup to be triggered.
[13:30] <xnox> seb128:  you are empowered to impove on the experience. but we can't do much more than to ask user for language; and dynamically install said language support if it exists, and when they have networking.
[13:32] <seb128> xnox, well, the VM was online, so the 'in session wizard' we display after restart where you pick the language/tz/keyboard could have pulled in the langpacks or called to language-selector
[13:32] <seb128> xnox, I was mostly asking if that's a regression or a missing feature, if it's a missing feature it's fine
[13:32] <seb128> that's something we might be able to improve in the new installer :)
[13:35] <xnox> seb128:  so when we build custom oem images; we build them with a different default locale (like the kylin/chinese one) and then everything defaults to that language, part of the install / config / and the second stage oem config.
[13:35] -queuebot:#ubuntu-release- Unapproved: open-iscsi (bionic-proposed/main) [2.0.874-5ubuntu2.10 => 2.0.874-5ubuntu2.11] (ubuntu-desktop, ubuntu-server)
[13:36] <bdmurray> Going forward could we add more languages to the ISOs?
[13:37] <seb128> xnox, the world is more complicated than that though, some german users buy a laptop in the US because they want qwerty but they still want to use german for their locale
[13:37] <xnox> seb128:  also i do wonder, if we could just double our iso size (because who cares) and just have all language packs anyway?
[13:37] <seb128> xnox, but as said I was mostly asking if that was the expected behaviour, and it is, we could easily do better with $resources
[13:38] <xnox> seb128:  i wonder how much space all the language packs are, versus the ones we ship already?
[13:38] <seb128> bdmurray, xnox, we could probably add other languages, it's tricky question on cost vs benefit, more content mean more mirror use, download time, install time
[13:39] <seb128> though the install time will be less of an issue in the new install where each language has it's own layer
[13:39] <seb128> rather than having the ubiquity way to copying everything to remove things then
[13:39] <bdmurray> I'd imagine we could add more languages for the point release
[13:39] <seb128> but also it would be trivial for oem-setup to call the language-selector helper if the system is online
[13:40] <seb128> rather than having to waiting for a systemd timed unit
[13:41] -queuebot:#ubuntu-release- Unapproved: gtk4 (jammy-proposed/main) [4.6.2+ds-1ubuntu2 => 4.6.2+ds-1ubuntu3] (desktop-core, i386-whitelist)
[13:42] <xnox> seb128:  Need to get 175 MB of archives. after doing (apt install --download-only 'language-pack-*') and it is xz compressed. I do wonder if actually having support for all/any language packs, is only 174MB, maybe it's worth it?
[13:43] <xnox> we may have them all in same layer and delete after the install like we do with most things; or yeah have layers that remove them.
[13:50] <jbicha> ubuntu-release: please accept gtk4 to jammy-proposed as a potential 0 day sru
[13:56] <bdmurray> jbicha: We usually just leave them in unapproved in case something else happens.
[13:57] <cpaelzer> ignore my question above, I'm rejecting network-manager-sstp for having grown build issues in the meantime
[13:58] <jbicha> so if nothing else critical happens, it might just be built on Thursday and if eligible, pushed out faster than the usual 7 day wait?
[14:04] <bdmurray> 0 day SRUs hasn't traditionally meant a speedy release to -updates but as with any SRU the 7 day period can be waived.
[14:05] <vorlon> LocutusOfBorg: ok, timing is suboptimal for accepting jansson now as this requires respins of all media if we accept it into the release pocket.  bdmurray, sil2100
[14:06] -queuebot:#ubuntu-release- New: rejected network-manager-sstp [source] (jammy-proposed) [1.3.0-0ubuntu1]
[14:06] <LocutusOfBorg> vorlon, in that case, also virtualbox might be good :)
[14:06] <LocutusOfBorg> if you respin
[14:07] <bdmurray> There is nothing on the radar yet which precipitate a respin
[14:08] -queuebot:#ubuntu-release- New: accepted halide [amd64] (jammy-proposed) [14.0.0-1ubuntu1]
[14:08] -queuebot:#ubuntu-release- New: accepted halide [riscv64] (jammy-proposed) [14.0.0-1ubuntu1]
[14:13] <sil2100> waveform: any luck with the snap seeding of the firefox snap? I think maybe we could have the snapd team looking at it as well?
[14:14] <waveform> sil2100, I've updated the bug with another semi-replication: managed to get it to wait for ~6.5 minutes on a fresh install, but then when I tried again with another fresh card there was no wait at all... (and no OOPS reported in syslog ... I'm wondering if it managed to set up the snap during the initial setup prior to the first login or something)
[14:16] <waveform> sil2100, given it always seems to rectify itself "after some time" and I've no idea *where* the actual issue is or why it only manifests on certain occasions, I'm tempted to just release note it ("if your firefox disappears after first login, just wait: it'll come back ... eventually")
[14:16] <sil2100> waveform: yeah, I think this is the only realistical way to handle it. Could you write some nice words about it on the raspi known issues?
[14:16] <vorlon> seb128: seems correct that casper should have a conflicts/replaces on lupin-casper, but I'm more concerned at why a user has installed and ended up with casper on the target system
[14:16] <sil2100> Thank you!
[14:17] <waveform> sil2100, will do
[14:17] <seb128> vorlon, right, I checked with the current candidate ISO and casper wasn't installed, unsure how they ended up in that situation...
[14:19] <vorlon> seb128: ack; asking for logs on the bug
[14:22] <sil2100> I'm a bit worried about LP #1969393
[14:22] <ubottu> Launchpad bug 1969393 in The Ubuntu-power-systems project "crash trying to install jammy final on a ppc64le" [Critical, New] https://launchpad.net/bugs/1969393
[14:22] -queuebot:#ubuntu-release- New: accepted pyboard-rshell [source] (jammy-proposed) [0.0.31-0ubuntu1]
[14:24] <sil2100> I still don't know if it's networking infra related or not, and it's now marked as critical
[14:24] <sil2100> And IIUC it was fine before?
[14:24] -queuebot:#ubuntu-release- New binary: pyboard-rshell [amd64] (jammy-proposed/none) [0.0.31-0ubuntu1] (no packageset)
[14:26] <vorlon> sil2100: there had been some internal discussion around this; speculation is that the network is "broken" and not giving proper DNS resolution but that subiquity used to handle this more gracefully.  A name resolution failure should not result in a crash of the installer, for usre
[14:26] <vorlon> *sure
[14:27] <vorlon> dbungert: ^^ ?
[14:27] <ogayot> sil2100: it would make sense since we moved from one HTTP library to another (i.e., from requests to aiohttp) for querying the geoip service for JJ.
[14:28] <bdmurray> vorlon: I believe ginggs has a casper MP
[14:29] <ogayot> but the logs don't have any element to prove the exception occurred when resolving the geoip service name
[14:29] <vorlon> bdmurray: yes, I've seen it
[14:29] <vorlon> bdmurray: are you wanting to land casper and respin for this?  As I said, the greater bug is casper being on the installed system
[14:30] <vorlon> the upgrade issue is a non-concern post-release, no one should be doing a dist-upgrade on a live system from 21.10 to 22.04
[14:30] <bdmurray> vorlon: no, I initially said having casper installed was weird
[14:31] <sil2100> vorlon: I think it
[14:32] <sil2100> eh, enter pressed too soon: I think we didn't saw it installed here during testing
[14:33] <sil2100> So at least in my understanding this is in no shape or form a release blocker
[14:33] <sil2100> (I mean, I just say I don't see any reason to respin just yet!)
[14:35] <bdmurray> jbicha: Have you seen anything about gdm taking 1m 30s to stop and slowing shutdown?
[14:36] <vorlon> sil2100: of course - and if they had that version installed they must have installed before we dropped lupin so we don't know that it even occurs with the current installer, and it's clearly infrequent - but we should follow up on it and maybe fix it for .1
[14:36] <sil2100> +1!
[14:36] <jbicha> bdmurray: no I haven't seen that for gdm
[14:37] <vorlon> seb128: so we bumped the size limit for Ubuntu Desktop to 3.6GB... today's image is 3654957056...
[14:38] <vorlon> seb128: the OVERSIZED warnings do not block us from releasing, but I do want to have agreement w/ Desktop team that it's ok that the image is this size
[14:41] <seb128> vorlon, :-(
[14:42] <seb128> vorlon, I wish we had a record of the manifest to be able to go back and see what changed, the KPI showed the ISO on the 8th was at 3.20GiB and on the 9th at 3.39GiB
[14:43] <vorlon> yeah, I have been thinking that we should start checking manifest + a record of the image size into git
[14:43] <seb128> vorlon, also http://cdimage.ubuntu.com/daily-live/pending/ shows 3.4GB
[14:43] <seb128> is a GB vs GiB mismatch?
[14:43] <vorlon> seb128: probably
[14:43] <seb128> can we get it bumped to 3.6GiB :p
[14:44] <vorlon> yes ;)
[14:44] <seb128> thx
[14:44] <sil2100> Those scary image sizes
[14:44] <vorlon> seb128: lol du -sh says it's 3.5GiB
[14:44] <vorlon> so I don't know why it's 3.4 on the website
[14:45] <seb128> the KPI says 3.39GiB
[14:45] <seb128> fun
[14:45] <vorlon> oh, du -sh is wrong, don't know why it's doing that
[14:45] <seb128> ah no, current is 3.404 there
[14:45] <vorlon> this is 3.4.0GiB
[14:45] <seb128> right
[14:45] <seb128> KPI being https://ubuntu-release.kpi.ubuntu.com/d/XgP-fUlGz/ubuntu-cd-images?orgId=1&var-release=jammy&var-flavour=ubuntu&from=now-30d&to=now
[14:46] <vorlon> anyway, bumped
[14:46] <dbungert> vorlon: regarding LP #1969393, I believe ogayot's assessment to be correct.
[14:46] <ubottu> Launchpad bug 1969393 in The Ubuntu-power-systems project "crash trying to install jammy final on a ppc64le" [Critical, New] https://launchpad.net/bugs/1969393
[14:46] <dbungert> sil2100: what can we do to alleviate your concern?
[14:47] <seb128> does someone still have the manifest of the beta image by any chance?
[14:47] <vorlon> dbungert: do we have time to fix the crash today and get a new subiquity out?
[14:47] <seb128> I'm still wondering why we got that increase on the 9th
[14:48] <seb128> I don't spot anything obvious on -changes
[14:48] <dbungert> vorlon: timewise that could be done
[14:48] <vorlon> seb128: beta is still published under https://releases.ubuntu.com/
[14:48] <seb128> vorlon, ah, thanks
[15:01] <Beret> how goes awesome folks?
[15:01] <Beret> I'm chomping at the bit over here - is it thursday yet? :)
[15:02] <vorlon> seb128: package additions: gnome-bluetooth-3-common libgl1-amber-dri libgnome-bluetooth-3.0-13 libnftables1 nftables xcvt.  We also *dropped* python3.9 since then.  And then there's lots of churn, new kernel of course and various library updates
[15:02] <sil2100> dbungert: if the fix is in subiquity itself, I think I'm a bit less concerned - since even if we don't respin, subiquity can always refresh to the new version for those with network
[15:03] <sil2100> Which is the use-case here
[15:03] <vorlon> Beret: only barely in New Zealand :)
[15:07] <dbungert> sil2100: I do believe that any change here is going to be in subiquity itself, even if only to handle the failure better.
[15:07] <sil2100> Beret: \o/
[15:08] <sil2100> dbungert: ok, so this makes me feel a bit better
[15:08] <seb128> vorlon, k, the increase is due to the oem kernel + corresponding nvidia&co being added to the pool of the iso
[15:09] <vorlon> seb128: ah
[15:09] <bdmurray> vorlon: should we also remove the OVERSIZED marker on cdimage?
[15:09] <vorlon> bdmurray: shrug.  It doesn't get copied to the release directory
[15:11] <bdmurray> jbicha: the slow shutdown happened on 1 out of 2 systems here so maybe its hardware specific
[15:19] <sil2100> jchittum: hey! How's the cloud image situation? Still all good?
[15:25] <jchittum> sil2100: we're at the chilling phase. I'm going to kick off download RCs in an hour or so
[15:25] <jchittum> things looking strong for the ISOs
[15:41] <dbungert> sil2100: vorlon: I just chatted with ogayot, who came up with a reproducer for this issue on amd64 by deliberatly configuring for bad DNS.  My plan for the day is to look further at that and see if we can make that robust.
[15:43] <sil2100> jchittum: excellent news then, thank you
[15:43] <sil2100> dbungert: yay!
[15:48] <jchittum> sil2100: Is there a targeted release time? I'm scrolling back and don't see thing
[15:49] <sil2100> jchittum: it's always hard to say. Usually those happen tomorrow in our afternoon/evening (UTC), so I'd aim for that
[15:49] <jchittum> 👍
[15:58] <vorlon> dbungert: thanks!
=== popey0 is now known as popey
[16:53] -queuebot:#ubuntu-release- New source: text-engine (jammy-proposed/primary) [0.1.1-0ubuntu2]
[16:56] -queuebot:#ubuntu-release- New: rejected text-engine [source] (jammy-proposed) [0.1.1-0ubuntu1]
[16:57] -queuebot:#ubuntu-release- New: accepted text-engine [source] (jammy-proposed) [0.1.1-0ubuntu2]
[16:59] -queuebot:#ubuntu-release- New binary: text-engine [s390x] (jammy-proposed/none) [0.1.1-0ubuntu2] (no packageset)
[17:00] -queuebot:#ubuntu-release- New binary: text-engine [ppc64el] (jammy-proposed/none) [0.1.1-0ubuntu2] (no packageset)
[17:01] -queuebot:#ubuntu-release- New binary: text-engine [arm64] (jammy-proposed/none) [0.1.1-0ubuntu2] (no packageset)
[17:02] -queuebot:#ubuntu-release- New binary: text-engine [amd64] (jammy-proposed/none) [0.1.1-0ubuntu2] (no packageset)
[17:02] -queuebot:#ubuntu-release- New binary: text-engine [armhf] (jammy-proposed/none) [0.1.1-0ubuntu2] (no packageset)
[17:08] -queuebot:#ubuntu-release- New: accepted pyboard-rshell [amd64] (jammy-proposed) [0.0.31-0ubuntu1]
[17:29] <Eickmeyer> Studio is looking good for release, but should we be expecting respins?
[17:29] <Eickmeyer> I mean, for whatever reason.
[17:31] <vorlon> I'm not aware of any
[17:31] <vorlon> we might have a server respin later
[17:31] <Eickmeyer> Thanks vorlon!
[17:37] -queuebot:#ubuntu-release- Unapproved: text-engine (jammy-proposed/universe) [0.1.1-0ubuntu2 => 0.1.1-0ubuntu3] (no packageset)
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted text-engine [source] (jammy-proposed) [0.1.1-0ubuntu3]
[17:40] -queuebot:#ubuntu-release- New binary: text-engine [s390x] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: text-engine [amd64] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[17:42] -queuebot:#ubuntu-release- New binary: text-engine [ppc64el] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[17:43] -queuebot:#ubuntu-release- New binary: text-engine [arm64] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[17:44] -queuebot:#ubuntu-release- New binary: text-engine [armhf] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[17:49] -queuebot:#ubuntu-release- New source: network-manager-sstp (jammy-proposed/primary) [1.3.0-0ubuntu1]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [amd64] (jammy-proposed) [0.1.1-0ubuntu2]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [armhf] (jammy-proposed) [0.1.1-0ubuntu2]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [s390x] (jammy-proposed) [0.1.1-0ubuntu2]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [arm64] (jammy-proposed) [0.1.1-0ubuntu3]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [ppc64el] (jammy-proposed) [0.1.1-0ubuntu3]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [arm64] (jammy-proposed) [0.1.1-0ubuntu2]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [amd64] (jammy-proposed) [0.1.1-0ubuntu3]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [s390x] (jammy-proposed) [0.1.1-0ubuntu3]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [ppc64el] (jammy-proposed) [0.1.1-0ubuntu2]
[17:52] -queuebot:#ubuntu-release- New: rejected text-engine [armhf] (jammy-proposed) [0.1.1-0ubuntu3]
[18:09] -queuebot:#ubuntu-release- New binary: text-engine [riscv64] (jammy-proposed/universe) [0.1.1-0ubuntu3] (no packageset)
[18:22] <jchittum> vorlon: why the server respin? Is it something I should hold cloud-image RCs for?
[18:22] <vorlon> jchittum: subiquity bug, nothing you need to worry about
[18:23] <vorlon> (the crash on DNS failure discussed in scrollback)
[18:24] <jchittum> TY. I'll spin cloud RCs now then
[18:29] -queuebot:#ubuntu-release- New: accepted text-engine [riscv64] (jammy-proposed) [0.1.1-0ubuntu3]
[18:33] -queuebot:#ubuntu-release- Unapproved: rejected json-c [sync] (jammy-proposed) [0.15-3]
[18:36] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-hwe [source] (jammy-proposed) [6.1.34-dfsg-1ubuntu1.22.04.1]
[18:38] -queuebot:#ubuntu-release- Unapproved: accepted firmware-sof [source] (jammy-proposed) [2.0-1ubuntu3]
[18:44] -queuebot:#ubuntu-release- Unapproved: accepted shotwell [source] (jammy-proposed) [0.30.14-1ubuntu6]
[18:48] <vorlon> rbasak: the network-manager-sstp upload has debian/copyright errors per lintian; "and/or" is not valid in a license specifier
[18:49] <vorlon> logically, "foo and bar or foo or bar" reduces to "foo or bar" so it should just say that :P
[18:51] <vorlon> also there's the annoying inconsistency that Debian requires debian/copyright to cover all files in the source whether or not these are copied into the binary packages, but an exception is made for autoconf output <cough>
[19:05] -queuebot:#ubuntu-release- Unapproved: gnome-control-center (jammy-proposed/main) [1:41.4-1ubuntu12 => 1:41.4-1ubuntu13] (ubuntu-desktop)
[19:07] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-manager (jammy-proposed/universe) [0.2.3-2 => 0.3.0-0ubuntu1] (no packageset)
[19:07] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-manager [source] (jammy-proposed) [0.3.0-0ubuntu1]
[19:14] <dbungert> if any ppc testers are around, we have a proposed change for LP: #1969393 on the edge channel
[19:14] <ubottu> Launchpad bug 1969393 in The Ubuntu-power-systems project "crash trying to install jammy final on a ppc64le" [Critical, New] https://launchpad.net/bugs/1969393
[19:15] <vorlon> dbungert: do you have an amd64 reproducer environment also and have you tested it there?
[19:16] <jbicha> the gnome-control-center upload fixes a high priority issue for at least a 0-day SRU
[19:17] <dbungert> vorlon: ogayot has a reproducer, it never worked for me.  Instead I've been using a hostile stub function that always fails the lookup.
[19:18] <vorlon> dbungert: ack.  I've pinged patriciasd internally
[19:19] <dbungert> yes, I'm working with patriciasd now
[19:19] <vorlon> ok great
[19:19] <vorlon> aside from validating the fix itself, what else needs to be done before promoting to stable?
[19:19] <vorlon> jbicha: accepted for SRU, not for release
[19:20] <dbungert> 1) cherry-pick to create a 2nd PR targetting the stable branch, 2) merge that, 3) import code to LP (quick), 4) trigger builds in launchpad (slow in the case of risc-v)
[19:20] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (jammy-proposed) [1:41.4-1ubuntu13]
[19:21] <rbasak> vorlon: the change was requested by cpaelzer. I just changed it to his paste (and added License text).
[19:21] <vorlon> rbasak: what exactly was the change requested?
[19:22] <rbasak> Well he gave me https://paste.ubuntu.com/p/Jhjw7v3FFt/ which might have just been the output from some tool
[19:22] <vorlon> evidently not a reliable tool
[19:22] <rbasak> I'm happy to adjust exactly as requested :)
[19:24] <vorlon> rbasak: well, I would say you can just omit all of this added stuff per my note about autoconf being accepted in Debian's copyright practice; and also I want to know what tools cpaelzer is using during NEW review that are giving bad output :)
[19:27] <rbasak> vorlon: no problem. Do you want a fresh upload with that bit undone?
[19:27] <vorlon> rbasak: yes please
[19:29] <rbasak> OK working on it
[19:31] -queuebot:#ubuntu-release- Unapproved: gnome-tweaks (jammy-proposed/universe) [42~beta-1 => 42~beta-1ubuntu1] (no packageset)
[19:32] <rbasak> Reuploaded. I'm just doing a quick build test, though I don't see that it should have changed.
=== dannf_ is now known as dannf
[19:32] <rbasak> Build test successful
[19:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-tweaks [source] (jammy-proposed) [42~beta-1ubuntu1]
[19:32] -queuebot:#ubuntu-release- New source: network-manager-sstp (jammy-proposed/primary) [1.3.0-0ubuntu1]
[19:32] <rbasak> vorlon: ^ thanks
[19:40] -queuebot:#ubuntu-release- New: rejected network-manager-sstp [source] (jammy-proposed) [1.3.0-0ubuntu1]
[19:42] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [source] (jammy-proposed) [1.3.0-0ubuntu1]
[19:44] <rbasak> Thanks!
[19:45] -queuebot:#ubuntu-release- New binary: network-manager-sstp [amd64] (jammy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
[19:45] -queuebot:#ubuntu-release- New binary: network-manager-sstp [s390x] (jammy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
[19:45] -queuebot:#ubuntu-release- New binary: network-manager-sstp [ppc64el] (jammy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
[19:46] -queuebot:#ubuntu-release- New binary: network-manager-sstp [arm64] (jammy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
[19:46] -queuebot:#ubuntu-release- New binary: network-manager-sstp [armhf] (jammy-proposed/none) [1.3.0-0ubuntu1] (no packageset)
[20:14] -queuebot:#ubuntu-release- New binary: network-manager-sstp [riscv64] (jammy-proposed/universe) [1.3.0-0ubuntu1] (no packageset)
[20:27] <mwhudson> good morning, how on fire is everything rn?
[20:58] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy Final] has been marked as ready
[21:18] -queuebot:#ubuntu-release- New source: rpi-ws281x-python (jammy-proposed/primary) [3.1.0-0ubuntu1]
[21:18] -queuebot:#ubuntu-release- New source: rpi-ws281x (jammy-proposed/primary) [1.1.0-0ubuntu1]
[21:19] -queuebot:#ubuntu-release- New source: unicorn-hat-hd (jammy-proposed/primary) [0.0.4-0ubuntu1]
[21:19] -queuebot:#ubuntu-release- New source: unicorn-hat (jammy-proposed/primary) [2.2.3-0ubuntu1]
[21:19] -queuebot:#ubuntu-release- New source: unicorn-hat-mini (jammy-proposed/primary) [0.0.2-0ubuntu1]
[21:40] -queuebot:#ubuntu-release- Unapproved: squeekboard (jammy-proposed/universe) [1.17.0-1 => 1.17.1-0ubuntu1] (no packageset)
[21:41] -queuebot:#ubuntu-release- Unapproved: accepted squeekboard [source] (jammy-proposed) [1.17.1-0ubuntu1]
[21:48] <vorlon> rbasak: fyi: I: network-manager-sstp: hardening-no-bindnow [usr/lib/pppd/2.4.9/nm-sstp-pppd-plugin.so]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [amd64] (jammy-proposed) [1.3.0-0ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [armhf] (jammy-proposed) [1.3.0-0ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [riscv64] (jammy-proposed) [1.3.0-0ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [arm64] (jammy-proposed) [1.3.0-0ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [s390x] (jammy-proposed) [1.3.0-0ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted network-manager-sstp [ppc64el] (jammy-proposed) [1.3.0-0ubuntu1]
[21:55] -queuebot:#ubuntu-release- New: accepted rpi-ws281x [source] (jammy-proposed) [1.1.0-0ubuntu1]
[21:56] -queuebot:#ubuntu-release- Unapproved: virtualbox (jammy-proposed/multiverse) [6.1.32-dfsg-1build1 => 6.1.34-dfsg-1] (kernel-dkms, ubuntu-cloud) (sync)
[21:56] <dbungert> I have new subiquity snaps building for Jammy.  Those snap builds are nearly done excluding RISC-V, which will be some time.
[21:56] -queuebot:#ubuntu-release- Unapproved: virtualbox-guest-additions-iso (jammy-proposed/multiverse) [6.1.32-1 => 6.1.34-1] (no packageset) (sync)
[21:57] -queuebot:#ubuntu-release- Unapproved: halide (jammy-proposed/universe) [14.0.0-1ubuntu1 => 14.0.0-2] (no packageset) (sync)
[21:57] -queuebot:#ubuntu-release- Unapproved: accepted halide [sync] (jammy-proposed) [14.0.0-2]
[21:57] -queuebot:#ubuntu-release- Unapproved: accepted virtualbox-guest-additions-iso [sync] (jammy-proposed) [6.1.34-1]
[21:57] -queuebot:#ubuntu-release- New binary: rpi-ws281x [armhf] (jammy-proposed/none) [1.1.0-0ubuntu1] (no packageset)
[21:58] -queuebot:#ubuntu-release- New binary: rpi-ws281x [arm64] (jammy-proposed/none) [1.1.0-0ubuntu1] (no packageset)
[22:06] -queuebot:#ubuntu-release- New: accepted rpi-ws281x-python [source] (jammy-proposed) [3.1.0-0ubuntu1]
[22:11] -queuebot:#ubuntu-release- New: accepted rpi-ws281x [arm64] (jammy-proposed) [1.1.0-0ubuntu1]
[22:11] -queuebot:#ubuntu-release- New: accepted rpi-ws281x [armhf] (jammy-proposed) [1.1.0-0ubuntu1]
[22:15] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Jammy Final] has been marked as ready
[22:17] <vorlon> jawn-smith, waveform: unicorn-hat has a debian/copyright that references the 'MIT' license; per https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ this should be referred to instead as 'Expat'
[22:17] <vorlon> (not a NEW reject)
[22:22] <vorlon> jawn-smith, waveform: also, not sure that a separate python-unicornhat-doc package is warranted; the documentation here doesn't seem overly large
[22:23] -queuebot:#ubuntu-release- New: accepted unicorn-hat [source] (jammy-proposed) [2.2.3-0ubuntu1]
[22:56] <waveform> bah ... I knew that one (the Expat licensing thing)
[22:57] <waveform> on the -doc package, yes it's a pretty trivial one (basically a autodoc generated API page); I just tend to always split sphinx stuff into a separate -doc package out of habit
[23:03] -queuebot:#ubuntu-release- New binary: rpi-ws281x-python [arm64] (jammy-proposed/universe) [3.1.0-0ubuntu1] (no packageset)
[23:03] -queuebot:#ubuntu-release- New binary: rpi-ws281x-python [armhf] (jammy-proposed/universe) [3.1.0-0ubuntu1] (no packageset)
[23:07] <jawn-smith> vorlon, bdmurray, sil2100: I had to fail jammy ISO tests on the CM4 due to bug 1969689
[23:07] <ubottu> Bug 1969689 in linux-raspi (Ubuntu) "USB devices not detected on CM4" [Undecided, New] https://launchpad.net/bugs/1969689
[23:09] <vorlon> jawn-smith: hmm.  so this regressed post-beta?
[23:10] <jawn-smith> vorlon: it looks that way. I definitely recall the USB copy working on the beta test
[23:14] <vorlon> jawn-smith: if it's a dtb/kernel mismatch, did this regress in the kernel?
[23:14] <vorlon> or are we feeding dtbs into the kernel from elsewhere?
[23:14] <vorlon> (from another package)
[23:15] <jawn-smith> vorlon: actually, I'm looking and apparently the CM4 wasn't one of the devices I tested for the beta. I remember doing the USB test a number of times but I never marked it for the CM4 so I must not have tested the CM4
[23:15] <jawn-smith> http://iso.qa.ubuntu.com/qatracker/milestones/431/builds/246333/testcases
[23:16] <jawn-smith> CM4 was never tested
[23:16] <vorlon> hmm
[23:16] <vorlon> well, our options are limited at this point; I think this is going to wind up being a release note, advising users to wait until .1
[23:17] <jawn-smith> that's good to hear
[23:18] <vorlon> I wasn't closely involved in the beta, I think there needs to be a post mortem on why the beta rpi images were released with only 9 of 16 mandatory tests completed
[23:21] <sil2100> vorlon: we almost never have full test coverage for beta - we try to get as much testing in as possible, but we don't block on the lack of testing. Possibly because of respins we didn't get all the time we needed
[23:22] <jawn-smith> From my point of view there are two issues: Who is responsible for the testing and a lack of hardware
[23:22] <sil2100> I suppose a good test would be taking the beta images and checking if those have the same issue to see if it's a recent kernel regression
[23:22] <jawn-smith> It's still not really clear to me if the foundations team or the devices team should be doing all this testing
[23:23] <jawn-smith> and there are quite a few devices listed that we either don't have at all, or only have one or two of
[23:23] <vorlon> sil2100: well, it still leaves us in the situation that no one tested the CM4 at all until the day before release
[23:23] <vorlon> which should not be allowed to be the case for anything declared 'mandatory'
[23:23] <vorlon> there /at least/ needs to be a test done before kernel freeze, on these devices
[23:23] <waveform> yup, I usually test it last because it's such a pain (can't just move SD cards around, have to reconfig the board and reflash it for every single image)
[23:24] <sil2100> Agreed. Is it still the case that the cert lab don't have the CM4? Since I remember that being the case in the past
[23:24] <waveform> the cert lab has *a* CM4 AFAIK
[23:24] <jawn-smith> They actually have one CM4 but no way to test USB input on it AFAIK
[23:24] <jawn-smith> plars might know more
[23:24] <waveform> (ideally we'd test all the memory sizes, and the lite-model too)
[23:25] <sarnold> but these are unobtanium, right?
[23:25] <waveform> currently, yes
[23:25] -queuebot:#ubuntu-release- New: accepted rpi-ws281x-python [arm64] (jammy-proposed) [3.1.0-0ubuntu1]
[23:25] <jawn-smith> well, I've found a few on AliExpress
[23:25] -queuebot:#ubuntu-release- New: accepted rpi-ws281x-python [armhf] (jammy-proposed) [3.1.0-0ubuntu1]
[23:25] <jawn-smith> they're at a hefty markup (think $150 for what should be $35) but they exist
[23:28] <sil2100> Anyway, can someone check the beta images on the CM4 and see if it's already broken there?
[23:28] <jawn-smith> I'll start flashing one now and check on it a bit later
[23:28] <sil2100> Thanks!
[23:28] <jawn-smith> they take a loooong time to flash on the CM4