Hi Thomas, Thank you for taking a look at this. Thomas Koch <thomas@koch.ro> writes: > Thank you Nicholas for the reminder and sorry for keeping you waiting. > > Unfortunately, I don't believe the package would pass the NEW queue in its current state. You did remove the apple.jpg file but you added a new apple.png file that is not mentioned in debian/copyright. > > I know how annoying these copyright issues are! > Which package are you looking at? I have insufficient permissions to rewrite history or delete the org-drill repo Emacsen Team project, thus insufficient permissions to clean the git repo. Going from the provided source package: https://mentors.debian.net/debian/pool/main/o/org-drill/org-drill_2.7.0+dfsg-1.dsc Copyright and source of apple.png is documented, and the license is CC0, which does not require specific documentation or attribution in copyright. CC0 Allows implicit relicensing, thus the debian/* rule in copyright applies GPL-3+ to debian/patches/0001-add-a-more-freely-licenced-image-of-an-apple.patch So the package is license-compliant. When upstream merges the PR the new apple.png will fall under the upstream "Files: *" GPL-3+ rule. At that time the package will also be license-compliant. I admit that documentation of this file's CC0 would be nice to have, to highlight the fact that one is free to do more with that file than the GPL-3+ permits, but this is not a license-compliance issue. > I think the easiest would be to just remove the file and its references without any replacement. You might then help upstream with a pull request to provide a dfsg free picture for the next version. > I filed such a PR the 28th of July. Please see the Forwarded header of that patch. > The following remarks are maybe not strictly required: > > Even if you add a new file, you should not use debian/patches to add it but just include it in the debian tarball. I actually never had to do this myself, so I have no experience with adding a binary file. > I chose to use a cherry picked patch from the PR I filed because then everything is documented in two places (the patch and the PR), and so that the patch can be automatically dropped in a future release (prioritises human time). I'm familiar with the alternative, which would additionally require additional documentation in README.source. > Please also add a version number to dfsg suffix like dfsg1 or dfsg-1. It happened to me before that I needed multiple uploads to the new queue before I found all non dfsg-unfree files: https://tracker.debian.org/pkg/nix > > Especially the version number of the orig tarball is different from the changelog. I wonder how this worked in the first place. > Ah, you're looking at the non-dfsg git repo... > If you want to reflect the dfsg cleaning work also in your git packaging branch, I started a knowledge base article here: > https://wiki.debian.org/kb/git_packaging_dfsg_clean_branch > An example of this: https://salsa.debian.org/debian/nix > > My nix package also contains a debian/watch example to produce a dfsg clean orig tarball. > > The git packaging repo does not contain the latest commits apparently, there is no debian/patches folder: > https://salsa.debian.org/emacsen-team/org-drill/-/tree/master/debian > Yes, that project should be deleted. The plan is to use a gbp-style repo that leverages uscan's Files-Excluded. > Thank you very much for your contribution and especially for your patience! You're welcome! Nicholas
Attachment:
signature.asc
Description: PGP signature