Re: [metaphlan] Added autopkgtes t and distutils patch — please review

Étienne Mollier <[email protected]> Mon, 2 Jun 2025 22:53:33 +0200
Newsgroups	gmane.linux.debian.devel.medical
Message-ID	<[email protected]>
Hi Harish,

harish chavre, on 2025-05-28:
> Thank you for your feedback and guidance on the metaphlan
> packaging work. I have made note of the changes you made,
> including the corrections to the copyright file, the
> improvements to the changelog, and the lintian checks. I
> appreciate your help in improving these areas and explaining
> the reasons behind the changes.
> 
> I wanted to ask, after writing tests for a package, should we
> run dpkg-buildpackage and lintian to check the changes?

Running dpkg-buildpackage (or better: pbuilder or sbuild,
isolating your build environment in chroot, which then run
dpkg-buildpackage under the hood) will produce binary packages:
the .debs.  They are a prerequisite to be able to run your
autopkgtest in actual autopkgtest conditions.  It is worth
noting that if .debs are missing, then barring the availability
of build tools, autopkgtest may be able to trigger the build
steps prior to running the tests.

Running lintian systematically after each package construction
may surprise you with various issues that it might flag.
Several linting items cover autopkgtest, so I would warmly
recommend it.  For what it's worth, I almost never manually
invoke lintian by hand.  Instead, I have configured sbuild to
automatically call lintian after packages construction with the
following extract from my ~/.config/sbuild/config.pl:

	# Lintian configuration
	$run_lintian = 1;
	$lintian = 'lintian';
	$lintian_opts = [
		'--display-info',
		'--pedantic',
		'--tag-display-limit=0'
	];

This is mostly equivalent to always run the following command
after each build:

	$ lintian --display-info --pedantic --tag-display-limit=0

There are many more options available, I also systematically run
autopkgtest or the default piuparts upgrade scenario for
instance.

> As we discussed, I have opened a pull request upstream for the patch:
> https://github.com/biobakery/MetaPhlAn/pull/232

Perfect, thank you!  I see upstream closed the request after
indicating that they resolved the issue independently.  This is
good, now we're sure that we can safely drop the patch once we
can upgrade the metaphlan package to version 4.2.0 or newer.
Remember, we're still in Debian 13 freeze period so newer
upstream version will have to wait for the beginning of Debian
14 development cycle (or be uploaded to experimental) to avoid
interferring with the release process.

> I have also updated the patch file to include the Forwarded field:
> https://salsa.debian.org/med-team/metaphlan/-/commit/b6ddbbfe558e3993559584b7ba496eaacfdccaba
> 
> I will also keep an eye on the metaphlan package tracker to monitor
> the piuparts issue.

As far as I can witness, the piuparts issue stemming from
metaphlan2-data is already flagged as not being a regression.
Thus, if I parse excuses for metaphlan[1] properly, then this is
not going to be a blocker for the migration.  There is just 14
days to go before migration, provided that no serious issues are
identified by then.  Things are looking good!

[1]: https://qa.debian.org/excuses.php?package=metaphlan

> Thank you again for your support.

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier <[email protected]>
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/2, please excuse my verbosity
   `-    on air: Steven Wilson - The Overview
signature.asc (application/pgp-signature, 833 B)