Re: OpenConnect 9.01 does not work under Ubuntu 20.04
> > > It would have to be ran manually every time. > > > > I thought it could be automated as part of debian/rules? > > It makes sense to maintain a symbols file only if each version is > annotated with the exact package version that first introduced it, so > that dpkg can generate the minimal dependency required based on the > subset of symbols used by the building package, picking the version > of the most recent one. Otherwise it has no benefits, and only > maintenance costs. Yeah, understood. That script *does* build a symbols file with the correct "first version" for each symbol, because that information is there in text form in the changelog at the top of openconnect.h It basically builds a file which is the same as the one you're doing by hand, although you ought to be marking the @OPENCONNECT_PRIVATE symbols as *new* in each release because they have no ABI guarantee; they shouldn't be considered the same as the same named symbol in 6.0 as your symbols file suggests. > > For the Fedora packages we just ship the library and binary together in > > the *same* package, and that means they are very much in lock-step > > anyway. The binary uses private exports from the library that are very > > much *not* API-managed. The normal library API hygiene doesn't help at > > all there. > > A symbols file wouldn't help with that, as it would make things more > lax, not more strict. Especially if you mark those symbols as being compatible with v6.0 :) > Forcing installations through dpkg is always > possible - it is a user error in most cases. The OBS page clearly > lists the repository and the instructions to use it first via apt, > bypassing that should not be done unless one knows exactly what they > are doing. Agreed. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 19:24 +0100, David Woodhouse wrote: > On Wed, 2022-05-04 at 19:19 +0100, Luca Boccassi wrote: > > On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote: > > > On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote: > > > > The same can be done by maintaining a symbols file. I do that for the > > > > actual Debian/Ubuntu builds ( > > > > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols > > > > > > > > ), but it's a _lot_ of work and it would constantly break the builds > > > > as new things are added/removed, so I did not add it to the upstream > > > > builds. > > > > > > It shouldn't break the build as things are added; surely that's the > > > point? > > > > I'm quite sure it's flagged as an error by Lintian if there's a symbol > > missing in the list. > > > > > It *should* break the build if things are removed without bumping the > > > soname. Which is also the point :) > > > > > > But I don't really understand why Debian lists each individual symbol. > > > The library *minor* version really ought to be enough for any even > > > semi-sanely-maintained library. And if the library is *so* badly > > > maintained that it isn't enough, all bets are off anyway; the developer > > > might even break binary ABI between versions *without* changing symbol > > > names or version, surely? > > > > I'm not sure why the tooling works the way it does, maybe historical > > reasons, it's ancient stuff. > > > > > Anyway, for OpenConnect this script ought to be able to build the > > > symbols file from openconnect.h, which does have a history of when each > > > symbol was added: > > > http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh > > > > > > > It would have to be ran manually every time. > > I thought it could be automated as part of debian/rules? It makes sense to maintain a symbols file only if each version is annotated with the exact package version that first introduced it, so that dpkg can generate the minimal dependency required based on the subset of symbols used by the building package, picking the version of the most recent one. Otherwise it has no benefits, and only maintenance costs. > > I'm not sure it's worth > > the hassle, for this setup? Is there any issue with lock-step updates? > > The only issue with the lock-step updates is that Dominik managed *not* > to update them in lock-step, it seems :) > > For the Fedora packages we just ship the library and binary together in > the *same* package, and that means they are very much in lock-step > anyway. The binary uses private exports from the library that are very > much *not* API-managed. The normal library API hygiene doesn't help at > all there. A symbols file wouldn't help with that, as it would make things more lax, not more strict. Forcing installations through dpkg is always possible - it is a user error in most cases. The OBS page clearly lists the repository and the instructions to use it first via apt, bypassing that should not be done unless one knows exactly what they are doing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 19:19 +0100, Luca Boccassi wrote: > On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote: > > On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote: > > > The same can be done by maintaining a symbols file. I do that for the > > > actual Debian/Ubuntu builds ( > > > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols > > > > > > ), but it's a _lot_ of work and it would constantly break the builds > > > as new things are added/removed, so I did not add it to the upstream > > > builds. > > > > It shouldn't break the build as things are added; surely that's the > > point? > > I'm quite sure it's flagged as an error by Lintian if there's a symbol > missing in the list. > > > It *should* break the build if things are removed without bumping the > > soname. Which is also the point :) > > > > But I don't really understand why Debian lists each individual symbol. > > The library *minor* version really ought to be enough for any even > > semi-sanely-maintained library. And if the library is *so* badly > > maintained that it isn't enough, all bets are off anyway; the developer > > might even break binary ABI between versions *without* changing symbol > > names or version, surely? > > I'm not sure why the tooling works the way it does, maybe historical > reasons, it's ancient stuff. > > > Anyway, for OpenConnect this script ought to be able to build the > > symbols file from openconnect.h, which does have a history of when each > > symbol was added: > > http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh > > > > It would have to be ran manually every time. I thought it could be automated as part of debian/rules? > I'm not sure it's worth > the hassle, for this setup? Is there any issue with lock-step updates? The only issue with the lock-step updates is that Dominik managed *not* to update them in lock-step, it seems :) For the Fedora packages we just ship the library and binary together in the *same* package, and that means they are very much in lock-step anyway. The binary uses private exports from the library that are very much *not* API-managed. The normal library API hygiene doesn't help at all there. smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 19:12 +0100, David Woodhouse wrote: > On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote: > > > > The same can be done by maintaining a symbols file. I do that for the > > actual Debian/Ubuntu builds ( > > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols > > ), but it's a _lot_ of work and it would constantly break the builds > > as new things are added/removed, so I did not add it to the upstream > > builds. > > It shouldn't break the build as things are added; surely that's the > point? I'm quite sure it's flagged as an error by Lintian if there's a symbol missing in the list. > It *should* break the build if things are removed without bumping the > soname. Which is also the point :) > > But I don't really understand why Debian lists each individual symbol. > The library *minor* version really ought to be enough for any even > semi-sanely-maintained library. And if the library is *so* badly > maintained that it isn't enough, all bets are off anyway; the developer > might even break binary ABI between versions *without* changing symbol > names or version, surely? I'm not sure why the tooling works the way it does, maybe historical reasons, it's ancient stuff. > Anyway, for OpenConnect this script ought to be able to build the > symbols file from openconnect.h, which does have a history of when each > symbol was added: > http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh It would have to be ran manually every time. I'm not sure it's worth the hassle, for this setup? Is there any issue with lock-step updates? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 18:59 +0100, Luca Boccassi wrote: > > The same can be done by maintaining a symbols file. I do that for the > actual Debian/Ubuntu builds ( > https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols > ), but it's a _lot_ of work and it would constantly break the builds > as new things are added/removed, so I did not add it to the upstream > builds. It shouldn't break the build as things are added; surely that's the point? It *should* break the build if things are removed without bumping the soname. Which is also the point :) But I don't really understand why Debian lists each individual symbol. The library *minor* version really ought to be enough for any even semi-sanely-maintained library. And if the library is *so* badly maintained that it isn't enough, all bets are off anyway; the developer might even break binary ABI between versions *without* changing symbol names or version, surely? Anyway, for OpenConnect this script ought to be able to build the symbols file from openconnect.h, which does have a history of when each symbol was added: http://git.infradead.org/users/dwmw2/openconnect-deb.git/blob/HEAD:/gensyms.sh smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 18:30 +0100, David Woodhouse wrote: > On Wed, 2022-05-04 at 16:51 +, Schütz Dominik wrote: > > > > when i install "openconnect_9.01-0+9.1_amd64.deb" from > > "https://software.opensuse.org/download.html?project=home%3Abluca%3Aopenconnect%3Arelease&;package=openconnect; > > it doesn't work, see text below: > > Make sure you also install the matching libopenconnect5 package from > https://download.opensuse.org/repositories/home:/bluca:/openconnect:/release/Ubuntu_20.04/amd64/libopenconnect5_9.01-0+9.1_amd64.deb > > I just did that here, and those builds *don't* have PKSC support. > > $ openconnect --version > OpenConnect version v9.01-0+9.1 > Using GnuTLS 3.6.13. Features present: TPMv2, PKCS#11, RSA software token, > HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP > Supported protocols: anyconnect (default), nc, gp, pulse, f5, fortinet, array > Default vpnc-script (override with --script): > /usr/share/vpnc-scripts/vpnc-script > $ ldd /usr/sbin/openconnect | grep pskc > $ There is no libpksc on Ubuntu 20.04: https://packages.ubuntu.com/search?suite=all=all=any=libpskc-dev=names > It's not clear why you managed to install the openconnect binary > package without the corresponding library. In RPM packaging you get a > dependency on 'libopenconnect.so.5(OPENCONNECT_5_8)(64bit)' which is > handled automatically. You wouldn't be able to install a package which > *uses* new symbols from libopenconnect.so.5.8 without also installing > that package. > > In Debian it's apparently different; I'm not sure if this is just > something that Debian packaging doesn't handle at all, or if it's an > issue with the way we build in OBS? Luca? The same can be done by maintaining a symbols file. I do that for the actual Debian/Ubuntu builds ( https://salsa.debian.org/debian/openconnect/-/blob/master/debian/libopenconnect5.symbols ), but it's a _lot_ of work and it would constantly break the builds as new things are added/removed, so I did not add it to the upstream builds. Instead, there's a strict dependency on the same version of the package: Depends: libopenconnect5 (= 9.01-0+9.1) Which makes a bit more sense for the upstream system, and it ensures that the packages are all updated in lockstep. It is not possible to install the openconnect package without the corresponding exact libopenconnect5 package, unless it was manually downloaded and forced through, which is of course a terrible idea. The repository is there to be used via apt/apt-get/aptitude/synaptic. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
Re: OpenConnect 9.01 does not work under Ubuntu 20.04
On Wed, 2022-05-04 at 16:51 +, Schütz Dominik wrote: > > when i install "openconnect_9.01-0+9.1_amd64.deb" from > "https://software.opensuse.org/download.html?project=home%3Abluca%3Aopenconnect%3Arelease&;package=openconnect; > it doesn't work, see text below: Make sure you also install the matching libopenconnect5 package from https://download.opensuse.org/repositories/home:/bluca:/openconnect:/release/Ubuntu_20.04/amd64/libopenconnect5_9.01-0+9.1_amd64.deb I just did that here, and those builds *don't* have PKSC support. $ openconnect --version OpenConnect version v9.01-0+9.1 Using GnuTLS 3.6.13. Features present: TPMv2, PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP Supported protocols: anyconnect (default), nc, gp, pulse, f5, fortinet, array Default vpnc-script (override with --script): /usr/share/vpnc-scripts/vpnc-script $ ldd /usr/sbin/openconnect | grep pskc $ It's not clear why you managed to install the openconnect binary package without the corresponding library. In RPM packaging you get a dependency on 'libopenconnect.so.5(OPENCONNECT_5_8)(64bit)' which is handled automatically. You wouldn't be able to install a package which *uses* new symbols from libopenconnect.so.5.8 without also installing that package. In Debian it's apparently different; I'm not sure if this is just something that Debian packaging doesn't handle at all, or if it's an issue with the way we build in OBS? Luca? smime.p7s Description: S/MIME cryptographic signature ___ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
OpenConnect 9.01 does not work under Ubuntu 20.04
Hi, when i install "openconnect_9.01-0+9.1_amd64.deb" from "https://software.opensuse.org/download.html?project=home%3Abluca%3Aopenconnect%3Arelease&;package=openconnect; it doesn't work, see text below: dominik at host1:~$ ldd /usr/sbin/openconnect /usr/sbin/openconnect: /lib/x86_64-linux-gnu/libopenconnect.so.5: version `OPENCONNECT_5_8' not found (required by /usr/sbin/openconnect) /usr/sbin/openconnect: /lib/x86_64-linux-gnu/libopenconnect.so.5: version `OPENCONNECT_5_6' not found (required by /usr/sbin/openconnect) /usr/sbin/openconnect: /lib/x86_64-linux-gnu/libopenconnect.so.5: version `OPENCONNECT_5_7' not found (required by /usr/sbin/openconnect) linux-vdso.so.1 (0x7ffcb49b9000) libopenconnect.so.5 => /lib/x86_64-linux-gnu/libopenconnect.so.5 (0x7ff85de8) libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x7ff85dcaa000) libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7ff85daf) libproxy.so.1 => /lib/x86_64-linux-gnu/libproxy.so.1 (0x7ff85dace000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff85daab000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff85d8b9000) libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x7ff85d8a1000) libtss2-esys.so.0 => /lib/x86_64-linux-gnu/libtss2-esys.so.0 (0x7ff85d80e000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ff85d7f2000) libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7ff85d6bc000) libstoken.so.1 => /lib/x86_64-linux-gnu/libstoken.so.1 (0x7ff85d4af000) libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7ff85d462000) libpcsclite.so.1 => /lib/x86_64-linux-gnu/libpcsclite.so.1 (0x7ff85d453000) liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7ff85d432000) libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x7ff85d411000) libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x7ff85d28f000) libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x7ff85d255000) libhogweed.so.5 => /lib/x86_64-linux-gnu/libhogweed.so.5 (0x7ff85d21e000) libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x7ff85d198000) /lib64/ld-linux-x86-64.so.2 (0x7ff85df02000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ff85d192000) libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x7ff85cfac000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7ff85cf83000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ff85ce34000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7ff85cc52000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7ff85cc35000) libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x7ff85c95f000) libtss2-sys.so.0 => /lib/x86_64-linux-gnu/libtss2-sys.so.0 (0x7ff85c93d000) libtss2-mu.so.0 => /lib/x86_64-linux-gnu/libtss2-mu.so.0 (0x7ff85c8f6000) libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x7ff85c8ea000) libtomcrypt.so.1 => /lib/x86_64-linux-gnu/libtomcrypt.so.1 (0x7ff85c809000) libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x7ff85c72c000) libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7ff85c6fb000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7ff85c6f4000) libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7ff85c6e5000) libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x7ff85ac22000) libtommath.so.1 => /lib/x86_64-linux-gnu/libtommath.so.1 (0x7ff85ac03000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7ff85abfc000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7ff85abe) dominik at host1:~$ When i copy the "libopenconnect.so.5.6.0" from "libopenconnect5_8.10-2build1_amd64.deb" to "/lib/x86_64-linux-gnu/" and make the Symlink "ln -sf libopenconnect.so.5.6.0 /lib/x86_64-linux-gnu/libopenconnect.so.5". Then it also does not work: dominik at host1:~$ sudo ldconfig dominik at host1:~$ dominik at host1:~$ ldd /usr/sbin/openconnect /usr/sbin/openconnect: /lib/x86_64-linux-gnu/libopenconnect.so.5: version `OPENCONNECT_5_8' not found (required by /usr/sbin/openconnect) /usr/sbin/openconnect: /lib/x86_64-linux-gnu/libopenconnect.so.5: version `OPENCONNECT_5_7' not found (required by /usr/sbin/openconnect) linux-vdso.so.1 (0x7ecf4000) libopenconnect.so.5 => /lib/x86_64-linux-gnu/libopenconnect.so.5 (0x7f226f5c3000) libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x7f226f3ed000) libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x7f226f233000) libproxy.so.1 =>
