Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-04-28: > > * https://salsa.debian.org/python-team/packages/python-pyppmd I reviewed through python-pyppmd and my remark are somewhat similar to packages I previously saw. 1. The debian/changelog misses the introduction of the patch to fix build failures on non-amd64 CPU architectures. 2. Introduction of autopkgtest-pkg-pybuild instead of -python would render the Testsuite non-superficial. This is not mandatory, but it is a low hanging fruit that would bring substancial quality to the package. I note the test is running at build time for this one, which is good. :) 3. I suggest again dh-sequence-python3 instead of dh-python. All that being said, the package looks to me in good shape, and I will have no objections to upload it once the changelog matches all the changes since 1.1.0+ds-1. I'll have a look at python-brotlicffi next, but I don't expect to have anything new to say. Don't hesitate to apply my existing feedback and suggestions on this package if I don't follow up explicitly on it, and to ping again once you think it is ready for upload. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Future Crew - Second Reality (part II) signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hi again Yokota, yokota, on 2024-04-28: > > * https://salsa.debian.org/python-team/packages/python-bcj I went through python-bcj this time, my observations follow. 1. Comparing to 1.0.2+ds-1, 1.0.2+ds-2, there are a few more changes than the ones documented in the debian/changelog. Please also document introduction of the quilt patch 0001-Avoid-to-use-sparc-keyword.patch, and introduction of the file debian/python3-bcj.docs. This has to be done before upload. 2. I would also recommend to enable build time tests and then replace the Testsuite by autopkgtest-pkg-pybuild, similarly to what I explained for python-inflate64. 3. I would also suggest the migration to dh-sequence-python3, similarly to what I explained for python-inflate64. The package looks in otherwise good shape, and I will be happy to upload once at least the content of the debian/changelog is matching the actual packaging changes since version 1.0.2+ds-1. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `-on air: Malcolm Smith - Monkey Signature signature.asc Description: PGP signature
Re: py7zr-related python packages was updated
Hi Yokota, yokota, on 2024-04-28: > Hello Debian Python Team, > > > My py7zr-related Python packages are updated to fix some issues. […] > > * https://salsa.debian.org/python-team/packages/python-inflate64 Thanks for your work on the py7zr stack, I reviewed through python-inflate64 and noticed the following documented changes were already part of the package in version 1.0.0+ds-1, so they should not appear in the changelog of version 1.0.0+ds-2: * Standards-Version: 4.7.0 (routine-update) * Testsuite: autopkgtest-pkg-python (routine-update) If you want to upload the package as-is without further changes for it to migrate to testing, the only entry would be: * Source-only upload. I would proceed to a source-only upload if you like, but I though it would be a good time for two recommendations with relation to the test suite (plus one recommendation relative to Python packaging). 1. Upstream source code embeds a pytest test suite below the tests/ directory. I think it would be well worth running them at build time through pybuild infrastructure. In the present case, this can be done easily by appending the build dependency python3-pytest to the package (the nocheck marker is to indicate the build dependency is only needed for running the test suite). 2. Once the test suite is up and running through pybuild, you may have noticed that routine-update added a Testsuite field to your debian/control. This enables somewhat automated autopkgtest to your package with little to no effort. The Testsuite automatically appended by routine-update is autopkgtest-pkg-python, but it is a bit limited as it only runs superficial checks: loading the Python module and check whether its version can be fetched. If you replace the Testsuite by autopkgtest-pkg-pybuild, the superficial test will be replaced by the test caught by pybuild, which in turn will have much more coverage. Standard migration time from unstable to testing is five days, but with non- superficial autopkgtest, this can be reduced as low as two days. 3. I would also suggest moving from dh-python to dh-sequence-python3, this will allow you to remove the --with=python3 argumen from your debian/rules file. Let me know when you have pushed commits for a source-only upload, or integrated the test suite to the packaging, and I will proceed to another review and hopefully upload. Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Cosmosquad - Jam For Jason PS: I'm under the impression these changes didn't make it to the VCS initially, hence the confusion with changelog entries, but I may guess wrong; the debian/1.0.0+ds-1 tag is missing though. Andreas, do you per chance still have the tag on your hard drive? signature.asc Description: PGP signature
colorspacious adopted
Hi, Thank you Julian for having taken the time to collate the list of orphaned packages. Julian Gilbey, on 2024-03-14: > #1065243 O: colorspacious -- library for doing colorspace conversions I adopted colorspacious (it was the first hit still orphaned while reading in the alphabetical order). I'll probably pick other packages, but I already have too many on my radar. Co- uploaders are more than welcome: actually I prefer not being alone on packages, in case I break an arm or something. In hope this helps, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Re: Suggesting change in DPT policy
Hi all, Andreas Tille, on 2024-02-28: > Am Tue, Feb 27, 2024 at 04:08:51PM +0100 schrieb Timo Röhling: > > 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. > > You are making an important point here. Thanks Timo for raising this point, it is important indeed. > > 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. > > I think this is a very good idea. In case MR[1] will be accepted this > should be added to the policy as well. I'm not sure whether the > "Maintainership" paragraph is the best place to add this. I wonder if > you (or someone with the same doubts) might want to suggest another MR > to add this debian/README.DPT feature. Policy changes aside, 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.) Of course this could be overred with a --readme-reviewed flag once ready to finalize the package with automation for instance. > [1] > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20 [2]: https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Dream the Electric Sleep - Utopic signature.asc Description: PGP signature
Re: debian/watch: How to watch version tags and what to capture?
Hello, c.bu...@posteo.jp, on 2023-09-17: > Why do we have to increase the volume of the list with that topic? Can > we just discuss this on an issue tracker about the tracker? ;) > Isn't this what a tracker is for? Bugs against the package tracker system can be reported against the pseudo package "tracker.debian.org" in the bug tracker system[0] using: $ reportbug tracker.debian.org You can see whether there could be a possibly duplicate issue on the corresponding web page[1]. [0]: https://bugs.debian.org [1]: https://bugs.debian.org/tracker.debian.org Hope this helps, -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Bug#1050081: ITP: python-parsl -- Parallel Scripting Library
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org * Package name: python-parsl Version : 2023.08.14 Upstream Contact: Yadu Nand Babuji , et al. * URL : https://github.com/Parsl/parsl * License : Apache 2.0 Programming Lang: Python Description : Parallel Scripting Library Parsl extends parallelism in Python beyond a single computer. . One can use Parsl just like Python's parallel executors but across multiple cores and nodes. However, the real power of Parsl is in expressing multi-step workflows of functions. Parsl lets one chain functions together and will launch each function as inputs and computing resources are available. This package is a new dependency for upgrading the qiime2 distribution on Debian Med radar. Since the module parsl itself is a bit more generic than medical field, I intend to put the package under the Debian Python team umbrella. A stub of packaging is available on Salsa[1]. [1]: https://salsa.debian.org/python-team/packages/python-parsl/ Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/2, please excuse my verbosity `- signature.asc Description: PGP signature
Re: Python pybuild system & setup.cfg
Hi Hilmar, Preuße, Hilmar, on 2023-03-23: > I'm a little bit lost, by building the pssh package. The upstream author > released a new version, which changed the build system. Before I had a > setup.py in the root directory, now there is a pyproject.toml and a > setup.cfg file, the setup.py is gone. The debian/rules file calls the dh > sequencer: > > DESTDIR=debian/tmp > > %: > dh $@ --buildsystem=pybuild > > The build fails right at the beginning, with: > > dh clean --buildsystem=pybuild >dh_auto_clean -O--buildsystem=pybuild > I: pybuild base:240: python3.11 setup.py clean > python3.11: can't open file '/<>/setup.py': [Errno 2] No > such file or directory > E: pybuild pybuild:388: clean: plugin distutils failed with: exit > code=2: python3.11 setup.py clean > > The content of the pyproject.toml is: > > [build-system] > requires = ["setuptools"] > build-backend = "setuptools.build_meta" > > The build Deps I use until now are: > > Build-Depends: debhelper-compat (= 13), > python3, > python3-setuptools, > dh-sequence-python3 > > I don't know what needs to be changed to convince debhelper to use the > setup.cfg instead of setup.py. My wild guess is that I have to change my > BD's but I don't know what needs to be added/removed. offpunk upstream made a similar move recently. I added the following packages to build dependencies: * flit * pybuild-plugin-pyproject Hope this helps, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. signature.asc Description: PGP signature
Bug#1031939: ITP: offpunk -- CLI and offline-first smolnet browser for Gemini, Gopher, etc
Package: wnpp Severity: wishlist Owner: Étienne Mollier X-Debbugs-Cc: debian-de...@lists.debian.org X-Debbugs-Cc: debian-python@lists.debian.org * Package name: offpunk Version : 1.8 Upstream Contact: Ploum * URL : https://git.sr.ht/~lioploum/offpunk/ * License : BSD-2-Clause Programming Lang: Python Description : CLI and offline-first smolnet browser for Gemini, Gopher, etc Offpunk is a command-line browser and feed reader dedicated to browsing the Web, Gemini, Gopher and Spartan. Thanks to its permanent cache, it is optimised to be used offline with rare connections but works as well when connected. . Offpunk is optimised for reading and supports readability mode, displaying pictures, subscribing to pages or RSS feeds, managing complex lists of bookmarks. Its integrated help and easy commands make it a perfect tool for command-line novices while power-users will be amazed by its shell integration. There are many clients for Web, Gemini, Gopher, etc, protocols in the archive. The line oriented interface makes this one more suitable to dumb terminals than the average text user interface browser. Also, the tooling to handle reading Internet resources offline sets it apart from most other browsers. I would like to maintain this package under DPT umbrella. There is a stub of packaging in progress on Salsa[1]. [1]: https://salsa.debian.org/python-team/packages/offpunk Have a nice day, :) -- .''`. Étienne Mollier : :' : gpg: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/7, please excuse my verbosity `-on air: Karnataka - Secrets Of Angels signature.asc Description: PGP signature
Re: Bug#1029593: nibabel: (armel autopkgtest) needs update for NumPy 1.24
Hi Andreas, Andreas Tille, on 2023-01-29: > Any idea what might be wrong here? The nibabel 5.0.0-1 migration log[2] and architecture memo[3] show that I have been too strict for my test skipping heuristic: ___ test_a2f_nan2zero_range @pytest.mark.skipif(os.uname().machine == 'armv7l', reason="fails on armel only, see #1029593.") def test_a2f_nan2zero_range(): […] The uname machine name may not have been armv7l on the test bed, leading to the present crash. This should read like the below and I consider pushing a "fix" in that direction tomorrow: @pytest.mark.skipif(os.uname().machine[0:3] == 'arm', reason="fails on armel only, see #1029593.") Of course it would be even better to fix the root cause on armel. Besides, I notice there is a regression in dipy[4], which may be caused by the nibabel version bump. Since we are in transission freeze, I suspect the package needs to be reverted to version 4. That being said the error message in amd64 doesn't make it very obvious the problem comes from nibabel, so I'm having a closer look before stating anything definitive. [2]: https://ci.debian.net/data/autopkgtest/unstable/armel/n/nibabel/30782893/log.gz [3]: https://wiki.debian.org/ArchitectureSpecificsMemo [4]: https://ci.debian.net/data/autopkgtest/testing/amd64/d/dipy/30816896/log.gz Thanks Graham for having kept an eye on this, Sorry for my mess, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. On air: Lee Abraham - Days Gone By signature.asc Description: PGP signature
Re: Python 3.11 for bookworm?
Hi, For information I tagged [#1027851] with help needed for the python3.11 port of pytorch, following a message from its main uploader. To people who might like to have a look at it: please be careful as pytorch may be quite the resource hog and time sink if one's time is better spent somewhere else. #1027851: pytorch FTBFS with Python 3.11 as default version [#1027851]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027851 Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/1, please excuse my verbosity. On air: A Liquid Landscape - Secret isle signature.asc Description: PGP signature
Re: request for review: python-pyglfw
Hi Timo,
Timo Röhling, on 2022-12-04:
> * É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
Ack, these look like an oversight of mine. These should be
fixed now. Sorry for the mess.
> - 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.
Ack, I did some further testing, and it seems to be fine to move
to arch all, unless I missed a bit.
> - The "Build-Depends: libglfw3 " seems unnecessary, because
> AFAICT, there is no test suite in the package at all.
If I remove it, the test scanner seems to catch something which
in turn fails to load the module:
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11/build;
python3.11 -m unittest discover -v
glfw (unittest.loader._FailedTest.glfw) ... ERROR
==
ERROR: glfw (unittest.loader._FailedTest.glfw)
--
ImportError: Failed to import test module: glfw
Traceback (most recent call last):
File "/usr/lib/python3.11/unittest/loader.py", line 440, in
_find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.11/unittest/loader.py", line 350, in
_get_module_from_name
__import__(name)
File
"/<>/.pybuild/cpython3_3.11/build/glfw/__init__.py", line 43, in
raise ImportError("Failed to load GLFW3 shared library.")
ImportError: Failed to load GLFW3 shared library.
In doubt, I'll keep the test dependency for now. For some
reason, I still witness this error in spite of the library
installed on riscv64, but arm64 build went alright; there might
be something wrong with the dependency.
> - 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 forcefully run it when running sbuild, so I tend to forget to
append it. I have a more in-depth test in preparation, but it's
commented out due to #1025312. Anyway, I added the necessary
statement to d/control, shouldn't hurt.
> - I've never set LC_ALL in d/rules. Is there a particular reason
> why it is necessary?
That's a safety precaution for reproducible builds, when some
artifacts are locale dependent. This may not be 100% necessary
in the present case, but I tend to keep it around just in case.
> - Personally, I prefer having dh-sequence-python3 in Build-Depends,
> so I don't have to add --with python3 in d/rules.
I was not aware of that (or just overheard it exists), I give it
a try. Thanks!
> 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!
Thanks for your time and the warm welcome! :)
Have a nice day, :)
--
Étienne Mollier
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
request for review: python-pyglfw
Hi, 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 Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. On air: The Tangent - The World We Drive Through signature.asc Description: PGP signature
Re: rdflib: URLInputSource can be abused to retrieve arbitrary documents if used naïvely
Control: tags -1 help Hi all, Apparently, help is needed from upstream rdflib development team on the critical security bug #1023399[0] and their respective entry on their bug tracker[1]. I tried to have a look some time ago, but didn't make sense of the issue. I tag the bug appropriately to raise awareness, in case someone were to have an idea for a proper patch. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012482 [1]: https://github.com/RDFLib/rdflib/issues/1844 In hope this helps indeed, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity. On air: OSI - Set The Controls For The Heart Of The Sun signature.asc Description: PGP signature
joining the python team
Ehlo, I would like to address #953053 affecting psychopy, under Debian Med team. For parts of the package to operate properly, they require several missing python dependencies. I noted some are already under RFP, and one ITP. I would be happy to join the team to help adding these packages and maintain them on the long run. In exchange, I may pop up from time to time to help sort random issues in various python packages. Some random facts: * my salsa login is emollier; * I have read a debian python team policy document at [1] and I agree to adhere to it; * I also happen to have hit the wiki page, but have not followed all the links, yet[2]; * I have plain quilt burned in my fingers but now that I read about gbp pq, I will try to learn it; * I subscribed to the debian-python@l.d.o mailing list; * I also have joined the team on tracker.debian.org[3] to get contacts, bugs, etc; * I am a DD. [1]: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst [2]: https://wiki.debian.org/Teams/PythonTeam [3]: https://tracker.debian.org/accounts/subscriptions/ Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
pkg_resources modules detection issues in various packages
TL;DR: 1. Has someone an idea of usage of the module pkg_resourses, specifically the iterator pkg_resources.iter_entry_points, for fetching local resources? 2. Is someone aware of recent (as in the past year or so) breaking changes in the way the pkg_resources module works? Greetings, While attempting to give a hand with maintenance of various debian-med python packages, various sources were failing their test suites due to diverse failures to import their test modules through the mechanism provided by the module pkg_resources. Andreas Tille first noted this in python-cobra: https://lists.debian.org/debian-med/2020/09/msg00369.html Then I hit some issues involving pkg_resources as well in Qiime, while attempting to update it, and it turned out even the current version does not manage to pass tests, due to failure to load a dummy-plugin with this system: https://lists.debian.org/debian-med/2020/10/msg00014.html https://salsa.debian.org/med-team/qiime Note the package will incorrectly report that the QIIMETEST variable should be set, although it actually is. Here is a sample error from a build attempt of qiime_2019.10.0-1.dsc: == ERROR: test_import_root (qiime2.tests.test_artifact_api.TestImports) -- Traceback (most recent call last): File "/tmp/autopkgtest.MTf3Wq/build.GrO/src/.pybuild/cpython3_3.8_qiime/build/qiime2/tests/test_artifact_api.py", line 23, in setUp get_dummy_plugin() File "/tmp/autopkgtest.MTf3Wq/build.GrO/src/.pybuild/cpython3_3.8_qiime/build/qiime2/core/testing/util.py", line 19, in get_dummy_plugin raise RuntimeError( RuntimeError: When running QIIME 2 unit tests, the QIIMETEST environment variable must be defined so that plugins required by unit tests are loaded. The value of the QIIMETEST environment variable can be anything. Example command: QIIMETEST=1 nosetests The get_dummy_plugin function is a wrapper around a class which ultimately calls an iterator like this to build a for loop: pkg_resources.iter_entry_points(group='qiime2.plugins') where qiime2/plugins.py is available at the root of the source code. My main problem is: I did not manage to get this construction to return a proper object to point to the dummy plugin stored at that location for the test suite, even when making sure the sys.path includes the current working directory prior to including the pkg_resources module. Nilesh Patra also followed up with something related to pkg_resources on the package gubbins and the open bug #97, although the situation seemed different this time, as this package shows issues in the requirements parser of pkg_resources and not the distribution locator: https://lists.debian.org/debian-med/2020/10/msg00015.html https://bugs.debian.org/97 I even saw something somewhat similar in the present list archives recently, although altering the PYTHONPATH, or even the sys.path directly, did not help in my case: https://lists.debian.org/debian-python/2020/10/msg5.html I'm afraid I'm not at ease with dealing with pkg_resources, although I did try to make sense of how it is supposed to work, by referring to its documentation, which I believe is here: https://setuptools.readthedocs.io/en/latest/pkg_resources.html All these test failures show slightly different symptoms, I even tested Qiime building on Buster, and the issue was already present, while former versions of python-cobra or gubbins made it to Buster, so it is quite possible they are unrelated after all. But just in case, is someone aware of recent breaking changes in the way pkg_resources module works? Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/3, please excuse my verbosity. signature.asc Description: PGP signature
Re: [Debian-med-packaging] pauvre is missing sklearn despite the package is installed
Étienne Mollier, on 2020-04-27 20:00:42 +0200: > Andrey Rahmatullin, on 2020-04-27 20:12:33 +0500: > > On Mon, Apr 27, 2020 at 01:17:50PM +0200, Andreas Tille wrote: > > > pkg_resources.DistributionNotFound: The 'sklearn' distribution was not > > > found and is required by pauvre > > It's actually called scikit-learn, not sklearn, see e.g. > > /usr/lib/python3/dist-packages/scikit_learn-0.22.2.post1.egg-info and > > https://pypi.org/project/sklearn/ > > Hi Andrey, > > Thank you for the pointers. I have a bit of time this evening, > will see if the test can be started with that information. Hi Andreas, I pushed a change which modifies the manifest in setup.py. This did some good for running `pauvre -h`. I believe testing can move forward. Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
Re: [Debian-med-packaging] pauvre is missing sklearn despite the package is installed
Andrey Rahmatullin, on 2020-04-27 20:12:33 +0500: > On Mon, Apr 27, 2020 at 01:17:50PM +0200, Andreas Tille wrote: > > pkg_resources.DistributionNotFound: The 'sklearn' distribution was not > > found and is required by pauvre > It's actually called scikit-learn, not sklearn, see e.g. > /usr/lib/python3/dist-packages/scikit_learn-0.22.2.post1.egg-info and > https://pypi.org/project/sklearn/ Hi Andrey, Thank you for the pointers. I have a bit of time this evening, will see if the test can be started with that information. Kind Regards, -- Étienne Mollier Fingerprint: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d Help find cures against the Covid-19 ! Give CPU cycles: * Rosetta@home: https://boinc.bakerlab.org/rosetta/ * Folding@home: https://foldingathome.org/ signature.asc Description: PGP signature
