[04:09] <RAOF> If anyone feels like what should be a quick, safe ffe review, bug #1988702 is available for their perusal.
[05:42] -queuebot:#ubuntu-release- New: accepted qt6-charts [arm64] (kinetic-proposed) [6.3.1-3]
[05:46] -queuebot:#ubuntu-release- New: accepted ubuntu-unity-backgrounds [amd64] (kinetic-proposed) [22.10-0ubuntu1]
[08:20] -queuebot:#ubuntu-release- New binary: gtksourceview4 [amd64] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:21] -queuebot:#ubuntu-release- New binary: gtksourceview4 [i386] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:21] -queuebot:#ubuntu-release- New binary: gtksourceview4 [ppc64el] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:21] -queuebot:#ubuntu-release- New binary: gtksourceview4 [s390x] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:24] -queuebot:#ubuntu-release- New binary: gtksourceview4 [arm64] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:24] -queuebot:#ubuntu-release- New binary: gtksourceview4 [armhf] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[08:57] -queuebot:#ubuntu-release- New binary: gtksourceview4 [riscv64] (kinetic-proposed/universe) [4.8.3-1ubuntu1] (i386-whitelist, ubuntu-desktop)
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [amd64] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [armhf] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [ppc64el] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [s390x] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [arm64] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [riscv64] (kinetic-proposed) [4.8.3-1ubuntu1]
[09:02] -queuebot:#ubuntu-release- New: accepted gtksourceview4 [i386] (kinetic-proposed) [4.8.3-1ubuntu1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [amd64] (jammy-proposed) [1.8.3-1~22.04.1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [armhf] (jammy-proposed) [1.8.3-1~22.04.1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [riscv64] (jammy-proposed) [1.8.3-1~22.04.1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [arm64] (jammy-proposed) [1.8.3-1~22.04.1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [s390x] (jammy-proposed) [1.8.3-1~22.04.1]
[12:35] -queuebot:#ubuntu-release- New: accepted fwupd [ppc64el] (jammy-proposed) [1.8.3-1~22.04.1]
[13:23] <coreycb> Hello SRU team, we have a package that was promoted to jammy-updates but depends on another SRU in bug 1985097. please can we get pyroute2 promoted as well? it is causing install failures.
[13:25] <rbasak> coreycb: I think you need a versioned dependency then. Now that we have apt phasing, just releasing the other one won't fully solve the problem :-/
[13:26] <coreycb> rbasak: I think it's failing due to the version dependency.  Nobuto mentioned in that bug that apt install hits " python3-neutron : Depends: python3-pyroute2 (>= 0.6.4-3ubuntu1~) but 0.6.4-3 is to be installed"
[13:27] <rbasak> Ah, OK.
[13:31] <rbasak> Released pyroute2 to Jammy
[13:32] <coreycb> rbasak: thank you very much. out of curiosity, in cases like this, is there any chance apt phasing can be turned off for an individual package update? probably not but figured I'd ask.
[13:33] <rbasak> It's possible, but I believe that as long as the dependencies are declared correctly (they are in this case) then as long as both packages are available in -updates, apt will do the right thing.
[13:33] <rbasak> An AA could also set full phasing, but I don't think that's necessary.
[13:34] <rbasak> The issue I think is to ensure that both packages are released at once which unfortunately didn't happen here.
[13:35] <rbasak> Otherwise an affected user would only be able to resolve dependencies correctly by using the release pocket I think, since the new -updates package will mask the previous one. And that's undesirable and I'm not sure apt would even do that by default without an explicit version.
[13:35] <coreycb> Right, I was just thinking that currently neutron will fail to install until pyroute2 is fully phased. not sure how long that takes.
[13:35] <rbasak> Oh for new installs? Yes, that makes sense, sorry.
[13:35] <rbasak> I don't have the powers to change phasing though. I believe that needs an AA.
[13:36] <rbasak> ubuntu-archive: ^
[13:36] <rbasak> So I retract what I said above. In cases like this we do need to avoid phasing, as I think it'll cause more harm than good because of the masking in -updates.
[13:39] <coreycb> yes, I agree
[15:19] <xnox> RAOF:  heya, would you be able to review https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=wireguard-linux-compat it is fairly recent solution, to our outstanding issue of unable to apply stable updates to bionic kernels; and recent stable updates break wireguard which i finally managed to fix.
[15:19] <xnox> once that wireguard-linux-compat is in proposed, we can actually resume stable updates for bionic linux kernels.
[15:19] <xnox> so somewhat urgent.
[15:21] <paride> sil2100, hey, do I have an ack to upload auto-upgrade-testing (NEW) to kinetic? :)
[15:29] <vorlon> rbasak, coreycb: pyroute2/jammy fully phased
[15:30] <rbasak> Thanks!
[15:35] <sil2100> paride: hey! What is that? I'm probably missing some context ;)
[15:45] <coreycb> vorlon: great, thanks very much
[15:56] <paride> sil2100, context is:
[15:56] <paride> We (qa team) would like to upload a New package: auto-upgrade-testing, which is meant to run upgrade tests of different Ubuntu releases
[15:56] <paride> it used to be in the archive in the past, but was RMd as it ended up being unmaintained
[15:56] <paride> but now it's maintained again
[15:57] <paride> sil2100, it's the same tool used in the platform-qa-jenkins for the upgrade tests. Having in in the archive will allow community and flavor maintainers to run the same tests locally
[15:57] <vorlon> LocutusOfBorg: is it you restarting the pandoc/armhf build?
[15:57] <paride> sil2100, is it OK if I upload it to kinetic? Asking you as I think your AA shift is tomorrow
[16:05] <vorlon> LocutusOfBorg: (if so, I'm interested to know what was in the log before it was restarted)
[16:40] <jbicha> paride: I'm not an AA, but please go ahead and upload the package to kinetic. They can review easier from the new queue :)
[16:53] <paride> jbicha, I was kind trying to follow https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages but well it probably makes sense to upload :)
[16:57] -queuebot:#ubuntu-release- New source: auto-upgrade-testing (kinetic-proposed/primary) [0.3]
[17:02] <bdmurray> vorlon: Could you copy tzdata 2022c to -security?
[17:24] <vorlon> bdmurray: done (isn't this meant to be done with sru-release --security?)
[17:25] -queuebot:#ubuntu-release- Unapproved: tzdata (bionic-security/main) [2022c-0ubuntu0.18.04.0 => 2022c-0ubuntu0.18.04.0] (core) (sync)
[17:25] -queuebot:#ubuntu-release- Unapproved: tzdata (focal-security/main) [2022c-0ubuntu0.20.04.0 => 2022c-0ubuntu0.20.04.0] (core) (sync)
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (bionic-security) [2022c-0ubuntu0.18.04.0]
[17:26] -queuebot:#ubuntu-release- Unapproved: tzdata (jammy-security/main) [2022c-0ubuntu0.22.04.0 => 2022c-0ubuntu0.22.04.0] (core) (sync)
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (focal-security) [2022c-0ubuntu0.20.04.0]
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted tzdata [sync] (jammy-security) [2022c-0ubuntu0.22.04.0]
[17:28] <RikMills> bdmurray: would it be possible to fully phase the kde plasma updates in jammy as soon as possible please? the partial phasing is causing people to let essential packages be removed when they unwisely force a full-upgrade/dist-upgrade
[17:28] <RikMills> e.g. https://www.reddit.com/r/Kubuntu/comments/x7bb6t/apt_fullupgrade_wants_to_remove_kubuntudesktop/
[17:29] <RikMills> e.g https://www.kubuntuforums.net/forum/newbie-support/help-the-new-guy/664968-apt-dist-upgrade-broke-kubuntu-decided-to-uninstall-sddm
[17:34] <bdmurray> vorlon: I don't recall how it is done.
[17:34] <bdmurray> RikMills: That'd actually require an AA
[17:36] <RikMills> bdmurray: ah.
[17:36] <RikMills> ubuntu-archive: ^^
[18:03] <sergiodj> hello, I have the following FFe request for sssd: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1988615.  when possible, could someone take a look into it?  TIA
[18:05] <LocutusOfBorg> vorlon, no.
[18:05] <LocutusOfBorg> I didnt notice
[18:05] <LocutusOfBorg> sad story
[18:14] <LocutusOfBorg> vorlon, this happened by somebody with *more* power than me
[18:15] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/24337009
[18:15] <LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/24337014
[18:15] <LocutusOfBorg> at the very same time they were restarted, and I think you need *lots* of power to retry from private ppas?
[18:15] <LocutusOfBorg> I'm pretty sure was some sort of LP general failure with no logs, restarted by the minion who sorted out the network?
[19:02] <cjwatson> LocutusOfBorg: rather more likely to have been automatically restarted by buildd-manager
[19:06] <vorlon> LocutusOfBorg: ok. On restart it appears to have been picked up by one of the "good" builders, so at least there's that
[19:08] <vorlon> RikMills: I'm fine to phase these packages, but can you elaborate on what's failing so we can try to avoid this problem in the future?
[19:20] -queuebot:#ubuntu-release- New: accepted fonts-vazirmatn [amd64] (kinetic-proposed) [33.003-0ubuntu1]
[19:27] <RikMills> vorlon: see the 2 forum links I posted. I have also had people ask for help on IRC/telegram. for some the phasing is making upgrades unistallable with some packages being removed
[19:27] <RikMills> I cannot replicate this myself to investigate more. I just get things 'held back'
[19:28] <RikMills> I do know if you skip phasing entirely, the plasma stack upgrades fine
[19:31] <vorlon> RikMills: right, I see nothing in the archive declaring a breaks: against kubuntu-desktop so this is non-obvious to me; a bug report against apt is in order but only helps if it's filed by someone who can reproduce the problem
[19:34] <RikMills> yeah, that one is puzzling
[19:35] <vorlon> RikMills: and the other one is a user manually running 'apt autoremove' after a dist-upgrade, and not paying attention to what it removed, well
[19:36] <RikMills> vorlon: well, not quite
[19:36] <RikMills> the dist-upgrade did do 'Remove: kubuntu-desktop:amd64 (1.418), sddm-theme-breeze:amd64 (4:5.24.4-0ubuntu1), kubuntu-settings-desktop:amd64 (1:22.04.10)'
[19:37] <vorlon> still, this needs to be analyzed in apt
[19:37] <vorlon> RikMills: right
[19:37] <RikMills> which then leaves other things autoremovable
[19:38] <RikMills> if I could reproduce I would. have tried upgrading a real machine, and am VM that I roll back a few times to repeat. have not hit the issue of removal so far
[19:43] <vorlon> RikMills: so it might be more effective to cajole one of the forum reporters to file a bug directly, such that juliank can interrogate them
[19:44] <rbasak> A list of packages installed with their versions would really help I think.
[19:45] <juliank> Ok so dist-upgrade presumably calls mark delete with from user set to true, which is wrong in terms of meta package handling as it does not transition the manual bit over to dependencies (apt remove xubuntu-desktop means you want to remove it all, vs something causing removal of xubuntu-desktop which would mark all its depends manually installed)
[19:46] <juliank> We've seen another instance of this with Ubuntu-Desktop
[19:46] <juliank> I think
[19:46] <vorlon> juliank: what triggers the metapackage being marked for removal at all? that's the problem here
[19:46] <juliank> This is the bug I think bdmurray was working on where it ten failed the tasks check
[19:46] <vorlon> there are no breaks against kubuntu-desktop in the archive
[19:46] <juliank> vorlon: we did not have data to analyze that further
[19:46] <vorlon> ack
[19:48] <juliank> We should in any case also mark those meta packages for install, and protect them, but I don't think we can reallY
[19:48] <juliank> Because there is not one Problem resolver running but multiple
[19:48] <juliank> But I might misremember and it would help in steps
[19:50] <bdmurray> The tasks check bug was with ubuntu-release-upgrader fwiw
[19:53] <juliank> Eh yeah I might have mixed about dist and release upgrade
[19:56] <LocutusOfBorg> thanks cjwatson nice feature then :)
[21:14] -queuebot:#ubuntu-release- New source: fonts-sahel (kinetic-proposed/primary) [3.4.0-0ubuntu1]
[22:45] -queuebot:#ubuntu-release- New sync: roger-router (kinetic-proposed/primary) [2.4.2-3]