*.deb contents and paths stay identical for all the built
packages, but setting bindir to /usr/bin should prevent
future mishaps with binaries that are supposed to end up in
/usr/bin (which is upstream's default for bindir)
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Aron Xu <aron@debian.org>
If the user has set umask 077 instead of the standard 022,
dpkg-buildpackage fails with:
chmod -x debian/tmp/etc/zfs/zfs-functions
chmod: debian/tmp/etc/zfs/zfs-functions: new permissions are rw-r-xr-x, not rw-r--r--
debian/rules:64: recipe for target 'override_dh_auto_install' failed
Signed-off-by: Lukas Wunner <lukas@wunner.de>
The patch makes use of the --with-systemdunitdir configure parameter
which we do not set and which incorrectly defaults to
/usr/lib/systemd/system/. (Debian uses /lib/systemd/system/.) Amend
debian/rules to set that parameter. This obviates the need to specify
the /lib/systemd/system/ path in debian/zfs-zed.install and
debian/zfsutils-linux.install, so fix those up while at it.
Signed-off-by: Aron Xu <aron@debian.org>
After upgrading to systemd 230 as included with Debian stretch, systems
that build their initramfs with dracut and have their root partition on
a zpool fail to boot:
On boot, /usr/lib/dracut/modules.d/98dracut-systemd/rootfs-generator.sh
generates a systemd unit to mount the "root=" kernel parameter, which
for ZFS may look like "zfs:pool/dataset" or "zfs:AUTO", a format not
understood by mount(8). As a result systemd switches to emergency mode.
A fix was committed upstream in April 2016 with a5a370227eb0 ("fix
booting via dracut generated initramfs"), but never made it into the
0.6.5.* point releases, presumably because they do not pick up fixes
in the contrib/ directory.
Signed-off-by: Aron Xu <aron@debian.org>
