> I'm not 100% sure I understand your question, but is something
> preventing you from installing the script with a
> debian/binoculars.install file?
nothink but it seems to me (I may be wrong), that pybuild install all files
directly in the python3- package
Am I wrong ?
I end up with the
Hello,
I am modernizing the binoculars package. I switch it to pyproject.toml and now
I need to update the packaging.
I would like your advices in order to replace this d/rules
---
export DH_VERBOSE=1
export PYBUILD_NAME=binoculars
export PYBUILD_AFTER_INSTALL=rm -rf {destdir}/usr/bin/
%:
ok for me
- Le 4 Jan 24, à 13:19, Alexandre Detiste alexandre.deti...@gmail.com a
écrit :
> Le jeu. 4 janv. 2024 à 07:48, Andreas Tille a écrit :
>> > @Vincent: this one package "gtextfsm" is yours
>> > do you green light an upload ?
>>
>> If you ask me the package is team maintained and a
stall=None, install_args=None, after_install=None, before_test=None,
test_args=None, after_test=None, test_nose=False, test_nose2=False,
test_pytest=False, test_tox=False, test_custom=False,
dir='/home/picca/debian/picca/bitshuffle', destdir='debian/tmp',
ext_destdir=None, ext_patt
Hello, I am updating the xraylarch package which contain something like this in
the setup.cfg
```
install_requires =
asteval>=0.9.28
numpy>=1.20
scipy>=1.7
uncertainties>=3.1.4
lmfit>=1.2.1
pyshortcuts>=1.9.0
xraydb>=4.5
silx>=0.15.2
matplotlib>=3.5
Hello,
I am the maintainer of silx
I have this problem with the gui application
$ silx view
Traceback (most recent call last):
File "/usr/bin/silx", line 33, in
sys.exit(load_entry_point('silx==1.1.2', 'console_scripts', 'silx')())
The sheband distributed by the upstream did not changed
#!python
but previously it was replaced by a python3 shebang.
here for the previous version
D: dh_python3 dh_python3:179: version: 5.20230109
D: dh_python3 dh_python3:180: argv: ['/usr/bin/dh_python3', '-i',
'-O--buildsystem=pybuild']
D:
Hello, I updated pymca with the new upstream version, and now the pymca package
depends on the missing python2:any package (which is not available in Debian).
This dependency was generated by dh_python3 during the build all.
dh_python3 -i -O--buildsystem=pybuild
D: dh_python3
Hello Louis
> It seems the only thing this line does is to install /usr/bin/silx. This can
> be
> done 'manually' via
> dh_install (see man dh_install).
Yes it install only this script for now. I can do it by end. but in thaht case,
I need to let python build the script from the entry point
Hello,
I try to update the silx package and I want to replace this call
python3 setup.py install_scripts -d debian/silx/usr/bin
with the right call without setup.py.
thanks for your help
Frederic
There is a fix from the upstream around enum.
https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013
Fix enum_type_object type on Python 3.11
The enum_type_object type inherits from PyLong_Type which is not tracked
by the GC. Instances doesn't have to be tracked
My pytango package has the same probleme...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024078
I: pybuild base:240: cd /<>/.pybuild/cpython3_3.11_tango/build;
python3.11 -m pytest tests
ImportError while loading conftest
'/<>/.pybuild/cpython3_3.11_tango/build/tests/conftest.py'.
in order to debug this, I started gdb
set a breakpoint in init_module_scitbx_linalg_ext
then a catch throw and I end up with this backtrace
Catchpoint 2 (exception thrown), 0x770a90a1 in __cxxabiv1::__cxa_throw
(obj=0xb542e0, tinfo=0x772d8200 , dest=0x772c1290
) at
Hello, I am trying to fix this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024859
I find the error message not very informative...
:~/$ python3.11
Python 3.11.0+ (main, Nov 4 2022, 09:23:33) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more
Hello, just for info.
I can confirm that the probleme was in the upstream build system, which was not
compatible with the setuptools > 60.
After patching the build system, I can confirm that without any change to the
rules files. It works out of the box.
So there is no issue in pybuild :)), or
ild:379: clean: plugin distutils failed with: exit code=1:
python3.10 setup.py clean
dh_auto_clean: error: pybuild --clean -i python{version} -p 3.10 returned exit
code 13
make: *** [debian/rules:16: clean] Error 25
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit
sta
Ok, I understand better what is going on.
in pyproject.toml there is these lines.
[build-system]
requires = [
"wheel",
"setuptools<60.0.0",
"oldest-supported-numpy",
"scipy",
"sphinx",
"nbsphinx",
"silx>=0.10",
"Cython>=0.25"
]
indeed the setuptools < 60, can not
:36:20 +0100 (CET)
Objet: Re: build package xrayutilities - wheel and pip with setuptools
On Tuesday, November 1, 2022 3:31:47 PM EDT PICCA Frederic-Emmanuel wrote:
I don#039;t think it should do that, so we need to investigate.
Where
can I find the updated packaging?
I did not push the change
> I dont think it should do that, so we need to investigate. Where can I
> find
> the updated packaging?
I did not push the change right now, I will push once I solve this issue :).
my opinion is that I should force via PYBUILD_SYSTEM=distutils
Fred
>It looks to me like the current pyproject.toml file for pyfai is not
>sufficient
> to build the package, so I would tempted to keep what you have now.
Due to the presence of this file, pybuild try to build using the "new way"
instead of building with setup.py.
I do not know if other package
> As far as I can see, the package doesnt ship any files in /usr/bin.
> Why do
> you need to build man pages (Im assuming thats what thats
> for? More
> generically, what problem did that step in the process solve thats not
> solved
> now?
this is for the pyfai package which I need to
thanks for your help.
I have one more question
I have this command from the previous build
{interpreter} setup.py build_man
how can I translate this with the new build systeme ?
> Hello Frederic,
Hello Carsten
> please could you provide next time direct links to the VCS/Tracker of
> your package, that prevents time to search for the correct package on my
> or others people side. Also a speaking subject content is helping me to
> decide if I want to spend time on
Le 2022-10-30 00:39, Scott Kitterman a écrit :
Adding pybuild-plugin-pyproject to build-depends should solve it. It
looks like it is trying to do the new pyproject.toml style build
without all the necessary parts in place.
the package contain a pyproject.toml file and a setup.py one.
the
Hello, I try to fix an FTBFS in the python-xrayutilities package.
When I try to build it, I get this error message., I do not understand
why I need to add a build dependency to python3-wheel.Is it something
missing in the dependency of python3-setuptools or python3.10 ?
thanks for your help
Hello, I am packaging the latest tomopy package.this software use ctype to open
some extensions during the import, but I have this error message.
>>> import tomopy
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/tomopy/__init__.py", line 63, in
from
For the record, I found it..., the upstream modify the HDF5_PLUGIN_PATH when
loading the dxtbx module.
they guess that they are using conda and override the path. All this is useless
on Debian since the plugin are system installed properly.
Cheers
Fred
# Ensures that HDF5 has the conda_base
Hello Neil
> Looks like you need a -v option to see more detail.
thanks for the advices, I found by removing files one by one that the failling
behavious is due to the import of the library itself.
the failing test PASS by himself, but if I add a useless import dxtbx inside,
it failes.
so
=
platform linux -- Python 3.10.6, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /home/picca/debian/science-team/dxtbx, configfile: pytest.ini
plugins: requests-mock-1.9.3, forked-1.4.0, xdist-2.5.0, mock-3.8.2
Hello Stephano
I end up with this
#! /usr/bin/make -f
export DH_VERSOBE=1
export PYBUILD_NAME=dxtbx
export PYBUILD_SYSTEM=distutils
export PYBUILD_AFTER_CONFIGURE=cmake -DPython_EXECUTABLE=/usr/bin/{interpreter}
-S . -B {build_dir}/lib
export PYBUILD_AFTER_BUILD=make -C {build_dir}/lib
> Oh. In this case setting PYTHONPATH (if it works, and Im not 100% sure
> it
> will) sounds like a better option.
> So, the cmake build path is, as far as I know, defined in
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm to be just
> obj-$DEB_HOST_GNU_TYPE.
thanks for the info. It seems to
> /usr/share/perl5/Debian/Debhelper/Buildsystem.pm to be just
> obj-$DEB_HOST_GNU_TYPE.
Thanks for the info, if I an not wrong during the build process we can setup a
new builddir.
So is is possible to obtain the real builddir during the build ?
> When trying to run tests you should look how does the upstream intend to
run them.
Yes they are building inplace the module like this
from https://github.com/dials/dxtbx/blob/main/.azure-pipelines/unix-build.yml
# Build dxtbx
- bash: |
set -e
. conda_base/bin/activate
set -ux
Hello Andrey
> Does the same happen when you run the test in the source tree manually?
I do not know, I am in the process to build the package in sbuild so I just try
to fix the build process.
If I have hard code the lib path the test are running failling for other
missing modules, but this
Hello, I am packaging a python extension which use cmake as build system
here the repo
https://salsa.debian.org/science-team/dxtbx
I try to activate the test but this cause this kind of trouble
During handling of the above exception, another exception occurred:
Hello, I am working on the silx package and the upstream install_requires is
sort of wrong.
It depends on the hdf5plugin, which is not necessary on Debian.
the purpose of this hdf5plugin is to register an hdf5 pluging when it is
uploaded.
the code of the application use a try execpt in order
> Hello,
> I’d suggest you build it from source (python.org/ftp... with the needed
> version) as an additional python version, and then create your venv using the
> 3.6.
> You can dm me if you might need more details.
It would be great to have a python-builder package whcih generates a
Hello, I am working on the lmfit-py package
lintian complain about this
https://salsa.debian.org/science-team/lmfit-py/-/jobs/909498
I use sphinx, so my question is: do you know how to fix this issue
lot's of package are affected by this
What about helping
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946035
python-language-server
is the only one missing now.
cheers
> If you want to embed python in an application, you need to use
> python3-embed.pc
> Or python3-config --embed
then it links the program with -lpython3.8
so what is the purpose of python3.pc ?
thanks
Fred
returned 1 exit status
so it seems that the program is not linked with the Python3 library
I use pkg-config to obtain the library
picca@2a02-8420-6c55-6500-d012-4688-0bee-a0c6:~/hkl/contrib/haskell$ pkg-config
--libs python3
picca@2a02-8420-6c55-6500-d012-4688-0bee-a0c6:~/hkl/contrib/haskell
I found this
--sourcedirectory=src
is it equivalent to -D
subsidiary question is it possible to run a command before all the dh_auto_xxx
without overrideing eveythings ?
I need to run a command whcih generate the setup.py file so I need to do
override_dh_auto_:
do_something
Hello, I have a packahe where the setup.py is not located at the root of the
directory.
So I need to do
override_dh_auto_XXX:
dh_auto_XXX -- -d
Is there a export somthing whcih allows to says where is the setup.py to deal
with ?
thanks
Frederic
> You should consider /usr/lib// if you want to make your
> package multiarch-safe.
And what about ?
/usr/lib//
whcih one is better ?
> > The issue is that the current build system do not provide rpath for
> > these libraries so I can not add one via chrpath.
> Well, ideally you need to fix the build system so that it sets the correct
> rpath directly.
I found patchelf whcih allows to add a rpath :))
So I just need to set
Hello, I am working on the dials[1] package. This scientific software
produce a bunch of python extension via boost python, but also a bunch
of libraries, which are the common part of the python extension.
when I package it, I moved the common library under the /usr/lib//
directory. This way
> Lintian-brush is a fine tool, but (correct me if I am wrong) it would
> generate a patch excluding badges, and patches require maintenance.
You are right
maybe we should have a dh_privacy helper for this purpose.
cheers
Fred
what about lintian brush ?
Hello, I am working on the vitables package.
during the build I get this error message [1]
= test session starts ==
1567 platform linux -- Python 3.7.6, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
1568 rootdir:
Indded
sorry for the noise
Fredric
Hello,
I am packaging a python application . So I dediced to put the module under the
private directory
/usr/share/
but this software contain a cython extension.
So at the end I have a lintian Error due to binary file under /usr/share.
What is the best soltuion when we need to package a
Hello
on unstable it works but on buster (and we need to make it work for buster)
we have this message
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>>
Hello,
We are working on the next pyfai package.
This new version use entry_points like this
gui_requires = ['PyQt5', 'h5py', 'hdf5plugin', 'PyOpenGL']
opencl_requires = ['pyopencl']
extras_require = {
'calib2': gui_requires, # Keep compatibility
'gui': gui_requires,
Hello,
and if at the end the upstream could take care of the Debian packaging, by
adding a
.salsa-ci.yml in the upstream directory, in order to have a feedback with nice
badges ?
Cheers
Hello, in one of my package (pymca), there is a syntax error like this.
byte-compiling
/builds/science-team/pymca/debian/output/pymca-5.5.2+dfsg/debian/python-pymca5/usr/lib/python2.7/dist-packages/PyMca5/Object3D/Object3DPlugins/ChimeraStack.py
to ChimeraStack.pyc
File
Hello, I would like to know if there is an equivalent of cabal-debian[1] ,
which helps a lot maintaining haskell packages.
I allow to do the initial packaging and also the upgrade of the packaging, by
updating the Build-dependencies, etc...
Cheers
Frederic
[1]
Hello sandro,
I can not find python-pyqtgraph in your list.
It seems to me that this package has reverse dependencies, but the python2
binaries where remove..., but this is another problem.
Cheers
Frederic
Hello Sandro,
> I've just submitted
> https://salsa.debian.org/python-team/tools/dh-python/merge_requests/9
> to address this; not sure how quickly it will get merged & released
thanks a lot, but what about backports. On backports we still need this mapping.
Cheers
Hello,
I am preparing the new spyder package.
since the removal of pylint3 from the src:pylint.
I need to remove the Build-Depends: pylint3.
Now dh_python3 still produce a pylint3 dependency for the binary packages.
It seems that thsi is hard coded here[0]
Is it a bug of dh-python ?
Cheers
Hello it seems that the pylint package does not provide pylint3 anymore (since
21h ;)
But the spyder package still require pylint3 and pylint when installint spyder
or spyder3.
this is why the next taurus will FTBFS.
So is it something expected and the spyder package should be fixed, or a bug
it would be nice, if the python2 packages could be skipped in bulleye but not
for backports in buster.
Is it something which could be envision ?
Fred
Hello,
while preparing one of our package (pyfai), we endup with an FTBFS due to
backports.functools_lru_cache [1].
here the backtrace
Traceback (most recent call last):
File "./run_tests.py", line 543, in
unittest.defaultTestLoader.loadTestsFromNames(options.test_name))
File
Hello, here a diff between the python3.6 and python3.7 modules once updated
via 2to3.
r:/tmp$ diff core*
174c174
< for (variance, tag) in zip(variances, tags))
---
> for (variance, tag) in list(zip(variances, tags)))
181c181
< for (coords, value) in
Hello Andreas,
> Patches are welcome (I have no idea what the construct is doing neither
> how to replace it with something valid).
> Patch welcome as well - preferably as commit to Git.
done but now, we need to understand why lintian complain about python module at
the wrong place before
I think that the real problem with the current build is that the conf.py file
change the sys.path.
this is why we see this syntax eror.
sphinx pick the wrong path.
I can not work on this now..., I am not in fron of a Debian box nor have
access to one todays...
Cheers
Fred
I found in the code a string with a ur''
This is the problematic line.
I do not know if this is a valid string construction.
I also dound that you need to remove the sys.path modifications from the
conf.py.
this can cause some troubles during the build.
Cheers.
Fred
I found the culprite, the conf.py file of the documentations prepend ".." to
sys.path befor importing the module.
This is why it use the wrong version of the built module.
Now during the build I have this
D: dh_python3 dh_python3:164: args: []
D: dh_python3 dh_python3:166: supported Python
Now the test part :))
Correlated variables. ... ok
Tests the input of correlated value. ... ok
==
ERROR: Failure: ImportError (No module named tests.support)
> try adding python3-setuptools to Build-Depends
ok I removed all the black magic from the debian/rules and added setuptools :)
so now, I have this error when building the documentation
PYTHONPATH=`pybuild --print build_dir --interpreter python3`
http_proxy='http://127.0.0.1:9/' sphinx-build
You are right , I did not noticed, that setuptools was not part of the build
dependencies...
Hello Andreas, it seems to me that the problem is due to the 2to3 conversion.
I looked at the first failure when you re-activate the unit test[1]
to my opinion, the code is modify in place with 2to3.
So the code on the source after the configuration is already converted to
python3.
And during
Hello Andreas,
during the test does it load the moduels from the source files or does it use
the one under the build directory.
Maybe there is a missmatch between python2 code and 2to3 python code targeting
python3.
did it helped ?
Fred
I think that there is a problem with cffi
pyopencl was built with
python3-cffi-backend i386 1.11.5-1 [80.2 kB]
but the backend used for the test is the current 1.11.5-3.
here the Debian changelog
python-cffi (1.11.5-3) unstable; urgency=medium
[ Ondřej Nový ]
* Use 'python3 -m
Hello,
I rebuilt pyopencl,and the problem vanished.
so what should I do now ?
ask for a binNMU or try to understand what is going on ?
thanks for your time.
Fred
picca@mordor:/tmp$ python3.7-dbg -c "import pyopencl"
/usr/lib/python3/dist-packages/pkg_resources/_vendor/pypars
e
refcount: 0
address : 0xb5f507a4
* op->_ob_prev->_ob_next
object : Erreur de segmentation
picca@mordor:~$ python3.7 -c "import pyopencl"
maybe the problem is in pyopencl.
But I find really strange thaht I have the WArning messages with python3.7-dbg
but not with python3.7
Is it normal ?
Ok, I could simplify the problem to a single import
picca@mordor:~$ python3.7-dbg
Python 3.7.0+ (default, Aug 31 2018, 23:21:37)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import silx.opencl
/us
Hello,
I try to understand this [1] test failure with python3.7-dbg
so, I ran this on my unstable box and I got this error from within gdb
testTrainingSpectrumReading (specfilewrapperTest.testSpecfilewrapper) ... ok
--
Ran 43
Hello,
I am trying to upgrade spyder and activate the unti test during the build.
But when pybuild try the test it ends with this error message
dh_auto_test: pybuild --test --test-pytest -i python{version} -p "3.7 3.6"
returned exit code 13
With no other information.
So My question is how
> remove control file and invoke py2dsp - it will regenerate it
> That said, you probably want dch (debchange) rather than new control
> file
Thanks a lot,
It would be nice to have an equivalent of dgit-main-xxx for maintaining python
packages.
Maybe in the policy ?
this way peoples new
Hello,
once debianize, is there a command which allow to update the control file for a
new upsteam version in order to take into account the new python dependencies ?
It would simplify a lot the maintenance of python packages.
py2dsp update
like the cme command ?
Cheers
Frederic
no problem Ghislain, I am on it :))
Cheers
Fred
Hello, I need to create a new package for
spyder_kernels.
Is there a tool which allows to create the first version of a package which
create the debian/directory from the setup.py files ?
thanks
Frederic
> A bit off-topic, but you should not use Qt 4 in new packages.
> See https://lists.debian.org/debian-devel-announce/2017/08/msg6.html.
I did the migration to qtcreator :))
do not worry
Fred
thanks a lot
Hello, I am preparing the new silx package and I got these error messages from
adequate
This package produce the silx python module but install also a bunch of files
for qtdesigner
in the rules file with this command.
# install the qtdesigner files only for the python3 package
What about teaching cme how to fix packages build-depends.
this way a simple
cme fix dpkg
would do the job ?
Or just use the sphinx-generated Makefile if there is one:
Except that when there is an autodoc in the documentation, I like to build the
doc with all {interpreters}.
It is a sort of unit test
Cheers
Fred
Hello guyes.
> override_dh_sphinxdoc:
> ifeq (,$(findstring nodocs, $(DEB_BUILD_OPTIONS)))
nodocs or nodoc
I alsa do something like this when there is extensions.
override_dh_sphinxdoc:
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
Hello, it seems that dependencies are not generated for the -dbg packages by
dh_python[23]
Is there s way to ask dh_python to generate these dependencies from the
build-dep of a package.
Thanks
Frederic
Hello Ghislain
> Indeed, you need to use the name registered on pypi, which can be
> different from the Debian package name. For OpenGL, the project is
> registered as PyOpenGL, for PyQt5 the name is PyQt5.
yes it works :)
> but for pyqt5 I do not have egg informations. Maybe the solution would
Hello Andrey
> Isn't just adding the package names to Depends easier?
I just want this to be automatically generated and "upstreamable".
> So do you have python-opengl, python-pyqt5 etc in Build-Depends?
yes, I think that I found the problem for opengl.
the egg info gives the name of the
Hello,
still working on my silx package...
When it comes to python:Depends, I try to add the right entries in the setup.py
So I added a bunch of modules there.
-"setuptools"]
+"setuptools",
+# Debian added
+"ipython",
+"qtconsole",
+"enum34",
+
Hello before reporting a bug against dh-python, I would like your opinion,
I try to skip test for all the debug version of the interpreter.
So I add this in the rules files
export PYBUILD_DISABLE_python2-dbg=test
export PYBUILD_DISABLE_python3-dbg=test
and here is my test target
#
Hello, When I tries to update one of my package, I got this errro via uscan
:~/Debian/lmfit-py/lmfit-py$ uscan
uscan warn: In watchfile debian/watch, reading webpage
https://pypi.debian.net/lmfit/ failed: 502 Bad Gateway
Someone knowns what is going on ?
Cheers
Frederic
Ok, If I replace
'{interpreter} setup.py build_man'
by
'env; setup.py build_man'
I get this
HOME=/home/picca
PYTHONPATH=/home/picca/Debian/silx/silx/.pybuild/pythonX.Y_2.7/build
but If I read the code of
def create_pydistutils_cfg(func):
"""distutils doesn't have sa
only=False,
dir='/home/picca/Debian/silx/silx', disable=None, ext_destdir=None,
ext_pattern='\\.so(\\.[^/]*)?$', install_args=None, install_dir=None,
install_only=False, interpreter=['python{version}'], list_systems=False,
name='silx', quiet=False, really_quiet=False, system=None, test_args=None,
f script_name is not None:
os.remove(script_name)
When I run the build it generate a pydistconfig file wit this content
D: pybuild plugin_distutils:55: pydistutils config file:
[clean]
all=1
[build]
build-lib=/home/picca/Debian/silx/silx/.pybuild/pythonX.Y_2.7/build
[install]
force=1
> The snippet you quoted is not specific to extension modules but to the
> use of the autodoc feature, which requires the modules to be in the
> PYTHONPATH. The `sys.path.insert` hack is just here so that you don't
> have to specify PYTHONPATH yourself when running the upstream Makefile.
I just
> First, that's very speculative. Second, that's upstream's problem.
> The upstream Makefile and conf.py are likely generated by Sphinx itself
> via sphinx-quickstart. Did your upstream tinker with them that much that
> they cannot be trusted?
No this is just that does not fit well with
> PYTHONPATH=. sphinx-build -N -b html
> One can also use the sphinx-generated Makefile if available:
> PYTHONPATH=$(CURDIR) $(MAKE) -C html
> Both are simple one-liners and do not rely on pybuild.
Yes it works but this is fragile since the organisation of the module can
change in the
1 - 100 of 150 matches
Mail list logo
