Re: morph's abandoned packages (list)
Hi Thomas, * Thomas Goirand [2024-03-17 23:09]: Anyone is welcome to join, it's just that I'm using git tag workflow, so it doesn't fit in the DPT, but that's the only thing. I am not familiar with that workflow and could not find any documentation. Can you give me a quick overview what I should do differently from the "regular" DPT workflow? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Pytest 8.x bug? "Permission denied: '/tmp/systemd-private-...-systemd-logind.service-.../__init__.py'"
Hi, Am 27. März 2024 10:59:46 MEZ schrieb Julian Gilbey : >I'm stymied by a pytest-related bug. I thought it was a bug in a >particular pytest plugin (pytest-order), but it's now shown up in >another pytest plugin as well, so I wonder if either there's a bug in >pytest 8.x or something subtle has changed that requires a >modification to the plugins. I couldn't see anything obvious on the >pytest changelog page, and the error message itself is mysterious to >me. The bug does not show with pytest 7.4.4, so it is certainly >related to the new pytest version. I wasn't able to pinpoint the cause yet, but I noticed that the failing sessions have "rootdir: /tmp" instead of the usual /tmp/autopkgtest-lxc.*/downtmp/autopkgtest_tmp/build Cheers Timo
Re: Changing hatchling shared-data installation directory: /usr/etc -> /etc
Hi Julian, * Julian Gilbey [2024-03-24 22:00]: Now, I can obviously move this to its correct location in debian/rules (either directly or using an appropriate dh-recognised file in debian/), but I wonder whether there is a "better" way to do this. Is there a way to tell hatchling that shared-data should be installed in / rather than in /usr? Or if I tell hatchling to use / as the base directory, would that mess everything else up? I know that both CMake and Meson special-case sysconfdir to point to /etc instead of $prefix/etc when installing to /usr. Hatchling should follow their lead. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: morph's abandoned packages (list)
Hi, * Julian Gilbey [2024-03-14 06:20]: #1065198 O: networkx -- tool to create, manipulate and study complex networks language I use this somewhat regularly, so I'd be happy to share the workload with zigo. #1065329 O: numpy -- Fast array facility to the Python 3 language I use this a lot; both ckk and I are willing to take over. #1065223 O: pysimplesoap -- simple and lightweight SOAP Library This is a transitive dependency of reportbug through python-debianbts. If no one else is interested, I'll take it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)
Hi, * Andreas Tille [2024-02-28 11:51]: I think it could be useful for the routine-update command to stop when such file is hit, in order to raise the importance that the package has quirks, and should not be casually updated without involved scrutiny. I wonder whether this can be generalized, like if d/README.source file is present? (Although the latter use is codified[2] and I'm not confident it is 100% suitable for such purpose: I see many such files on my radar which do not necessarily hint for quirks.) I like all your suggestions. When reading Timo's suggestion about debian/README.DPT I also thought about rather using the more generic debian/README.source. In any case I agree that routine-update should respect such debian/README.* (except debian/README.Debian which is user oriented). I also thought of README.source at first, and I remained on the fence until Étienne brought up the potential use for routine-update, which makes me think that a dedicated "quirks" file makes more sense. I'm not too attached to the .DPT suffix though, maybe something like README.team or even README.quirks signals the intention behind the file even better. I'll leave the bikeshedding to interested readers for now. :) Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Suggesting change in DPT policy
Hi, * Andreas Tille [2024-02-27 09:05]: Since I consider the current situation as demotivating for newcomers as well as long standing contributors I would like to suggest to drop this "weak statement of collaboration" option from policy. +1 from me. I guess the motivation behind the weak collaboration model is that some packages have hidden "gotchas", which a casual team uploader might not know. For instance, pygit2 is one of multiple libgit2 language bindings which all need to be upgraded in lock-step when a new upstream version is released. Instead of restricting collaboration, we could let policy encourage maintainers to state such constraints in debian/README.DPT and ask team members to check that file before they team-upload. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Breaking changes in pytest 8
Hi Julian, * Julian Gilbey [2024-01-09 17:45]: Please can we hold back on uploading pytest 8 to unstable until the current Python 3.12 transition is complete? Sure! I'll keep it in experimental, and we can check what still needs fixing after the Python 3.12 dust has settled. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Breaking changes in pytest 8
Hi, I recently uploaded the pre-release pytest 8.0.0~rc1 to experimental as an early warning for the breaking changes which typically happen on major version bumps. I've attached a dd-list of packages which exhibit autopkgtest regressions [1], with the intent of MBF'ing (with separate announcement) once pytest 8 is released. Typically, packages will fail if they - have deprecation warnings of type PytestRemovedIn8Warning, or - assume a particular pytest stdout/stderr output which might have changed, or - rely on the precise order in which pytest collects tests, especially the behavior of the pytest.Package collector. Please refer to the upstream changelog [2] for a complete list of breaking changes. Cheers Timo [1] https://qa.debian.org/excuses.php?experimental=1=pytest [2] https://docs.pytest.org/en/latest/changelog.html -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ Adam Cecile python-fastjsonschema (U) Agustin Henze docopt Alastair McKinstry python-xarray (U) Andreas Tille python-hmmlearn (U) tifffile (U) Andrew Starr-Bochicchio libcloud (U) Andrey Rakhmatullin python-parsel (U) Andrius Merkys python-ase (U) Ask Hjorth Larsen python-ase (U) Bo YU tox-current-env (U) xdoctest (U) Carsten Schoenert python-graphene (U) Daniele Tricoli requests (U) Debian Astronomy Maintainers astropy pytest-mpl Debian Astronomy Team sunpy Debian Games Team protontricks Debian Med Packaging Team dcmstack intake khmer python-anndata python-gffutils python-hmmlearn python-screed Debian Python Modules Team python-b2sdk Debian Python Team dask hickle ipyparallel javaproperties libcloud loguru mplcursors pytest-arraydiff pytest-order pytest-services pytest-sugar python-dateutil python-dict2xml python-fakeredis python-fastjsonschema python-graphene python-marshmallow-sqlalchemy python-parsel python-pytest-benchmark python-pytest-lazy-fixture python-sparse python-syrupy python-testfixtures python-upsetplot python-werkzeug requests setuptools-scm sqlalchemy (U) superqt tifffile tox-current-env twine wxutils xdoctest xonsh Debian Science Maintainers joblib openpyxl python-xarray spyder-line-profiler statsmodels Debian Science Team dolfin fenics-dolfinx Debichem Team mdtraj opendrop python-ase Diane Trout dask (U) python-anndata (U) python-graphviz python-sparse (U) python-upsetplot (U) statsmodels (U) Drew Parsons dolfin (U) fenics-dolfinx (U) mdtraj (U) opendrop (U) Edward Betts hickle (U) pytest-sugar (U) Emmanuel Arias python-marshmallow-sqlalchemy (U) Federico Ceratto freedombox (U) FreedomBox packaging team freedombox Ghislain Antony Vaillant python-sparse (U) python-xarray (U) spyder-line-profiler (U) Gordon Ball xonsh (U) Graham Inggs python-ase (U) Guido Günther python-dateutil (U) Hans-Christoph Steiner libcloud (U) Ignace Mouzannar python-parsel (U) James Valleroy freedombox (U) Joel Cross python-pytest-lazy-fixture (U) Johannes Ring dolfin (U) Jon Bernard barectf (U) Joseph Nahmias ipyparallel (U) Julian Gilbey pytest-order (U) spyder-line-profiler (U) Julien Puydt setuptools-scm (U) Kevin Murray khmer (U) Leo Singer pytest-mpl (U) Luca Boccassi javaproperties (U) Michael Fladischer python-testfixtures (U) Michael Hanke openpyxl (U) statsmodels (U) Michael Hanke dcmstack (U) Michael Jeanson barectf Michael R. Crusoe khmer (U) python-gffutils (U) python-screed (U) Nick Daly freedombox (U) Nilesh Patra loguru (U) Ole Streicher astropy (U) pytest-arraydiff (U) sunpy (U) tifffile (U) ttkthemes (U) Ondřej Kobližek python-b2sdk (U) python-fakeredis (U) Ondřej Nový python-fakeredis (U) python-werkzeug (U) Petter Reinholdtsen freedombox (U) Pierre-Elliott Bécue pytest-services (U) Piotr Ożarowski freedombox (U) sqlalchemy Rebecca N. Palmer openpyxl (U) statsmodels (U) Scott Kitterman python-dict2xml (U) Shayan Doust intake (U) Soren Hansen libcloud (U) Stefano Rivera twine (U) Steffen Moeller loguru (U) python-anndata (U) python-gffutils (U) Stephan Lachnit protontricks (U) Stuart Prescott opendrop (U) superqt (U) Sudip Mukherjee mplcursors (U) Sunil Mohan Adapa freedombox (U) Tcl/Tk Debian Packagers ttkthemes Thomas Goirand python-werkzeug (U) Timo Röhling python-pytest-benchmark (U) python-syrupy (U) Tzafrir Cohen freedombox
Re: RFS: dateparser [RC]
* Andrey Rakhmatullin [2023-12-20 10:00]: Hello! My key in the keyring is temporarily expired so can please someone upload dateparser 1.2.0-2? It's tagged in salsa. Done! -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Python module packaging request to help me maintain apt-listchanges
Hi Jonathan, * Jonathan Kamens [2023-10-23 06:00]: I'm writing to ask for your assistance in getting pytest-subprocess packaged into Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053360 As one of the uploaders for pytest, I am happy to sponsor you! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1052028: please update to pydantic 2.x
Source: pydantic Version: 1.10.4-1 Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, I would like to have pydantic updated to the latest 2.x major release, because rstcheck depends on it. The 2.x API has some breaking changes, but according to the pydantic README, version 1.10.4 is shipped as pydantic.v1 legacy module. Therefore, any reverse dependency which is incompatible with the 2.x API can be fixed trivially at import level. As pydantic is only weakly team managed, I am submitting this wishlist bug, but I am willing to do the grunt work for this and provide the necessary team uploads. I cc'd the Python team mailing list as advance notice for the maintainers of affected reverse dependencies. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmUFgtIACgkQ+C8H+466 LVlPWgwA48KvUKxcwuy9DEQKH6jPaa7g8vNJXIz7EdXnqhUJAVUlDV+7nJ4T5+rJ aesvqHpC6NE76Okkm76UhPk3wwCvsvoww+Ib4OHMKfYt9f1QS3FvQvMRSQWZrUpq +AB0nPfUxc5HepCcH+prshDeUkJ5QmotqeMZTmDbdmZmpHyyF1hAz+0BfgXuJlSg Gpyew8M/qm4IiN04wdG34JwyVTSGutxcHNV8o4cnupp7TuiYpLFVDVYkeJkdWYq1 vFIH80pHfTvDX+2Gk+KlfJA4tcPxvMu2sZm3S4OvIYSq97FeVWLHBUiZmNYboXIe doiAC87EFEo/NTjv1xFXzjKYz27ae/XTpTVgS2FD2U1YUYyYUtr88423QrtvUGnz gDiz+efixPsdy3H26yH1x/Y6qRLQWnag3dyXjPx3xUZgDe0Merhrm5C9Djk8ZKD4 9WuSLNVwXit3n6MMZRZHIdNO/QVxYyFsPSobytXRluroxWVYhOYeSH+uEOhvBYLl qhf317wZ =6qsd -END PGP SIGNATURE-
Re: Uncleaned egg-info directory giving lots of bugs about failing to build after successful build
* Julian Gilbey [2023-08-18 13:42]: One could handle it by manually adding this directory to debian/clean in each package, but perhaps this should be the default behaviour of dh-python? See https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/46 Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: How to realize different test categories?
Hi Christian, * c.bu...@posteo.jp [2023-07-28 12:14]: Or any other idea on your site? I had a look at the backintime sources, and I noticed that you have implemented a very unusual (for Python, at least) build system. There are well-known tools and standard practices in the Python ecosystem for packaging [1], and much of the Python packaging in Debian is designed to work well with them. There are also tools for test isolation such as [2]. Instead of increasing your workload by maintaining an extra set of tests for Debian, why not let backintime take advantage of established practices and tools? Not only will this reduce friction with the Debian packaging, it will generally make your package more accessible to other Python developers, which in turn may attract more people to help fix bugs and keep the software in good shape. Cheers Timo [1] https://packaging.python.org/en/latest/tutorials/packaging-projects/ [2] https://tox.wiki/ -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Python module installation with cmake
Hi Gregor, * Gregor Riepl [2023-07-28 09:21]: I'm looking for help with a regression in cmake 3.27, that is currently producing incorrect module installation paths for the Python package Uranium: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042157 I posted an explanation to debian-devel yesterday: https://lists.debian.org/debian-devel/2023/07/msg00307.html Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#1041778: python3.11: 'posix_local' scheme conflicts with 'base' and 'platbase' prefix overrides
Package: python3.11
Version: 3.11.4-1
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org
Control: found -1 3.11.2-6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Dear maintainer,
the 'posix_local' scheme will unexpectedly insert "/local"s into path
names if the 'base' prefix is changed to something other than '/usr':
>>> import sysconfig
>>> sysconfig.get_path('purelib')
'/usr/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/opt/mystuff'})
'/opt/mystuff/local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': './'})
'local/lib/python3.11/dist-packages'
>>> sysconfig.get_path('purelib', vars={'base': '/usr/local'})
'/usr/local/local/lib/python3.11/dist-packages'
As code like the above is actually being used "in the wild" to create
FHS-like directory structures in locations other than /usr, we should
consider if and how we manage the implied expectation behind that code.
As far as I understand the rationale behind the 'posix_local' scheme, it
is supposed to prevent local installations into the dpkg-managed
/usr/lib, for the reasons given in PEP-668. To that end, the scheme is
arguably slightly "overpowered", as it does more than just divert
'purelib' and 'platlib' from /usr/lib.
We could make sysconfig.get_path() and sysconfig.get_paths() check if
'base' or 'platbase' are overridden to something other than '/usr'
before applying the 'posix_local' scheme for 'purelib' and 'platlib',
respectively. This would certainly help minimize the impact of the
Debian-specific posix_local scheme. Technically, it means that the
posix_local scheme can no longer be expressed as a simple dict, but as
far as I see it, this is just a current implementation detail and
nothing promised by the sysconfig API.
So while it is possible that we would violate other expectations about the
behavior of get_path() along the way, I believe we would make the
Debianized version of Python more compatible with other platforms and
behave less surprisingly in the common use case, which I consider a Good
Thing.
Feel free to rebut (or second) my reasoning. :)
Cheers
Timo
-BEGIN PGP SIGNATURE-
iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmS9PJgACgkQ+C8H+466
LVlrvQv/S8NjYecZVDu1ARN/DiYg5qCVdWQjpTzWhm+VSBLJ/fkcjyYNLWB+/ott
H9DA0bTMsDTKn1G+VZ238Wb8Nm9Hwhx+aVQRENGKh6LR9JLDZT8RzpTQrp/4e9gM
KPYaS5KcLi3vpy+9eiu0V0zFTBv5sPLy91bipQ9Cbh6it69Cv7QhUBGNkVz6ckLN
5YWqlK56z2nu2tvaedS/1LrxB7zy6axo1RPLZKKkbk12rTCaeVBSetBnYos978eu
4puSqgKdYKAskvOFo0XCKDR9msBLdKm1V907mkzVfRoh3wWX00gMz9/BplPPnkHB
tavi3fqdwkunvq+a1zAn2YKX15JH31vzuTKfIB+XPVgsRuAV9y7y8X/CrMYpy7zX
RGRTq8Ycg8BRRMyxIwv/TDJqpXjF6iiL5Qbt/ju7gy/pyDVyqi6VS7BNxhJhprlJ
Xk8ctWYj1495hf7O0Hrn1U0q31AW8s9dGJ6ilF+VqAsDqrmsm4vp2dmURHC+0jGn
KXOiI8T1
=TwPy
-END PGP SIGNATURE-
Re: Bug#1041633: cmake: FindPython.cmake returns /usr/local/lib/python3.11/dist-packages for Python_SITEARCH
Control: reassign -1 qgis 3.28.8+dfsg-1
Control: retitle -1 qgis: needs DEB_PYTHON_INSTALL_LAYOUT=deb to build
Hi Bas,
* Sebastiaan Couwenberg [2023-07-21 17:17]:
Changes between bookworm and sid:
cmake 3.25.1:
``Python_SITELIB``
Third-party platform independent installation directory.
Information returned by
``distutils.sysconfig.get_python_lib(plat_specific=False,standard_lib=False)``
or else ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
Third-party platform dependent installation directory.
Information returned by
``distutils.sysconfig.get_python_lib(plat_specific=True,standard_lib=False)``
or else ``sysconfig.get_path('platlib')``.
cmake 3.27.0:
``Python_SITELIB``
Third-party platform independent installation directory.
Information returned by ``sysconfig.get_path('purelib')``.
``Python_SITEARCH``
Third-party platform dependent installation directory.
Information returned by ``sysconfig.get_path('platlib')``.
On bookworm distutils is still used which returns:
>>> distutils.sysconfig.get_python_lib(
plat_specific=False,
standard_lib=False,
)
'/usr/lib/python3/dist-packages'
On sid sysconfig is used which results:
>>> sysconfig.get_path('platlib')
'/usr/local/lib/python3.11/dist-packages'
To get the right path for the Debian python3 interpreter,
you need to add 'deb_system':
>>> sysconfig.get_path('platlib', 'deb_system')
'/usr/lib/python3/dist-packages'
After a bit of discussion in #d-python, I believe that
CMake actually behaves as intended now, and the previous behavior was
unintended.
The default use-case is a local user build, not a package build, and
the default SITELIB reflects that.
It is the package maintainer's responsibility to set
DEB_PYTHON_INSTALL_LAYOUT=deb in d/rules, either implicitly through
the use of pybuild, or explicitly with "export
DEB_PYTHON_INSTALL_LAYOUT", as you already did in Salsa.
Cheers
Timo
--
⢀⣴⠾⠻⢶⣦⠀ ╭────────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Bug#1041341: html5lib: FTBFS on unstable
Source: html5lib Version: 1.1-3 Severity: serious Tags: ftbfs X-Debbugs-Cc: debian-python@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, html5lib seems to fail to build due to a change in Traceback.filter() Relevant excerpt from build log: ../../../html5lib/tests/testdata/tokenizer/domjs.test ... INTERNALERROR> Traceback (most recent call last): INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py", line 270, in wrap_session INTERNALERROR> session.exitstatus = doit(config, session) or 0 INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py", line 324, in _main INTERNALERROR> config.hook.pytest_runtestloop(session=session) INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in __call__ INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult) INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in _hookexec INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, firstresult) INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 60, in _multicall INTERNALERROR> return outcome.get_result() INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in get_result INTERNALERROR> raise ex[1].with_traceback(ex[2]) INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in _multicall INTERNALERROR> res = hook_impl.function(*args) INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/main.py", line 349, in pytest_runtestloop INTERNALERROR> item.config.hook.pytest_runtest_protocol(item=item, nextitem=nextitem) INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in __call__ INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult) INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in _hookexec INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, firstresult) INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 60, in _multicall INTERNALERROR> return outcome.get_result() INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_result.py", line 60, in get_result INTERNALERROR> raise ex[1].with_traceback(ex[2]) INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 39, in _multicall INTERNALERROR> res = hook_impl.function(*args) INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 114, in pytest_runtest_protocol INTERNALERROR> runtestprotocol(item, nextitem=nextitem) INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 133, in runtestprotocol INTERNALERROR> reports.append(call_and_report(item, "call", log)) INTERNALERROR>^^ INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 224, in call_and_report INTERNALERROR> report: TestReport = hook.pytest_runtest_makereport(item=item, call=call) INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 265, in __call__ INTERNALERROR> return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult) INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 80, in _hookexec INTERNALERROR> return self._inner_hookexec(hook_name, methods, kwargs, firstresult) INTERNALERROR> ^ INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 55, in _multicall INTERNALERROR> gen.send(outcome) INTERNALERROR> File "/usr/lib/python3/dist-packages/_pytest/skipping.py", line 266, in pytest_runtest_makereport INTERNALERROR> rep = outcome.get_result() INTERNALERROR> INTERNALERROR> File "/usr/lib/python3/dist-packages/pluggy/_result.py",
Bug#1038883: dolfin: autopkgtest failure due to bytes as docstring
Source: dolfin Version: 2019.2.0~git20230116.bd54183-2 Severity: serious Tags: patch X-Debbugs-Cc: debian-python@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer, your package fails the autopkgtest with the new pytest 7.3 because python/test/unit/function/test_function_space.py uses a bytes object (b""" literal) as module docstring, and pytest crashes while looking for the "PYTEST_DONT_REWRITE" marker. As far as I understand, using a bytes() object as docstring violates PEP-257, which is why I am filing this as a dolfin bug and not a pytest regression. I have Cc'd the debian-python mailing list for a second opinion, but I believe this bug should be resolved by getting rid of the erroneous "b" prefix. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSUVIMACgkQ+C8H+466 LVlDnwwAvkNiICYQNkEcEL6b8cCBs5omarn94D+xGVDAILX/LZvOJxzpL2fklo4Y 4cdyjdiq3Kye5j/tQ5C4CE76jEBt3Y/JCXKJnet8PpM2mrD1mBJR9m5yxznrgxer 9jZPGx9I8F2/E/O211cSMC+5WgX5OePD9mIlVDINmXRRU6NGgm1KIMaFhG5rS0qW 6OG0cjX6UrzlEbiD+xZbt56dlfZz3o1FvRqSaGmRwNVsDeRuNdrYiN15FVnqOw88 0sy+wgE/x74hCCNgqkDeHQiZfO+fw9sIn0g0NU4pa2HqZHO7yRjJrctohvPkfHTd U1R7yfZZOeSJVVC2+RyRBjOYudG9p4C3qraGnfRlZ9s64ok5rwVruZ6mK9eWClMU VJcIpLVrSIWyuYdGsu2Cj/mmdfypDDsPk7Yp+U21g+EThv2CI9vlgwnKwhTNBtwa fT4oKTn+odfYLUzv3+tSd1FdYyGZB71m4X4i7ckzShf8uL4zMiYB7WhFhm+9QCfs 9+rI0cvw =gZ+8 -END PGP SIGNATURE-
Re: Python 3.11 for bookworm?
* Stefano Rivera [2022-12-22 12:44]: There have been rebuilds in Ubuntu that give us some idea of how much work remains. I think it's tractable, but also will have some package casualties. I have some spare time right now, and I am happy to help work on problematic cases, so hopefully nobody will feel left out in the cold with their favorite packages. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Python 3.11 for bookworm?
* Graham Inggs [2022-12-12 23:51]: with the bookworm transition freeze only one month away [5], we'd like to hear from the Python Team within the next week whether they wish to proceed with Python 3.11 being the only supported version for bookworm [...] Should it be the former, we'd like an undertaking from the Python Team that they will help resolve the remaining bugs against key packages One remaining problem is the unmaintained nose package, which is not compatible with Python 3.11 and still a dependency of 200+ packages, including ~40 key packages [1]. I've seen that crusoe has done some work patching up nose, but AFAICT it is not building yet. Is this something we can resolve in time, either by fixing nose or removing it altogether? If yes, +1 for Python 3.11 Cheers Timo [1] https://udd.debian.org/bugs/?release=bookworm=ign=7=7=only=nose-rm=python-modules-team%40lists.alioth.debian.org=1=1=id=asc=html#results -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: request for review: python-pyglfw
Hi Étienne, * Étienne Mollier [2022-12-04 12:46]: I'm a DD, but since this is my first DPT package, I wouldn't be against having a second pair of eyeballs having a look at the python-pyglfw package I produced this morning[1]. The packaging in itself was super smooth, I just wanted to make sure I didn't miss team specific bits; I had the policy and guide under the eyes while packaging, but one never knows. [1]: https://salsa.debian.org/python-team/packages/python-pyglfw - You forgot to push the upstream and pristine-tar branches, the upstream/2.5.5+dfsg tag, and you should set "debian-branch = debian/master" in d/gbp.conf - I think the package can be arch:all, as the package will be identical an all architectures, with all architecture-specific bits hidden behind the ctypes indirection. - The "Build-Depends: libglfw3 " seems unnecessary, because AFAICT, there is no test suite in the package at all. - There is no "Testsuite: autopkgtest-pkg-python" in d/control. I'm really not sure if this is an issue, because I usually have more intrusive tests and seldomly rely on the default one. Besides, you did add a config in d/tests, which may also suffice? I really don't know, but wanted to mention it just in case. - I've never set LC_ALL in d/rules. Is there a particular reason why it is necessary? - Personally, I prefer having dh-sequence-python3 in Build-Depends, so I don't have to add --with python3 in d/rules. Everything else looks good to me, with the caveat that I did not actually test-build the package, because of the missing pushes. Oh, and welcome to the team, nice to have you here! Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: pyyaml 6
Hi Gordon, * Gordon Ball [2022-10-07 00:10]: * Upload to unstable and see what breaks? * Request an archive rebuild with this version and see what breaks? * File bugs against all likely affected packages with a fixed date for an upload? * Wait until after the freeze? Considering that PyYAML has been issuing a YAMLLoadWarning since version 5.1 (i.e. September 2019), I would expect that many (most?) reverse dependencies have been fixed, and anything that still breaks is probably in dire need of maintenance anyway. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: python-attrs update
Hi Antonio, * Antonio Valentino [2022-08-09 18:31]: I have prepare an updated version of the package python-atts. The code is in my fork on salsa: https://salsa.debian.org/antonio.valentino/python-attrs [...] I kindly ask to someone in debian-python to review the changes and upload the new version of the package. 1. This is a "Team upload", not a "Non-maintainer upload" 2. The copyright holder "Hynek Schlawack" is duplicated in d/copyright Other than that, the packaging looks good and I'll gladly upload it for you. Feel free to commit to the main repository. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Versioneer [was Re: a review of your bumblebee-status package]
Hi everyone, * Ben Westover [2022-06-06 22:42]: As far as I understand it, this file is used by the author of the program, not end users. I don't understand it well, though, because I haven't put much time into researching what versioneer even does. Versioneer is meant to simplify version tracking for the developer; it supports a number of authoritative sources such as "git describe" to determine the current version number. There are two modes of operation: - in developer mode, versioneer detects the version number dynamically. This is what you'll see if you use the (Git) repository sources. - in install mode, the release version number is statically embedded. This is what you'll see if you download from PyPI. Internally, these modes are realized by two different _version.py files; the developer version is usually added to version control, and the setuptools "build" and "sdist" steps are intercepted to insert the static _version.py as needed. In my experience, it Just Works with pybuild, so I wouldn't bother with any special treatment; the versioneer.py source is public domain, so you're not going to run into any licensing issues. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
Hi Julian, * Julian Gilbey [2022-04-26 11:03]: It turns out that I'd also messed up more than I'd realised: even when I pulled in the updated master branch, I didn't pull the upstream branch, so managed to introduce even more conflicts. Oh well. It's an easy mistake to write "git pull" if you meant to do "gbp pull". I lost count how often I wrote "git pq" by accident... To fix the problem, I did: $ git checkout upstream $ git reset --hard upstream/5.3.0 Judging from the current commit graph, you probably threw in a "git merge -s ours origin/upstream" here as well? $ git checkout master $ gbp pristine-tar commit and that fixed everything. I finished with git push --all and git push --tags. Nice! I hope I don't make this mistake again! Don't worry about it too much. Git is quite resilient, and as long as you do not panic and start force-pushing random stuff, everything can be repaired. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
* Timo Röhling [2022-04-24 22:42]: Make sure that your local upstream branch and the upstream/5.3.0 tag both point at commit 08935221b549bf32157d739cd54eb1645a2ab123: Aaaand I copied the wrong commit hash to the email. :/ e228e8902aeb91011a53bb1a91f7f3390a771e0e is the one you should be looking for: https://salsa.debian.org/python-team/packages/python-qtconsole/-/commit/e228e8902aeb91011a53bb1a91f7f3390a771e0e Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Messed up a salsa commit - how best to fix?
Hi Julian, * Julian Gilbey [2022-04-24 21:01]: Somehow I managed to really mess up a commit to python-qtconsole: the upstream and pristine-tar branches do not have the upstream/5.3.0 sources (the current ones). However, there's already an upstream/5.3.0 tag in the repository, pointing to a commit to the master branch. I think the simplest thing to do is to "rewrite history": delete the head commits to the master branch and the 5.3.0 tags, and then recommit correctly and force-push to salsa. Would people be OK with me doing this, or do you have an alternative suggestion? I looked at the Salsa repository, and it is not so bad. It seems like you forgot to pull the latest changes in upstream and pristine-tar from the 5.2.2 import first, so your import of 5.3.0 forked the those branches unintentionally. As the first order of business, you should run $ git fetch origin to update all your remote branches to the actual locations. Then, we can fix the branches one by one. For the pristine-tar branch, the easiest way is to rebase your commit to the actual remote branch that includes the 5.2.2 import by Frédéric: $ git checkout pristine-tar $ git rebase origin/pristine-tar $ git push origin pristine-tar The upstream branch cannot be rebased, because it is interwined with the master branch. Fortunately, that is not necessary, because the 5.2.2 import has been merged into master and therefore is connected in the graph. Make sure that your local upstream branch and the upstream/5.3.0 tag both point at commit 08935221b549bf32157d739cd54eb1645a2ab123: $ git -P log -n1 upstream $ git -P log -n1 upstream/5.3.0 If they do, you can $ git push --force origin upstream upstream/5.3.0 This will remove the 5.2.2 import from the upstream branch history, but it will not be lost because it is still connected to the master branch, which is arguably the more important connection, as it allows you to reproduce the 5.2.2 upload if required. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
rstcheck: how should I package the new public module?
Hi, rstcheck used to be a pure CLI application, so I packaged it as "rstcheck" with a private module in /usr/share/rstcheck. The latest version has added a public module interface, so "import rstcheck" has become a thing and the module needs to be installed publicly for that. My question is: should I move/rename the whole package to python3-rstcheck (and keep rstcheck temporarily as transitional dummy package), or should I keep /usr/bin/rstcheck in the old package indefinitely and only move the module to python3-rstcheck? The latter solution feels cleaner to me, because it neatly separates the library and the appliation, but at the cost of an almost empty binary package, which is frowned upon by the FTP team. Any suggestions how I should proceed? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭────╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: packaging help request: paths for build_py and build_scripts phases
Hi Jonathan,
* Jonathan Dowland [2021-10-18 11:04]:
Here, the scripts are copied to a path *not* rooted in <>.
So far as I can tell, both phases are normal parts of the
setuptools/distutils build lifecycle, and I haven't spotted anything
obviously non-standard about the way that is specified.
[...]
A BTS bug requesting the new version with some back-and-forth trying to
figure this out is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597
The main issue is the implicit upstream assumption that the tests
are run from the source root dir; I've had a similar problem with
tweepy and my solution was to make sure that the tests find
everything they need in the build folder, i.e. add the following
snippet to d/rules:
export PYBUILD_BEFORE_TEST=cp {dir}/trash-* {dir}/script/bump.py {build_dir}
export PYBUILD_AFTER_TEST=rm {build_dir}/trash-* {build_dir}/bump.py
The second line is needed so the extraneous stuff is not installed
with the built package. It's not very pretty, and hopefully someone
else has a better solution, but it gets the job done.
You'll also have to patch tests/run_command.py to run python3 and
add python3-psutils to your Build-Depends.
diff --git a/tests/run_command.py b/tests/run_command.py
index 2e31e11..746cdad 100644
--- a/tests/run_command.py
+++ b/tests/run_command.py
@@ -17,7 +17,7 @@ def run_command(cwd, command, args=None, input='', env=None):
if args == None:
args = []
command_full_path = os.path.join(base_dir, command)
-process = subprocess.Popen(["python", command_full_path] + args,
+process = subprocess.Popen(["python3", command_full_path] + args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
Cheers
Timo
PS. I worked around the missing fork
PPS. I thought about patching run_command.py to use the scripts from
the source directory, but that will use the trashcli module from the
source tree, not from the build tree, and contaminate the source tree
with __pycache__ folders.
--
⢀⣴⠾⠻⢶⣦⠀ ╭────╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
Team membership request
Hello! I'd like to join the team! Right now, I would like to help maintain the outdated Tweepy package which I'm currently using, but more generally, I am an avid Python user, so it would be my pleasure to help keep the Python package ecosystem in good shape. I'm also member of the Science Team, where I help maintain a number of (ROS related) Python packages. My Salsa login is roehling. I have read https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst and accept it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
