Can we collaborate with Debian better?

[Frank Heimes]

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.

BR, Frank


On Sun, May 5, 2024 at 7:32 PM Simon Quigley <simon at tsimonq2.net> wrote:

> Hi Dima,
>
> As a Debian Developer myself, I understand your concerns. Processes in
> this respect could be slightly better, but it also comes down to the
> differences between the two distributions. More detailed responses inline.
>
> On 5/2/24 10:56 AM, Dima Kogan wrote:
> > Hello.
> >
> > I'm a Debian developer, and contribute to Ubuntu only indirectly: by my
> > contributions to Debian being automatically pulled into Ubuntu. But
> > since Ubuntu has more users than Debian, most of MY users use the Ubuntu
> > packages. So I'd like to talk about improving the links between the two
> > projects. In particular:
>
> Ubuntu and Debian package maintenance responsibilities are slightly
> different; in Ubuntu, members of the Core Developers team are
> collectively responsible for the packages in the Main and Restricted
> components, and Masters of the Universe are collectively responsible for
> packages in the Universe and Multiverse. The ratio of "maintainers
> holding responsibility":"packages to be maintained" is much lower in
> Ubuntu than it is in Debian.
>
> Once a package has landed in the Ubuntu archive, Ubuntu Developers now
> collectively hold responsibility for that package. We ease much of this
> work by autosyncing packages without deltas to Ubuntu in the first half
> of each cycle; that being said, we sometimes drive major transitions in
> Ubuntu before Debian, to align with our release cycle.
>
> Many Ubuntu Developers (myself included) are trained to give as much
> back to Debian as we possibly can. If we fix a package that both exists
> in Debian and has the same bug, we are encouraged to send that fix
> upstream to the Debian bug tracker (or upstream itself, or both) to
> ensure less friction when we have to merge new changes from Debian. Some
> teams within Ubuntu do not follow this process at all, but I would
> consider them the exception rather than the rule.
>
> The Debian maintainers of a package are not responsible for how their
> packages are used in Ubuntu, that's Ubuntu's responsibility. That being
> said, it is best practice to collaborate as much as we reasonably can,
> with the time we are given.
>
> > 1. Debian and Ubuntu both have separate bug trackers. But for most
> >     Ubuntu packages, there's no "Ubuntu" maintainer: there's just the
> >     indirect one from Debian. In this case (which is most packages), it's
> >     unhelpful for the Ubuntu bug tracker to exist as a separate thing. If
> >     it must exist as a separate thing, those bugs should be forwarded
> >     automatically to the Debian bug tracker. And updates (including
> >     status updates) should be ingested back into the Ubuntu tracker. For
> >     my packages I do try to manually look at the Ubuntu bug reports, but
> >     I have no rights to close those bugs on launchpad. Probably I can
> >     sign up somewhere, but as the DEBIAN developer, I shouldn't need to
> >     do that.
>
> I disagree with this approach. Ubuntu and Debian are not ABI-compatible;
> Ubuntu has a slightly different toolchain than Debian, and there are
> core differences in e.g. dpkg. Not all Ubuntu bugs are Debian bugs, not
> all Ubuntu teams want their bugs sent up to Debian, and many Debian
> Maintainers don't care about Ubuntu. This is a reality of maintaining
> separate distributions.
>
> In some common cases, yes this seems reasonable, we should forward bugs
> to Debian. That being said, the first step is making sure the bug
> actually exists in the Debian-built version of the package, which is not
> always the case.
>
> Generally, I do think we can be better about triaging our bugs and
> sending what we can up to Debian. That being said, I disagree with the
> solution of completely automating it.
>
> > 2. As I just discovered, when Ubuntu rebuilds the archive for a release,
> >     packages that FTBFS are silently dropped. There's no bug report on
> >     either of the two bug trackers. I'm upstream for a project that has
> >     been excluded from 24.04 because of this gap in the process. There
> >     really should be a bug report filed, so that the problem can be fixed
> >     before the release (what Debian does for their releases). And this
> >     should be filed on the Debian bug tracker, if that's where the
> >     maintenance happens.
>
> This entirely falls on the Ubuntu Archive Administrators. To my
> understanding as an Ubuntu Developer, if we want a package removed, it
> is best practice to either have a Debian removal bug or an Ubuntu
> removal bug explaining the rationale. Whether this is enforced is up to
> the Archive Administrator doing the removal, since the only known public
> documentation says nothing about filing bugs:
> https://wiki.ubuntu.com/ArchiveAdministration#Removals
>
> To say that packages that FTBFS are indiscriminately removed during
> transitions ignores the fact that usually, we do have to file a bug if
> we want an AA to remove a package.
>
> > I don't know how hard the above is, but the current situation isn't
> > great for either of us.
> >
> > Related question: is there any way to get my packages included into some
> > sort of noble "updates", or something like that?
> >
> > I'm looking at the "mrcal" source package that had an ininteresting
> > FTBFS bug due to some dependency changing its interface. There was a
> > Debian bug report filed and quickly fixed, but this happened too late
> > for noble:
> >
> >    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398
> >
> > The fix is to update the "mrbuild" package to at least 1.9. Is it
> > possible to get an updated "mrbuild" and "mrcal" into 24.04?
> >
> > If I'm misinterpreting what's going on, please let me know. Right now I
> > see this:
> >
> >    dima at shorty:~$ rmadison -u ubuntu mrbuild | grep noble
> >     mrbuild | 1.8-1 | noble/universe    | source, all
> >
> >    dima at shorty:~$ rmadison -u ubuntu libmrcal-dev | grep noble
> >     libmrcal-dev | 2.4.1-1build1 | noble-proposed/universe    | arm64,
> ppc64el, riscv64
> >
> > The latest mrcal IS 2.4.1, but here it's in "noble-proposed" and not for
> > amd64 for some reason.
>
> I would highly suggest filing a bug against the package in Launchpad
> following the Stable Release Update procedure:
> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
>
> If you can articulate your case and the rationale for the update well,
> it is unlikely that it will be rejected.
>
> Best regards,
> --
> Simon Quigley
> simon at tsimonq2.net
> @tsimonq2:ubuntu.com on Matrix
> tsimonq2 on LiberaChat and OFTC
> 5C7A BEA2 0F86 3045 9CC8
> C8B5 E27F 2CF8 458C 2FA4
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20240505/69b19be2/attachment-0001.html>