following debian upstream (which pulled it in from Ubuntu in
44915cf387d45a123b11a8c24d3f30a8fdbcc532)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following commit da40a1b007d2a99bac95bd67ec6dd7b8e217c0cf from
debian-upstream.
However since some of our rust-packages seem to depend on
libcurl4-gnutls-dev (via librust-curl-sys-dev) we add a
option for the dependency - I would assume that both should work
equally well (the callers are in upstream/lib/libzfs/libzfs_crypto.c)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following commit ec311430e2fd66492498a1559f56ef25e1192266 ZFS
upstream due to
> Added functions (2):
> - boolean_t zpool_is_draid_spare(const char *);
> - zpool_compat_status_t zpool_load_compat(const char *,
> boolean_t *, char *, char *);
However since libzfs increased both the current as well as the age,
as there where only addition but no changes of previously existing
ABI, the soname of the library remained at libzfs4.so - following
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html I left
the package name at libzfs4linux
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[ Thomas: added a bit more context ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
suggesting the new -dbgsym packages without having a strict dependency
on a specific version of the library packages, like the old no longer
built zfs-dbg package had.
this commit can be reverted after the package has been uploaded once, or
kept for one release cycle if we might do the -dbgsym migration in
oldstable as well to avoid the oldstable zfs-dbg package version
overtaking the transitional one here.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
automatically generated -dbgsym packages has become the default
(see dh_strip(1) and [0]).
While we have no direct need to migrate, it helps in avoiding
debhelper bug 939164 (see [1]), when migrating to debhelper-compat 12.
(alternative option would be to depend on debhelper from backports, or
to skip dh_dwz).
The change is well described in dh_strip(1).
[0] https://wiki.debian.org/AutomaticDebugPackages
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939164
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
this commit follows: 93661343d884a5339631afd7b683e232d20b7baf and
0b52b09c6083bd590e46cb9884d06bae1b712a2a from debian-upstream [0].
the `make checkabi` invocation takes < .4s on my workstation - so it
seems worth the change.
[0] https://salsa.debian.org/zfsonlinux-team/zfs
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
during the tracking of zfs-2.0.x integration in debian upstream I did
not notice that the library packages got renamed yet another time (see
[0]) to match the soname version.
This patch renames our library packagenames to match debian upstream
and includes Breaks,Depends on the intermediate versions we shipped
with the zfs-2.0.3 release.
Noticed while checking an issue (with `aptitude` vs. `apt`) reported
on pve-user.
Tested on a VM running our latest packages and on one still running
zfs 0.8.5
[0] 42ba750f8c
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
ZFS includes (since 2.0.0) a pam-module, which takes the login
credentials of an user to unlock their home-dataset.
Enabling it in its current state can cause some side-effects like
prompting for a password when running `su` as root (see [0]).
Our update to ZFS 2.0.0 shipped the pam config in zfsutils-linux,
whereas debian-upstream split it out into its own optional package
This commit adopts this change.
based on debian-upstream [1] commit
cad2f3d24aa44cfdce1e2eae8b6ba027efaba2d6
The issue becomes apparent by installing the current zfsutils-linux
package and running `pam-auth-update --package` (e.g. by installing
an upgraded libpam-runtime package).
[0] https://github.com/openzfs/zfs/issues/11222
[1] https://salsa.debian.org/zfsonlinux-team/zfs/
Reported-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Originally-by: Antonio Russo <aerusso@aerusso.net>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
