Hi Harish,
harish chavre, on 2025-05-19:
> I have updated the Debian copyright file to include the origin
> of the test files and embedded the test data as per the debian
> med policy .
Thanks, I have taken a look at your changes to metaphlan tonight
and the integration of debian-test-data looks on good tracks:
import of the component tarball in the pristine-tar branch is
missing, but at this point, I consider this is more of a
complicated implementation detail[1] and I pushed the necessary
changes to the pristine-tar branch to Salsa.
About the d/copyright file, the paragraph you added clarifies
the origin of the dataset. Note however that in its current
form, the d/copyright file is malformed regarding the copyright
format v1.0 normalisation[2]:
1. the "Files: debian-tests-data" stanza needs to appear after
the header paragraph (which starts with the Format stanza),
right now it appears before and this breaks the conformity
to copyright v1.0, thus breaking automated license checking
tools;
2. as documented in copyright v1.0, the Files stanza does not
admit a Source field, but since the information you provided
is essential to understanding where the data comes from, I
think that you should use a Comment field instead (you can
find an example how to use this field in other packages on
Salsa[3]).
Also, you accumulated several changes to the package, but the
file d/changelog does not reflect those changes yet. A quick
and easy way to get a template to document your changes is to
use:
$ gbp dch
This will read your git log and dynamically construct a template
entry for your Debian changelog. Be wary that, since I tagged
the version including your component debian-tests-data as
version 4.0.4+ds, you need to restart the packaging version from
4.0.4+ds-1, otherwise gbp dch will trip on the carpet by
proposing to set version 4.0.4-2 which would be incorrecte with
your component tarball injection. When you finalize your
changelog entries, be notably wary to indicate that your new
autopkgtest "Closes: #1035175", so that the corresponding bug
entry[4] gets automatically closed on package upload to the
archive. Also, please keep the distribution as UNRELEASED while
the package is not deemed fit for upload yet. This allows any
team member to determine that the package includes changes but
is still work in progress.
[1]: for reference, in order to import the missing pristine-tar
branch commit, I tagged the upstream branch 4.0.4+ds to
advertize the inclusion of the component tarball, refreshed
d/changelog with `gbp dch`, exported missing tarball files
with `gbp export-orig` and reimported them using the
command `gbp pristine-tar --component=debian-tests-data
commit ../metaphlan_4.0.4+ds.orig.tar.gz`, roughly.
[2]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
[3]: https://salsa.debian.org/med-team/amide/-/blob/master/debian/copyright?ref_type=heads#L70
[4]: https://bugs.debian.org/1035175
> The only remaining tasks are creating an issue and sending a
> PR to upstream.
During yesterday's Debian Med videoconference meeting, you
mentioned difficulties with proposing the change upstream.
Looking up their Github page[5], they seem to offer the
capability to propose pull requests. Perhaps the "New pull
request" is misleading: I never used it. Typically, to issue a
Github pull request, I first fork the project, then clone it on
my machine, create a branch related to my changes, push it to my
fork, then trigger the pull request from within my fork project
page, on which an interface to offer me to issue a pull request
upstream appears as soon as the push of the branch finishes. I
have not gone through these steps very recently though, and they
could very well have slightly changed, hopefully not too much.
[5]: https://github.com/biobakery/MetaPhlAn/pulls
In hope this helps,
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
`-
Attachment:
signature.asc
Description: PGP signature