Bug#946233: Non-deterministic build depending on presence of cmake

[Drew Parsons]

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