(Disclaimer: I haven't looked at the package; this is not a review) Am Tue, May 19, 2026 at 04:55:14AM -0500, schrieb Timothy Gaskell: > 1. Since the last release that Debian packaged, the upstream developer > has accepted patches from several github users without publicly-known > email addresses. Is there a preferred way for the copyright file to > acknowledge their contribution?
You don't have to invent, assemble or complete copyright statements. Just take what upstream has declared in terms of names, mails and years, if any for all and/or any of them (Missing or incorrect statements are an upstream problem they have to correct – or not: Not everyone even wants to appear in copyright statements. If a patch isn't adding it, it usually means they don't want/care). As I was curious what you might mean: The 'Comment' in the current d/copyright file as seen on salsa is not needed (and a misuse of the field) – remove it rather than trying to extend it by digging through version control history. It might very well be wrong to declare a patch author to have copyright for a patch while they wrote it on company time, for example, and you can't know that. > 2. The existing control file references a git repository on > salsa.debian.org. Do I need to wait until my account creation there is > approved to proceed, or will the sponsor also update salsa? Your sponsor can push to the debian/ namespace … manually. This is not automatic, so you might want to remind them. That said, you can adopt a package (look in the developer reference for a description of how to do this with ITA bug wangling and so on) and as the maintainer a DD can add you to that repository so that you might push your changes yourself. Note that there is also no automation from a push to salsa to the archive (dgit, if you have heard of it, is an entirely separate beast in this regard). > Does it > complicate things any that upstream pekwm no longer uses git as they > have switched to fossil? Not in particular. For better or worse Debian uploads consist of a tarball that may or may not be provided by upstream in some form. That grants Debian a certain independence from the (not) usage of version control systems in both upstream and downstream directions. > 3. The first patch in the quilting series was still applicable in > function but needed a near-total rewrite to fit current upstream. Is > listing the original patch date and author but also adding to the > description and inserting a Last-Update date the correct way to handle > this? It's a possible way; similar to a 'git rebase', I suppose, in that it keeps the original author and date while potentially changing everything (or nothing). What you could also do is write a 'new' patch with you as author and a current date noting that it was inspired/derived by an other patch. That depends a bit on your (and upstream's) preferred style. If it's really near-total I would personally go with the later as it feels more honest: All the bugs I have certainly added in that rewrite are mine, not the fault of the perfectly written older patch by that other author. Your mileage may vary, of course. Best regards David Kalnischkies
signature.asc
Description: PGP signature
