Test suite needs script built after dh_auto_test is run
Hello, I'm packaging a Python application, ocrmypdf [1], that has a test suite run by py.test. Most of the tests fail because they try to call the /usr/bin/ocrmypdf script. This script doesn't exist until after debhelper has run setup.py, which generates it using its "entry points script" feature. And this comes after dh_auto_test. The only solution I've come up with is producing my own entry point script and putting it into $PATH for the test suite to use. But that rather defeats the purpose of testing the actual package's contents. What would be the most elegant way to handle this? Can anyone point me to a package that had a similar issue with the test suite needing a file not yet generated? Thanks. [1] https://github.com/jbarlow83/OCRmyPDF -- Sean Whitton signature.asc Description: PGP signature
Re: Test suite needs script built after dh_auto_test is run
Dear Barry, On Fri, Feb 05, 2016 at 02:17:51PM -0500, Barry Warsaw wrote: > If ocrmypdf supports Python's -m option, you could consider patching the test > suite to run `python -m ocrmydf` instead. Season to taste for python3 and or > both if you're using pybuild. > > [snip] > > As a last resort, I have disabled the build-time tests (all or only the ones > that require the /usr/bin) and then arranged for the full test suite to run > via autopkgtest/DEP-8. It's not ideal because Debian currently doesn't gate > on DEP-8 passing, but Ubuntu does and at least I'll see failures there. Thank you for your input: that worked, aside from one test that wanted to pass Unicode on the command line which the `python -m ocrmypdf` method doesn't like. I commented that one out and have got the full test suite running with autopkgtest. I've submitted a request to join the Python Apps Packaging Team so that I can request sponsorship for my package. -- Sean Whitton signature.asc Description: PGP signature
Bug#815027: RFS: ocrmypdf/4.0.1-1 [ITP] -- add an OCR text layer to PDF files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package ocrmypdf. OCRmyPDF generates a searchable PDF/A file from a regular PDF containing only images. It uses the Tesseract OCR engine and so supports the 39 languages that Tesseract does. It is a convenient wrapper around Tesseract, unpaper, qpdf and other tools for processing scans, obviating the need for a user to construct a haphazard shell script connecting these tools together. There are many such scripts floating around online, but ocrmypdf is much more carefully put together. * Package name: ocrmypdf Version : 4.0.1-1 Upstream Author : James R. Barlow * URL : https://github.com/jbarlow83/OCRmyPDF * License : MIT Section : graphics Download with dget: dget -x http://mentors.debian.net/debian/pool/main/o/ocrmypdf/ocrmypdf_4.0.1-1.dsc Or build it with gbp: git clone https://git.spwhitton.name/ocrmypdf git checkout pristine-tar # to create the branch locally, so gbp uses it git checkout debian/4.0.1-1 git verify-tag debian/4.0.1-1 # if you have my key gbp buildpackage Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]
Hello Pierre, On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote: > Le lundi 26 décembre 2016 à 20:38:42+0000, Sean Whitton a écrit : > > control: tag -1 +moreinfo > > > > Dear Pierre, > > > > Thank you for your interest in adopting this package. > > > > Unfortunately, your work has not been properly integrated with what is > > already in Debian: > > > > - you marked version 0.4.74-4 as released but it was never uploaded > > True. Yet, it is in the team repo. The changelog tracks the Debian archive. You should merge the existing 0.4.74-4 changelog entry with your changes. > > - you haven't included the NMU 0.4.74-3.1 > > Actually, it is included. The commit is just hidden in the history of the > team git repository for an unknown reason. See commit > 53434cf161a64ab9ac1578fec3613cce20ed451b and merge commit > 6fd4d560cf1f1f25a581a28a3c0a93ebd3159386. I added manually the changelog > that has been truncated in the merge. Sorry, my fault, thanks for fixing up the changelog in your upload. > > - your work is not pushed to the team git repository > > I have no permission to push. Have you asked to join the team? -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#848416: RFS: pyvtk/0.5.18-1 [ITA]
Hello Pierre, On Thu, Dec 29, 2016 at 09:20:02PM +0100, Pierre-Elliott Bécue wrote: > Le mardi 27 décembre 2016 à 22:11:38+0000, Sean Whitton a écrit : > > Hello Pierre, > > > > On Tue, Dec 27, 2016 at 06:04:58PM +0100, Pierre-Elliott Bécue wrote: > > > Le lundi 26 décembre 2016 à 20:38:42+, Sean Whitton a écrit : > > > > control: tag -1 +moreinfo > > > > > > > > Dear Pierre, > > > > > > > > Thank you for your interest in adopting this package. > > > > > > > > Unfortunately, your work has not been properly integrated with what is > > > > already in Debian: > > > > > > > > - you marked version 0.4.74-4 as released but it was never uploaded > > > > > > True. Yet, it is in the team repo. > > > > The changelog tracks the Debian archive. You should merge the existing > > 0.4.74-4 changelog entry with your changes. > > 0.4.74-4 is not in the debian archive, only in the team repo. How should I > merge exactly? This is roughly what I have in mind: pyvtk (0.5.18-1) unstable; urgency=low [ Jakub Wilk ] * Use canonical URIs for Vcs-* fields. * Remove obsolete Conflicts/Replaces with python2.3-pyvtk and python2.4-pyvtk. [ Stefano Rivera ] * Convert inline patch to 3.0 (quilt) to ease git-dpm migration. [ Ondřej Nový ] * Fixed VCS URL (https) [ Pierre-Elliott Bécue ] * New maintainer (Closes: #795017). * New upstream release * Uses pybuild for building the package. * Cleaning debian/* -- Pierre-Elliott Bécue Sat, 17 Dec 2016 00:24:15 +0200 > > > > - your work is not pushed to the team git repository > > > > > > I have no permission to push. > > > > Have you asked to join the team? > > I don't feel that I've done enough to get permissions, maybe my > interpretation is wrong. I see what you mean, and every Debian team is different. However, chances are they would prefer that you join the team and push your git history there, as then other team members can more easily build upon your work. So please submit a request, explaining that you want to work on pyvtk. If they say no, it's not a big deal! -- Sean Whitton signature.asc Description: PGP signature
Request to join DPMT
Hello pythoners, I'd like to join the team so that I can put my new package, pytest-helpers-namespace (#867375), under DPMT team maintenance. I have read, and I accept, <https://python-modules.alioth.debian.org/policy.html>. My alioth username is spwhitton. Thanks! -- Sean Whitton signature.asc Description: PGP signature
Bug#903624: ITP: python-xmp-toolkit -- python library to read and write XMP metadata
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: python-xmp-toolkit Version : 2.0.1 Upstream Author : Lars Holm Nielsen, John Evans, Federico Caboni, Amit Kapadia and Steve Rubin * URL : https://github.com/python-xmp-toolkit/python-xmp-toolkit * License : BSD-3-clause Programming Lang: Python Description : python library to read and write XMP metadata I am packaging this as a new dependency of OCRmyPDF's version 7.0.0 release. I intend to maintain it under the Debian Python Modules Team umbrella. -- Sean Whitton signature.asc Description: PGP signature
Bug#903625: ITP: pikepdf -- python library for reading and writing PDFs, powered by qpdf
Package: wnpp Severity: wishlist Owner: Sean Whitton * Package name: pikepdf Version : 0.2.2 Upstream Author : James R. Barlow * URL : https://github.com/pikepdf/pikepdf * License : MPL-2.0 Programming Lang: Python & C++ Description : python library for reading and writing PDFs, powered by qpdf This is a new dependency of the latest upstream release of OCRmyPDF. I intend to maintain it under the Debian Python Modules Team umbrella. After discussion with upstream, I plan to upload to experimental, because the library's API is not yet stable. Upstream expects it to have stabilised in time to upload to unstable in time for the buster freeze. -- Sean Whitton signature.asc Description: PGP signature
git-dpm required?
[please CC me] Hello, The team policy says that git-dpm is mandatory but someone here at DebConf (sorry, can't remember who) told me that since the move to salsa, this has been relaxed to the simple requirement that the tree be buildable with `gbp buildpackage`. Before I add a new python library to Debian, pleast let me know whether I have to use git-dpm. Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: git-dpm required?
Hello, On Mon 30 Jul 2018 at 09:54PM -0400, Sergio Durigan Junior wrote: > This is my understanding as well: git-dpm is not mandatory anymore, and > gbp is the preferred tool. I've been packaging all of my Python modules > using gbp for a while. Do I have to use the full suite of gbp tools (e.g. gbp-pq) or is it enough that `gbp buildpackage` will work? -- Sean Whitton signature.asc Description: PGP signature
Re: git-dpm required?
Hello, On Tue 31 Jul 2018 at 12:00AM -0400, Sergio Durigan Junior wrote: > On Monday, July 30 2018, Sean Whitton wrote: > >> Hello, >> >> On Mon 30 Jul 2018 at 09:54PM -0400, Sergio Durigan Junior wrote: >> >>> This is my understanding as well: git-dpm is not mandatory anymore, and >>> gbp is the preferred tool. I've been packaging all of my Python modules >>> using gbp for a while. >> >> Do I have to use the full suite of gbp tools (e.g. gbp-pq) or is it >> enough that `gbp buildpackage` will work? > > You don't have to use the full suite if you don't like. The important > thing is to have the repository in the correct format > (debian/upstream/pristine-tar branches [or something else, as long as > properly documented in d/gbp.conf], tags, etc.), so that other people > can use gbp without problems. Thank you. Just to note that gbp will work with patches-applied too, but I won't do that. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017487: RFP: python-sphinx-design -- Sphinx extension for designing view size-responsive web components
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python-sphinx-design Version : 0.2.0 Upstream Author : Chris Sewell * URL : https://github.com/executablebooks/sphinx-design * License : Expat Programming Lang: Python Description : Sphinx extension for designing view size-responsive web components The latest upstream version of pikepdf, primarily maintained by me, requires this library for its docs build. I'd therefore be very grateful if someone on the Python team would package it. -- Sean Whitton signature.asc Description: PGP signature
Bug#1017873: RFA: pikepdf
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org, barlow@gmail.com Control: affects -1 src:pikepdf I request an adoptor for the pikepdf package. It would be better if someone with more knowledge of either or both Python and PDFs were to maintain it. I have also filed an RFA for ocrmypdf, the most important reverse dependency. The package description is: pikepdf is a Python library to read and write PDFs with QPDF. Features include: . * Editing, manipulation and transformation of existing PDFs * Based on the mature, proven QPDF C++ library * Works with encrypted PDFs * Supports all PDF compression filters * Can create "fast web view" (linearized) PDFs * Creates standards compliant PDFs that pass validation in other tools * Automatically repairs damaged PDFs, just like QPDF * Implements more of the PDF specification than existing Python PDF tools * IPython notebook and Jupyter integration -- Sean Whitton signature.asc Description: PGP signature
Bug#1017872: RFA: ocrmypdf -- add an OCR text layer to PDF files
Package: wnpp Severity: normal X-Debbugs-Cc: debian-python@lists.debian.org, barlow@gmail.com Control: affects -1 src:ocrmypdf I request an adopter for the ocrmypdf package. I don't use it as often as I did (hardly ever the past couple of years), and anyway it would be better for a Python programmer to maintain it. The package description is: OCRmyPDF generates a searchable PDF/A file from a regular PDF containing only images, allowing it to be searched. . It uses the Tesseract OCR engine and so supports all the languages that Tesseract does. . Some other main features: . * Places OCR text accurately below the image to ease copy / paste * Keeps the exact resolution of the original embedded images * When possible, inserts OCR information as a lossless operation without rendering vector information * Keeps file size about the same * If requested deskews and/or cleans the image before performing OCR * Validates input and output files * Provides debug mode to enable easy verification of the OCR results * Processes pages in parallel when more than one CPU core is available * Battle-tested on thousands of PDFs, a test suite and continuous integration. -- Sean Whitton signature.asc Description: PGP signature
Re: Bug#1018689: override: python3:python/standard
control: tag -1 + moreinfo On Sun 28 Aug 2022 at 10:33PM -05, Daniel Lewart wrote: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: override > X-Debbugs-Cc: debian-b...@lists.debian.org, pyth...@packages.debian.org > > Debian FTP Master(s) and Matthias, > > Currently, python3 is Priority: optional. > > The following Buster packages have Priority: standard: > * python > * python-minimal > * python2.7 > * python3-reportbug > > Now the following Priority:standard packages depend on python3 > (directly or indirectly): > * apt-listchanges > * python3-reportbug > * reportbug > > Therefore, I think that python3 should change from: > Priority: optional > to: > Priority: standard I don't think these dependency relationships bear directly on the issue? Anyway, we need to hear from the package maintainers about this before considering the change. -- Sean Whitton
Re: python-werkzeug CVEs
Hello, On Fri 29 Nov 2024 at 08:38am +01, Carsten Schoenert wrote: > Hi Sean, > > Am 29.11.24 um 04:22 schrieb Sean Whitton: >> Hello, >> There are three DoS CVEs for python-werkzeug in stable. >> I intend to fix these as part of the Debian LTS team, sponsored by >> Freexian. I would like also to fix them in bookworm, because that will >> become an LTS release eventually. Would you like me to go ahead and >> submit a stable update request, or are you already working on something? > > no, I haven't looked into the details yet to fix these CVEs for the older > versions in Debian, I was intending to look into these after the recent happen > update of Werkzeug plus Flask *and* after my moving of home. It would take at > least some more weeks on my sid, please go ahead and don't wait for me. Thanks for getting back to me so quickly. I'll see how I get on. -- Sean Whitton
python-werkzeug CVEs
Hello, There are three DoS CVEs for python-werkzeug in stable. I intend to fix these as part of the Debian LTS team, sponsored by Freexian. I would like also to fix them in bookworm, because that will become an LTS release eventually. Would you like me to go ahead and submit a stable update request, or are you already working on something? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Anyone interested in python-pgpy?
Hello, python-pgpy is undermaintained and has long been so. This has meant that its reverse dependency mailscripts (which I maintain) is added to the autoremovals list each time python-pgpy breaks. The script in mailscripts that depends on python-pgpy, email-print-mime-structure, is a nice, well-documented piece of software, and it would be a great shame to lose it. However, I can't really let the whole of mailscripts miss trixie as a result of keeping it. So, I'll have to drop email-print-mime-structure from the mailscripts package if this situation persists. Would anyone be interested in taking over maintainance of python-pgpy? Thanks. -- Sean Whitton signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello Xiyue, On Mon 02 Dec 2024 at 01:28pm -08, Xiyue Deng wrote: > I have made a MR[1] including a few quick fixes for the RC bugs, in hope > that they are acceptable for another NMU to unblock this package and its > dependencies. PTAL. Thanks! > > [1] https://salsa.debian.org/debian/pgpy/-/merge_requests/2 Thank you very much for taking a look at this one. I'm a bit queasy about just disabling the failing tests. Do we have reason to believe that pgpy is not actually broken with Python 3.13? In other words, what makes you think that it's just the tests that are broken, not the program? Thanks. -- Sean Whitton
Bug#1089079: bookworm-pu: package python-werkzeug/2.2.2-3+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: debian-python@lists.debian.org, c.schoen...@t-online.de Control: affects -1 + src:python-werkzeug Dear release team, Fix three DoS CVEs. Straightforward backports of upstream's commits, all of which are already in unstable. Upstream's test suite passes so I believe that no ordinary functionality is impacted, although, upstream did not provide new tests to verify the fixes. The changes regarding trusted hosts is only for the debugger, so wouldn't inadvertedly impact anyone's production usage. I have not uploaded, but pushed to salsa:python-team/packages/python-werkzeug#debian/bookworm. Thanks. -- Sean Whitton diff -Nru python-werkzeug-2.2.2/debian/changelog python-werkzeug-2.2.2/debian/changelog --- python-werkzeug-2.2.2/debian/changelog 2023-04-21 19:37:22.0 +0800 +++ python-werkzeug-2.2.2/debian/changelog 2024-12-05 11:47:13.0 +0800 @@ -1,3 +1,11 @@ +python-werkzeug (2.2.2-3+deb12u1) bookworm; urgency=high + + * Backport upstream fix for CVE-2023-46136 (Closes: #1054553). + * Backport upstream fixes for CVE-2024-34069 (Closes: #1070711). + * Backport upstream fix for CVE-2024-49767 (Closes: #1086062). + + -- Sean Whitton Thu, 05 Dec 2024 11:47:13 +0800 + python-werkzeug (2.2.2-3) unstable; urgency=medium [ Robin Gustafsson ] diff -Nru python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch --- python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch 1970-01-01 08:00:00.0 +0800 +++ python-werkzeug-2.2.2/debian/patches/CVE-2023-46136.patch 2024-12-05 11:47:13.0 +0800 @@ -0,0 +1,35 @@ +From: =?utf-8?q?Pawe=C5=82_Srokosz?= +Date: Thu, 12 Oct 2023 18:50:04 +0200 +Subject: Fix: slow multipart parsing for huge files with few CR/LF characters + +(cherry picked from commit b1916c0c083e0be1c9d887ee2f3d696922bfc5c1) +--- + src/werkzeug/sansio/multipart.py | 10 +- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/src/werkzeug/sansio/multipart.py b/src/werkzeug/sansio/multipart.py +index 2684e5d..2c0947d 100644 +--- a/src/werkzeug/sansio/multipart.py b/src/werkzeug/sansio/multipart.py +@@ -206,12 +206,20 @@ class MultipartDecoder: + self._search_position = max(0, len(self.buffer) - SEARCH_EXTRA_LENGTH) + + elif self.state == State.DATA: +-if self.buffer.find(b"--" + self.boundary) == -1: ++boundary = b"--" + self.boundary ++ ++if self.buffer.find(boundary) == -1: + # No complete boundary in the buffer, but there may be + # a partial boundary at the end. As the boundary + # starts with either a nl or cr find the earliest and + # return up to that as data. + data_length = del_index = self.last_newline() ++# If amount of data after last newline is far from ++# possible length of partial boundary, we should ++# assume that there is no partial boundary in the buffer ++# and return all pending data. ++if (len(self.buffer) - data_length) > len(b"\n" + boundary): ++data_length = del_index = len(self.buffer) + more_data = True + else: + match = self.boundary_re.search(self.buffer) diff -Nru python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch --- python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch 1970-01-01 08:00:00.0 +0800 +++ python-werkzeug-2.2.2/debian/patches/CVE-2024-34069-1.patch 2024-12-05 11:47:13.0 +0800 @@ -0,0 +1,142 @@ +From: David Lord +Date: Thu, 2 May 2024 11:55:52 -0700 +Subject: restrict debugger trusted hosts + +Add a list of `trusted_hosts` to the `DebuggedApplication` middleware. It defaults to only allowing `localhost`, `.localhost` subdomains, and `127.0.0.1`. `run_simple(use_debugger=True)` adds its `hostname` argument to the trusted list as well. The middleware can be used directly to further modify the trusted list in less common development scenarios. + +The debugger UI uses the full `document.location` instead of only `document.location.pathname`. + +Either of these fixes on their own mitigates the reported vulnerability. + +(cherry picked from commit 71b69dfb7df3d912e66bab87fbb1f21f83504967) +--- + docs/debug.rst| 35 ++- + src/werkzeug/debug/__init__.py| 10 ++ + src/werkzeug/debug/shared/debugger.js | 4 ++-- + src/werkzeug/serving.py | 3 +++ + 4 files changed, 45 insertions(+), 7 deletions(-) + +diff --git a/docs/debug.rst b/docs/debug.rst +index 25a9f0b..d842135 100644 +--- a
Re: Anyone interested in python-pgpy?
Hello, On Wed 04 Dec 2024 at 01:18am -08, Xiyue Deng wrote: > Looks like this has nothing to do with Python version but gpgme: I have > tested with a snapshot of gpgme1.0 version 1.18.0-6+b1 and everything > works; upgrading to version 1.23.2-5 and the tests start to show the > same errors. I have been trying to see what has changed from gpgme side > but so far nothing conclusive yet. > > On the other hand, python-pgpy may be working fine as all failures in > the tests are caused by using the gpgme python binding, which somehow > doesn't like the PGP signed message generated by python-pgpy anymore. So the bug has nothing to do with the python 3.13 transition, in fact? I think that means its severity should be changed. I guess you're not sure yet whether or not it should be reassigned to pgpme? -- Sean Whitton
Re: Anyone interested in python-pgpy?
Hello, On Sat 07 Dec 2024 at 06:56pm -08, Xiyue Deng wrote: > I was thinking about keeping the bug open and downgrade to important so > that we keep tracking it. But as I have forwarded it upstream we can > monitor the upstream bug directly. I think that downgrading it like that would make sense were you the maintainer. But given that we're doing an NMU to deal with RC bugs, just closing is a simpler documentation of your intent. The maintainer might reopen it and downgrade its importance later. Great work figuring out and then documenting these fixes. mailscripts' dependency on python3-pgpy lives on! -- Sean Whitton signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello, Thank you very much for the update and help thus far. -- Sean Whitton
Re: Anyone interested in python-pgpy?
Hello, On Sat 07 Dec 2024 at 02:27am -08, Xiyue Deng wrote: > Sean Whitton writes: > >> Hello, >> >> Many thanks, and nice documentation of the changes. >> >> If you'd like to send an MR or patch with a d/changelog entry, I can >> upload the NMU credited to you. >> > > Sounds good. I have the MR for updating d/changelog at [1]. I have a > separate commit to finalize in case there are any comments to address. > Please let me know if I should leave out the finalization instead. > Thanks! No, don't leave it out, and also, I think you should close #1086378, else this doesn't help with the autoremoval :) -- Sean Whitton signature.asc Description: PGP signature
Re: Anyone interested in python-pgpy?
Hello, Many thanks, and nice documentation of the changes. If you'd like to send an MR or patch with a d/changelog entry, I can upload the NMU credited to you. -- Sean Whitton signature.asc Description: PGP signature
