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
Frederic
dh clean --buildsystem=pybuildthe following exception:
dh_auto_clean -O--buildsystem=pybuild
install -d /<<PKGBUILDDIR>>/debian/.debhelper/generated/_source/home
pybuild --clean -i python{version} -p 3.10
I: pybuild base:240: python3.10 setup.py clean >/usr/lib/python3/dist-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprecated. Requirements should be satisfied by a PEP 517 installer.
warnings.warn(
WARNING: The wheel package is not available.
/usr/bin/python3.10: No module named pip
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/setuptools/installer.py", line 82, in fetch_build_egg
subprocess.check_call(cmd)
File "/usr/lib/python3.10/subprocess.py", line 369, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmpq9o0m_9e', '--quiet', 'h5py']' returned non-zero exit status 1.The above exception was the direct cause of
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.
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 build system in the pyproject file is setuptools.
[build-system]
requires = ["setuptools", "wheel", "numpy"]
build-backend = "setuptools.build_meta"
So I imagine that under the hood it use the setup.py file.
now it fails with this error message
adding 'xrayutilities-1.7.3.dist-info/top_level.txt'
adding 'xrayutilities-1.7.3.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
* Building wheel...
Successfully built xrayutilities-1.7.3-cp310-cp310-linux_x86_64.whl
I: pybuild plugin_pyproject:118: Unpacking wheel built for python3.10 with "installer" module
E: pybuild pybuild:379: build: plugin pyproject failed with: File already exists: /<<PKGBUILDDIR>>/.pybuild/cpython3_3.10_xrayutilities/build/xrayutilities/VERSION
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit code 13
make[1]: *** [debian/rules:20: override_dh_auto_build-arch] Error 25
this failure seems to come from the indep part
%:
dh $@ --buildsystem=pybuild
execute_after_dh_auto_clean:
rm -rf build
override_dh_auto_build-arch:
dh_auto_build
override_dh_auto_build-indep: override_dh_auto_build-arch
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
dh_auto_build -- -s custom --build-args="env
PYTHONPATH={build_dir} {interpreter} setup.py build_doc"
endif
since I make the indep part depends on the arch one, it build the
package a second time. and this is during this second reconstruction
that
it failes.
it seems that the arch rules does not gard from a second build, and it
is not indepotent...
$ git diff
diff --git a/debian/control b/debian/control
index 4a702ea..1b746a3 100644
--- a/debian/control
+++ b/debian/control
@@ -10,9 +10,9 @@ Section: science
Priority: optional
Build-Depends:
debhelper-compat (= 13),
- dh-python,
dh-sequence-numpy3,
dh-sequence-python3,
+ pybuild-plugin-pyproject,
python3-all-dev,
python3-h5py,
python3-lmfit,
diff --git a/debian/rules b/debian/rules
index 54c4cb0..089385d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,6 +4,7 @@
# Uncomment this to turn on verbose mode.
export DH_VERBOSE=1
export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+export DEB_HOST_ARCH?=$(shell dpkg-architecture -qDEB_HOST_ARCH)
# copy the tests to the build dir to be able to pass nose
export PYBUILD_NAME=xrayutilities
@@ -11,18 +12,13 @@ export PYBUILD_BEFORE_TEST=cp -r tests {build_dir}; cp -r examples {build_dir};
export PYBUILD_AFTER_TEST=rm -rf {build_dir}/tests; rm -rf {build_dir}/xrayutilities/materials/data; rm -rf {build_dir}/examples
%:
- dh $@ --buildsystem=pybuild
+ dh $@ --with sphinxdoc --buildsystem=pybuild
-execute_after_dh_auto_clean:
- rm -rf build
-
-override_dh_auto_build-arch:
- dh_auto_build
-
-override_dh_auto_build-indep: override_dh_auto_build-arch +override_dh_sphinxdoc:
ifeq (,$(findstring nodoc, $(DEB_BUILD_OPTIONS)))
- dh_auto_build -- -s custom --build-args="env PYTHONPATH={build_dir} {interpreter} setup.py build_doc"
+ PYTHONPATH=. python3 -m sphinx -b html -N doc/source $(CURDIR)/debian/python-xrayutilities-doc/usr/share/doc/python-xrayutilities-doc/html
+ dh_sphinxdoc
endif
-execute_after_dh_installdocs:
- dh_installdocs -p python-xrayutilities-doc build/sphinx/html +execute_after_dh_auto_clean:
+ rm -rf build
Hello Frederic,
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 taking a look, you've choose a very generic line. :-)
https://tracker.debian.org/pkg/xrayutilities https://salsa.debian.org/science-team/python-xrayutilities
No as you have overwritten the default target by a call that is quite
similar to the original pybuild call.
Yes, the environment isn't the same for the second call, you'd need to
ensure that the build directory is clean before starting the second run.
But I don't see why this construct you've build in d/rules is needed
that way.
I can build the package basically doing these modifications and by
adding the additional B-D package Scott did mention. Simply let
dh_sphinxdoc build the documentation and adding the additional needed
package dependencies.
lintian has some additional remarks any way, I haven't looked further at these.
I can build the package basically doing these modifications and by
adding the additional B-D package Scott did mention. Simply let
dh_sphinxdoc build the documentation and adding the additional needed
package dependencies.
[your patch]
In your proposition you removed the arch/indep split, is it on purpose ?
Hello Frederic,
Am 31.10.22 um 08:57 schrieb PICCA Frederic-Emmanuel:
I can build the package basically doing these modifications and by
adding the additional B-D package Scott did mention. Simply let
dh_sphinxdoc build the documentation and adding the additional needed
package dependencies.
[your patch]
In your proposition you removed the arch/indep split, is it on purpose ?
yes, building the Sphinx based documentation doesn't need to be done
that (to me fragile) way. debhelper is smart enough to do the right
things in the correct order if you tell it to use the sphinxdoc module.
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 ?
On Tuesday, November 1, 2022 2:42:22 PM EDT PICCA Frederic-Emmanuel wrote:
As far as I can see, the package doesn't ship any files in
/usr/bin.
Why do you need to build man pages (I'm assuming that's what that's for? More generically, what problem did that step in the process solve that's not solved now?
this is for the pyfai package which I need to update
https://salsa.debian.org/science-team/pyfai
I see. I was confused by the subject saying this was about xrayutilities still. I'll have a look.
Scott K
As far as I can see, the package doesn't ship any files in /usr/bin. Why do you need to build man pages (I'm assuming that's what that's for? More generically, what problem did that step in the process solve that's not solved now?
this is for the pyfai package which I need to update
https://salsa.debian.org/science-team/pyfai
As far as I can see, the package doesn't ship any files in /usr/bin. Why do
you need to build man pages (I'm assuming that's what that's for? More
generically, what problem did that step in the process solve that's not solved
now?
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 are in this state, but if produce an FTBFS.
Cheers
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.
I don't 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
I don't think it should do that, so we need to investigate. Where can I find
the updated packaging?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 349 |
Nodes: | 16 (2 / 14) |
Uptime: | 116:29:12 |
Calls: | 7,612 |
Files: | 12,786 |
Messages: | 5,683,800 |