Re: request to join python-team/packages group on salsa
On 10/3/21 7:18 PM, Afif Elghraoui wrote: > > > On 10/3/21 6:50 PM, Sandro Tosi wrote: >>> I sometimes need to add or make updates to python packages. Currently, I >>> just uploaded a newer upstream version of httpbin and I'd like to push >>> the changes to the git repository, which resides in python-team/packages. >> >> httpbin has been orphaned, so it appears as if this repo should be >> moved from the python-team to the debian namespace (only admins can do >> that). >> >> please let us know if you still want to join the team. >> > > I'd still like to join. > ...so may I join? My salsa login again: afif thanks and regards Afif
Re: request to join python-team/packages group on salsa
On 10/3/21 6:50 PM, Sandro Tosi wrote: >> I sometimes need to add or make updates to python packages. Currently, I >> just uploaded a newer upstream version of httpbin and I'd like to push >> the changes to the git repository, which resides in python-team/packages. > > httpbin has been orphaned, so it appears as if this repo should be > moved from the python-team to the debian namespace (only admins can do > that). > > please let us know if you still want to join the team. > I'd still like to join. thanks and regards Afif
request to join python-team/packages group on salsa
Hello, I sometimes need to add or make updates to python packages. Currently, I just uploaded a newer upstream version of httpbin and I'd like to push the changes to the git repository, which resides in python-team/packages. Salsa login: afif I have read and accept https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي https://afif.ghraoui.name
Re: pybuild renaming extensions breaks upstream code
Hi, Dmitry,
Thanks for your reply
على السبت 2 تـمـوز 2016 23:03، كتب Dmitry Shachnev:
>> Is there a better way around this problem?
> If it is not a Python extension but rather a generic plugin, you can tell
> dh_python2 not to touch it (i.e. via the -X flag), or better install it to
> some private directory different from dist-packages.
It's a Python extension as far as I know. After investigating this a bit
more, it seems that numpy's ctypeslib.load_library function can guess
the library's extension. So for the unit test (before dh-python has
renamed anything and the library is still librarybasename.so), it can
guess properly if it's called as
numpy.ctypeslib.load_library("librarybasename","/path/to/library/")
but this won't work afterwards. I instead get
File "/usr/lib/python2.7/dist-packages/numpy/ctypeslib.py", line
163, in load_library
raise OSError("no file with expected extension")
OSError: no file with expected extension
Would it be a good idea to patch numpy to also look for multiarch
strings in the suffix?
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
signature.asc
Description: OpenPGP digital signature
pybuild renaming extensions breaks upstream code
Hello,
I'm maintaining a set of python modules that have this pattern of code
for finding compiled extensions (this example is from the kineticstools
package):
~~~
if platform.system() == "Windows":
libfn = "tree_predict.dll"
path = os.path.dirname(os.path.abspath(__file__))
windowsLib = path + os.path.sep + libfn
if os.path.exists(windowsLib):
self._lib = np.ctypeslib.load_library(libfn, path)
else:
raise Exception("can't find tree_predict.dll")
else:
DLL_PATH = _getAbsPath("tree_predict.so")
if os.path.exists(DLL_PATH):
self._lib = np.ctypeslib.load_library("tree_predict.so",
DLL_PATH)
else:
raise Exception("can't find tree_predict.so")
~~~
When the package is built and the architecture is renamed:
I: dh_python2 fs:322: renaming tree_predict.so to
tree_predict.x86_64-linux-gnu.so
the upstream code breaks. What I've done in the past is patch it so that
it searches for the extension the way we rename it (which I get using
sysconfig.get_config_var('MULTIARCH')) as in the patch at
http://anonscm.debian.org/git/debian-med/pbh5tools.git/tree/debian/patches/multiarch-module-path.patch
Is there a better way around this problem?
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Re: Bug#798066: Multiarch-renamed python extensions not found during autopkgtest testing
على الجمعـة 11 كانون الأول 2015 03:09، كتب Antonio Terceiro: > I also > don't see other python packages that contain compiled extensions needing > to do this sort of thing. > I have a few other packages that have this problem -- python-cobra is one. For two other packages (python-pbh5tools and kineticstools), I disabled tests that require the compiled extensions because they were failing for this reason. > I tried python-pysam here, and after some trial and error, I can also > reproduce > the same issue outside of autopkgtest. The issue is that Python load path is > being confused by the fact that you are on root of the source package: > [...] Many thanks for that information. I can reproduce that effect as well and things are making much more sense now. Now, I just need to find a proper solution to this python module priority problem. > > So your problem has nothing to do autopkgtest, other than the fact that > autopkgtest always starts the tests from the root of the source package. > Thanks-- I didn't set out to bash autopkgtest with this. I just wanted to know why the tests weren't running properly and how to resolve that problem. Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name signature.asc Description: OpenPGP digital signature
Re: Bug#798066: Multiarch-renamed python extensions not found during autopkgtest testing
Hi,
على الأربعاء 9 كانون الأول 2015 05:25، كتب Antonio Terceiro:
> autopkgtest does not do anything special wrt dependencies, it will
> install exactly what you told it to in debian/tests/control
[...]
>
> I am therefore closing this bug.
The problem is not that something is not installed. The problem is that
the multiarch configuration for python is not right in autopkgtest (or
schroot). During the package build, dh-python renames the compiled
extension to contain the multiarch triplet. For some reason, only in
autopkgtest, python is not properly configured to find the extension
after it has been renamed, so autopkgtest runs requiring the compiled
extensions fail.
So should we continue to have hacks like this to get autopkgtest to find
multiarch-renamed extensions?
cd /usr/lib/python2.7/dist-packages/pysam
gnutype=`dpkg-architecture -qDEB_TARGET_GNU_TYPE`
for so in *.${gnutype}.so ; do sudo ln -sf $so `basename $so
.${gnutype}.so`.so ; done
http://anonscm.debian.org/cgit/debian-med/python-pysam.git/tree/debian/tests/run-nose-tests
regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Multiarch-renamed python extensions not found during autopkgtest testing
Hi, debian-python, For Debian Med's python packages that have compiled extensions, I noticed that test suites run via autopkgtest fail because the package cannot find those extensions, as they've been renamed with the multiarch triplet. It seems to only be a problem with autopkgtest because I have in one case manually installed such a package and successfully ran its test suite. I therefore reported #798066 [1] against autopkgtest, but quite some time has elapsed since then and I'd like to get this resolved. Does anyone know why this might be the case? Autopkgtest for these packages is currently not very helpful because there are many spurious failures due to this issue. There are more details in my original bug report [1]. Many thanks and regards Afif 1. http://bugs.debian.org/798066 -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: Request to Join DPMT
Because I got no response to my request from ten days ago (below), I am maintaining python-avro within Debian Med. I was sponsored there and it has already been accepted by the ftp-masters. Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name On الخميس 15 تشرين الأول 2015 00:20, Afif Elghraoui wrote: > Hello, > A project I wanted to package as part of Debian Med has a dependency on > the python modules for Apache Avro. I'd like to join the DPMT and > package python-avro as part of this team. While I could just as well do > it within Debian Med, I think DPMT is a better home for this package's > development. > > I am a DM and my alioth account username is afif-guest. I've read the > modules team policy [1] and agree with it. I also saw the message > recently posted to -devel-announce [2] regarding the git transition you > all made. > > I already maintain some biology-related python packages as part of > Debian Med-- these are python-cobra, python-pbcore, and > python-pbh5tools. I also have two more python packages currently in > NEW-- pbalign and pbgenomicconsensus. > > Many thanks and regards > Afif > > > 1. http://python-modules.alioth.debian.org/python-modules-policy.html > 2. https://lists.debian.org/debian-devel-announce/2015/10/msg0.html > signature.asc Description: OpenPGP digital signature
