[00:18] -queuebot:#ubuntu-release- Unapproved: cloud-init (kinetic-proposed/main) [22.4.2-0ubuntu0~22.10.1 => 23.1.1-0ubuntu0~22.10.1] (core, ubuntu-cloud) [01:11] -queuebot:#ubuntu-release- New source: jtreg7 (lunar-proposed/primary) [7.1.1+1~us1-0ubuntu1] [01:14] -queuebot:#ubuntu-release- New: accepted jtreg7 [source] (lunar-proposed) [7.1.1+1~us1-0ubuntu1] [01:17] vpa1977: ^^ [01:23] -queuebot:#ubuntu-release- New binary: jtreg7 [amd64] (lunar-proposed/none) [7.1.1+1~us1-0ubuntu1] (no packageset) [01:30] vorlon: Thank you!!!!! [02:11] -queuebot:#ubuntu-release- New binary: python-line-profiler [amd64] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:12] -queuebot:#ubuntu-release- New binary: python-line-profiler [arm64] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:12] -queuebot:#ubuntu-release- New binary: python-line-profiler [ppc64el] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:12] -queuebot:#ubuntu-release- New binary: python-line-profiler [armhf] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:12] -queuebot:#ubuntu-release- New binary: python-line-profiler [s390x] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:33] -queuebot:#ubuntu-release- New binary: python-line-profiler [riscv64] (lunar-proposed/universe) [4.0.2-1] (no packageset) [02:59] I think ruby3.0 is ready for removal === chris14_ is now known as chris14 [03:29] jbicha: agreed [04:30] -queuebot:#ubuntu-release- Unapproved: cockpit (kinetic-backports/universe) [285-1~bpo22.10.1 => 286-1~bpo22.10.1] (no packageset) [04:33] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (kinetic-backports) [286-1~bpo22.10.1] [04:38] -queuebot:#ubuntu-release- Unapproved: cockpit (jammy-backports/universe) [285-1~bpo22.04.1 => 286-1~bpo22.04.1] (no packageset) [04:50] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (jammy-backports) [286-1~bpo22.04.1] [05:37] well, glymur 0.12.2-2 migrated into Debian testing despite failing s390x autopkgtests [05:42] linux-signed migrated but its binaries apparently didn't come with it; spectacular [05:43] mm, no, not that - it showed up in NBS so I deleted the binaries? whee? [05:44] anyway, will be back with the next publisher run [12:34] vorlon: thank you for removing ruby3.0 from lunar [15:14] please *DO NOT* accept the fwupd-efi binaries [15:16] So the issue is: We need to sign fwupd-efi in the PPA and we don't want the tarballs to get to the archive signing service [15:16] So the plan was to copy from Debian to the PPA and then do the signing and copy to the archive [15:17] but the source is published now and the binary builds are unapproved [15:17] Not clear to me how to proceeed [15:18] We can either accept the binaries, copy them over to the PPA and then do sign dance there and copy back, but it's always annoying as you need to wait additional publisher runs because now the -signed packages will FTBFS in the signing PPA because the build-deps are satisfied from the main archive but there's no signed binaries to pull yet (because it's not published in PPA) [15:18] If we can reject the binaries, build them in the PPA and copy them back to the archive, life would be easier [15:20] Maybe this works, I don't know launchpad well enough, sometimes it allows copying binaries with already-published source, sometimes not [15:21] Either way, this blocks me so I'll pivot to finishing my apt licensing issues for now (urgently need to finish the bookworm stable release :D) [15:30] I wonder if we can somehow setup auto rejects for grub2-unsigned, grub2-signed, fwupd-efi, fwupd-signed, shim, shim-signed source uploads [15:30] they should only be allowed to be copies from ~ubuntu-uefi-team owned PPAs [15:32] (because they need to route through signing service and it gets confusing if the same version is already in the archive) [15:49] -queuebot:#ubuntu-release- Unapproved: libfprint (jammy-proposed/main) [1:1.94.3+tod1-0ubuntu2~22.04.03 => 1:1.94.3+tod1-0ubuntu2~22.04.04] (ubuntu-desktop) [16:33] jbicha: there, i "fixed" matplotlib :) thanks for your help with rebuilds dropping 3.10. please leave the rest for me, i plan to work on that in the next pulse [16:34] matplotlib 3.6.3 from debian is still very broken when built in ubuntu, still no idea why [16:37] -queuebot:#ubuntu-release- Unapproved: netplan.io (kinetic-proposed/main) [0.105-0ubuntu2.1 => 0.105-0ubuntu2.2] (core) [16:39] -queuebot:#ubuntu-release- Unapproved: netplan.io (kinetic-proposed/main) [0.105-0ubuntu2.1 => 0.105-0ubuntu2.2] (core) [16:42] -queuebot:#ubuntu-release- Unapproved: rejected netplan.io [source] (kinetic-proposed) [0.105-0ubuntu2.2] [16:42] -queuebot:#ubuntu-release- Unapproved: netplan.io (jammy-proposed/main) [0.105-0ubuntu2~22.04.2 => 0.105-0ubuntu2~22.04.3] (core) [16:43] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (kinetic-proposed) [0.105-0ubuntu2.2] [16:44] -queuebot:#ubuntu-release- Unapproved: accepted netplan.io [source] (jammy-proposed) [0.105-0ubuntu2~22.04.3] [16:51] ginggs: ok ☺️ [16:59] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [22.4.2-0ubuntu0~18.04.1 => 23.1.1-0ubuntu0~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server) [16:59] -queuebot:#ubuntu-release- Unapproved: cloud-init (focal-proposed/main) [22.4.2-0ubuntu0~20.04.2 => 23.1.1-0ubuntu0~20.04.1] (core, edubuntu, ubuntu-cloud) [16:59] -queuebot:#ubuntu-release- Unapproved: cloud-init (jammy-proposed/main) [22.4.2-0ubuntu0~22.04.1 => 23.1.1-0ubuntu0~22.04.1] (core, ubuntu-cloud) [17:15] vorlon: cloud-init SRU uploads have been queued for B, F, and J per https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2008230 . We have a couple of supplemental fixes in version 23.1.1-* . Could you please review so we can get them into proposed? Thank you. [17:15] -ubottu:#ubuntu-release- Launchpad bug 2008230 in cloud-init (Ubuntu Kinetic) "sru cloud-init (23.1 update) Bionic, Focal, Jammy, Kinetic" [Undecided, New] [17:16] B, F, J and K ^ [17:22] aciba is EOW, so other cloud-init folks will shepherd discussion if needed on this upload [17:50] juliank: we don't have a framework for autorejects of sources unfortunately, because when the archive is open they don't go into a queue. We could reject binaries though. [17:51] vorlon: but can I copy the binaries if the source is already published? [17:51] juliank: you want to reach out to Mario wrt the constraints about fwupd-efi syncs? [17:51] juliank: I ... am not sure. Try it and see [17:52] vorlon: I have yes [17:52] ok [17:52] I think I should sync blacklist this [17:53] because it's always wrong to sync it from Debian now [17:53] (auto or, as in this case, manual) [17:53] -queuebot:#ubuntu-release- Unapproved: rejected fwupd-efi [amd64] (lunar-proposed) [1:1.4-1] [17:53] -queuebot:#ubuntu-release- Unapproved: rejected fwupd-efi [armhf] (lunar-proposed) [1:1.4-1] [17:53] -queuebot:#ubuntu-release- Unapproved: rejected fwupd-efi [arm64] (lunar-proposed) [1:1.4-1] [17:53] if we're lucky, then rejecting these binaries, copying through the signing ppas, and copying back works. But even if it does work, there's no reason to copy it first to the archive as opposed to the staging ppa [18:46] jbicha: you have triggered 5 separate libreoffice tests on arm64. Is that really necessary? instead of a single test with --all-proposed? [18:48] LocutusOfBorg: how are you submitting test requests? I see duplicate requests for gromacs/arm64 in the queue (in addition to the one already scheduled by britney, which wouldn't match retry-autopkgtest-regressions dedup pattern) [19:17] vorlon: I believe I have everything sorted on the iso tracker for Edubuntu. Any further steps? [20:09] vorlon, I did it manually [20:09] sorry for that [20:10] -queuebot:#ubuntu-release- New: accepted jtreg7 [amd64] (lunar-proposed) [7.1.1+1~us1-0ubuntu1] [20:11] Eickmeyer: there's probably a bit of admin work for me to do on the iso tracker, I don't think we've set it up to know edubuntu exists and should be tested for lunar [20:13] vorlon: I may have just done that yesterday, but you can double-check my work. There's also one thing I can't do, but you can, and that's actually put it on the tracker itself. Probably a click that I don't have access to. [20:15] It's in the manifest, testsuites/testcases. [20:19] oh you have iso tracker admin rights? alrighty then [20:20] cjwatson, xnox: have finally gotten around to nuking the useless 111G apt-mirror/dists directory on snakefruit, which nearly doubles the amount of free space on that disk ;P [20:21] Eickmeyer: http://iso.qa.ubuntu.com/qatracker/milestones/441/builds doesn't show edubuntu, which it should? [20:22] vorlon: Yes. Don't know how to get it there. :) [20:22] Eickmeyer: has there been a build since you made your changes to the tracker? [20:22] vorlon: No. Want to trigger one and see what happens? [20:22] ok [20:24] Eickmeyer: http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/1/downloads is empty [20:24] vorlon: I saw that, it should be populated for sure. [20:24] Eickmeyer: everything else looks good [20:25] sweet [20:25] Eickmeyer: I have no quick way to populate that, it's basically a cut'n'paste job from another existing product record. feel free to do it, or else I'll look at it after I get some SRU vanguard time in [20:25] Ok, I can do it. [20:28] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (kinetic-proposed) [2:21.1.4-2ubuntu1.6] [20:29] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (jammy-proposed) [2:21.1.3-2ubuntu2.8] [20:33] ahasenack: what am I missing on the kinetic apparmor upload to explain why it's been languishing in the queue since November? it looks completely straightforward to me which makes me wonder what I'm missing! [20:33] vorlon: I think that should did the trick? http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/1/downloads [20:33] *do [20:34] Eickmeyer: that covers the basics, but this page is also used for handling things like providing rsync/zsync downloads, pointer to checksum and signature files, etc. See the set of not-release-qualified records on http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/15/downloads for comparison? [20:35] Oh yes, that's right. [20:35] also we typically point to the actual filename, you've pointed to the directory [20:35] Oh, I can't see that. I can only see Studio and Edubuntu since I'm not on the release team for the one you linked. [20:35] oh and you shouldn't use 'current' in the download link, it should use the wildcard VERSION so that the url is correct for each build! [20:36] Ok, I can fix. [20:36] http://cdimage.ubuntu.com/kubuntu/daily-live/VERSION/SERIES-desktop-amd64.iso [20:36] e.g. [20:37] -queuebot:#ubuntu-release- Unapproved: accepted apparmor [source] (kinetic-proposed) [3.0.7-1ubuntu2.1] [20:42] vorlon: I'm pretty sure I've got it now. [20:48] Eickmeyer: lgtm. the 'lunar' entries are ftr unnecessary since we don't do point releases of non-LTS releases [20:49] vorlon: Ah, yeah, that makes sense. [20:52] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (kinetic-proposed) [21.11.3-0ubuntu0.22.10.1] [20:52] Eickmeyer: http://iso.qa.ubuntu.com/qatracker/milestones/441/builds looks good now [20:52] Eickmeyer: oh this isn't in the crontab yet, is it? [20:52] I don't believe so. [20:55] Eickmeyer: ok added to cron, so you'll now get daily images [20:56] vorlon: Ok, great! Should I email the TB asking for official status or are we done? [20:56] * arraybolt3 zsyncs a new ISO and tests it out [20:57] uh is there supposed to be an additional sign-off from the TB? I've lost track [20:57] vorlon: I mean, so have I. Maybe not? [20:57] I don't remember that being a requirement; AFAIK you've addressed everything the TB raised so from my perspective it's presumed that you're good to go [20:58] feel free to email the TB if you want additional confirmation [20:58] I would also suggest now that you have test cases that you run through them and confirm that you have a daily image that *passes* the tests [20:58] so that you have confidence you're ready to go by beta [20:59] Well, the last one did, but I do need to get the slideshow switched at some point. [20:59] Need a new release of the slideshow first. [21:00] vorlon: there are (were?) two apparmor SRUs [21:01] ahasenack: I didn't see 2 for kinetic [21:04] vorlon: ah, for kinetic, yes, just that one [21:04] I was thinking of another one which has 4 bugs attached [21:04] 17283130 1964636 1993353 and 1994146 [21:05] first two just focal, latter two focal and jammy [21:07] https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1993572 has the block-proposed tag, I didn't think it was worth an sru of its own, and was expecting it to be bundled with some other sru for kinetic [21:07] -ubottu:#ubuntu-release- Launchpad bug 1993572 in apparmor (Ubuntu Kinetic) "samba profile: missing rule for mkdir /var/cache/samba/printing" [Low, Fix Committed] [21:09] ahasenack: sru bug 2009074 has some screenshots from the person who reported to me, verifying the fix. [21:09] -ubottu:#ubuntu-release- Bug 2009074 in sddm (Ubuntu Kinetic) "[SRU Regression] SDDM display inset patch crashes" [Critical, Fix Committed] https://launchpad.net/bugs/2009074 [21:09] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (jammy-proposed) [21.11.3-0ubuntu0.22.04.1] [21:34] -queuebot:#ubuntu-release- Unapproved: accepted dpdk [source] (focal-proposed) [19.11.14-0ubuntu0.20.04.1] [21:37] I resent this xscreensaver SRU forcing me to look at 1990s-era X configuration files [21:39] that actually made me look at what the default "modern" screensaver is in ubuntu, and it's just a blank screen [21:39] even gnome-screensaver doesn't do anything basically [21:39] that made me sad [21:42] ahasenack: yes, gnome-screensaver was minimized to just a black screen, but GNOME no longer uses it. Someone could restore the older screensavers to it [21:43] arraybolt3: ftr both @DEFAULT_IMAGE_DIRECTORY@ and @DEFAULT_TEXT_FILE@ are supposed to be configured via --with-foo options to configure; it shouldn't be necessary to hard-code values via a patch against the upstream code. But --with-image-directory is already being passed, so I'm trying to see what's going on here [21:49] if test -d "$with_imagedir" ; then [21:49] that's the bug [21:50] it doesn't let you specify an image dir that doesn't exist as build time [21:50] clever [21:50] ditto the --with-text-file option [21:53] -queuebot:#ubuntu-release- Unapproved: accepted xscreensaver [source] (kinetic-proposed) [6.02+dfsg1-2ubuntu1.1] [21:55] athos: for squid, note that it's helpful when reviewing SRUs if you actually remove the patch rather than simply commenting it out in debian/patches/series, so that it's possible to see in the debdiff what the changed behavior is [21:59] vorlon: Yeah, that's part of why I did it the way I did it. [21:59] Directories that will exist on the installed system don't exist in the built environment. [22:00] In fact I think that's the only reason I resorted to hard-coding values in the config file. [22:00] Changing the config directly is, IMO, less likely to cause problems than modding the configuration code. [22:04] -queuebot:#ubuntu-release- Unapproved: accepted squid [source] (jammy-proposed) [5.2-1ubuntu4.4] [22:38] -queuebot:#ubuntu-release- Unapproved: rejected cups [source] (kinetic-proposed) [2.4.2-1ubuntu4] [22:39] -queuebot:#ubuntu-release- Unapproved: rejected veusz [source] (kinetic-proposed) [3.5.3-2~22.10] [22:49] vorlon: oh, I didn't realize commenting that would generate more effort for SRU reviews. I was trying to emphasize what was going on there so no one would mistakenly revert that in the future. There is a kinetic counterpart for that as well. Should I remove the comments or maintain consistency now? :) [23:07] athos: it's not the commenting out that's the issue, it's the fact that the actual patch is still in the package, so a debdiff as generated by launchpad doesn't show the actual nature of the change [23:07] i.e. we see the patch has been commented out but don't see what that patch is and what it does [23:10] I see. So since that was accepted, should I do the proper change for the kinetic counterpart? I am also making those suggested changes to supress the offending warning to see if we can avoid removing lto for s390x === OldManWinter is now known as Ukikie [23:28] athos: since I've already reviewed and accepted jammy, I don't mind either way if you delete that patch for kinetic [23:31] -queuebot:#ubuntu-release- Unapproved: rejected u-boot-xlnx [source] (kinetic-proposed) [2022.01-2022.1-update3+repack-0ubuntu1~22.10] [23:32] -queuebot:#ubuntu-release- Unapproved: rejected u-boot-xlnx [source] (jammy-proposed) [2022.01-2022.1-update3+repack-0ubuntu1~22.04] [23:40] -queuebot:#ubuntu-release- Unapproved: accepted xilinx-bootgen [source] (kinetic-proposed) [2022.2-2ubuntu1~22.10] [23:41] -queuebot:#ubuntu-release- Unapproved: accepted xilinx-bootgen [source] (jammy-proposed) [2022.2-2ubuntu1~22.04] [23:49] jamespage: so why do we have an Ubuntu-specific 'libmaas' python module in the archive which had its test suite disabled at package build time and which has no autopkgtests now in the devel series? https://autopkgtest.ubuntu.com/packages/a/python-libmaas [23:49] jamespage: the lack of autopkgtests remains a future foot-gun in the face of future python transitions. Is anyone tasked with correcting this? [23:51] -queuebot:#ubuntu-release- Unapproved: accepted python-libmaas [source] (kinetic-proposed) [0.6.8-0ubuntu0.22.10.1] [23:54] -queuebot:#ubuntu-release- Unapproved: accepted python-libmaas [source] (jammy-proposed) [0.6.8-0ubuntu0.22.04.1]