On Sun, May 05, 2024 at 09:53:06PM +0200, Frank Heimes wrote:
> There is a little bit more on "removing packages" here:
> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
> So it's actually a 'must' to have a LP bug for getting a package removed.
The word "must" does not appear in that text. It simply says that, if you
are asking for a package to be removed from Ubuntu, the process to follow is
to file a bug in Launchpad.
However:
On Sun, May 05, 2024 at 03:03:18PM -0700, Erich Eickmeyer wrote:
> I recently learned this too, and that's not entirely accurate. Apparently
> we treat Debian bugs as though they're our own, so if they're filed in
> Debian's bug tracker, then they're fair game. So, if a removal bug is
> filed in Debian, it applies to Ubuntu as well and doesn't require a
> Launchpad bug.
This is broadly correct. More precisely, if there is a release-critical bug
(such as a report of FTBFS) filed against the package in Debian that has
caused / will cause its removal, archive admins will often consider this
adequate documentation of a removal reason. Because wanting bug reports
filed for package removals is largely about having something to point to in
the removal messages:
"Removed from disk on 2024-04-18.
Removal requested on 2024-04-17.
Deleted on 2024-04-17 by Matthias Klose
Debian #1069220, ftbfs, no rdeps"
https://launchpad.net/ubuntu/+source/mrcal/+publishinghistory
In this case, the bug pointed to is in fact one that Matthias himself filed,
so he was documenting the build failure for the Debian maintainer prior to
removing the package.
mrbuild 1.10-1, which would have fixed this build failure, was published to
Debian unstable on 2024-04-05. However, Debian Import Freeze happened on
2024-02-29, so well before, meaning this package was not pulled into Ubuntu;
and mrcal COULD NOT be shipped in Ubuntu if it couldn't be built, because
2.4.1-1 was built for the wrong version of python, and 2.4.1-1build1 was
built with the wrong version of xz-utils present in the host environment.
So while python3.12 wasn't the cause of the build failure and this was a
misdiagnosis (2.4.1-1build1 was a no-change rebuild *for* python 3.12 and it
succeeded), on 2024-04-18 when Matthias removed the package we were 8 days
out from release and doing everything necessary to get to the state of a
Noble releasable on time without risk of compromise due to xz-utils-tainted
binaries.
So although you did reply right away with an explanation of how to fix the
build failure, it's understandable that Matthias did not prioritize bringing
this package back into the noble release pocket and syncing the new mrbuild
necessary to get it to build in the week before release, when many other
things were in flight.
It is also understandable to me that Matthias did not prioritize
communicating in the Debian bug that the issue he was reporting would result
in the package's removal from the upcoming Ubuntu release. It would have
been REASONABLE for Matthias to note this in the bug, but on the other hand
I do not want to commit our archive admins to a policy that we MUST notify
Debian maintainers before their packages are removed from Ubuntu.
However, given the circumstances of the removal for xz-utils:
> Related question: is there any way to get my packages included into some
> sort of noble "updates", or something like that?
As a member of the SRU team my answer is yes, I would consider this. It
would require an actual SRU process for mrbuild, since that package has
other reverse-build-dependencies in noble (libdogleg, mrgingham, vnlog)
which should not be allowed to regress; but provided there is a proper SRU
test case to assert this, I think it's a sensible path towards letting mrcal
back in the archive for 24.04.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
