Bug#946233: Non-deterministic build depending on presence of cmake
On 2020-02-18 01:58, Joachim Reichel wrote: The bug number for dh-python is #949305. I don't see how the dh-python bug is blocking a fix here, so I'll leave setting the tag to you. In addition, if they decide to rank "cmake" higher than "distutils" (e.g. when sorting the plugins alphabetically), then your package will use the wrong toolchain all the time. I doubt they'd prefer cmake over distutils. But the ambiguity is real, since both install systems are available for the package. Adding a Build-Conflicts: would do the right thing, but might be a bit drastic. There seems to be another solution: pybuild supports "-s" or "--system" to select "distutils". Not sure how to make dh to pass arguments to pybuild ... But pybuild also supports the environment variable PYBUILD_SYSTEM. Just mentioning, I did not test that. This sounds like the right way to go. I think we can make it work this way. The package could build either way, and therefore the package build needs to specify the desired system. Thanks Joachim. Drew
Bug#946233: Non-deterministic build depending on presence of cmake
The bug number for dh-python is #949305. I don't see how the dh-python bug is blocking a fix here, so I'll leave setting the tag to you. In addition, if they decide to rank "cmake" higher than "distutils" (e.g. when sorting the plugins alphabetically), then your package will use the wrong toolchain all the time. Adding a Build-Conflicts: would do the right thing, but might be a bit drastic. There seems to be another solution: pybuild supports "-s" or "--system" to select "distutils". Not sure how to make dh to pass arguments to pybuild ... But pybuild also supports the environment variable PYBUILD_SYSTEM. Just mentioning, I did not test that.
Bug#946233: Non-deterministic build depending on presence of cmake
Source: pygalmesh Followup-For: Bug #946233 Good that you found why cmake is mislaunching for you. It's a strange bug. Behaviour like that should never depend on the order in which files got written to disk. Please do file a bug against dh-python. I don't want to insert Build-Conflicts: cmake into the package since that will interfere with other build tests (I don't want to have to uninstall cmake just to test a local build of pygalmesh). But we can leave this bug open to report it as a workaround for systems which are affected by the problem. When you file the bug against dh-python, please tag it as blocking this bug.
Bug#946233: Non-deterministic build depending on presence of cmake
Hi Drew, I just saw your reply by accident. It seems you did not copy me. Note that the submitter does not receive mails to n...@bugs.debian.org. Either use nnn-submitter@b.d.o. or add me directly. > I checked with Nico upstream, cmake is not intended for building > pygalmesh for python module deployment. Ok, fine. I didn't want to suggest that the cmake build is better -- it is mainly about the discrepancy. After some debugging I found out why this happens: If you add "print (tmp_plugin, tmp_certainty)" in line 105 of /usr/bin/pybuild, you'll see that there is a tie between distutils and cmake and the first one tried wins. The order in which the plugins are tried is the file order in the directory /usr/share/dh-python/dhpython/build. In one chroot where I can reproduce the problem I see cmake first: $ ls -U1 /usr/share/dh-python/dhpython/build plugin_cmake.py plugin_custom.py base.py __init__.py plugin_distutils.py __pycache__ In another chroot where I can not reproduce the problem I see distutils first: $ ls -U1 /usr/share/dh-python/dhpython/build __init__.py plugin_distutils.py __pycache__ plugin_custom.py base.py plugin_cmake.py I guess the latter is also the case for the environment you used. I'll file a separate bug on dh-python. But since this is probably rather an implementation detail on their side, and for the being, I think a Build-Conflicts: cmake is in order for pygalmesh. Best regards, Joachim
Bug#946233: Non-deterministic build depending on presence of cmake
Source: pygalmesh Followup-For: Bug #946233 I checked with Nico upstream, cmake is not intended for building pygalmesh for python module deployment. He's set up the cmake scripts as a convenience for testing during development. https://github.com/nschloe/pygalmesh/issues/56 That fact that you've got a cmake-dependent build is a different problem. The build is supposed to be controlled by dh --buildsystem in debian/rules. It's currently set to --buildsystem=pybuild for python module building. The cmake build can be triggered by changing that to --buildsystem=cmake. But that cmake build should not be happening by accident depending merely on the availability of cmake. Obviously I've got cmake installed, but the pygalmesh proceeds with the pybuild build not a cmake build. It looks as if your system has some weird configuration that overrides the --buildsystem setting in debian/rules and always enforces --buildsystem=cmake. Are there any DH_ environment variables that might do this? I don't know of any, but the build is certainly not supposed to use cmake automatically simply because it's installed. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#946233: Non-deterministic build depending on presence of cmake
Source: pygalmesh Version: 0.4.0 Severity: normal Hi, as already pointed in bug #933848: the build system behaves completely different based on the presence or absence of cmake. With cmake: --- debian/rules build dh build --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:217: dh_auto_configure --buildsystem=cmake --builddirectory="/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build" -- -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 -DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 cd .pybuild/cpython3_3.8_pygalmesh/build && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON -DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run "-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python3.8 -DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.8/config-3.8-x86_64-linux-gnu/libpython3.8.so -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.8 ../../.. --- Without cmake: --- debian/rules build dh build --with python3 --buildsystem=pybuild dh_update_autotools_config -O--buildsystem=pybuild dh_autoreconf -O--buildsystem=pybuild dh_auto_configure -O--buildsystem=pybuild I: pybuild base:217: python3.8 setup.py config running config I: pybuild base:217: python3.7 setup.py config running config debian/rules override_dh_auto_build make[1]: Entering directory '/mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0' dh_auto_build I: pybuild base:217: /usr/bin/python3.8 setup.py build running build running build_py creating /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/__about__.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/cli.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/main.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh copying pygalmesh/__init__.py -> /mnt/debian/packages/cgal/rdeps/pygalmesh-0.4.0/.pybuild/cpython3_3.8_pygalmesh/build/pygalmesh [...] --- You should either add a Build-Depends or Build-Conflicts on cmake to make the build deterministic. With cmake, a binNMU would have been sufficient for the CGAL 5.0 transition. Without cmake (which is likely the case on the buildds), a sourceful upload is necessary. Best regards, Joachim
