Thank you! Those were very helpful answers. I will tidy things accordingly and upload another build shortly.
Regards, Timothy Gaskell On Sat, May 23, 2026 at 1:24 PM David Kalnischkies <[email protected]> wrote: > > (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
