Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
1,036 views
Skip to first unread message
Albert Nash
Oct 6, 2022, 6:30:04 PM10/6/22
to
Package: gnome-control-center
Version: 1:3.38.4-1
Severity: important
Control: affects -1 samba-libs
Version: 1:3.38.4-1
Severity: important
Control: affects -1 samba-libs
The control center starts neither from gnome (Alt+F1 > Settings) nor from an xterm. In the last case, we get some (hopefully, useful) output:
$ gnome-control-center
gnome-control-center: /lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
$
(I presume that some dependencies of samba-libs or gnome-control-center are outdated or simply wrong.) The system is Debian stable 11 “bullseye” with a few updated packages from Debian testing. I'd be happy if this bug report finds attention soon because the package, as of now, is useless to me: the control center won't start (e.g., I have no means to adjust printers or screens).
Thanks in advance,
Albert
Albert
Albert Nash
Oct 6, 2022, 6:40:03 PM10/6/22
to
severity 1021371 important
affects 1021371 - control:
affects 1021371 - severity:
affects 1021371 - important
affects 1021371 - affects
affects 1021371 - version:
affects 1021371 - -1
affects 1021371 - 1:3.38.4-1
thanks
Some more data:
$ sudo aptitude show libsmbclient | grep Version
Version: 2:4.13.13+dfsg-1~deb11u5
$ sudo aptitude show samba-libs | grep Version
Version: 2:4.13.13+dfsg-1~deb11u5
(Sorry for the mess with the header: I tried my best to say that exactly two packages are affected: gnome-control-center and samba-libs. Something went wrong with the header https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1021371;msg=5 ; I don't know what.)
Simon McVittie
Oct 7, 2022, 4:40:04 AM10/7/22
to
Control: reassign -1 libldb2 2:2.5.2+samba4.16.5-1
Control: severity -1 serious
On Thu, 06 Oct 2022 at 22:18:46 +0000, Albert Nash wrote:
> The control center starts neither from gnome (Alt+F1 > Settings) nor from an
> xterm. In the last case, we get some (hopefully, useful) output:
>
> $ gnome-control-center
>
> gnome-control-center: /lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4'
> not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
...
they are often not completely supportable, because the number of possible
combinations of package versions is just too high.
In this case, it looks like you have probably upgraded libldb2 from bullseye
to testing without also upgrading samba-libs. The dependencies allow this,
so it should in principle be OK, but in fact libldb2 has an incompatible
change to its versioned symbols that means it is not.
I can reproduce this without using gnome-control-center, by using
smbclient, so this is not a gnome-control-center bug. In a minimal
bullseye container:
# apt install --no-install-recommends smbclient nano
# smbclient --help # it works
# nano /etc/apt/sources.list # and add bookworm apt sources
# apt install --no-install-recommends libldb2 # upgrades libldb2
# does not upgrade samba-libs
# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
Workaround: also upgrade samba-libs to the version from testing, or fully
upgrade to testing.
Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.
Also, when a single source package builds multiple libraries, it's usually
a lot more robust if the dependencies between those libraries are strict
(libfoo Depends: libbar (= ${binary:Version}) so that users are forced
to upgrade either everything or nothing from that source package. This
is because the upstream developer will never have tested with mismatched
versions, and code in the same source package often uses private/internal
interfaces that are not formally part of the API/ABI, or relies on
internal implementation details that might change in a newer version.
The easiest way to achieve those strict dependencies is usually to add a
debian/shlibs.local that lists all the libraries built by this source
package and makes them generate a strict dependency on the corresponding
package. For instance, here's the one from pango1.0:
https://salsa.debian.org/gnome-team/pango/-/blob/debian/master/debian/shlibs.local
Thanks,
smcv
Control: severity -1 serious
On Thu, 06 Oct 2022 at 22:18:46 +0000, Albert Nash wrote:
> The control center starts neither from gnome (Alt+F1 > Settings) nor from an
> xterm. In the last case, we get some (hopefully, useful) output:
>
> $ gnome-control-center
>
> gnome-control-center: /lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4'
> not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
> The system is Debian stable 11 “bullseye” with a few
> updated packages from Debian testing.
Debian tries to support partial upgrades on a best-effort basis, but
> updated packages from Debian testing.
they are often not completely supportable, because the number of possible
combinations of package versions is just too high.
In this case, it looks like you have probably upgraded libldb2 from bullseye
to testing without also upgrading samba-libs. The dependencies allow this,
so it should in principle be OK, but in fact libldb2 has an incompatible
change to its versioned symbols that means it is not.
I can reproduce this without using gnome-control-center, by using
smbclient, so this is not a gnome-control-center bug. In a minimal
bullseye container:
# apt install --no-install-recommends smbclient nano
# smbclient --help # it works
# nano /etc/apt/sources.list # and add bookworm apt sources
# apt install --no-install-recommends libldb2 # upgrades libldb2
# does not upgrade samba-libs
# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
Workaround: also upgrade samba-libs to the version from testing, or fully
upgrade to testing.
Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.
Also, when a single source package builds multiple libraries, it's usually
a lot more robust if the dependencies between those libraries are strict
(libfoo Depends: libbar (= ${binary:Version}) so that users are forced
to upgrade either everything or nothing from that source package. This
is because the upstream developer will never have tested with mismatched
versions, and code in the same source package often uses private/internal
interfaces that are not formally part of the API/ABI, or relies on
internal implementation details that might change in a newer version.
The easiest way to achieve those strict dependencies is usually to add a
debian/shlibs.local that lists all the libraries built by this source
package and makes them generate a strict dependency on the corresponding
package. For instance, here's the one from pango1.0:
https://salsa.debian.org/gnome-team/pango/-/blob/debian/master/debian/shlibs.local
Thanks,
smcv
Michael Tokarev
Oct 7, 2022, 11:20:03 AM10/7/22
to
Control: tag -1 + confirmed
07.10.2022 11:38, Simon McVittie wrote:
...
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.
When I packaged 4.17 version (currently in experimental), I created a patch
which adds missing intermediate versions (added during maintenance of 4.16
series) to 4.17, but later on dropped it. It will be the same with 4.16->
4.17 upgrade. See
https://salsa.debian.org/samba-team/samba/-/commit/363ec9c9cf107536b94bfd0d5bd623644413b165
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb. For a bullseye version of samba-dsdb-modules
package, the dependency is
libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
(so it conflicts even with next minor version of libldb2).
But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.
> Also, when a single source package builds multiple libraries, it's usually
> a lot more robust if the dependencies between those libraries are strict
> (libfoo Depends: libbar (= ${binary:Version}) so that users are forced
> to upgrade either everything or nothing from that source package. This
The only real user of libldb2 in samba is samba-dsdb-modules. And exactly
due to this reason I switched from the ugly "between" version like I
demonstrated above to exact version. libldb2 builds from samba package
since bookworm version (4.16), in bullseye libldb was in its own package.
> is because the upstream developer will never have tested with mismatched
> versions, and code in the same source package often uses private/internal
> interfaces that are not formally part of the API/ABI, or relies on
> internal implementation details that might change in a newer version.
I weren't aware that libldb2 is linked to from samba-libs. Now I do, and
ofc I'll take care of this. Either by adding countless patches adding
missing versions which upstream refuses to add for some unknown reason
like I initially did for 4.17 version, or by rearranging libraries into
different packages so that libldb isn't used by samba-libs, or maybe
upstream will do their part and add those versions itself, I dunno.
Thanks,
/mjt
07.10.2022 11:38, Simon McVittie wrote:
...
> # smbclient --help
> smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
>
> Workaround: also upgrade samba-libs to the version from testing, or fully
> upgrade to testing.
>
> Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
> should have versioned Breaks against dependent packages that use the old
> symver. It looks as though only the samba and maybe sssd source packages
> will be affected by this.
I talked about this with upstream samba. It is their decision to break old
> smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found (required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
>
> Workaround: also upgrade samba-libs to the version from testing, or fully
> upgrade to testing.
>
> Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
> should have versioned Breaks against dependent packages that use the old
> symver. It looks as though only the samba and maybe sssd source packages
> will be affected by this.
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.
When I packaged 4.17 version (currently in experimental), I created a patch
which adds missing intermediate versions (added during maintenance of 4.16
series) to 4.17, but later on dropped it. It will be the same with 4.16->
4.17 upgrade. See
https://salsa.debian.org/samba-team/samba/-/commit/363ec9c9cf107536b94bfd0d5bd623644413b165
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb. For a bullseye version of samba-dsdb-modules
package, the dependency is
libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
(so it conflicts even with next minor version of libldb2).
But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.
> Also, when a single source package builds multiple libraries, it's usually
> a lot more robust if the dependencies between those libraries are strict
> (libfoo Depends: libbar (= ${binary:Version}) so that users are forced
> to upgrade either everything or nothing from that source package. This
due to this reason I switched from the ugly "between" version like I
demonstrated above to exact version. libldb2 builds from samba package
since bookworm version (4.16), in bullseye libldb was in its own package.
> is because the upstream developer will never have tested with mismatched
> versions, and code in the same source package often uses private/internal
> interfaces that are not formally part of the API/ABI, or relies on
> internal implementation details that might change in a newer version.
ofc I'll take care of this. Either by adding countless patches adding
missing versions which upstream refuses to add for some unknown reason
like I initially did for 4.17 version, or by rearranging libraries into
different packages so that libldb isn't used by samba-libs, or maybe
upstream will do their part and add those versions itself, I dunno.
Thanks,
/mjt
Albert Nash
Oct 7, 2022, 5:20:03 PM10/7/22
to
Simon, thanks, this worked for me:
Workaround: also upgrade samba-libs to the version from testing …
It pulled, I think, also a new version of libc6. Now I finally have control :-). And also thanks for cleaning up the “Package:” mess I inadvertently created.
Cheers!
Albert
0 new messages