Can we collaborate with Debian better?

[Dima Kogan]

Thanks for the replies, everybody. This was helpful.

First off, let me ask about the bug tracker divergence. There are a
number of bugs in Ubuntu launchpad, describing issues that have long
been fixed in Debian. For instance:

  https://bugs.launchpad.net/ubuntu/+source/vlfeat/+bug/1313166

I'm not the Ubuntu maintainer, so I can't close these bugs. Are yall
saying that it's the responsibility of the Ubuntu maintainers to close
these, and they just haven't gotten around to it yet? For such packages
(few rdeps, nothing Ubuntu-specific; tons of these!), we don't want
tighter integration between the two bug trackers?



Now about mrcal. Here's how this looked from my perspective:

- Mar 20. Debian FTBFS bug was filed:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398

  This was a Debian bug. Unrelated to the Ubuntu release

- Mar 21. mrbuild 1.9-1 uploaded to fix this bug; this fix had a small
  problem, so ...

- Mar 26. mrbuild 1.9-2 uploaded to fix that problem as well

- Apr 18. Mattias files

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069220

  Sent from his Debian address. He's talking about a build fault with
  Python 3.12. No mention of Ubuntu at all

- Apr 18. I confirm that it builds fine with Python 3.12; Matthias
  points at the build log on ubuntu's server. He doesn't say that this
  is in any way related to the 24.04 release, and this is the last I
  hear from him.

Given the very late date, and the fact that I haven't seen any Ubuntu
bugs, I assume that mrcal is in 24.04.


We can see how this looks like a gap in the process, right? Yes,
Matthias could have done a better job in communicating, but even so,
doing the rebuild and filing a FTBFS bug on Apr 18 for the 24.04 release
sounds shockingly late. Not to mention the fact that it wasn't presented
at all as related to the 24.04 release, and causing the deletion of the
package. Debian seems to do this much better.


>   "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.

I guess he did that, but I never saw any of it.



> 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

As noted above, mrbuild 1.9-2, published on Mar 26 fixed this problem
(and 1.9-1, published on Mar 21 would probably have fixed it too). These
both made the deadline.


> 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.

Yeah. The timing of the xz disclosure was really unfortunate. It sounds
like the extra work should have pushed back the Ubuntu release. Even if
the communication was clear here, the time crunch made it impossible to
actually fix the problem.


> 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.

I think that would be a very good policy, actually. Do you think
somebody else should be notified about their packages being removed?
Who? Was anybody at all notified in this case?


>> 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.

OK. I'll look at the process now.

Thank you, all.