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 <emollier@debian.org> : :' : 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
Attachment:
signature.asc
Description: PGP signature