You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While packaging your software for Debian, I've noticed that a minimal chroot (which is typical for building purposes) might not have any /etc/machine-id (or the /var/lib/dbus/machine-id counterpart), leading to testsuite failures. Of course, I could just ignore testsuite results (which will be done in the first revision of this package), but it's not ideal.
Would it make sense to support something like an environment variable to point at a different root, or to have an extra file that one could look at? The usual constraint while building Debian package is staying inside $(CURDIR) and having no root privileges.
Thanks for your input.
Cheers,
Cyril.
The text was updated successfully, but these errors were encountered:
In hindsight, we might go for tweaking upstream sources (in the package that currently depends on this module) to read /etc/machine-id directly, which should be good enough for our purposes.
Hi,
While packaging your software for Debian, I've noticed that a minimal chroot (which is typical for building purposes) might not have any
/etc/machine-id
(or the/var/lib/dbus/machine-id
counterpart), leading to testsuite failures. Of course, I could just ignore testsuite results (which will be done in the first revision of this package), but it's not ideal.Would it make sense to support something like an environment variable to point at a different root, or to have an extra file that one could look at? The usual constraint while building Debian package is staying inside
$(CURDIR)
and having noroot
privileges.Thanks for your input.
Cheers,
Cyril.
The text was updated successfully, but these errors were encountered: