Re: [Help] Re: python-envisage: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" returned exit code 13
On Thu, 10 Feb 2022, Andreas Tille wrote:
Control: tags -1 help
Hi,
I've updated python-envisage in Salsa[1] to the latest upstream version
and bumped its failing predepends to their according latest upstream and
fixed all bugs in those. For envisage I'm stumbling upon a Python3.10
related bug I'd like to ask for help:
...
==
ERROR: test_exclude_multiple
(envisage.tests.test_egg_plugin_manager.EggPluginManagerTestCase)
exclude multiple
--
Traceback (most recent call last):
File
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_plugin_manager.py",
line 115, in test_exclude_multiple
self._add_eggs_on_path([self.egg_dir])
File
"/build/python-envisage-6.0.1/.pybuild/cpython3_3.10_envisage/build/envisage/tests/test_egg_based.py",
line 59, in _add_eggs_on_path
raise SystemError("Cannot find eggs %s" % errors)
SystemError: Cannot find eggs {}
I spent some time looking into this. The problem is that upstream
includes binary eggs (which are Python version specific) as part of its
test suite. The problem here is that there are no eggs included for
Python 3.10. Upstream is aware of this[1] but unfortunately, that patch
can't be applied because it is a binary patch. They have also later[2]
removed the binary eggs completely, but that patch can't be applied either
because it involves files that are not in the PyPI distribution. The best
solution might be do what Fedora did[3], but for that we'd probably have
to switch to using a GitHub tarball instead of the PyPI tarball because
the PyPI tarball is missing files.
Scott
[1]
https://github.com/enthought/envisage/commit/d29e6f438d16fc6ac6ede5381ba12d9849187b14
[2]
https://github.com/enthought/envisage/commit/6e5c7ba004e8700bd009c3d2b9444d543709a4d7
[3]
https://src.fedoraproject.org/rpms/python-envisage/c/a20fa2cf6fe0eaf7604394a8b93bf8d3b48bc599?branch=rawhide
Re: Python Team membership request for Nicotine package
Thanks Stefano! I've just moved the package to the python team repo: https://salsa.debian.org/python-team/packages/nicotine Best, François Le dimanche 13 février 2022 à 14:49 +, Stefano Rivera a écrit : > Hi François (2022.02.12_10:15:46_+) > > I think your request just got missed or forgotten about. > > I've added you to the team, welcome! > > SR > > > Hello Python Team, > > > > unless I'm mistaken, I haven't received any answer to my requests. > > Is > > the team interested by co-maintaining the nicotine package? > > > > > > Best, > > François > > > > > > > > Le dimanche 30 janvier 2022 à 17:38 +0100, François Mazen a écrit : > > > Dear Python team, > > > > > > I'm working on reintroduction of the nicotine package [1] [2]. > > > This > > > software is written in python and Bastian Germann advises me to > > > move > > > the package to the Python Team's umbrella [3]. > > > > > > I really like this idea so I'm requesting to be part of the > > > Debian > > > Python team. My salsa login is mzf. I've read the team policy and > > > I > > > accept it. > > > > > > The package is currently at [4] in good shape. I guess it should > > > move > > > to the salsa python team group and comply to the policy (use gbp > > > pq > > > for > > > instance). So feel free to guide me with the migration. > > > > > > Thanks! > > > François > > > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966000 > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004401 > > > [3] https://mentors.debian.net/package/nicotine/ > > > [4] https://salsa.debian.org/mzf/nicotine > > > > >
Re: Python Team membership request for Nicotine package
Hi François (2022.02.12_10:15:46_+) I think your request just got missed or forgotten about. I've added you to the team, welcome! SR > Hello Python Team, > > unless I'm mistaken, I haven't received any answer to my requests. Is > the team interested by co-maintaining the nicotine package? > > > Best, > François > > > > Le dimanche 30 janvier 2022 à 17:38 +0100, François Mazen a écrit : > > Dear Python team, > > > > I'm working on reintroduction of the nicotine package [1] [2]. This > > software is written in python and Bastian Germann advises me to move > > the package to the Python Team's umbrella [3]. > > > > I really like this idea so I'm requesting to be part of the Debian > > Python team. My salsa login is mzf. I've read the team policy and I > > accept it. > > > > The package is currently at [4] in good shape. I guess it should move > > to the salsa python team group and comply to the policy (use gbp pq > > for > > instance). So feel free to guide me with the migration. > > > > Thanks! > > François > > > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966000 > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004401 > > [3] https://mentors.debian.net/package/nicotine/ > > [4] https://salsa.debian.org/mzf/nicotine > -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1005701: ITP: python-untangle -- Convert XML to a Python object
Package: wnpp Severity: wishlist Owner: Julian Gilbey X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-untangle Version : 1.1.1+git20200807.fb916a9 Upstream Author : Christian Stefanescu * URL : https://github.com/stchris/untangle * License : MIT Programming Lang: Python Description : Convert XML to a Python object Untangle has a very simple API for converting XML to a Python object: you just call the "parse" function on either a string, a filename or a URL. This package is used in the tests for pydevd, which I am currently working on packaging (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933070). It will be maintained within the Debian Python Team. Best wishes, Julian
Re: Advice wanted: handling weird vendoring situation
> So the solution I'm currently in the process of trying is to copy the > version from the oldest supported Python version at Debian package > build time. We'll see how this goes > >> Perhaps they have a maintenance script for updating the vendored >> dependencies? You could use that to find out how to reverse the changes, >> or start from a clean slate? > > Unlikely; some of their vendored dependencies date back to Python 2.5! In that case, I think this is the issue that must be solved first: Ensuring that their code is compatible with the *latest* published version, and vendoring the system version at build time. Not a good solution, since it will still leave the system vulnerable when one of the dependencies gets a security update, but better than shipping a static version that might have numerous issues and will no longer receive any patches. The alternative would be that they take full responsibility for their vendored code, but then it will be much harder to detect when they're affected by a vulnerability.
