[06:27] -queuebot:#ubuntu-release- Unapproved: libcupsfilters (lunar-proposed/main) [2.0~rc1-0ubuntu1 => 2.0~rc1-0ubuntu1.1] (no packageset)
[07:10] -queuebot:#ubuntu-release- Unapproved: libppd (lunar-proposed/main) [2:2.0~rc1-0ubuntu1 => 2:2.0~rc1-0ubuntu1.1] (no packageset)
[09:09] <RikMills> archive-admin: if anyone has a chance to review ktextaddons in NEW that would be appreciated. needed to be able to update the KDE PIM stack in mantic to the latest current release
[09:10] <RikMills> LP: #2021510
[09:10] -ubottu:#ubuntu-release- Launchpad bug 2021510 in Ubuntu "[needs packaging] ktextaddons" [Wishlist, New] https://launchpad.net/bugs/2021510
[11:40] -queuebot:#ubuntu-release- Unapproved: adv-17v35x (jammy-proposed/universe) [5.0.6.0-1 => 5.0.6.0-1ubuntu1] (kernel-dkms)
[12:33] -queuebot:#ubuntu-release- Unapproved: ristretto (focal-proposed/universe) [0.10.0-1 => 0.10.0-1ubuntu0.1] (ubuntustudio, xubuntu)
[12:42] -queuebot:#ubuntu-release- Unapproved: gtk4 (lunar-proposed/main) [4.10.3+ds-0ubuntu1 => 4.10.4+ds-0ubuntu1] (desktop-core, i386-whitelist, ubuntu-desktop)
[13:18] <ccdm941> good morning/afternoon. I was wondering if it is possible to push the mantic perl update currently in proposed. The test failures that are still happening seem to be unrelated to the update (meaning, not a regression caused by the update). Thanks in advance!
[13:20] <ccdm941> one of the tests is failing because it is flaky and the other one is solved if the newer mysql-8.0 package in proposed is used instead
[13:27] -queuebot:#ubuntu-release- Unapproved: python-websockets (jammy-proposed/universe) [9.1-1 => 10.2-1ubuntu0.22.04.1] (no packageset)
[13:38] -queuebot:#ubuntu-release- Unapproved: libmbim (jammy-proposed/main) [1.28.0-1~ubuntu20.04.1 => 1.28.0-1~ubuntu20.04.2] (desktop-core, i386-whitelist)
[14:30] <vorlon> ccdm94: how did you determine that the libmonitoring-livestatus-perl/arm64 test is "flaky", when it has passed 3 times in a row with the perl in the release pocket, and failed 7 times in a row with the perl in -proposed?
[14:53] <ccdm94> vorlon: sorry if this was an incorrect assumption about the test. However, I do not think that the update is the cause for the failure because the change applied was to force CPAN to verify SSL certificates when using HTTP::Tiny to recover modules from an HTTPS source. This test seems to not be failing because of a CPAN fail (or at least the messages do not seem to indicate this). Also, it seems like for other architectures, such
[14:53] <ccdm94>  as amd64, this is marked as "Not a regression" and the same tests are failing, so it could be a test issue, not an update issue. That was the reasoning behind this.
[14:56] <vorlon> ccdm94: ok, yes I see that amd64 was failing the same way; curious that arm64 was not.  NB this is not proof that the regression isn't introduced by the new perl version - it could perhaps be a change in behavior triggered by rebuilding with a new toolchain - but this at least establishes that the test in question is dubious and shouldn't block
[14:56] <vorlon> ccdm94: NB the test still passes on armhf and s390x...
[14:57] <vorlon> anyway, I will add a hint to ignore this test failure on arm64
[15:00] <ccdm94> vorlon: thank you
[15:30] <jbicha> bdmurray: since you're on today's SRU schedule, could you review gtk4 in lunar unapproved? it fixes a regression with the previous update, bug 2022851
[15:30] -ubottu:#ubuntu-release- Bug 2022851 in gtk4 (Ubuntu Lunar) "Nautilus displays invalid directory content after deleting" [Critical, In Progress] https://launchpad.net/bugs/2022851
[16:22] <vorlon> jbicha: this appears to have the wrong bug tag? it's marked regression-release instead of regression-update
[16:23] <jbicha> vorlon: thanks, updated now
[17:11] <vorlon> ccdm94: https://autopkgtest.ubuntu.com/packages/m/mysql-8.0/mantic/s390x mysql-8.0 autopkgtest failed with new perl
[17:14] <ccdm94> vorlon: yes, I saw this
[17:14] <vorlon> I've triggered it again to see if it behaves better
[17:19] <ccdm94> From what I understand, it seems like the issue is test 'main.derived_condition_pushdown', which is failing. I am looking at the output and I am not sure how the perl update would have resulted in this error, however, I also see that some previous builds (triggered by other packages) also failed because of this test (like the one triggered by sysvinit/3.06-4ubuntu1, for example). I can try to check what the test does and see if t
[17:19] <ccdm94> he perl update would cause an issue.
[17:22] <bdmurray> jbicha: have you looked into why gtk4 is stuck in -proposed for mantic?
[17:23] <bdmurray> libreoffice mantic/armhf w/ gtk4 looks like a timeout so I'll retry that
[17:24] <jbicha> bdmurray: I have running retries of those 2 libreoffice autopkgtests
[17:25] <bdmurray> Ah, I see that now.
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted gtk4 [source] (lunar-proposed) [4.10.4+ds-0ubuntu1]
[18:22] -queuebot:#ubuntu-release- Unapproved: accepted libppd [source] (lunar-proposed) [2:2.0~rc1-0ubuntu1.1]
[18:30] -queuebot:#ubuntu-release- Unapproved: accepted libcupsfilters [source] (lunar-proposed) [2.0~rc1-0ubuntu1.1]
[18:42] <ccdm94> vorlon: i see the mysql-8.0 autopkgtest re-run has passed. Yay to that!
[19:04] <vorlon> ccdm94: then perl should migrate automatically now
[19:05] <ccdm94> vorlon: thank you very much for the help and feedback on this!
[19:38] -queuebot:#ubuntu-release- New source: docker.io-app (mantic-proposed/primary) [20.10.25-0ubuntu1]
[19:45] <kanashiro[m]> vorlon: I am working to split the docker.io library and application so we can easily update the application in supported releases without breaking rdeps of the library. I just uploaded src:docker.io-app (in NEW) which provides docker.io (application) and docker-doc (documentation) binary packages. Those binary packages are provided right now by src:docker.io and I am moving them to src:docker.io-app. In LP #2022390, I am working o
[19:45] <kanashiro[m]> where we are going to basically follow Debian regarding the -dev package and remove the other binaries (moved to src:docker.io-app). With all that said, we need to upload the src:docker.io merge with Debian and review/accept src:docker.io-app, not sure if we need to remove the docker.io and docker-doc binaries provided by src:docker.io before we land src:docker.io-app.
[19:45] -ubottu:#ubuntu-release- Launchpad bug 2022390 in docker.io (Ubuntu) "Keep all binaries but docker.io (application) in sync with Debian" [Undecided, In Progress] https://launchpad.net/bugs/2022390
[19:47] <vorlon> kanashiro[m]: I think part of your message got lost due to irc line splitting; I got "In LP #2022390, I am working o" and then "where we are going to basically follow Debian"
[19:47] -ubottu:#ubuntu-release- Launchpad bug 2022390 in docker.io (Ubuntu) "Keep the -dev binary package in sync with Debian" [Undecided, In Progress] https://launchpad.net/bugs/2022390
[19:47] <kanashiro[m]> meh, sorry, let me also split my message
[19:48] <vorlon> kanashiro[m]: you do not need to remove the binaries before landing src:docker.io-app; you will need to remove them as part of the next upload of src:docker.io after src:docker.io-app is accepted (otherwise, the package will build in launchpad but binaries will fail to upload)
[19:48] <kanashiro[m]> In LP #2022390, I am working on a src:docker.io merge where we are going to basically follow Debian regarding the -dev package and remove the other binaries (moved to src:docker.io-app).
[19:48] <kanashiro[m]>  With all that said, we need to upload the src:docker.io merge with Debian and review/accept src:docker.io-app, not sure if we need to remove the docker.io and docker-doc binaries provided by src:docker.io before we land src:docker.io-app.
[19:48] -ubottu:#ubuntu-release- Launchpad bug 2022390 in docker.io (Ubuntu) "Keep the -dev binary package in sync with Debian" [Undecided, In Progress] https://launchpad.net/bugs/2022390
[19:50] <kanashiro[m]> vorlon: right, thanks for letting me know. So I am going to wait for the review/acceptance of src:docker.io-app so I can proceed with the src:docker.io upload
[19:50] <vorlon> you also don't have to wait, because the new docker.io that drops the binaries will be held in -proposed until the binaries are superseded in the release pocket
[19:53] -queuebot:#ubuntu-release- Unapproved: accepted glibc [source] (jammy-proposed) [2.35-0ubuntu3.2]
[20:05] <vorlon> Vcs-Git: https://github.com/canonical/docker.io-app.git
[20:05] <vorlon> really? not git-ubuntu?
[20:07] <kanashiro[m]> vorlon: we are maintaining there to keep our relationship with tianon, they are still helping us with reviews
[20:08] <vorlon> +ListenStream=/run/docker.sock
[20:08] <vorlon> I really need to do a /var/run audit over the archive sometime
[20:08] <kanashiro[m]> At least now we are using the canonical namespace :)
[20:10] -queuebot:#ubuntu-release- New: accepted docker.io-app [source] (mantic-proposed) [20.10.25-0ubuntu1]
[20:37] <kanashiro[m]> vorlon: thanks for accepting docker.io-app ! ^
[20:45] <rbasak> vorlon: I don't think git-ubuntu works for a maintaining team that originates the packaging
[20:48] <vorlon> rbasak: sorry, I don't understand what you mean
[23:22] -queuebot:#ubuntu-release- New binary: domdf-python-tools [amd64] (mantic-proposed/none) [3.4.0-1] (no packageset)