[Debian-med-packaging] Bug#1025370: ntcard: ftbfs with nthash 2.3.0

[Nilesh Patra]

Hi Andreas,

On 12 December 2022 12:17:37 am IST, Andreas Tille <tille at debian.org> wrote:
>Am Fri, Dec 09, 2022 at 03:12:35PM +0530 schrieb Nilesh Patra:
>> > I'm considering reverting the version bump (shame on me I did not tested
>> > ntcard before uploading).
>> 
>> I'm personally quite annoyed with this, I suppose your uploads, or rather
>> team uploads have broken quite a few packages in the past days. It was
>> first t-coffee update that broke biopython, and then mcl which broke pplacer
>> and now this.
>
>I think this "common feature to break something" is quite different in
>the single cases.  It was pretty hard to estimate the effect of the
>t-coffee case. 

I tend to differ. That new update was segfaulting for a number of months until Hamid and you had a discussion to build it with no optimisations. When seeing signs of a software getting _kind of_ unstable, extra care should be taken, atleast given the fact that we are close to release.

There's a tool called reverse-depends that's a part of the ubuntu-dev-tools package. Simply running "$ reverse-depends t-coffee" and "$ reverse-depends t-coffee -b" would give an idea of the impact.

>A lot of effort was done to fix its autopkgtest in
>advance.  I simply assumed that passing its test is sufficient for an
>upload.

Which we have seen is not the case.
Again, this is from the perspective of us being near freeze. Such breakages are unhealthy at this point in time.

Autopkgtests are a good indicator that the current package is working for a few cases. But it can never almost give an indication about updating current software will break something else.

>While the breaking upload of MCL was not intended I would even insist
>that there is a point in the breaking upload.  MCL is a popular program
>which we should deliver in its recent version.  The support and
>cooperation by upstream rectified this.  The fact that some packages
>like pplacer depend from a patch by third party which is not maintained
>by its author since 10 years might mean that we will possibly loose
>these packages which is a shame but may be the fate of those packages.

Agreed. But here's the question: was this really the right time to do a broken upload? Was it really that necessary?

Couldn't we have taken small steps and waited until the next debian release (Trixie) freeze to see if we got the ocaml support?

>However, there is some hope that MCL upstream might find a solution.

For sure. But I'm not sure if this is going to happen before the soft freeze ends.

>> The mcl update also most likely needs to be rolled back. The ocaml changes are
>> not compatible with the new version of mcl, and someone needs to update pplacer
>> too to make sure that it is compatible with newer mcl.
>
>There is some hope for an updated OCaml patch[1], thought.  If the OCaml
>patch can be updated that would be great.  If not I see no chance to
>keep pplacer in the long term.
> 
>> I want to make it a mandatory policy: do NOT upload packages randomly. Run ratt
>> or run https://salsa.debian.org/ruby-team/meta atleast given that we are close to
>> release, random updates of not so important packages is un-necessarily breaking a
>> lot of things.
>
>I confirm that running ratt or meta of Ruby team would be a good idea in
>some cases.  However, I disagree to make it mandatory in policy.

I request the policy to be made mandatory during freeze time, i.e. starting from "soft-freeze - 2 months" till "release"

>Picking three cases of uploads from the number of all uploads is not a
>very strong argument.  We have *lots* of uploads pending for the next
>couple of weeks to meet the freeze.  Delaying these just because three
>broken uploads (one is fixed meanwhile and there is a clear way to fiy
>the second for ntcard by reverting the vesion bump of nthash if upstream
>does not respond timely) is not a good strategy in my eyes.

There are also library packages that are being updated. And I completely and absolutely disagree that updating them randomly without checking reverse deps does not cause any harm.

Not all upstreams follow semantic versioning properly and then are un-noticed API breakages which we have seen in nthash already for instance. I don't think doing more of these unchecked updates is benefitting anyone using debian at all.

>[1] https://alioth-lists.debian.net/pipermail/debian-med-packaging/2022-December/105589.html

--
Best,
Nilesh