Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1029732: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
500 views
Skip to first unread message
Daniel Kahn Gillmor
Jan 26, 2023, 4:50:04 PM1/26/23
to
Package: src:pypdf2
Severity: wishlist
Control: affects -1 src:pypdf
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
Control: reassign -2 bookletimposer
Control: reassign -3 kraft
Control: reassign -4 krop
Control: reassign -5 odoo-14
Control: reassign -6 orangeassassin
Control: reassign -7 pdfposter
Control: reassign -8 python3-xhtml2pdf
Control: reassign -9 tryton-modules-stock-package-shipping-dpd
Control: reassign -10 diffoscope
Control: reassign -11 diffoscope-minimal
Control: block -1 by -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
Python module has moved to the "pypdf" namespace.
Correspondingly, there is a new python3-pypdf package in debian
unstable.
The packages listed above all currently depend on (or recommend) PyPDF2,
but probably should move to the updated version. When all these bug
reports are closed, we can consider removing the pypdf2 source package
and python3-pypdf2 from debian.
The migration should be relatively straightforward; much of the API
remains the same, just under the "pypdf" module name instead of the
"PyPDF2" module name. Where the API differs, the version of PyPDF2
currently in debian testing/unstable (2.12.1-3) emits a
PendingDeprecationWarning wherever a piece of the API will break.
For example:
foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead.
(PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
as it is an API break from 2.x, and pypdf 3.x supercedes it)
To transition a given package:
- run tests with as complete coverage as possible and note the
PendingDeprecation warnings
- for each warning, patch the upstream line as recommended
- ensure that the tests pass without PendingDeprecationWarnings
- convert from "PyPDF2" to "pypdf" on any import or scoped reference in
python
- update dependency indicators in upstream metadata annotations
(e.g. pyproject.toml, setup.cfg, etc)
- update dependency indicators in debian packaging (from python3-pypdf2
to python3-pypdf).
- run the tests again
Please send any upstream fixes back upstream as well, of course!
Regards,
--dkg
Severity: wishlist
Control: affects -1 src:pypdf
Control: clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
Control: reassign -2 bookletimposer
Control: reassign -3 kraft
Control: reassign -4 krop
Control: reassign -5 odoo-14
Control: reassign -6 orangeassassin
Control: reassign -7 pdfposter
Control: reassign -8 python3-xhtml2pdf
Control: reassign -9 tryton-modules-stock-package-shipping-dpd
Control: reassign -10 diffoscope
Control: reassign -11 diffoscope-minimal
Control: block -1 by -2 -3 -4 -5 -6 -7 -8 -9 -10 -11
As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
Python module has moved to the "pypdf" namespace.
Correspondingly, there is a new python3-pypdf package in debian
unstable.
The packages listed above all currently depend on (or recommend) PyPDF2,
but probably should move to the updated version. When all these bug
reports are closed, we can consider removing the pypdf2 source package
and python3-pypdf2 from debian.
The migration should be relatively straightforward; much of the API
remains the same, just under the "pypdf" module name instead of the
"PyPDF2" module name. Where the API differs, the version of PyPDF2
currently in debian testing/unstable (2.12.1-3) emits a
PendingDeprecationWarning wherever a piece of the API will break.
For example:
foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead.
(PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
as it is an API break from 2.x, and pypdf 3.x supercedes it)
To transition a given package:
- run tests with as complete coverage as possible and note the
PendingDeprecation warnings
- for each warning, patch the upstream line as recommended
- ensure that the tests pass without PendingDeprecationWarnings
- convert from "PyPDF2" to "pypdf" on any import or scoped reference in
python
- update dependency indicators in upstream metadata annotations
(e.g. pyproject.toml, setup.cfg, etc)
- update dependency indicators in debian packaging (from python3-pypdf2
to python3-pypdf).
- run the tests again
Please send any upstream fixes back upstream as well, of course!
Regards,
--dkg
Mathias Behrle
Jan 26, 2023, 6:42:28 PM1/26/23
to
tag -1 pending
API changes were already considered in
https://foss.heptapod.net/tryton/tryton/-/merge_requests/25
https://foss.heptapod.net/tryton/tryton/-/merge_requests/27
and Tryton packages should be fit for any version 1, 2, 3 of pypdf.
We are waiting for backports of the fixes to 6.0. We will anyway include them
for bookworm. As we are maintaining backports for bullseye and buster we will
stick for now with python3-pypdf2, until python3-pypdf will be available as
backport in the targeted Debian releases.
--
Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
API changes were already considered in
https://foss.heptapod.net/tryton/tryton/-/merge_requests/25
https://foss.heptapod.net/tryton/tryton/-/merge_requests/27
and Tryton packages should be fit for any version 1, 2, 3 of pypdf.
We are waiting for backports of the fixes to 6.0. We will anyway include them
for bookworm. As we are maintaining backports for bullseye and buster we will
stick for now with python3-pypdf2, until python3-pypdf will be available as
backport in the targeted Debian releases.
--
Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
Glenn
Mar 2, 2023, 4:50:06 AM3/2/23
to
I think this bug could be more serious than wishlist, as the server
doesnt start, for me at least.
When trying to start it with the same line from its init file, it
concludes with the error; No module named 'PyPDF2.utils'
Note that i have no prior experience with this package, and am not a
python developer, so i could have something wrong.
It should be easy to verify if the package works for someone else.
$ sudo /usr/bin/odoo --config /etc/odoo/odoo.conf --logfile
/var/log/odoo/odoo-server.log
Traceback (most recent call last):
File "/usr/bin/odoo", line 5, in <module>
import odoo
File "/usr/lib/python3/dist-packages/odoo/__init__.py", line 113, in
<module>
from . import modules
File "/usr/lib/python3/dist-packages/odoo/modules/__init__.py", line
8, in <module>
from . import db, graph, loading, migration, module, registry
File "/usr/lib/python3/dist-packages/odoo/modules/graph.py", line 10,
in <module>
import odoo.tools as tools
File "/usr/lib/python3/dist-packages/odoo/tools/__init__.py", line 9,
in <module>
from . import pdf
File "/usr/lib/python3/dist-packages/odoo/tools/pdf.py", line 5, in
<module>
from PyPDF2.utils import b_
ModuleNotFoundError: No module named 'PyPDF2.utils'
doesnt start, for me at least.
When trying to start it with the same line from its init file, it
concludes with the error; No module named 'PyPDF2.utils'
Note that i have no prior experience with this package, and am not a
python developer, so i could have something wrong.
It should be easy to verify if the package works for someone else.
$ sudo /usr/bin/odoo --config /etc/odoo/odoo.conf --logfile
/var/log/odoo/odoo-server.log
Traceback (most recent call last):
File "/usr/bin/odoo", line 5, in <module>
import odoo
File "/usr/lib/python3/dist-packages/odoo/__init__.py", line 113, in
<module>
from . import modules
File "/usr/lib/python3/dist-packages/odoo/modules/__init__.py", line
8, in <module>
from . import db, graph, loading, migration, module, registry
File "/usr/lib/python3/dist-packages/odoo/modules/graph.py", line 10,
in <module>
import odoo.tools as tools
File "/usr/lib/python3/dist-packages/odoo/tools/__init__.py", line 9,
in <module>
from . import pdf
File "/usr/lib/python3/dist-packages/odoo/tools/pdf.py", line 5, in
<module>
from PyPDF2.utils import b_
ModuleNotFoundError: No module named 'PyPDF2.utils'
Sébastien Delafond
Mar 3, 2023, 4:40:05 AM3/3/23
to
On Thu, Mar 02 2023, Glenn wrote:
> I think this bug could be more serious than wishlist, as the server
> doesnt start, for me at least.
>
> When trying to start it with the same line from its init file, it
> concludes with the error; No module named 'PyPDF2.utils'
Hi Glenn,
> I think this bug could be more serious than wishlist, as the server
> doesnt start, for me at least.
>
> When trying to start it with the same line from its init file, it
> concludes with the error; No module named 'PyPDF2.utils'
the bug you're hitting is actually #1032300.
Cheers,
--
Seb
Glenn L. McGrath
Mar 4, 2023, 12:00:05 AM3/4/23
to
thanks Seb;
Bastian Germann
May 13, 2023, 8:10:05 AM5/13/23
to
Upstream switched to pypdf with 0.2.9.
Bastian Germann
May 13, 2023, 8:30:06 AM5/13/23
to
Control: forwarded -1 https://github.com/dragotin/kraft/issues/199
Scott Kitterman
Jan 21, 2024, 12:30:04 PM1/21/24
to
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor <d...@fifthhorseman.net>
wrote:
As we approach the first anniversary for this bug, an update:
I've recently adopted pypdf and pypdf2 into the Debian Python Team in response
to an RFA for both packages. As these are somewhat security sensitive
packages (among my first acts after adopting the packages was to upload
proposed updates for both to address minor security issues in Bookworm in the
next point release - same bug in both), I do not think we should release
pypdf2 in Trixie and have filed an RC bug to that effect.
If you want this package to be in Trixie, you will need to use pypdf instead
of pypdf2.
Scott K
wrote:
I've recently adopted pypdf and pypdf2 into the Debian Python Team in response
to an RFA for both packages. As these are somewhat security sensitive
packages (among my first acts after adopting the packages was to upload
proposed updates for both to address minor security issues in Bookworm in the
next point release - same bug in both), I do not think we should release
pypdf2 in Trixie and have filed an RC bug to that effect.
If you want this package to be in Trixie, you will need to use pypdf instead
of pypdf2.
Scott K
Scott Kitterman
Jan 21, 2024, 12:30:04 PM1/21/24
to
Scott Kitterman
Jan 21, 2024, 12:30:04 PM1/21/24
to
Scott Kitterman
Jan 21, 2024, 12:30:05 PM1/21/24
to
Scott Kitterman
Jan 21, 2024, 1:10:05 PM1/21/24
to
On Fri, 27 Jan 2023 00:26:31 +0100 Mathias Behrle <m...@mailbox.org> wrote:
> tag -1 pending
>
> API changes were already considered in
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/25
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/27
> and Tryton packages should be fit for any version 1, 2, 3 of pypdf.
>
> We are waiting for backports of the fixes to 6.0. We will anyway include them
> for bookworm. As we are maintaining backports for bullseye and buster we
will
> stick for now with python3-pypdf2, until python3-pypdf will be available as
> backport in the targeted Debian releases.
> tag -1 pending
>
> API changes were already considered in
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/25
> https://foss.heptapod.net/tryton/tryton/-/merge_requests/27
> and Tryton packages should be fit for any version 1, 2, 3 of pypdf.
>
> We are waiting for backports of the fixes to 6.0. We will anyway include them
> for bookworm. As we are maintaining backports for bullseye and buster we
will
> stick for now with python3-pypdf2, until python3-pypdf will be available as
> backport in the targeted Debian releases.
Scott Kitterman
Jan 21, 2024, 1:10:05 PM1/21/24
to
> As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2
> Python module has moved to the "pypdf" namespace.
>
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
>
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version. When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
>
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name. Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
>
> For example:
>
> foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be
removed in PyPDF2 3.0.0. Use get_object instead.
>
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
> Python module has moved to the "pypdf" namespace.
>
> Correspondingly, there is a new python3-pypdf package in debian
> unstable.
>
> The packages listed above all currently depend on (or recommend) PyPDF2,
> but probably should move to the updated version. When all these bug
> reports are closed, we can consider removing the pypdf2 source package
> and python3-pypdf2 from debian.
>
> The migration should be relatively straightforward; much of the API
> remains the same, just under the "pypdf" module name instead of the
> "PyPDF2" module name. Where the API differs, the version of PyPDF2
> currently in debian testing/unstable (2.12.1-3) emits a
> PendingDeprecationWarning wherever a piece of the API will break.
>
> For example:
>
> foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be
removed in PyPDF2 3.0.0. Use get_object instead.
>
> (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf
> takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian,
> as it is an API break from 2.x, and pypdf 3.x supercedes it)
As we approach the first anniversary for this bug, an update:
I've recently adopted pypdf and pypdf2 into the Debian Python Team in response
to an RFA for both packages. As these are somewhat security sensitive
packages (among my first acts after adopting the packages was to upload
proposed updates for both to address minor security issues in Bookworm in the
next point release - same bug in both), I do not think we should release
pypdf2 in Trixie and have filed an RC bug to that effect.
If you want this package to be in Trixie, you will need to use pypdf instead
of pypdf2. There is a new upstream release that supports this transition, but
I've recently adopted pypdf and pypdf2 into the Debian Python Team in response
to an RFA for both packages. As these are somewhat security sensitive
packages (among my first acts after adopting the packages was to upload
proposed updates for both to address minor security issues in Bookworm in the
next point release - same bug in both), I do not think we should release
pypdf2 in Trixie and have filed an RC bug to that effect.
If you want this package to be in Trixie, you will need to use pypdf instead
packaging it will be non-trivial.
Scott K
Bastian Germann
Feb 3, 2024, 8:30:04 AM2/3/24
to
Control: block -1 by 1062808
On Sun, 21 Jan 2024 13:03:44 -0500 Scott Kitterman <deb...@kitterman.com> wrote:
> If you want this package to be in Trixie, you will need to use pypdf instead
> of pypdf2. There is a new upstream release that supports this transition, but
> packaging it will be non-trivial.
The pyHanko library is needed, which needs to be packaged.
On Sun, 21 Jan 2024 13:03:44 -0500 Scott Kitterman <deb...@kitterman.com> wrote:
> If you want this package to be in Trixie, you will need to use pypdf instead
> of pypdf2. There is a new upstream release that supports this transition, but
> packaging it will be non-trivial.
0 new messages