Re: Packaging of pdm (Was: pdm-pep517: Shall we package it now?)
On 2022-07-03 00 h 49, Boyuan Yang wrote: > 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 Nice! As I'm sure people will confuse "python3-pdm" (the cli tool) and "python3-pdm-pep517" (the tool used to build packages), I've created a Lintian tag: https://salsa.debian.org/lintian/lintian/-/merge_requests/401 -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
Re: pdm-pep517: Shall we package it now?
On Thu, Jul 07, 2022 at 03:36:30PM -0400, Boyuan Yang wrote: > 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 Brilliant! Thanks for this! (I think you'll need to do a source-only upload now to allow migration to testing, unless the procedures have changed recently.) Best wishes, Julian
Re: Making py2dsp/pypi2deb the default tool to create Python-based packages in Debian
Hi! El vie, 8 jul 2022 a la(s) 00:10, Sandro Tosi (mo...@debian.org) escribió: > Hello, > Piotr has kindly moved pypi2deb to salsa[1] and given me access to the > project so i was able to merge my changes and release[2] a new version > of this tool in Debian. > > [1] https://salsa.debian.org/python-team/tools/pypi2deb > [2] > https://tracker.debian.org/news/1343951/accepted-pypi2deb-320220707-source-into-unstable/ > > My goal is to make py2dsp (contained in pypi2deb) the default tool > used to create Python packages in Debian (like many other > language-specific tools already do f.e. for go, rust, npm, etc). The > new release contains several enhancements that should cover many of > the packaging needs, in particular: > > * the ability to package directly from a github project url > * create the salsa project in the DPT group > Great, this is a very useful tool. I used your fork and cover all that I need > Please let me know if you think something is missing, or should be > expanded/fix, you can also open bugs against the package or directly > MR to the salsa project. > > Should we start advertising this tool in other locations, like the > python policy, guidelines, wiki, etc? what do y'all think? > I think that it should be mentioned at least here [0][1]. IMO they're the first resources that are checked when someone starts packaging Python modules in Debian. [0] https://www.debian.org/doc/packaging-manuals/python-policy/ [1] https://wiki.debian.org/Python/LibraryStyleGuide Cheers, Emmanuel > > Thanks, > -- > Sandro "morph" Tosi > My website: http://sandrotosi.me/ > Me at Debian: http://wiki.debian.org/SandroTosi > Twitter: https://twitter.com/sandrotosi > >
Asking for help for python-xlib
Hello everybody, I'm working on the new upstream release 0.31 and I'm looking for this bug [0]. But, I can not reproduce it. If I run in 0.29 and 0.31 the tests finish successfully, but in [1] fails in different archs. Could you reproduce it? Could you give me some advice/tips/clues about why I cannot reproduce it, please? Anyway I created this patch, because I suspect that for some reason, the self.display.flush() is raising the Exception before pytest can catch it, but I don't think that is possible. ``` From: Emmanuel Arias Date: Wed, 6 Jul 2022 18:10:50 -0300 Subject: Use context manager to avoid error in test. Use context manager in tests to avoid an error during the Build in Debian. Bug-Debian: https://bugs.debian.org/1006033 --- test/test_xlib_display.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/test/test_xlib_display.py b/test/test_xlib_display.py index a41c53b..a2e31f3 100644 --- a/test/test_xlib_display.py +++ b/test/test_xlib_display.py @@ -52,8 +52,9 @@ class TestXlibDisplay(unittest.TestCase): self.assertEqual(str(self.display.display.socket_error), "Display connection closed by client") def test_can_close_display_and_check_for_error(self): - self.display.close() - self.assertRaises(Xlib.error.ConnectionClosedError, self.display.flush) + with self.assertRaises(Xlib.error.ConnectionClosedError): + self.display.close() + self.display.flush() def test_return_fileno(self): self.assertTrue(isinstance(self.display.fileno(), int)) ``` [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006033 [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-xlib.html Thanks! Cheers, Emmanuel OpenPGP_0xFA9DEC5DE11C63F1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: archive rebuild for pytest from experimental
Hi, Am 16.06.22 um 10:05 schrieb Julian Gilbey: ... Great, thanks. Since the pygments in testing fails on pytest 7.2.1, and the version in experimental depends on pytest >= 7.0, we'll need to do the following when we are ready to upload pytest 7.2.1 to unstable: * Mark pytest 7.2.1 as Breaks: pygments (<< 2.12.0) looking at the autopkgtest on the CI pygments is still failing while testing with versions from testing. Mostly because I think as pytest < 7 (from testing) is used. All other versions differences are not critical I guess. The following list of used packages are given by the different versions between testing and unstable. testing: python3-lib2to3 all 3.9.12-1 testing: python3-distutils all 3.9.12-1 testing: python3-toml all 0.10.2-1 testing: python3-pytest all 6.2.5-3 unstable: python3-lib2to3 all 3.10.5-1 unstable: python3-distutils all 3.10.5-1 unstable: python3-tomli all 1.2.2-2 unstable: python3-pytest all 7.1.2-2 Currently python3-pytest hasn't an entry for breaking on pygments like Julian was proposing. Maybe I'm still missing something. -- Regards Carsten
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
[no subject]
Nilson F. Silva
