Bug#1028559: pypdf2: replace with pypdf
On Fri 2023-01-13 14:24:12 -0500, Daniel Kahn Gillmor wrote: > 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") This is now done, and i've uploaded 2.12.1 of pypdf2 with baseline packaging fixes, including a cleanup of debian/watch to only look for versions on the 2.x series. (took me three tries -- i had to correct my own mistake for the Vcs-* fields, and to disable two more network tests, sorry for the sloppiness) > 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 working on this now, but... > 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 I've taken the approach for now that we'll just skip the sample-files. Looks like we can use the pytest annotations to do that, as well as skipping the externally-fetched files. (there are some missing upstream annotations, but upstream will hopefully accept those fixes directly: https://github.com/py-pdf/pypdf/pull/1551) I've pushed that work to debian/unstable in the same repository, and i should have an upload for pypdf 3.2.1 in NEW by the time you receive this. Please let me know if you have any concerns with the choices i've made here. --dkg signature.asc Description: PGP signature
Bug#1028559: pypdf2: replace with pypdf
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
Bug#1028559: pypdf2: replace with pypdf
Hi Daniel, On Fri, Jan 13, 2023 at 1:36 AM Daniel Kahn Gillmor wrote: > looks like PyPDF2 2.12.1 is the last version before a major > (backward-incompatible) change in 3.0.0. and PyPDF2 3.0.0 itself > indicates that it is deprecated in favor of pypdf 3.x Indeed, that's the last backward compatible release. > I've prepared some packaging for PyPDF2 2.12.1-0.1 and put it in salsa > at https://salsa.debian.org/debian/pypdf Cool! But I still haven't checked. Hopefully I will check tomorrow morning. > If that's someplace that you'd be up for collaborating, i'd be happy to > help out on it with you there. 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. > We can probably also use the same repository (just different branches) > for packaging pypdf, since i would expect that packaging to just inherit > directly from the pypdf2 packaging, and it can be nice to have the > history in the same location. I'm not sure what would be the best practices for this case, but definitely a continued packaging is preferred from my side. > Let me know if that's something you'd be up for collaboratong on, > László! I'm even open to you taking over the package and making me an uploader. > If you don't like it, i'm also happy to remove the repo from salsa. I > defer to you as the maintainer here. To be honest, I was going to look for an adopter for this package this summer, probably after migrating it to src:pypdf. If you are interested, even contributed already to the project then you are the best candidate. As noted, you can take over immediately while leaving me as an uploader for a while. Best, Laszlo/GCS
Bug#1028559: pypdf2: replace with pypdf
On Thu 2023-01-12 13:18:24 -0500, Daniel Kahn Gillmor wrote: > Debian should probably provide both PyPDF2 and pypdf for the next stable > release, and then drop PyPDF2 afterward. looks like PyPDF2 2.12.1 is the last version before a major (backward-incompatible) change in 3.0.0. and PyPDF2 3.0.0 itself indicates that it is deprecated in favor of pypdf 3.x I've prepared some packaging for PyPDF2 2.12.1-0.1 and put it in salsa at https://salsa.debian.org/debian/pypdf If that's someplace that you'd be up for collaborating, i'd be happy to help out on it with you there. We can probably also use the same repository (just different branches) for packaging pypdf, since i would expect that packaging to just inherit directly from the pypdf2 packaging, and it can be nice to have the history in the same location. Let me know if that's something you'd be up for collaboratong on, László! If you don't like it, i'm also happy to remove the repo from salsa. I defer to you as the maintainer here. All the best, --dkg signature.asc Description: PGP signature
Bug#1028559: pypdf2: replace with pypdf
Package: src:pypdf2 Version: 2.11.2-1 https://github.com/py-pdf/PyPDF2 now redirects to https://github.com/py-pdf/pypdf. In that repository, it's clear that PyPDF2 has been replaced by "pypdf", and version 3.0.0 is the end of the line for PyPDF2. Debian should probably provide both PyPDF2 and pypdf for the next stable release, and then drop PyPDF2 afterward. --dkg signature.asc Description: PGP signature
