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

[Andreas Tille]

Dear Nilesh,

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.  A lot of effort was done to fix its autopkgtest in
advance.  I simply assumed that passing its test is sufficient for an
upload.

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.
However, there is some hope that MCL upstream might find a solution.
 
> 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.
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.  I perfectly
agree that running autopkgtest could be made mandatory in policy,
thought.

Kind regards
   Andreas.

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

-- 
http://fam-tille.de