Re: Eric-22.12 and trove-classifiers
Hi again list The trove-classfiers library is only three minor files and the calver library is a single small file, I don't find it worth it to make Debian packages out of them plus I can only build them using setuptools. Eric contains a ThirdParty directory and I can add the trove-classifiers there and it works perfectly. Is there any drawback from adding trove-classifiers as a patch in the Eric package? /Gudjon
Re: python-tesserocr: flaky autopkgtest
Hello DPT, I have updated the package python-tesserocr [1] to skip the flaky test to fix the issue below. I need a maintainer please to upload the new release version 2.5.2-2 to the Debian archive. [1] https://salsa.debian.org/python-team/packages/python-tesserocr Regards, Malik | | | | On Sat, 14 May 2022 13:45:08 +0200 Paul Gevers wrote: > Source: python-tesserocr > Version: 2.5.2-1 > Severity: serious > X-Debbugs-CC: debian...@lists.debian.org > User: debian...@lists.debian.org > Usertags: flaky > > Dear maintainer(s), > > I looked at the results of the autopkgtest of you package on ppc64el > because it was showing up as a regression for the upload of gcc-12. I > noticed that the test regularly fails and I saw failures on other > architectures too (but not on amd64). > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. > > Paul > > https://ci.debian.net/packages/p/python-tesserocr/ > > https://ci.debian.net/data/autopkgtest/testing/ppc64el/p/python-tesserocr/21168683/log.gz > > autopkgtest [00:42:09]: test upstream: [--- > ...F.. > == > FAIL: test_recognize (tests.test_api.TestTessBaseApi) > Test Recognize with and without timeout. > -- > Traceback (most recent call last): > File > "/tmp/autopkgtest-lxc.zbt5r5ou/downtmp/autopkgtest_tmp/tests/test_api.py", > line 336, in test_recognize > self.assertTrue(res) > AssertionError: False is not true > > -- > Ran 22 tests in 83.470s > > FAILED (failures=1) > autopkgtest [00:43:33]: test upstream: ---]
Re: python-tesserocr: flaky autopkgtest
On Sun, 18 Dec 2022, Malik Mlitat wrote: Hello DPT, I have updated the package python-tesserocr [1] to skip the flaky test to fix the issue below. I need a maintainer please to upload the new release version 2.5.2-2 to the Debian archive. [1] https://salsa.debian.org/python-team/packages/python-tesserocr Uploaded. But the ftp-master server is down, so it's unclear when that will be fixed (and hopefully the uploads that are occurring now will be processed?). Regards, Scott
Re: python-tesserocr: flaky autopkgtest
On December 18, 2022 4:47:39 PM UTC, Scott Talbert wrote: >On Sun, 18 Dec 2022, Malik Mlitat wrote: > >> >> Hello DPT, >> >> I have updated the package python-tesserocr [1] to skip the flaky test to >> fix the issue below. >> >> I need a maintainer please to upload the new release version 2.5.2-2 to >> the Debian archive. >> >> >> [1] https://salsa.debian.org/python-team/packages/python-tesserocr > >Uploaded. But the ftp-master server is down, so it's unclear when that will >be fixed (and hopefully the uploads that are occurring now will be processed?). They will. The upload queue lives on another box and uploads will stay there and be processed for accept once Fasolo is back. Scott K
Re: Python 3.11 for bookworm?
On Thu, Dec 15, 2022 at 04:10:05PM +0100, Thomas Goirand wrote: > On 12/13/22 13:34, Julian Gilbey wrote: > > If Python 3.11 is the default, then it is highly likely that Spyder > > will not be included: debugpy, which is a dependency of Spyder and > > python3-ipykernel (and lots of things that depend on that) seems to > > require major work upstream to make it fully compatible with Python > > 3.11. This is work in progress, but I don't know whether it will be > > ready in time for the freeze. At the moment, I have worked around > > this problem by just skipping the failing tests, but that is far from > > an ideal solution. > > It's probably ok if it's a *TEMPORARY* solution until upstream fixes > everything in time for the release (which is months after the freeze). The > question is: do you believe this may happen for let's say next March? The truth is that I don't know. Upstream is very good, but the Python 3.11 internal changes are very significant, and debugpy (along with pydevd, which is part of debugpy) are deeply affected by this, as they work at the level of Python's internals. So I don't know how long it will take them to make the required changes (and it's far beyond my capability or capacity to do myself). I can hope they'll do it in time for the freeze, but I wouldn't like to place a bet on it. Best wishes, Julian
How do you create entry-points for Python applications?
Hello, a python application isn't a binary but a script. So to invoke such an application there need to be a shell script somewhere in PATH that invoke that script via python3 interpreter. Imagine an application with a GUI (qt, tikinter, gtk, ...). On the upstream site modern python projects using pyproject.toml (only), some use setup.cfg. There you can define "entry points" and the "pip" installer does generate a shell script based on that information and place it in PATH. That is a nice mechanism when installing via pip. On your site as distro maintainers. How do you take care of then when creating deb files? When a project do follow modern python packaging standards using pyproject.toml/setup.cfg and doesn't offer any other explict start shell script. Do you use that pip mechanic for the deb package? Or how do you create your shell scripts? I don't have an real world example of a python application for that. I only have an example of a project (backintime) that don't use pyproject.toml/setup.cfg and offer its own shell script. I'm part of the new maintainer team and we will evolve the project to current python packaging standards; which means using pyproject.toml.
Re: How do you create entry-points for Python applications?
AFAIK Debian helper for Python handles this در 18 دسامبر 2022 19:18:44 (UTC)، c.bu...@posteo.jp نوشت: >Hello, >a python application isn't a binary but a script. So to invoke such an >application there need to be a shell script somewhere in PATH that invoke that >script via python3 interpreter. Imagine an application with a GUI (qt, >tikinter, gtk, ...). > >On the upstream site modern python projects using pyproject.toml (only), some >use setup.cfg. >There you can define "entry points" and the "pip" installer does generate a >shell script based on that information and place it in PATH. >That is a nice mechanism when installing via pip. > >On your site as distro maintainers. How do you take care of then when creating >deb files? >When a project do follow modern python packaging standards using >pyproject.toml/setup.cfg and doesn't offer any other explict start shell >script. Do you use that pip mechanic for the deb package? >Or how do you create your shell scripts? > >I don't have an real world example of a python application for that. > >I only have an example of a project (backintime) that don't use >pyproject.toml/setup.cfg and offer its own shell script. I'm part of the new >maintainer team and we will evolve the project to current python packaging >standards; which means using pyproject.toml. >
Re: How do you create entry-points for Python applications?
Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی: AFAIK Debian helper for Python handles this ;) Yes, but how? Does it ignore the pip-default-entry-point-scripts? Does it create its own script? Do you have to explicit write a script?
Re: How do you create entry-points for Python applications?
On December 19, 2022 5:13:27 AM UTC, c.bu...@posteo.jp wrote: >Am 18.12.2022 23:03 schrieb Danial Behzadi دانیال بهزادی: >> AFAIK Debian helper for Python handles this > >;) Yes, but how? > >Does it ignore the pip-default-entry-point-scripts? Does it create its own >script? >Do you have to explicit write a script? You don't. Pybuild using the pyproject plugin will build a wheel and then install the necessary files in the package using the installer module. The entry point scripts are in the wheel, just like an upstream built wheel. Your best bet is to find a package in the archive that's similar and see how it was done. Scott K
Re: How do you create entry-points for Python applications?
Dear Scott, thanks for the reply. Am 19.12.2022 06:25 schrieb Scott Kitterman: Pybuild using the pyproject plugin will build a wheel and then install the necessary files in the package using the installer module. The entry point scripts are in the wheel, just like an upstream built wheel. Do I get that correct? The entry scripts (their content and their location) is the same installing a package via pip and apt? In that case I'm right trying to make the "pip install" process as correct as possible to save resources for the distro maintainers. Your best bet is to find a package in the archive that's similar and see how it was done. That is why I'm asking here. ;)
Re: How do you create entry-points for Python applications?
On December 19, 2022 6:27:55 AM UTC, c.bu...@posteo.jp wrote: >Dear Scott, > >thanks for the reply. > >Am 19.12.2022 06:25 schrieb Scott Kitterman: >> Pybuild using the pyproject plugin will build a wheel and >> then install the necessary files in the package using the installer >> module. The entry point scripts are in the wheel, just like an >> upstream built wheel. > >Do I get that correct? >The entry scripts (their content and their location) is the same installing a >package via pip and apt? > >In that case I'm right trying to make the "pip install" process as correct as >possible to save resources for the distro maintainers. There are exceptions, but generally that is correct. >> Your best bet is to find a package in the archive that's similar and >> see how it was done. > >That is why I'm asking here. ;) Hopefully someone will chime in with a good example. The only package I maintain that I can think of at the moment with entrypoints and project.toml is too complicated to be a good example. Scott K
