hi László-- Sounds like we're roughly on the same page on this.
On Fri 2023-01-13 18:51:14 +0100, László Böszörményi (GCS) wrote: > I'm not sure if we know each other, but I have the knowledge that you > are a nice guy. Sure, I'm open to collaboration and Salsa is a good > place to start. Works for me. I'll change the repository description to remove the term "prospective" (it's currently "proposed packaging history for pypdf2 and its successor, pypdf") > I'm not sure what would be the best practices for this case, but > definitely a continued packaging is preferred from my side. I'll take a crack at that. I'll probably do it with two separate branches in a single repository, so we can just have one place where the work on the two packages is happening. > I'm even open to you taking over the package and making me an uploader. I'd rather not do that -- i'm happy to be an additional uploader for now, but i don't want to be the only one responsible, as i'm kind of under water on other work too (debian and non-debian work). Maybe we can collaborate to find someone else who is interested and willing to take point on it. At the moment, i suspect the biggest challenge for getting a pypdf package into debian is related to #1028570: the licensing for the sample documents is not DFSG-free, which means that the ftp team is likely to reject any package that comes through NEW (even though it has slipped through in the current archive). I've opened https://github.com/py-pdf/sample-files/issues/18 to ask upstream about relicensing, but if that doesn't work we probably need to strategize about other approaches for the renamed package. One approach would be to simply upload the package without any tests. This would be disappointing. Another approach could be to upload the pypdf-sample-files as a separate package, directly to non-free under the current BY-NC-ND license. Then, the packaging could run tests conditionally on whether that package was installed. This wouldn't help any of the CI or buildd networks, but it would at least give maintainers a way to run the tests manually before upload, and auditors a way to confirm the same in a repeatable fashion. What do you think makes sense? --dkg
signature.asc
Description: PGP signature
