[00:00] <sarnold> ideally, with some upstream attention on valgrind or -fsanitize=address or coverity or something, to spot more cases like these
[00:14] -queuebot:#ubuntu-release- New binary: ffcv [amd64] (lunar-proposed/none) [0.0.3-2build1] (no packageset)
[00:16] -queuebot:#ubuntu-release- New binary: ffcv [arm64] (lunar-proposed/none) [0.0.3-2build1] (no packageset)
[00:16] -queuebot:#ubuntu-release- New binary: ffcv [ppc64el] (lunar-proposed/none) [0.0.3-2build1] (no packageset)
[00:16] -queuebot:#ubuntu-release- New binary: ffcv [armhf] (lunar-proposed/none) [0.0.3-2build1] (no packageset)
[00:18] -queuebot:#ubuntu-release- New binary: ffcv [s390x] (lunar-proposed/none) [0.0.3-2build1] (no packageset)
[00:33] -queuebot:#ubuntu-release- Unapproved: nextepc (lunar-proposed/universe) [0.3.10+nods-4.2 => 0.3.10+nods-4.2ubuntu1] (no packageset)
[00:34] -queuebot:#ubuntu-release- Unapproved: accepted nextepc [source] (lunar-proposed) [0.3.10+nods-4.2ubuntu1]
[00:44] -queuebot:#ubuntu-release- New: accepted ffcv [amd64] (lunar-proposed) [0.0.3-2build1]
[00:44] -queuebot:#ubuntu-release- New: accepted ffcv [armhf] (lunar-proposed) [0.0.3-2build1]
[00:44] -queuebot:#ubuntu-release- New: accepted ffcv [arm64] (lunar-proposed) [0.0.3-2build1]
[00:44] -queuebot:#ubuntu-release- New: accepted ffcv [ppc64el] (lunar-proposed) [0.0.3-2build1]
[00:45] -queuebot:#ubuntu-release- New: accepted ffcv [s390x] (lunar-proposed) [0.0.3-2build1]
[00:47] <vorlon> fyi snakefruit has been turned off.  As far as we know everything has been migrated to the new instance but if anyone sees anything not working, please ping
[00:55] <athos> Hi! I am about to push a new bug-fix version of ubuntu-advantage-tools. lucasmoura will probably mention additional details for a beta freeze exception request on this one :)
[00:56] <lucasmoura> yes, we have created this bug to detail the whole reason why thig bug should be a BetaFreezeException: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/2012735
[00:56] -ubottu:#ubuntu-release- Launchpad bug 2012735 in ubuntu-advantage-tools (Ubuntu) "update-manager crashed with uaclient.exceptions.UserFacingError in get_lscpu_arch()" [Critical, New]
[00:56] <lucasmoura> Please let me know if there is any additional detail that I need to provide regarding this release
[00:57] <vorlon> "we believe the dpkg command is stable enough" um lol it better be
[00:58] <vorlon> lucasmoura, athos: beta freeze exception means you believe the user impact is so critical that it's worth potentially delaying the beta release over; I want to make sure that assessment is correct
[01:00] <lucasmoura> vorlon, currently, ubuntu-advantage-tools is breaking update-manager on any release that is using a non-english locale. Since we are pushing this fix during beta freeze, that's why we thought the Beta Freeze Exception was needed
[01:00] <vorlon> any non-english locale is sufficient for me
[01:01] <vorlon> just wanted to check that this was the scope, since it didn't immediately look like a recent regression
[01:01] <vorlon> lucasmoura, athos: upload ASAP so I can review it in the queue, please
[01:02] <vorlon> ah but in fact, it's a regression from the immediately preceding version, so
[01:02] <vorlon> can we PLEASE lose these ~23.04 decorations on version numbers
[01:03] <lucasmoura> Yep, we have actually discussed about dropping those. We can remove it for the next release
[01:04] <athos> vorlon: ^ is this acceptable for this beta freeze?
[01:04] <vorlon> yes
[01:04] <vorlon> <vorlon> any non-english locale is sufficient for me
[01:05] <athos> I meant keeping the ~23.04 for this specific upload as suggested by lucasmoura
[01:05] <vorlon> athos: yes, as much as I hate it and as easy as I think it ought to be to change I'm not blocking you on version numbers being ugly
[01:06] <vorlon> kanashiro_: why is ruby-rackup in unstable if ruby-rack 3.0 is in experimental?
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (focal-proposed/main) [27.13.6~20.04.1 => 27.14.2~20.04.1] (core)
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (kinetic-proposed/main) [27.13.6~22.10.1 => 27.14.2~22.10.1] (core)
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (jammy-proposed/main) [27.13.6~22.04.1 => 27.14.2~22.04.1] (core)
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (lunar-proposed/main) [27.14.1~23.04.1 => 27.14.2~23.04.1] (core)
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (bionic-proposed/main) [27.13.6~18.04.1 => 27.14.2~18.04.1] (core)
[01:19] -queuebot:#ubuntu-release- Unapproved: ubuntu-advantage-tools (xenial-proposed/main) [27.13.6~16.04.1 => 27.14.2~16.04.1] (no packageset)
[01:19] <kanashiro[m]> vorlon: ruby-rackup in unstable was a mistake. It should have gone to experimental
[01:20] <vorlon> kanashiro[m]: fair enough. ruby-rack-session also?
[01:20] <kanashiro[m]> yes
[01:20] <vorlon> athos: lucasmoura: so does that run of notifications mean this bug is believed to break update-manager in all series?
[01:21] <lucasmoura> yes, it will. But 27.14.1 is not yet released on the other releases
[01:21] <athos> vorlon: it would with the current pending uploads in those series
[01:21] <vorlon> ok
[01:33] <vorlon> athos, lucasmoura: so there are some corner cases here, that are in no way supported configurations and I don't believe we have to care about them, but I wonder - is there a reason you weren't using the output of `uname -m` for this in the first place?
[01:35] <lucasmoura> We were using lscpu here because Livepatch was also using it to fetch architecture information
[01:35] <lucasmoura> And we wanted it to be consistent
[01:35] <Trevinho> <arraybolt3> "If there are too many problems..." <- None... I think it's better to handle the issues, that were just been ignored or hidden before but for sure were still causing some crashes hard to reproduce
[01:35] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-advantage-tools [source] (lunar-proposed) [27.14.2~23.04.1]
[01:36] <vorlon> lucasmoura: ok well that's a weird interface for them to have been using too
[01:37] <lucasmoura> But if the question is related to why we are using dpkg --print-architecture instead of uname, I think the decision was made here: https://github.com/canonical/ubuntu-pro-client/issues/914
[01:37] -ubottu:#ubuntu-release- Issue 914 in canonical/ubuntu-pro-client "Do not use `uname` to determine architecture" [Closed]
[01:37] <lucasmoura> vorlon, yes I think one of member of the Pro client team has opened an issue on Livepatch we found out about that issue
[01:38] <lucasmoura> I will confirm that tomorrow once he is working again
[01:39] <vorlon> right.  So the thing I'm thinking of is that it is entirely possible to be running an armhf userspace on an arm64 kernel and in this case dpkg --print-architecture and uname -m (or lscpu) give you two *different* answers.  I don't think we have arm64 livepatch and running ua pro for armhf on arm64 would just be a weird thing to even be trying to do, but it's technically possible
[01:40] <vorlon> so IMHO you should all be clear about which you *mean* (from the set of: dpkg userspace architecture; CPU architecture; kernel architecture) and be consistent with that
[01:42] <lucasmoura> vorlon, we already have a architecture mapping for those differences between dpkg and lscpu: https://github.com/canonical/ubuntu-pro-client/blob/main/uaclient/util.py#L611
[01:43] <lucasmoura> But if the architecture you are mentioned is not there, we can extend that mapping
[01:44] <lucasmoura> s/mentioned/mentioning
[02:50] <vorlon> lucasmoura: the point is it is not a 1:1 mapping
[02:50] <vorlon> and not a fixed mapping
[02:53] <lucasmoura> vorlon, yes, of course. I am just mentioning that it currently covers the scenarios we expect Livepatch to be covered by. But we can better align with the Livepatch team about how to better handle that mapping in the future
[03:02] <lucasmoura> Maybe with us not using lscpu anymore, we don't even need it. Then we could just rely on the output of dpkg. But I will need confirmation from Livepatch that the architectures will be properly handled by the Livepatch API
[03:02] <lucasmoura> I will bring that to team tomorrow so we can better discuss this
[03:03] <sarnold> lucasmoura: do we intend to support livepatch on eg ubuntu core systems? do those have a dpkg available?
[03:05] <lucasmoura> sarnold, this is being discussed. But we would first need to support a snap version of the Pro client. But I don't have an answer right now about dpkg support for that type of system
[03:12] <sarnold> lucasmoura: aha! good enough for me :)
[03:12] <sarnold> [ ] a problem for another day :D
[04:22] -queuebot:#ubuntu-release- Unapproved: papi (lunar-proposed/universe) [7.0.0-2 => 7.0.0-2ubuntu1] (no packageset)
[04:23] -queuebot:#ubuntu-release- Unapproved: accepted papi [source] (lunar-proposed) [7.0.0-2ubuntu1]
[04:41] -queuebot:#ubuntu-release- Unapproved: swi-prolog (lunar-proposed/universe) [8.4.2+dfsg-2ubuntu1 => 9.0.4+dfsg-1ubuntu1] (no packageset)
[04:42] -queuebot:#ubuntu-release- Unapproved: accepted swi-prolog [source] (lunar-proposed) [9.0.4+dfsg-1ubuntu1]
[05:23] -queuebot:#ubuntu-release- New binary: graph-tool [riscv64] (lunar-proposed/universe) [2.45+ds-10ubuntu1] (no packageset)
[05:24] <vorlon> -ifneq (,$(filter $(DEB_HOST_ARCH),arm hppa))
[05:24] <vorlon> lovin' it
[05:30] -queuebot:#ubuntu-release- New: accepted graph-tool [amd64] (lunar-proposed) [2.45+ds-10ubuntu1]
[05:30] -queuebot:#ubuntu-release- New: accepted graph-tool [ppc64el] (lunar-proposed) [2.45+ds-10ubuntu1]
[05:30] -queuebot:#ubuntu-release- New: accepted graph-tool [s390x] (lunar-proposed) [2.45+ds-10ubuntu1]
[05:30] -queuebot:#ubuntu-release- New: accepted graph-tool [arm64] (lunar-proposed) [2.45+ds-10ubuntu1]
[05:30] -queuebot:#ubuntu-release- New: accepted graph-tool [riscv64] (lunar-proposed) [2.45+ds-10ubuntu1]
[05:45] -queuebot:#ubuntu-release- Unapproved: vectorscan (lunar-proposed/universe) [5.4.8-2.1 => 5.4.9-1] (no packageset) (sync)
[05:46] -queuebot:#ubuntu-release- Unapproved: accepted vectorscan [sync] (lunar-proposed) [5.4.9-1]
[06:06] <vorlon> test results are in for mesa on arm64.  s390x is not but s390x is behind and is not an interesting mesa architecture generally (and regressions wouldn't affect s390x beta images).  Unblocking mesa, preparing for mass-respins
[06:29] -queuebot:#ubuntu-release- Unapproved: newsboat (lunar-proposed/universe) [2.21-1.5 => 2.21-1.5ubuntu1] (no packageset)
[06:29] -queuebot:#ubuntu-release- Unapproved: accepted newsboat [source] (lunar-proposed) [2.21-1.5ubuntu1]
[06:52] -queuebot:#ubuntu-release- Unapproved: gmenuharness (lunar-proposed/universe) [0.1.4-5 => 0.1.4-5ubuntu1] (no packageset)
[06:53] -queuebot:#ubuntu-release- Unapproved: accepted gmenuharness [source] (lunar-proposed) [0.1.4-5ubuntu1]
[07:16] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (focal-proposed) [2:1.20.13-1ubuntu1~20.04.7]
[07:38] -queuebot:#ubuntu-release- Unapproved: sphinx (lunar-proposed/main) [5.3.0-3 => 5.3.0-3ubuntu1] (i386-whitelist, ubuntu-desktop, ubuntu-server)
[07:59] -queuebot:#ubuntu-release- Unapproved: bioxtasraw (lunar-proposed/universe) [2.1.1-4build1 => 2.1.1-4build2] (no packageset)
[08:00] -queuebot:#ubuntu-release- Unapproved: accepted bioxtasraw [source] (lunar-proposed) [2.1.1-4build2]
[08:30] <ricotz> hello, please accept libreoffice/lunar, its autopkgtests passed https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#libreoffice
[08:46] -queuebot:#ubuntu-release- Builds: Ubuntu Core amd64 edge [Lunar Beta] has been updated (20230329)
[09:33] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:36] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop (Legacy) amd64 [Lunar Beta] has been updated (20230329)
[09:39] -queuebot:#ubuntu-release- Builds: Edubuntu Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:41] -queuebot:#ubuntu-release- Unapproved: snapd (lunar-proposed/main) [2.58.3+23.04ubuntu1 => 2.59.1+23.04] (desktop-core, ubuntu-server)
[09:43] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:44] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:45] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Lunar Beta] has been updated (20230329)
[09:51] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Lunar Beta] has been updated (20230329)
[10:18] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Lunar Beta] has been updated (20230329)
[10:30] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop amd64 [Lunar Beta] has been updated (20230329)
[10:30] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64 [Lunar Beta] has been updated (20230329)
[10:38] -queuebot:#ubuntu-release- Unapproved: accepted studio-controls [source] (jammy-backports) [2.3.9-0ubuntu2~bpo22.04.1]
[10:41] -queuebot:#ubuntu-release- Unapproved: accepted borgmatic [source] (jammy-backports) [1.7.9-0ubuntu1~bpo22.04.1]
[10:42] -queuebot:#ubuntu-release- Unapproved: tzdata (lunar-proposed/main) [2023b-1exp1ubuntu1 => 2023c-1exp1ubuntu1] (core)
[10:44] -queuebot:#ubuntu-release- Builds: Ubuntu WSL [Lunar Beta] (4552871144) has been added
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Lunar Beta] has been updated (20230329)
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Lunar Beta] has been updated (20230329)
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Lunar Beta] has been updated (20230329)
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Lunar Beta] has been updated (20230329)
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Lunar Beta] has been updated (20230329)
[10:54] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Lunar Beta] has been updated (20230329)
[11:04] -queuebot:#ubuntu-release- Unapproved: tzdata (kinetic-proposed/main) [2023b-0ubuntu0.22.10.0 => 2023c-0ubuntu0.22.10.0] (core)
[11:10] -queuebot:#ubuntu-release- Unapproved: tzdata (jammy-proposed/main) [2023b-0ubuntu0.22.04.0 => 2023c-0ubuntu0.22.04.0] (core)
[11:16] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2023b-0ubuntu0.20.04.0 => 2023c-0ubuntu0.20.04.0] (core)
[11:22] -queuebot:#ubuntu-release- Unapproved: python-certbot (lunar-proposed/universe) [2.1.0-2 => 2.1.0-3] (no packageset) (sync)
[11:23] -queuebot:#ubuntu-release- Unapproved: accepted python-certbot [sync] (lunar-proposed) [2.1.0-3]
[11:25] -queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2023b-0ubuntu0.18.04.0 => 2023c-0ubuntu0.18.04.0] (core)
[11:32] <bdrung> rbasak, bdmurray: The new SRUs for tzdata 2023c are ready. I reused https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/2012599
[11:32] -ubottu:#ubuntu-release- Launchpad bug 2012599 in tzdata (Ubuntu Lunar) "tzdata 2023a/2023b/2023c release - Egypt restoring DST" [Critical, Fix Committed]
[12:36] -queuebot:#ubuntu-release- Unapproved: fsarchiver (lunar-proposed/universe) [0.8.6-2ubuntu1 => 0.8.7-1] (no packageset) (sync)
[12:37] -queuebot:#ubuntu-release- Unapproved: therion (lunar-proposed/universe) [6.1.6-2 => 6.1.6-3] (no packageset) (sync)
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted fsarchiver [sync] (lunar-proposed) [0.8.7-1]
[12:37] -queuebot:#ubuntu-release- Unapproved: accepted therion [sync] (lunar-proposed) [6.1.6-3]
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Lunar Beta] has been updated (20230329)
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Lunar Beta] has been updated (20230329)
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+icicle [Lunar Beta] has been updated (20230329)
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+licheerv [Lunar Beta] has been updated (20230329)
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+nezha [Lunar Beta] has been updated (20230329)
[13:02] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Lunar Beta] has been updated (20230329)
[13:14] <AlsoItzSwirlz> It looks like Cinnamon didn't build yesterday, did something fail or is it building through everything
[13:48] <rbasak> bdrung: "The SRUs to the stable include the recent changes for generating the debconf template and the timezone mappings in convert_timezone(). Previous SRUs did forget to update them for the changes from upstream." -> shouldn't this be in a Test Plan somewhere for SRU verification?
[13:48] <ginggs> AlsoItzSwirlz: no build yesterday or today, I'll look into it
[13:48] <rbasak> It seems still relevant now since AFAICT that change hasn't landed in updates yet.
[13:48] <AlsoItzSwirlz> ginggs: thx
[13:49] <adrien> hi, can someone unblock strace 6.2? it cannot migrate due to the FF but exception has been granted (and in the future, it will probably follow the kernel freeze instead)
[13:49] <adrien> thanks :)
[13:49] <rbasak> bdrung: and I think this upload needs a -v2022g-0ubuntu0.22.10.1 to cover everything that hasn't landed yet.
[13:50] <rbasak> I've only been looking at Kinetic - I assume the older stable release uploads are identical and will need the equivalent stuff done there too.
[13:51] <ginggs> adrien: strace is blocked from migration due to beta freeze, please ping me on Friday
[13:52] <adrien> ok, will do, thanks
[14:04] <bdrung> rbasak, regarding the test plan: the SRUs got enhanced with autopkgtest test cases (with all things that i could come up with)
[14:05] <bdrung> rbasak, good point for the -v parameter. do i need to re-upload them?
[14:07] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Lunar Beta] has been updated (20230329)
[14:08] -queuebot:#ubuntu-release- Builds: Ubuntu Cinnamon amd64 [Lunar Beta] (20230327) has been added
[14:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Lunar Beta] has been updated (20230329)
[14:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Lunar Beta] has been updated (20230329)
[14:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Lunar Beta] has been updated (20230329)
[14:08] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Lunar Beta] has been updated (20230329)
[14:12] <rbasak> bdrung: I appreciate the new dep8 tests - thanks! Do they cover the debconf templates?
[14:13] <ginggs> AlsoItzSwirlz: cinnamon spinning now...
[14:13] <AlsoItzSwirlz> ginggs: thanks
[14:14] <rbasak> bdrung: also I have no issue with fixing debconf templates lagging behind by autogenerating them instead, including in an SRU. I just want to make sure that given we're touching them, we're checking that they don't regress something. I don't mind if that's automatic or manual - just that it's not missed.
[14:19] <rbasak> bdrung: yes - please re-upload with -v.
[14:20] <bdrung> rbasak, yes. see debian/tests/debconf
[14:21] <rbasak> Oh great. Sorry I missed tat.
[14:22] <rbasak> C
[14:23] <bdrung> rbasak, the debconf template was generated in bash before but is now done using Python
[14:26] <bdrung> the combination of generating them and the debconf test case ensure that they are in good shape.
[14:27] <rbasak> bdrung: I think https://wiki.ubuntu.com/StableReleaseUpdates#tzdata could do with an explanation of that. Otherwise SRU reviewers will see an unexplained diff.
[14:27] <rbasak> (which is usually an error)
[14:28] <bdrung> let's see if I can log-in to the wiki
[14:29] <rbasak> Oh, hang on. Is it being generated before upload or as part of the build?
[14:30] <bdrung> yes
[14:30] <rbasak> If the latter, then it wouldn't result in unexplained diffs (except this time, and this time it is explained in the SRU bug which I very much appreciate!)
[14:32] <bdrung> Yes. it's the latter. the generated debconf template is part of the source package
[14:38] <bdrung> rbasak, I checked it again. People can forget to include the template update in the source package. In this case lintian will complain about an outdated template in the source package.
[14:39] <rbasak> bdrung: the SRU team doesn't check lintian output. At least I'm not aware that anyone does.
[14:40] <bdrung> rbasak, at least I am doing that. So if I miss to include it, I will notice it before the upload.
[14:40] <rbasak> bdrung: could we stick steps into the wiki to verify that the mistake isn't made somehow maybe? Like ask for lintian to be run explicitly, or something in a standard Test Plan, or an additional dep8 test maybe.
[14:40] <rbasak> For this time it's fine. I'd just like to make the process smoother for everyone in the future.
[14:45] -queuebot:#ubuntu-release- Unapproved: swtpm (lunar-proposed/main) [0.6.3-0ubuntu5 => 0.7.3-0ubuntu1] (no packageset)
[14:45] <rbasak> ^ FFe approved and it's not in an image
[14:47] -queuebot:#ubuntu-release- Unapproved: accepted swtpm [source] (lunar-proposed) [0.7.3-0ubuntu1]
[14:52] -queuebot:#ubuntu-release- Unapproved: vim (lunar-proposed/main) [2:9.0.1000-4ubuntu2 => 2:9.0.1000-4ubuntu3] (core, i386-whitelist)
[14:56] <bdrung> rbasak, I am not sure if not having the debconf generation in the debdiff is really a problem. Let me explain the debconf issue with some examples: Kiev was renamed Kyiv. Without any change, both names could be selected in debconf. if you add kiev to the conversion list in tzdata.config, you will get an inconsistency which will not detected by test_timezone_conversions
[14:58] <bdrung> rbasak, explaining this now makes me think that the debconf template generation should have a allow list for symlinks as well. Then it will fail in this Kiev to Kyiv rename case if both could be selected.
[14:58] <rbasak> bdrung: I'm not saying it's a problem. I'm just saying that whatever changes are made, they should be verified - either automatically or manually. And for review, everything that appears in the debdiff should have an explanation. If there's automated stuff happening, then that's fine, but we should explain it in the wiki, so that it doesn't get held up by confused reviewers.
[14:59]  * bdrung agrees.
[15:41] <vorlon> ricotz: libreoffice/lunar should not be accepted today, it's not beta-critical and does not warrant media respins and re-testing
[15:45] <jbicha> ubuntu-release: please promote the Ubuntu Desktop amd64 iso from pending/ to current/ since the isotracker download link points to current/
[15:46] <jbicha> promoting from pending to current is manual currently, after the switch to the new installer
[15:49] -queuebot:#ubuntu-release- Unapproved: swi-prolog (lunar-proposed/universe) [9.0.4+dfsg-1ubuntu1 => 9.0.4+dfsg-1ubuntu2] (no packageset)
[15:50] -queuebot:#ubuntu-release- Unapproved: accepted swi-prolog [source] (lunar-proposed) [9.0.4+dfsg-1ubuntu2]
[15:52] -queuebot:#ubuntu-release- Unapproved: logol (lunar-proposed/universe) [1.7.9+dfsg-6 => 1.7.9+dfsg-6build1] (no packageset)
[15:53] -queuebot:#ubuntu-release- Unapproved: accepted logol [source] (lunar-proposed) [1.7.9+dfsg-6build1]
[15:53] -queuebot:#ubuntu-release- Unapproved: ppl (lunar-proposed/universe) [1:1.2-8.1build1 => 1:1.2-8.1build2] (no packageset)
[15:53] <ricotz> vorlon, I see, ack (unfortunately the autopkgtests were slow again)
[15:54] -queuebot:#ubuntu-release- Unapproved: accepted ppl [source] (lunar-proposed) [1:1.2-8.1build2]
[16:00] <rbasak> bdrung: are you planning re-uploads of tzdata today with the -v?
[16:01] <schopin> ubuntu-release: vim isn't beta critical either, I kinda forgot about the beta freeze, sorry :/
[16:09] <vorlon> schopin: no worries, we can just not look at the unapproved queue for anything people aren't screaming for
[16:17] <orndorffgrant> lucasmoura, vorlon: following up on the lscpu vs dpkg arch differences conversation. I've submitted an issue for livepatch-client here to discuss moving away from parsing lscpu outpu: https://github.com/canonical/livepatch-client/issues/348 and for pro-client I made this issue for using uname -m for livepatch related things
[16:17] <orndorffgrant> https://github.com/canonical/ubuntu-pro-client/issues/2517
[16:17] -ubottu:#ubuntu-release- Issue 2517 in canonical/ubuntu-pro-client "livepatch support should be queried with kernel architecture, not user-space package arch" [Open]
[16:18] <vorlon> orndorffgrant: cheers
[16:21] <bdrung> rbasak, yes. Do you need to drop the current version or can I just do the upload?
[16:21] <rbasak> You can just upload on top.
[16:22] <rbasak> I'm reviewing from what's there currently so it's easier to keep it there for now if you don't mind. I'll clean up after.
[16:22] <rbasak> No need to change the version strings.
[16:26] -queuebot:#ubuntu-release- Unapproved: tzdata (kinetic-proposed/main) [2023b-0ubuntu0.22.10.0 => 2023c-0ubuntu0.22.10.0] (core)
[16:26] -queuebot:#ubuntu-release- Unapproved: tzdata (jammy-proposed/main) [2023b-0ubuntu0.22.04.0 => 2023c-0ubuntu0.22.04.0] (core)
[16:27] <bdrung> rbasak, re-upload done
[16:27] -queuebot:#ubuntu-release- Unapproved: tzdata (bionic-proposed/main) [2023b-0ubuntu0.18.04.0 => 2023c-0ubuntu0.18.04.0] (core)
[16:27] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-proposed/main) [2023b-0ubuntu0.20.04.0 => 2023c-0ubuntu0.20.04.0] (core)
[16:30] <rbasak> Thanks!
[16:35] <jbicha> vorlon: are you able to do the iso promotion or do you know who we could ask?
[16:36] <vorlon> jbicha: what do you mean by "iso promotion"
[16:37] <jbicha> vorlon: copy the Ubuntu Desktop amd64 daily-live iso from pending/ to current/
[16:38] <vorlon> that's supposed to happen automatically based on test results
[16:38] <jbicha> it doesn't work yet
[16:38] <vorlon> (or the absence of test results if none are defined)
[16:38] <vorlon> well that seems bad!
[16:39] <vorlon> jbicha: daily-live/current has a bunch of symlinks pointing to today's build
[16:39] <vorlon> ah but not for amd64 which is at 20230324
[16:39] <vorlon> so if that one was promoted but 20230329 was not does that mean tests *did* pass but have regressed?
[16:40] <vorlon> jbicha: I would note that none of this is relevant for beta
[16:41] <jbicha> vorlon: maybe there is a different bug but http://iso.qa.ubuntu.com/qatracker/milestones/444/builds/275082/testcases "link to the download information" is pointing to current
[16:41] <vorlon> well that's silly, it should point to the serial
[16:41] <jbicha> so I'm concerned that we could get test reports for the wrong iso
[16:42] <jbicha> it did for previous milestones 🤷
[16:42] <vorlon> let me check that
[16:42] <vorlon> fixed
[16:43] <jbicha> my understanding is that previous amd64 ISOs since the switch to subiquity have been promoted to current manually ☹️
[16:43] <vorlon> don't know who did that
[16:43] <jbicha> thanks!!
[16:43] <vorlon> ok well I'm not touching manual promotion given that the beta problem is fixed.  Someone on Desktop Team needs to either own getting the auto tests fixed, or own regressing auto test coverage
[16:44] <vorlon> (and it would be ideal if QA Team were resourced to address sorting this out, but in the meantime-)
[16:46] <bdmurray> vorlon: you may have fixed bug 2012345
[16:46] -ubottu:#ubuntu-release- Bug 2012345 in Ubuntu QA Website "Links for Ubuntu Lunar ISO downloads are incomplete" [Undecided, New] https://launchpad.net/bugs/2012345
[16:47] <rbasak> Argh. tzdata Focal and Bionic are *differently different*? :-/
[16:49] <seb128> vorlon, I'm working with paride on getting the ISO tests working with the new installer, the provisioning got updated to switch from d-i preseeding style to subiquity autoinstall but there are some problems still so we have been relying on Lukasz to promote our images from pending to current on a semi regular basis through pings after rounds of manual testing
[16:50] <vorlon> ack
[16:51] <vorlon> still not relevant for beta (anymore) ;)
[16:51] <vorlon> bdmurray: partial fix.  This new product was set up without all the usual auxiliary links, as mentioned
[16:51] <vorlon> queuing that to maybe finish today
[17:37] <AlsoItzSwirlz> ginggs: sorry, but is everything ok with the cinnamon image? the qa tracker says its rebuilding, i don't see a 3/29 build and if an image is taking 3 hours to build, I don't think its just installing cinnamon
[17:37] <AlsoItzSwirlz> is it installing every single flavor package? lol
[17:40] -queuebot:#ubuntu-release- Unapproved: sphinx (lunar-proposed/main) [5.3.0-3 => 5.3.0-4] (i386-whitelist, ubuntu-desktop, ubuntu-server) (sync)
[17:42] <vorlon> ItzSwirlz: you can always check here if an image build has been successfully dispatched https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/lunar/ubuntucinnamon
[17:42] -queuebot:#ubuntu-release- Unapproved: libsigc++-3.0 (lunar-proposed/universe) [3.4.0-1 => 3.4.0-1ubuntu1] (no packageset)
[17:43] <AlsoItzSwirlz> 30 seconds left supposedly?
[17:43] <vorlon> in this case we ran into some hangups with the image builds actually getting dispatched; owing to ubuntucinnamon being a new product
[17:43] <AlsoItzSwirlz> no problem, it's alright
[17:43] <vorlon> yes, the build was only kicked off a few minutes ago when bdmurray noticed it
[17:43] <AlsoItzSwirlz> no problem
[17:43] -queuebot:#ubuntu-release- Unapproved: accepted libsigc++-3.0 [source] (lunar-proposed) [3.4.0-1ubuntu1]
[17:44] <vorlon> note that this is the eta for the squashfs build - it then has to be wrapped into an ISO and rsynced over to the web frontend. I'd say give it 10-15 minutes
[17:44] <AlsoItzSwirlz> no problem, i got a free period right now
[17:45] <AlsoItzSwirlz> looks like, according to the logs it isn't installing firefox
[17:46] <vorlon> the snap?
[17:46] <bdmurray> AlsoItzSwirlz: per a previous private conversation I'l be adding the test cases "nstall (entire-disk) and Live Session" for Ubuntu Cinnamon
[17:46] <AlsoItzSwirlz> bdmurray: thank you!
[17:47] <AlsoItzSwirlz> vorlon: yeah, in the seed it's there: https://git.launchpad.net/~ubuntucinnamon-dev/ubuntu-seeds/+git/ubuntucinnamon/tree/desktop
[17:47] <vorlon> AlsoItzSwirlz: livecd-rootfs probably needs to be updated to know to look in this seed for snaps
[17:47] <AlsoItzSwirlz> vorlon: or could it be that i think i put snap as a recommend [(snap:firefox) instead of snap:fierfox]
[17:48] <vorlon> I mean, that's quite possible
[17:49] <vorlon> it's meaningless to 'recommend' a snap from a seed since they're not expressed via dpkg deps
[17:49] <AlsoItzSwirlz> let me check other seeds
[17:49] <vorlon> and yeah I checked livecd-rootfs and the code is generic with respect to picking up snaps from 'desktop'
[17:49] <arraybolt3[m]> I'm almost positive Lubuntu doesn't attempt to "recommends" the Firefox snap, it just includes it.
[17:50] <AlsoItzSwirlz> Yep. Studio's code highlights it well, putting the parens around "firefox" and later saying specifically snap:firefox
[17:50] <vorlon> is this... the first image build
[17:50] <vorlon> ?
[17:51] <vorlon> ah no there were builds before but they've been expired out
[17:53] <AlsoItzSwirlz> i'm trusting snap:gnome-42-2204 is necessary
[17:53] <AlsoItzSwirlz> along with gtk-common-themes
[17:55] -queuebot:#ubuntu-release- Builds: Ubuntu Cinnamon Desktop amd64 [Lunar Beta] (20230327) has been added
[17:57] <bdmurray> AlsoItzSwirlz: https://iso.qa.ubuntu.com/qatracker/milestones/444/builds/275105/testcases
[17:57] <AlsoItzSwirlz> gracias
[17:57] <bdmurray> The latest build didn't actually get published on the isotracker, I could rebuild it now or wait for the firefox issue. AlsoItzSwirlz what do you think?
[17:58] <AlsoItzSwirlz> I didn't push the firefox fix yet so dont worry
[17:58] <AlsoItzSwirlz> There's a few more packages I want to check
[17:58] <AlsoItzSwirlz> okay now it pushed but dw about it
[17:59] <bdmurray> rebuilding now then (good thing its nice and quick!)
[17:59] <AlsoItzSwirlz> its going to take as long as it will to download the current most recent file on school wifi but no problem
[18:01] -queuebot:#ubuntu-release- Unapproved: libsigc++-3.0 (lunar-proposed/universe) [3.4.0-1 => 3.4.0-1ubuntu2] (no packageset)
[18:02] -queuebot:#ubuntu-release- Unapproved: accepted libsigc++-3.0 [source] (lunar-proposed) [3.4.0-1ubuntu2]
[18:08] -queuebot:#ubuntu-release- Unapproved: libsigc++-3.0 (lunar-proposed/universe) [3.4.0-1 => 3.4.0-1ubuntu3] (no packageset)
[18:09] -queuebot:#ubuntu-release- Unapproved: accepted libsigc++-3.0 [source] (lunar-proposed) [3.4.0-1ubuntu3]
[18:14] <AlsoItzSwirlz> ubiquity "try or install" screen still has debian wallpaper, so note #1
[18:16] <bdmurray> Respinning xubuntu-minimal since its rebuild request failed
[18:18] -queuebot:#ubuntu-release- Builds: Ubuntu Cinnamon Desktop amd64 [Lunar Beta] has been updated (20230329.1)
[18:33] -queuebot:#ubuntu-release- Builds: Xubuntu Minimal amd64 [Lunar Beta] has been updated (20230329.1)
[18:42] <bdmurray> vorlon: did you fix the libevernt issue? lubuntu failed to build earlier because of that
[18:42] <bdmurray> *libevent
[18:43] <vorlon> bdmurray: yes, libevent migrated last night
[18:43] <vorlon> bdmurray: so hopefully "earlier" means before that
[18:44] <bdmurray> earlier means the 28th - so rebuilding lubuntu too
[18:45] <seb128> vorlon, could you promote pending to current anyway? it's not an iso for the iso tracker and beta but we still have users testing current and we would like that pointing to an uptodate image
[18:45] <seb128> not an issue...
[18:46] -queuebot:#ubuntu-release- Unapproved: otf2 (lunar-proposed/universe) [3.0.2-1 => 3.0.2-1ubuntu1] (no packageset)
[18:47] -queuebot:#ubuntu-release- Unapproved: accepted otf2 [source] (lunar-proposed) [3.0.2-1ubuntu1]
[18:47] <vorlon> rebuilding ubuntu-unity after fixing the seed for snaps
[18:48] <vorlon> seb128: not a priority from my side, sorry
[18:49] <seb128> vorlon, sorry I though that was a one command 5s type of job, if it's creating work it can wait
[18:49] <vorlon> seb128: 5 minutes to figure out what the command is, 5s to run it
[18:50] <seb128> fair enough, sounds like something to document in the team process for the next person to figure it out
[18:52] <seb128> Lukasz know how to do it but he doesn't seem to be around or at least not on IRC?
[18:52] <vorlon> sure; it's past EOD
[18:53] <vorlon> (also today is a sick day for him)
[18:53] <seb128> right, I meant he was not there earlier, I checked hr.c.c but that didn't reflect it
[18:56] <vorlon> seb128: what I *DO* know how to do offhand is to disable waiting for test results before promoting to current, if you want that
[18:57] <seb128> vorlon, the end result is the same right?
[18:57] <seb128> I just want to avoid confusion of people thinking they test beta by fetching current
[18:57] <vorlon> the difference is whether you're pinging the release team daily, or only once you're ready to turn the gating back on
[18:58] <seb128> I think at this point of the cycle that's what we want so please do it
[19:08] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Lunar Beta] (20230329) has been added
[19:15] <bdmurray> Okay, lubuntu built
[19:22] <arraybolt3> \o/
[19:23] <arraybolt3> Ah, and Unity is already fixed. Very nice.
[19:23] <arraybolt3> Guess this is "test like crazy" day.
[19:32] <vorlon> seb128: ok I've marked it as not-blocked by test results.  (Would be nice to block the legacy images instead by those same tests but I assume code needs changed in 5 other places to handle that, given the discontinuity)  I don't know that this will cause the currently-pending image to be promoted, if you don't see it promoted in the next hour I can sort out a manual promotion
[19:39] <vorlon> bdmurray, jbicha, seb128: fixed the download links, http://iso.qa.ubuntu.com/qatracker/milestones/444/builds/275082/downloads
[19:49] -queuebot:#ubuntu-release- Unapproved: otf2 (lunar-proposed/universe) [3.0.2-1ubuntu1 => 3.0.2-1ubuntu2] (no packageset)
[19:50] -queuebot:#ubuntu-release- Unapproved: accepted otf2 [source] (lunar-proposed) [3.0.2-1ubuntu2]
[19:57] <rbasak> bdrung: what was the purpose of https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/tzdata/commit/?h=ubuntu/kinetic&id=fb5ab09a595b2a7eeeddd6630adae99471a8828e? Was that generated by something?
[19:57] -ubottu:#ubuntu-release- Commit fb5ab09 in ~ubuntu-core-dev/ubuntu/+source/tzdata "d/tzdata.config: Use convert_timezone from 2023g-1"
[20:11] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/2013236 Looks like something has broken with ubuntu-drivers or possibly Broadcom firmware.
[20:11] -ubottu:#ubuntu-release- Launchpad bug 2013236 in ubiquity (Ubuntu) "Failed to install bcmwl wireless driver during the install" [Undecided, Confirmed]
[20:12] <arraybolt3> wget-ing the Ubuntu Desktop Legacy image to confirm that this affects that too.
[20:14] <arraybolt3> uh... tar, I actually no longer have the hardware to test taht.
[20:14] <arraybolt3> *that
[20:18] <vorlon> arraybolt3: thanks.  Probably not something we're fixing for beta.  May be an ubuntu-drivers issue wrt replacing bcmwl source package with broadcom-sta.  Logs on the bug show no evidence of ubuntu-drivers installing broadcom-sta-dkms
[20:19] <arraybolt3> +1, figured it was worth mentioning since it's been happening for a while.
[20:19] <arraybolt3> (btw, for bugs that I think will probably hang things up but that are going unnoticed, what's a good way to bring them up *before* we're in a time crunch?)
[20:20] <vorlon> logs do confirm broadcom-sta-dkms is present on the ISO. apt show confirms that it has Modaliases consistent with the previous bcmwl package
[20:20] <vorlon> arraybolt3: good way> flagging them here works as well as anyt
[20:21] <arraybolt3> Nice, will do.
[20:21]  * arraybolt3 vanishes back into other work
[20:22] <vorlon> arraybolt3: kernel logs don't show a pci dev matching what's supported by either bcmwl or broadcom-sta
[20:23] <arraybolt3> Try looking at the logs of my duplicate bug report, I have a chip in a laptop I used to use for testing that I *know* works with the bcmwl driver.
[20:24] <vorlon> arraybolt3: confirmed, *your* dev matches modaliases (14e4:4359)
[20:25] <arraybolt3[m]> Oh weird.
[20:25] <vorlon> arraybolt3: I suggest deduping the bugs based on this
[20:26] <arraybolt3[m]> +1
[20:28] <vorlon> arraybolt3: yeah on the parent bug, the device in question wouldn't have had bcmwl loaded in jammy either
[20:29] <arraybolt3[m]> That's weird, since it used to work for him. Are there multiple Broadcom drivers or something?
[20:29] <arraybolt3[m]> Oh, actually there are. The STA driver, the new STA driver, and the b43 driver...
[20:29] <vorlon> arraybolt3: he asserts "bcmwl was installed correctly" but I doubt this is true
[20:29] <vorlon> he probably had wifi *working*, with a different driver
[20:30] <arraybolt3[m]> Which would make sense since I think Macbooks have different Broadcom chips than normal laptops at least in some instances.
[20:34] <vorlon> arraybolt3: from the live env, please run 'ubuntu-drivers devices', 'ubuntu-drivers list' and paste to the bug
[20:34] <vorlon> ubuntu-unity build failed, saying it couldn't download the very snap I just seeded
[20:34] <vorlon> investigating
[20:34] <arraybolt3[m]> Unfortunately, the laptop I reproduced the bug on had to be put into normal use and isn't available for testing right this second. I might be able to boot it into a live env in a bit though.
[20:35] <vorlon> arraybolt3: 'ubuntu-drivers' probably works in a chroot fwiw
[20:36] <arraybolt3> Hmm, not a bad idea, but I have Jammy installed on the machine right now, not sure if that's helpful?
[20:36] <arraybolt3> But if it's just the live env, no big deal, I can just flash a USB, boot it, do the test, then boot it back into the normal OS.
[20:37] <vorlon> I'm saying if it's easier than taking your current workload down for rebooting, you can mk-sbuild yourself a lunar chroot, install ubuntu-drivers-common into that, and see what it says
[20:38] <vorlon> trying the ubuntu-unity build again in case this is a fluke with the store
[20:38] <arraybolt3> Ah, that makes sense. It's not that hard though (that alternative is actually harder :P)
[20:38] <arraybolt3> (It's not being used as my PC, I'm turning it into a weird server of sorts.)
[20:52] <arraybolt3> OK, booting a legacy Desktop ISO on it now.
[20:52] <rbasak> bdrung: also, what's the upstream source for debian/icu?
[20:52] -queuebot:#ubuntu-release- Unapproved: ubuntu-unity-backgrounds (lunar-proposed/universe) [22.10.1-0ubuntu1 => 23.04-0ubuntu1] (no packageset)
[20:52] <rbasak> I found https://github.com/unicode-org/icu/tree/main/icu4c/source/data/misc, but it isn't clear to me if that's where you're getting it from. I don't see a matching tag.
[20:52] <arraybolt3> vorlon: Info added to report.
[21:04] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+unmatched [Lunar Beta] has been updated (20230329.2)
[21:08] <vorlon> found the ubuntu-unity issue, it was my dumb editing mistake
[21:25] -queuebot:#ubuntu-release- Unapproved: qtcreator (lunar-proposed/universe) [9.0.2-1 => 9.0.2-2] (qt5) (sync)
[21:25] <bdmurray> rbasak: icu-data upstream is here https://github.com/unicode-org/icu-data/tree/main/tzdata/icunew
[21:26] <vorlon> blaaaahhhh ubuntu-unity still failed because livecd-rootfs pulls the seeds from archive-team.internal which hadn't refreshed yet
[21:26] <vorlon> should've waited 5 minutes
[21:31] <bdrung> rbasak, see update-icu from debian/rules
[21:35] <vorlon> jbicha: looking at reports I don't check up on often, I see that gnome-remote-desktop in jammy-updates has had phasing at 0 since January 5.  Are you aware of this, have you reviewed the errors that caused phasing to halt?
[21:35] <vorlon> (https://ubuntu-archive-team.ubuntu.com/phased-updates.html)
[21:47] <rbasak> bdrung: ah thanks! I looked for a debian/README* or similar and in debian/watch, debian/upstream/ etc  but didn't think to look for a custom rule.
[21:48] <vorlon> since it's under debian/ unfortunately a debian/watch wouldn't dtrt
[21:50] <rbasak> yeah but I was looking for a comment or something
[21:50] <rbasak> I had also looked in debian/copyright
[21:50] <rbasak> just for a pointer
[21:50] <rbasak> bdrung: debian/icu/zoneinfo64.txt seems to mismatch?
[21:50] <LocutusOfBorg> please reject sphinx/5.3.0-3ubuntu1 in unapproved queue
[21:50] <rbasak> Only on version, but is that expected?
[21:50] <LocutusOfBorg> 5.3.0-4 in the same queue has a proper fix
[21:51] -queuebot:#ubuntu-release- Builds: Ubuntu Unity Desktop amd64 [Lunar Beta] (20230329.3) has been added
[21:51] <rbasak> bdrung: https://paste.ubuntu.com/p/g9JScs3rRK/
[21:52] <rbasak> I don't know if a version mismatching the expected one might cause an issue
[21:54] <rbasak> bdrung: also did you see my earlier question? What was the purpose of https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/tzdata/commit/?h=ubuntu/kinetic&id=fb5ab09a595b2a7eeeddd6630adae99471a8828e? Was that generated by something?
[21:54] -ubottu:#ubuntu-release- Commit fb5ab09 in ~ubuntu-core-dev/ubuntu/+source/tzdata "d/tzdata.config: Use convert_timezone from 2023g-1"
[22:02] <rbasak> Oh, I see:   * Update the ICU timezone data to 2023a (2023b is not available yet)
[22:03] <rbasak> OK so just the tzdata.config question remaining right now. I'll continue to review.
[22:09] <bdrung> rbasak, the convert_timezone function is used to update obsolete timezones (e.g. rename kiev to kyiv) to timezones that can also be selected by debconf.
[22:10] <bdrung> The use of convert_timezone from 2023g-1 ensures that the conversion is consistent with all the updates.
[22:13] <bdrung> commit 09c572f98c4d55478ab163488ee2ad12e2fdc24b ("Build timezones that differ pre-1970"), da07a111db15f0f70957fb6aa68cac6ee1a9b051 ("Update conversion targets to America/Indiana/Indianapolis"), 5c6c755c00842a77dc7c186a4b8622f8b7f1fa99 ("Do not update US/* timezones to their America/* counterparts"), 4c2b898ef99c134a9d202405643136d4b0d38048 ("Drop wrong conversion of the Pacific/Enderbury timezone")
[22:13] <rbasak> bdrung: I don't understand how that relates to the diff
[22:13] -queuebot:#ubuntu-release- Unapproved: unity-tweak-tool (lunar-proposed/universe) [0.0.7+-0ubuntu10 => 0.0.7+-0ubuntu11] (no packageset)
[22:14] <rbasak> Looks like a bunch of refactoring with no functional change? Where did that come from?
[22:14] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (lunar-proposed/main) [2.817 => 2.818] (desktop-core, i386-whitelist)
[22:15] -queuebot:#ubuntu-release- Unapproved: ubuntu-settings (lunar-proposed/main) [23.04.3 => 23.04.4] (ubuntu-desktop)
[22:16] <bdrung> rbasak, since i took the whole function from 2023g-1 it includes the refactorings as well: be005c0482bd45d676e9ab85beb8a89f584dee0e ("d/tzdata.config: Sort timezone case matches alphabetical"), 6648a42324af7e4a27e65640e383a99c70445bc5 ("d/tzdata.config: Group matches by target timzones")
[22:17] <bdrung> and commit 41a71b73947165a26583218421ece599b3009b6a ("d/tzdata.config: Make case statement format consistent")
[22:17] <rbasak> I see :-/
[22:17]  * rbasak isn't sure how to review this then
[22:18] <rbasak> Normally I wouldn't expect an SRU to do refactoring.
[22:18] <rbasak> https://wiki.ubuntu.com/StableReleaseUpdates#tzdata also says that we don't expect to change packaging in tzdata SRUs
[22:21] <rbasak> What about stuff like the removal of "Enderbury" -> "Pacific/Kanton"?
[22:21] <bdrung> tzdata SRUs include addition and renames of timezones. That causes changes to the convert_timezone function and also to the debconf template generation code. That's why I backported the changes to those parts to the SRU, but kept the remaining part of tzdata.config unchanged.
[22:23] <rbasak> But isn't stuff being removed, too?
[22:24] <rbasak> Which is particularly hard to see because of the reordering refactor, but "Enderbury" is a concrete example.
[22:27] <bdrung> rbasak, the timezone "Enderbury" did not exist, the replacement was meant to be "Pacific/Enderbury"
[22:27] <rbasak> Oh OK so that one came from https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/tzdata/commit/?id=4c2b898ef99c134a9d202405643136d4b0d38048
[22:27] -ubottu:#ubuntu-release- Commit 4c2b898 in ~ubuntu-core-dev/ubuntu/+source/tzdata "Drop wrong conversion of the Pacific/Enderbury timezone"
[22:27] <rbasak> But that's a change that might regress users, no?
[22:27] <rbasak> Fine for a development release, but not for a stable release?
[22:30] <bdrung> not really, since the timezone "Enderbury" did / does not exist and users could not set it and it would have been broken. On upgrades these broken timezone would not be changed to "Pacific/Kanton".
[22:30] <bdrung> user could have set the timezone to Pacific/Enderbury.
[22:31] <rbasak> How can I confirm that for my review?
[22:33] <bdrung> You could check that no package ships /usr/share/zoneinfo/Enderbury. You could dpkg-reconfigure tzdata to Pacific -> Enderbury. Then upgrade the package.
[22:36] <rbasak> Are there other changes like this one that need similar consideration?
[22:36] <rbasak> This kind of thing is what SRU documentation is supposed to be used for, and why we don't expect unrelated changes to be backported without an SRU bug to explain it :-/
[22:37] <rbasak> It might all be correct, but what's the point of an SRU review if not to check, and in that case, surely this isn't a reasonable way to present it to the SRU team for review?
[22:38] <bdrung> would it have been better to cherry pick all those changes to the tzdata.config file separately?
[22:39] <rbasak> From a review perspective it's easier not to cherry-pick unnecessary changes at all. SRU policy is to keep changes minimal, and I think this thread is one good explanation as to why.
[22:41] <rbasak> The same goes for the bash -> Python template generation refactoring really.
[22:42] <rbasak> It should at least have been explained in an SRU bug
[22:42] <rbasak> Like maybe it is a better approach and we do want it in an SRU. But that decision is supposed presented for review by the SRU team.
[22:43] <rbasak> supposed *to be* presented
[22:44] <rbasak> I haven't finished reviewing that part either FWIW. I was working breadth-first - trying to understand what bits were changed for what reason first.
[22:45] <bdrung> The Python code is simple to read/write than Shell code and more robust compared to the "find | egrep | sort" construct that needs to be touched.
[22:45] <bdrung> rbasak, do you look at the git repository? the commits have some explanation.
[22:47] <rbasak> "Drop wrong conversion of the Pacific/Enderbury timezone" isn't really an explanation!
[22:47] <rbasak> I mean I can see it's a conversion from the diff. So that might as well say "Fix wrong thing".
[22:48] <bdrung> "Drop wrong conversion of the Pacific/Enderbury timezone" -> "Pacific/Enderbury" != "Enderbury"
[22:49] <rbasak> The Python code is simple...> sure, but that's not normally what we do in SRUs.
[22:49] <rbasak> To review such an SRU, it's then required to review all of that, rather than what might be small diffs.
[22:50] <rbasak> See "In line with this, the requirements for stable updates..." in https://wiki.ubuntu.com/StableReleaseUpdates
[22:50] <rbasak> That's my expectation when reviewing an SRU, and I would expect deviation from that to come with an explanation as to why this case is exceptional.
[22:50] <rbasak> I'll ask other SRU team members for an opinion on how to proceed here.
[22:50] <rbasak> And move on for now.
[22:51] <bdrung> https://paste.ubuntu.com/p/pRQMHMCTng/
[22:58] <bdrung> rbasak, I extended the [ Other Info ] section in bug #2012599
[22:58] -ubottu:#ubuntu-release- Bug 2012599 in tzdata (Ubuntu Lunar) "tzdata 2023a/2023b/2023c release - Egypt restoring DST" [Critical, Fix Committed] https://launchpad.net/bugs/2012599
[23:01] <bdrung> rbasak, including the changes for "Build timezones that differ pre-1970" makes the diff bigger. Maybe it would have been better to split that into two SRUs.
[23:18] <teward> ubuntu-archive: spotcheck my knowledge please - the builders for releases, release-updates, and release-security (where release is any given release name) do NOT include the backports repo in available libraries in the build envs, correct?
[23:18] <teward> (it was my understanding that only -backports targeted things get -backports included in the builder at build time)
[23:19] <cjwatson> teward: correct, see https://git.launchpad.net/launchpad/tree/lib/lp/soyuz/adapters/archivedependencies.py#n72
[23:19] <teward> Eickmeyer: ^ relevant to the pinging in #ubuntustudio-devel you're doing for me
[23:20] <cjwatson> (and just to be clear, they're all the same builders, just with different job configuration dispatched to them)
[23:24] <Eickmeyer> teward: ack, kindof knew that.
[23:25] <teward> cjwatson: ack, i knew they're the same builders but I was implying in the *environment* within the builder at build time (hence the different job confs)
[23:25] <teward> cjwatson: thanks for confirming what I already knew ;)
[23:26] -queuebot:#ubuntu-release- Unapproved: xdg-terminal-exec (lunar-proposed/universe) [0~20221120-1 => 0~20230318-1] (no packageset) (sync)
[23:26] <teward> this came up as a q from Eickmeyer about backporting libzita-alsa-pcmi which would cause an ABI bump and be incompatible with the current version in LTS if backported so then it'd be NCR(s) against "backported" but that's not a thing, hence the question to confirm my knowledge of the builder envs
[23:26] -queuebot:#ubuntu-release- Unapproved: accepted xdg-terminal-exec [sync] (lunar-proposed) [0~20230318-1]
[23:27] <teward> (so the only way that'd work would be to backport the library, and then backport all the tools that depend on it) cc ddstreet_away mapreri
[23:28] <Eickmeyer> I'd have no problem with backporting any of those tools since it's only a handful so long as I get everything to build correctly in a PPA first.
[23:28] <Eickmeyer> And of course, submitting as separate backport requests.
[23:29] <Eickmeyer> The biggest issue is that it doesn't qualify for SRU since it's two versions ahead and several changes, not a simple bugfix, nor can it be cherry-picked without opening a can of worms.
[23:46] <vorlon> Trevinho: it would have been helpful to have some follow-through from the Desktop side on the gtk4 promotion of libgtk-4-media-gstreamer to a Recommends:, Recommends are not enforced by proposed-migration so users who install the beta will not have it because libgtk-4-media-gstreamer is not yet in main and wasn't included on the candidate images
[23:48] <Trevinho> vorlon: oh, I thought seb128 had handled that main inclusion
[23:48] <vorlon> not according to https://ubuntu-archive-team.ubuntu.com/component-mismatches.html