Joining the DPMT Team
Hi all, I have been working in the PAPT Team for quite some time and found that it's not really easy to be working under PAPT without DPMT access, since fixes for Python applications would often require changes in Python libraries. Can anyone add me into the DPMT Team? My Salsa account is @byang. Thanks very much in advance! Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1001730: RFH: qdarkstyle
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-python@lists.debian.org debian-scie...@lists.debian.org Package qdarkstyle is currently team-maintained under Debian Python Team. It is a (build-)dependency for the versatile Python-based scientific IDE spyder ( https://tracker.debian.org/pkg/spyder ). The current version of qdarkstyle in Debian archive is 2.8.1. Newer releases of spyder IDE requires qdarkstyle 3.x, which seems to need a lot more packaging efforts in handling upstream buildsystem and dependencies. Any help around new version packaging would be welcome. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
pdm-pep517: Shall we package it now?
Hi all, I have encountered more and more packages that uses pdm-pep517 as build backend. Looking at [1], existing packages in Debian added patches to manually switch to other backends, such as Poetry. I am wondering if it's time to package pdm-pep517 itself [2], or is there any blocking for it. I am aware that some sort of bootstrapping might be needed since pdm-pep517 seems to build-depends on itself. Besides that, what about packaging of pdm? Please correct me if needed: my mind and my packaging work is still stuck in the old times of setup.py, and I just started to look into the new ecosystem of pep517. Thanks! Regards, Boyuan Yang [1] https://codesearch.debian.net/search?q=pdm.pep517 [2] https://github.com/pdm-project/pdm-pep517 signature.asc Description: This is a digitally signed message part
ITP: pdm-pep517 -- Yet another PEP 517 backend for PDM projects
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pdm-pep517 Version : 1.0.0 Upstream Author : Frost Ming * URL : https://github.com/pdm-project/pdm-pep517 * License : Expat Programming Lang: Python Description : Yet another PEP 517 backend for PDM projects This is the backend for PDM projects, while you can also use it alone. It reads the metadata of PEP 621 format and coverts it to Core metadata. This package is the build-dependency for several packages in Debian. I intend to maintain this package as part of the Debian Python Team. Packaging work will be stored at https://salsa.debian.org/python-team/packages/pdm-pep517 . Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: pdm-pep517: Shall we package it now?
Hi, 在 2022-06-28星期二的 13:32 +，Stefano Rivera写道： > Hi Boyuan (2022.06.28_13:24:49_+) > > I am wondering if it's time to package pdm-pep517 itself [2], or is there > > any blocking for it. I am aware that some sort of bootstrapping might be > > needed since pdm-pep517 seems to build-depends on itself. > > Yes, probably time to package it. > > Bootstrapping shouldn't be problematic, PEP517 includes support for > bootstrapping (backend-path = ["."]), so backends can build themselves > from their own source trees. Thanks. I have uploaded an initial version to the NEW queue. The packaging work is at https://salsa.debian.org/python-team/packages/pdm-pep517/ . It is worth noting that I took the very aggressive way in stripping every vendored libraries, see https://salsa.debian.org/python-team/packages/pdm-pep517/-/tree/master/debian/patches . This may not be ideal since the patch will need human intervention for every new upstream release, but anyway let's have a working version in Sid first. Meanwhile, any review or other types of help would be appreciated. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Packaging of pdm (Was: pdm-pep517: Shall we package it now?)
Hi all, 在 2022-06-28星期二的 09:24 -0400，Boyuan Yang写道： > Hi all, > > I have encountered more and more packages that uses pdm-pep517 as build > backend. Looking at [1], existing packages in Debian added patches to > manually switch to other backends, such as Poetry. > > I am wondering if it's time to package pdm-pep517 itself [2], or is there > any blocking for it. I am aware that some sort of bootstrapping might be > needed since pdm-pep517 seems to build-depends on itself. Besides that, > what > about packaging of pdm? Please correct me if needed: my mind and my > packaging work is still stuck in the old times of setup.py, and I just > started to look into the new ecosystem of pep517. Thanks! As an update, I also pushed pdm package [3] as well as several of its build- dependencies into the NEW queue. [3] http://salsa.debian.org/python-team/packages/pdm Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: pdm-pep517: Shall we package it now?
Hi, 在 2022-06-28星期二的 11:19 -0400，Louis-Philippe Véronneau写道： > On 2022-06-28 09 h 24, Boyuan Yang wrote: > > Hi all, > > > > I have encountered more and more packages that uses pdm-pep517 as build > > backend. Looking at [1], existing packages in Debian added patches to > > manually switch to other backends, such as Poetry. > > > > I am wondering if it's time to package pdm-pep517 itself [2], or is > > there > > any blocking for it. I am aware that some sort of bootstrapping might be > > needed since pdm-pep517 seems to build-depends on itself. Besides that, > > what > > about packaging of pdm? Please correct me if needed: my mind and my > > packaging work is still stuck in the old times of setup.py, and I just > > started to look into the new ecosystem of pep517. Thanks! > > > > Regards, > > Boyuan Yang > > > > > > [1] https://codesearch.debian.net/search?q=pdm.pep517 > > [2] https://github.com/pdm-project/pdm-pep517 > > Once packaged, please ping me so I can update the > "missing-prerequisite-for-pyproject-backend" Lintian tag accordingly and > let people know they can migrate to it. This is now accepted at https://tracker.debian.org/pkg/pdm-pep517 . Cheers, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: bleak and dbus-next as part of the Python team
Hi, 在 2022-07-04星期一的 09:11 +0200，Tino Mettler写道： > Hi, > > recently I coded some stuff for BTLE (Bluetooth Low Energy) > communication and used the bleak python library: > > https://github.com/hbldh/bleak > > I depends on another library which is not yet in Debian: > https://github.com/altdesktop/python-dbus-next > > I prepared packages for both libraries, which was pretty > straightforward. > > Would you accept to include both packages in the Python packaging team? You can now find python-dbus-next at https://tracker.debian.org/pkg/python-dbus-next . If you need to package the bleak python library, please go ahead. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: bug: vorta 0.8.7-1~bpo11+1 - error on startup: The 'secretstorage' distribution was not found and is required by vorta
Hi,
Since the backported version was uploaded by the original package
maintainer, I am forwarding your message to the bpo package uploader.
Also, vorta in buster-backports is of version 0.7.5, not 0.8.7. I assume
that you were talking about vorta in bullseye-backports.
Thanks,
Boyuan Yang
在 2022-08-05星期五的 16:10 +0300，Axel Wikström写道：
> Installing vorta from buster-backports on a fresh Debian 11 install
> with XFCE, and trying to start it from the command line yields this:
>
> Traceback (most recent call last):
> File "/usr/bin/vorta", line 33, in
> sys.exit(load_entry_point('vorta==0.8.7', 'gui_scripts', 'vorta')())
> File "/usr/bin/vorta", line 25, in importlib_load_entry_point
> return next(matches).load()
> File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
> module = import_module(match.group('module'))
> File "/usr/lib/python3.9/importlib/__init__.py", line 127, in
> import_module
> return _bootstrap._gcd_import(name[level:], package, level)
> File "", line 1030, in _gcd_import
> File "", line 1007, in _find_and_load
> File "", line 986, in
> _find_and_load_unlocked
> File "", line 680, in _load_unlocked
> File "", line 790, in exec_module
> File "", line 228, in
> _call_with_frames_removed
> File "/usr/lib/python3/dist-packages/vorta/__main__.py", line 10, in
>
> from vorta.store.connection import init_db
> File "/usr/lib/python3/dist-packages/vorta/store/connection.py",
> line 9, in
> from .migrations import run_migrations
> File "/usr/lib/python3/dist-packages/vorta/store/migrations.py",
> line 6, in
> from .models import (DB, ArchiveModel, BackupProfileModel,
> EventLogModel,
> File "/usr/lib/python3/dist-packages/vorta/store/models.py", line
> 13, in
> from vorta.utils import slugify
> File "/usr/lib/python3/dist-packages/vorta/utils.py", line 23, in
>
> from vorta.borg._compatibility import BorgCompatibility
> File "/usr/lib/python3/dist-packages/vorta/borg/_compatibility.py",
> line 1, in
> from pkg_resources import parse_version
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 3243, in
> def _initialize_master_working_set():
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 3226, in _call_aside
> f(*args, **kwargs)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 3255, in _initialize_master_working_set
> working_set = WorkingSet._build_master()
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 568, in _build_master
> ws.require(__requires__)
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 886, in require
> needed = self.resolve(parse_requirements(requirements))
> File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py",
> line 772, in resolve
> raise DistributionNotFound(req, requirers)
> pkg_resources.DistributionNotFound: The 'secretstorage' distribution
> was not found and is required by vorta
>
> Axel
>
signature.asc
Description: This is a digitally signed message part
Bug#1062604: cython-legacy: Please package new release 0.29.37
Source: cython-legacy Severity: normal Version: 0.29.36-3 X-Debbugs-CC: gin...@debian.org debian-python@lists.debian.org Hi, The cython upstream has released a new 0.29.37 release, that hopefully have brought official python 3.12 support. Please test and package it in Debian and I hope it could solve the compatibility issue between cython-legacy and python 3.12. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: Re: Docu: Need help to understand section about package creation
Hi, (I am off debian-python mailing list -- please CC me. Also, I cannot include previous text in the threads because I don't have them in my mailbox. Sorry!) Reading https://lists.debian.org/debian-python/2024/03/msg00152.html and https://lists.debian.org/debian-python/2024/03/msg00151.html , I can see that https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package is indeed poorly written: *) It still points to pages of GitDpm, which the Python team is not using anymore. *) It does not describe the procedure of packaging from scratch very well. To be precise, it lacks info about packaging from a status where both git repo and the .dsc source package are nonexistant. It doesn't describe the "gbp import-orig" subcommand for packaging initialization, which is suprising. The same issue applies to https://wiki.debian.org/PackagingWithGit . For newcomers, I believe they will get lost at the very first line on https://wiki.debian.org/Python/GitPackaging#Creating_a_new_package , which is "uscan". No one knows why uscan can work with an empty directory. The newcomer may not even know what uscan is (actually they are supposed to know what uscan is in advance -- but explanation should be added here anyway). If you really want a readily-available better documentation, consider reading the official documentation of git-buildpackage at https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/ . After you understand that, merge the remaining useful information from https://wiki.debian.org/Python/GitPackaging to get a thorough understanding. I don't have a good solution to Wiki pages yet since the article logic needs some major editing. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
python3-setuptools uninstallable in Sid due to removed python3-distutils
Hi all, Just to let you all be aware of https://bugs.debian.org/1076036 . Currently in Sid python3-setuptools cannot be installed in Debian Sid due to the removal of python3-distutils. This will become problematic very quickly. python3-distutils Reverse Depends: Depends: python3-all (>= 3.11.5-1~) Depends: python3-versiontools Depends: python3-sage Depends: jhbuild Depends: python3-dockerpycreds Depends: anki |Depends: zfs-dkms (<< 3.12) Depends: wfuzz Depends: python3-setuptools Depends: python3-venv (>= 3.11.5-1~) Depends: python3-full Depends: python3-dev (>= 3.11.5-1~) Depends: python3-azure-cli-core Depends: python3-gnocchiclient Depends: python3-docker Depends: matrix-synapse Depends: hamster-time-tracker Depends: grass-core Depends: flowblade Depends: python3-compose Depends: docker-compose Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: [backintime] Naming of documentation directory
Hi, Regarding https://lists.debian.org/debian-python/2024/10/msg00055.html : Have you made this issue aware by the package maintainers and uploaders as listed on https://tracker.debian.org/pkg/backintime ? If not, please contact them first, ideally by submitting a Debian bug report against source package backintime (and cc the maintainers). Personally I believe renaming the binary package backintime-qt to backintime could be a reasonable move, but I have zero control over it. Only the package maintainers as listed on https://tracker.debian.org/pkg/backintime can decide how to handle this issue. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Testsuite: autopkgtest-pkg-pybuild: weird behavior in my uploaded package
(Please CC me; I am not on the list.)
Hi all,
According to pybuild-autopkgtest(1) [1], it seems that Python packages
that uses Testsuite: autopkgtest-pkg-build will "run the tests in the
same way as pybuild ... exception that tests are not run in the build
directory". I have some confusion on it with my recent uploads.
When I look at fscacher/0.4.1-1.1 upload [2], the autopkgtest failure
for this upload is weird. In [3], it looks like the tests are still to
be executed in the "build" directory. Since this package is not built in
autopkgtest, pytest cannot find anything to test and then directly fails:
74s I: pybuild base:311: cd
/tmp/autopkgtest-lxc.n_cjis13/downtmp/autopkgtest_tmp/build; python3.12
-m pytest
74s = test session starts
==
74s platform linux -- Python 3.12.6, pytest-8.3.3, pluggy-1.5.0
74s rootdir: /tmp/autopkgtest-lxc.n_cjis13/downtmp/autopkgtest_tmp/build
74s configfile: pyproject.toml
74s plugins: mock-3.14.0, cov-5.0.0, typeguard-4.4.1
74s collected 0 items
74s
74s no tests ran in 0.00s
=
74s E: pybuild pybuild:389: test: plugin pyproject failed with: exit
code=5: cd /tmp/autopkgtest-lxc.n_cjis13/downtmp/autopkgtest_tmp/build;
python3.12 -m pytest
74s pybuild-autopkgtest: error: pybuild --autopkgtest --test-pytest -i
python{version} -p 3.12 returned exit code 13
This behavior is different from my understanding of the man page
pybuild-autopkgtest(1).
Can anyone give me some hints on how to solve this issue (and fix this
autopkgtest failure)?
Thanks,
Boyuan Yang
[1]
https://manpages.debian.org/unstable/dh-python/pybuild-autopkgtest.1.en.html
[2] https://tracker.debian.org/pkg/fscacher
[3] https://ci.debian.net/packages/f/fscacher/testing/amd64/54147867/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1095519: O: glyphspkg -- Converter from .glyphspackage to .glyphs files
Package: wnpp Control: affects -1 + src:glyphspkg X-Debbugs-Cc: debian-python@lists.debian.org debian-fo...@lists.debian.org Severity: normal I intend to orphan the glyphspkg package as I do not use it anymore. The package itself is in good shape. The recent versions of fontmake already provides the functionality of handling .glyphspackage file format, and in fact this tool is not needed anymore. The only reverse build-dep uses it in upstream Makefile: -> % build-rdeps glyphspkg Reverse Build-depends in testing/main: -- fonts-junicode The package description is: This package provides a utility to convert GlyphsApp package to monolithic files. It is commonly needed by some open-source font building tools, such as fontmake and fonttools. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
