On 2023-12-26 02:38, Martin-Éric Racine wrote:
On Mon, Dec 25, 2023 at 12:20 AM Richard Laager <[email protected]> wrote:If past me was correct, without systemd at build-time, waf will not install the systemd units. Then we will end up with other failures in debian/rules or from the .install files.Not installing them on platforms where systemd has not been ported is the correct action.
Agreed. My point was that additional work would be required, during the package building process, to not blow up when those files are missing from `waf install`.
bin:ntpdate is just a transitional package to transition uses of the old src:ntp's bin:ntpdate to src:ntpsec's bin:ntpsec-ntpdate. It is Architecture: all, which is why it is available on Hurd.It built enough to have ntpdate.
In ntpsec, the ntpdate executable is just a thin wrapper around ntpdig, which ships in the bin:ntpsec-ntpdig package (formerly, it was in bin:ntpsec-ntpdate). While ntpdig is Python, so it doesn't actually require compilation, it is presumably going to require some build steps happen.
ifeq (hurd, $(DEB_HOST_ARCH_OS)) # hurd does not provided the system calls needed for ntpd to work. exit 1 endif I see a couple of ways forward here: A) I properly indicate this package does not support HURD. I think I would just replace the "Architecture: any" with "Architecture: linux-any" on binary packages in debian/control, but I would love confirmation on that.Which is what this bug requested
I'm confused.What you asked for was for me to limit "Build-Depends: systemd" to [linux-any]. What I said here was that I'd limit all the built binary packages to [linux-any], dropping any claims of support for HURD.
The rest of your email reads to me like you think this package should support HURD to some degree. But here you are agreeing with the choice that it should not support HURD _at all_.
I'm fine with dropping support for HURD entirely. I think that would be more honest than the current state of affairs where the build just fails.
But if ntpdig is something that would be useful on HURD, I suppose it would be nice if we could figure out how to make bin:ntpsec-ntpdig (and some other packages) build for HURD.
If you are interested in HURD support, could you start with the attached patch to ntpsec, try to build it, and see what happens?
-- Richard
diff --git a/debian/control b/debian/control
index a33a26ecb..2b1bc2a18 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@
python3,
python3-dev,
python3-gps,
- systemd,
+ systemd [linux-any],
xsltproc,
xz-utils,
Build-Conflicts: libavahi-compat-libdnssd-dev,
@@ -31,7 +31,7 @@
Homepage: https://www.ntpsec.org
Package: ntpsec
-Architecture: any
+Architecture: [linux-any]
Pre-Depends: ${misc:Pre-Depends},
Depends: adduser,
netbase,
diff --git a/debian/rules b/debian/rules
index dc23970f5..ff816974d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,10 +12,6 @@
dh $@ --with apache2,python3
override_dh_auto_configure:
-ifeq (hurd, $(DEB_HOST_ARCH_OS))
- # hurd does not provided the system calls needed for ntpd to work.
- exit 1
-endif
# Only build with refclocks NOT slated for removal. See also
# debian/patches/update-refclock-docs.patch. However, if the reason
# for deprecation is only "two digit years", I *am* keeping it.
OpenPGP_signature.asc
Description: OpenPGP digital signature
