[00:09] -queuebot:#ubuntu-release- New binary: zbar [arm64] (kinetic-proposed/universe) [0.23.92-6] (i386-whitelist, kubuntu)
[00:09] -queuebot:#ubuntu-release- New binary: zbar [armhf] (kinetic-proposed/universe) [0.23.92-6] (i386-whitelist, kubuntu)
[00:54] -queuebot:#ubuntu-release- New binary: zbar [riscv64] (kinetic-proposed/universe) [0.23.92-6] (i386-whitelist, kubuntu)
[03:07] -queuebot:#ubuntu-release- Unapproved: ubuntustudio-meta (jammy-proposed/universe) [0.266 => 0.266.1] (ubuntustudio)
[04:47] <tsimonq2> The s390x autopkgtest queue is looking a bit backed up (e.g. the package I'm waiting on is backed up by 26 hours compared to the top queue item). Is this normal behavior?
[05:17] -queuebot:#ubuntu-release- New binary: dnswire [amd64] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: dnswire [ppc64el] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: gnunet-gtk [amd64] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: gnunet-gtk [ppc64el] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[05:24] -queuebot:#ubuntu-release- New binary: dnswire [arm64] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[05:27] -queuebot:#ubuntu-release- New binary: dnswire [armhf] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[05:29] -queuebot:#ubuntu-release- New binary: gnunet-gtk [armhf] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[05:31] -queuebot:#ubuntu-release- New binary: gnunet-gtk [arm64] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[05:40] -queuebot:#ubuntu-release- New binary: dnswire [riscv64] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: gnunet-gtk [riscv64] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[06:47] <luis220413> tjaalton: Bug 1978555 meets the microrelease SRU criteria. Please upload the patched packages to focal-proposed and jammy-proposed (with the version number changed to reflect the removal of files from the upstream tarball (I added .1, but this is not correct)).
[09:29] -queuebot:#ubuntu-release- New sync: oem-somerville-tentacool-meta (jammy-proposed/primary) [22.04~ubuntu1]
[10:57] <luis220413> tjaalton: ^
[11:06] <cjwatson> tsimonq2: Probably same reason the s390x builders were mostly down.  The infrastructure has been picked up and shaken again and maybe that will help autopkgtest too?
[12:06] -queuebot:#ubuntu-release- New binary: zbar [s390x] (kinetic-proposed/universe) [0.23.92-6] (i386-whitelist, kubuntu)
[12:10] -queuebot:#ubuntu-release- New binary: dnswire [s390x] (kinetic-proposed/universe) [0.3.3-1] (no packageset)
[12:15] -queuebot:#ubuntu-release- New binary: gnunet-gtk [s390x] (kinetic-proposed/universe) [0.16.0-4] (no packageset)
[12:50] <luis220413> rbasak: My spip SRU is ready. Please upload the packages to the proposed pockets.
[12:51] <luis220413> with the version number of the upstream tarball changed to reflect the removal of excluded files from the upstream tarball (I added .1 to that version number, but this is not correct).
[13:20] <luis220413> tjaalton: ^
[13:21] <luis220413> I will go now, but the upstream versions of SPIP should be unchanged as done by the Debian maintainer, even if files were excluded from the upstream tarball.
[13:22] <luis220413> s/versions of SPIP/version numbers/
[13:22] <rbasak> luis220413: the policy from https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases is that if the package doens't meet the requirements then you have individual bugs in Launchpad and verify every single bug.
[13:22] <rbasak> That doens't seem practical.
[13:22] <rbasak> Also, note that you need a sponsor to upload this package. That's not necessarily an SRU team member. SRU team members review after a sponsor has uploaded it.
[13:24] <luis220413> rbasak: Where can I ask for sponsorship?
[13:25] <rbasak> Putting the bug in the sponsorship queue and asking on IRC as you've been doing is fine. My point is that demanding work from just SRU team members isn't helpful.
[13:26] <rbasak> I'd also happily sponsor this for you if your work was acceptable to me.
[13:26] <rbasak> However I am not prepared to sponsor a bulk microrelease update as you're requesting in this case, if the upstream doesn't meet the requirements as you say.
[13:27] <rbasak> If you have specific fixes you need, then please cherry-pick them and I'll sponsor those (assuming the number of bugs you actually *need* fixed is small)
[13:29] <rbasak> If those are security updates, then they should be cherry-picked and go via the security pocket, and you'll need a security team sponsor for that.
[13:34] <luis220413> For Focal, there are 24 security vulnerability fix commits, 9 necessary fix commits, 27 bugfix commits, 6 new-feature commits and 3 code readability improvement commits, and there are not more in Jammy.
[13:34] <luis220413> For the security commits, the necessary follow-up commits and the code readability commits I can go through the security pocket. Right?
[13:34] <luis220413> rbasak: ^
[13:35] <rbasak> You're expected to make only the minimal changes required for the security fixes. So it depends on whether your follow-up commits are required for security.
[13:35] <rbasak> I suggest asking in #ubuntu-security for their specific requirements as they'll be doing the review and making the final decision.
[13:36] <luis220413> rbasak: Upstream does not meet the requirements for not filing individual bugs, however I can file 20-30 bugs for each of the issues that will not be fixed through security.
[13:36] <luis220413> s/20-30 bugs for each of the issues/1 bug for each of the 20-30 issues/
[13:36] <rbasak> Are these 20-30 bugs really affecting users of the package in Ubuntu?
[13:36] <rbasak> This seems unlikely to me.
[13:37] <rbasak> I think you're placing an unreasonable demand on Ubuntu developer teams here for no tangible benefit to Ubuntu users.
[13:37] <luis220413> rbasak: Most of them yes, but depends on the PHP version and configuration and SPIP configuration.
[13:37] <rbasak> Please pick a few of the actually important, impactful bugs that are affecting Ubuntu users today.
[13:38] <rbasak> If nobody else has reported the bug in Ubuntu, then that's an indicator to me that nobody is actually affected by this.
[13:39] <rbasak> And reviewers in Ubuntu aren't going to be inclined to spend time on reviewing these changes for you, or prioritising them.
[13:39] <rbasak> On the other hand, if there are specific issues that really need addressing, then Ubuntu developers will be happy to help. But you need to provide an acceptable justification that this is actually needed.
[13:40] <luis220413> rbasak: But I can test them all after July 19.
[13:41] <rbasak> luis220413: you also need a sponsor to review them all, and an SRU team member to review them all. That's not reasonable to do unless there are real Ubuntu users impacted by these issues. I see no evidence of that.
[13:42] <rbasak> Security is separate, of course - I'm speaking for non-security issues here.
[13:42] <luis220413> rbasak: Therefore, I will only fix the security issues and a fatal bug that does not allow SPIP to start in PHP environments where ini_set is disabled.
[13:42] <luis220413> This bug was only fixed in the 4.0 series (for Jammy).
[13:42] <rbasak> That sounds more reasonable - thanks.
[13:42] <rbasak> I would start with the security issues first, and put those in via the security pocket.
[13:42] <rbasak> Then work on the SRU for your important bug later.
[13:43] <rbasak> It's possible to do multiple things at once but that just makes it more complicated for everyone, and you're new to this.
[13:43] <luis220413> rbasak: And the few other fatal non-security bugs
[13:43] <luis220413> rbasak: I would also start with the security pocket, then update the debdiff in the SRU bug to address only the fatal bugs
[13:43] <luis220413> *debdiffs
[13:45] <luis220413> rbasak: I will go. The security fixes will be ready on July 19.
[13:45] <luis220413> I will go now.
[13:49] <rbasak> OK. Thanks!
[14:05] <bdmurray> tsimonq2: No it isn't normal behavior and I am aware of the issue.
[16:12] <tsimonq2> cjwatson, bdmurray: Thanks! Much appreciated
[16:34] <seb128> could someone trigger a new canary desktop/amd64/kinetic iso build?
[16:35] <seb128> also please don't forgot to include the ppa in the build
[16:37] <fheimes> hi SRU team (maybe tjaalton today) could you please have a look at s390-tools(-signed) in the focal queue and ideally approve? (it's stuck in the queue for a while) - thx
[17:21] -queuebot:#ubuntu-release- New binary: gnunet-gtk [amd64] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: gnunet-gtk [ppc64el] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[17:23] -queuebot:#ubuntu-release- New: accepted dnswire [s390x] (kinetic-proposed) [0.3.3-1]
[17:23] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [amd64] (kinetic-proposed) [0.16.0-5]
[17:24] -queuebot:#ubuntu-release- New: accepted zbar [s390x] (kinetic-proposed) [0.23.92-6]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [s390x] (kinetic-proposed) [0.16.0-4]
[17:24] -queuebot:#ubuntu-release- New binary: gnunet-gtk [s390x] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [ppc64el] (kinetic-proposed) [0.16.0-5]
[17:24] <seb128> bdmurray, ^ could you maybe help with the canary build?
[17:24] -queuebot:#ubuntu-release- New: accepted dnswire [arm64] (kinetic-proposed) [0.3.3-1]
[17:24] -queuebot:#ubuntu-release- New: accepted dnswire [ppc64el] (kinetic-proposed) [0.3.3-1]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [amd64] (kinetic-proposed) [0.16.0-4]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [armhf] (kinetic-proposed) [0.16.0-4]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [riscv64] (kinetic-proposed) [0.16.0-4]
[17:24] -queuebot:#ubuntu-release- New: accepted dnswire [armhf] (kinetic-proposed) [0.3.3-1]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [arm64] (kinetic-proposed) [0.16.0-4]
[17:24] -queuebot:#ubuntu-release- New: accepted dnswire [riscv64] (kinetic-proposed) [0.3.3-1]
[17:24] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [ppc64el] (kinetic-proposed) [0.16.0-4]
[17:24] <vorlon> coreycb: heya, impish is hitting EOL and there are openstack packages in impish-proposed.  Do you want these verified and released, or dropped out of -proposed before we EOL?  I guess it doesn't matter much either way even if you take them into UCA, because you're not getting any subsequent SRUs
[17:24] -queuebot:#ubuntu-release- New: accepted dnswire [amd64] (kinetic-proposed) [0.3.3-1]
[17:24] -queuebot:#ubuntu-release- New: accepted zbar [riscv64] (kinetic-proposed) [0.23.92-5]
[17:24] <vorlon> coreycb: anyway if you want to verify and release them your deadline is ~EOD
[17:24] -queuebot:#ubuntu-release- New: accepted zbar [arm64] (kinetic-proposed) [0.23.92-6]
[17:24] -queuebot:#ubuntu-release- New: accepted zbar [i386] (kinetic-proposed) [0.23.92-6]
[17:24] -queuebot:#ubuntu-release- New: accepted zbar [riscv64] (kinetic-proposed) [0.23.92-6]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [arm64] (kinetic-proposed) [0.23.92-5]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [armhf] (kinetic-proposed) [0.23.92-6]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [amd64] (kinetic-proposed) [0.23.92-6]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [ppc64el] (kinetic-proposed) [0.23.92-6]
[17:25] -queuebot:#ubuntu-release- New: accepted pymdown-extensions [amd64] (kinetic-proposed) [9.5-2]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [amd64] (kinetic-proposed) [0.23.92-5]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [i386] (kinetic-proposed) [0.23.92-5]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [s390x] (kinetic-proposed) [0.23.92-5]
[17:25] -queuebot:#ubuntu-release- New: accepted python-sarif-python-om [amd64] (kinetic-proposed) [1.0.4-2]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [ppc64el] (kinetic-proposed) [0.23.92-5]
[17:25] -queuebot:#ubuntu-release- New: accepted zbar [armhf] (kinetic-proposed) [0.23.92-5]
[17:27] -queuebot:#ubuntu-release- New binary: gnunet-gtk [arm64] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: gnunet-gtk [armhf] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[18:03] -queuebot:#ubuntu-release- New binary: gnunet-gtk [riscv64] (kinetic-proposed/universe) [0.16.0-5] (no packageset)
[18:14] <seb128> vorlon, ^ or maybe you to start a canary/kinetic iso build?
[18:25] <seb128> apw, ^ or you maybe?
[18:25] <seb128> also is there a way to request acl to trigger an iso build job without being a release member?
[18:26] <bdmurray> seb128: Can you not "Request a rebuild" here? https://iso.qa.ubuntu.com/qatracker/milestones/433/builds
[18:35] <bdmurray> Anyway, I'll kick one off on the server
[18:50] <seb128> bdmurray, ah, learning every day, and thanks!
[18:51] <seb128> bdmurray, ah, that was a question, seems note but currently the website loads in 'textmode' for me so I will retry later
[18:53] <vorlon> seb128: the 'textmode' is likely mixed URI for the stylesheets :/
[19:18] <bdmurray> seb128: it's available now
[19:18] <seb128> bdmurray, thanks!
[19:28] <vorlon> bdmurray: opencryptoki, ubuntu-release-upgrader fully phased
[19:28] <vorlon> (how often does that report update? since there's at least one just-released SRU)
[19:37] <bdmurray>  42 5,11,17,23 * * *     http_proxy= https_proxy= run-phased-updater
[19:41] <vorlon> and it took over an hour to run? yuck
[19:41] <vorlon> 2hours even
[20:26] -queuebot:#ubuntu-release- New binary: mkdocs-section-index [amd64] (kinetic-proposed/universe) [0.3.4-2] (no packageset)
[21:36] -queuebot:#ubuntu-release- Unapproved: fprintd (jammy-proposed/main) [1.94.2-1 => 1.94.2-1ubuntu0.22.04.1] (ubuntu-desktop)
[23:19] -queuebot:#ubuntu-release- New binary: python-aiormq [amd64] (kinetic-proposed/none) [6.3.4-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: python-pypartpicker [amd64] (kinetic-proposed/none) [1.9.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: python-mock-open [amd64] (kinetic-proposed/none) [1.4.0-1] (no packageset)
[23:19] -queuebot:#ubuntu-release- New binary: ytfzf [amd64] (kinetic-proposed/none) [2.3-2] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: python-gflanguages [amd64] (kinetic-proposed/none) [0.4.0-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: python-pyepics [amd64] (kinetic-proposed/none) [3.4.1+ds-1] (no packageset)
[23:53] -queuebot:#ubuntu-release- New: accepted mkdocs-section-index [amd64] (kinetic-proposed) [0.3.4-2]
[23:53] -queuebot:#ubuntu-release- New: accepted python-gflanguages [amd64] (kinetic-proposed) [0.4.0-1]
[23:53] -queuebot:#ubuntu-release- New: accepted python-pyepics [amd64] (kinetic-proposed) [3.4.1+ds-1]
[23:53] -queuebot:#ubuntu-release- New: accepted ytfzf [amd64] (kinetic-proposed) [2.3-2]
[23:53] -queuebot:#ubuntu-release- New: accepted python-aiormq [amd64] (kinetic-proposed) [6.3.4-1]
[23:53] -queuebot:#ubuntu-release- New: accepted python-pypartpicker [amd64] (kinetic-proposed) [1.9.0-1]
[23:53] -queuebot:#ubuntu-release- New: accepted python-mock-open [amd64] (kinetic-proposed) [1.4.0-1]
[23:53] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [arm64] (kinetic-proposed) [0.16.0-5]
[23:53] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [riscv64] (kinetic-proposed) [0.16.0-5]
[23:53] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [armhf] (kinetic-proposed) [0.16.0-5]
[23:53] -queuebot:#ubuntu-release- New: accepted gnunet-gtk [s390x] (kinetic-proposed) [0.16.0-5]