Hi,

my package gensio, which generates a library package, has recently
thrown a few lintian warnings regarding missing symbols files. I read
the wiki page and the manual page of dpkg-gensymbols and had
dpkg-gensymbols generate a debian/libgensio0.symbols file, added the Build-Depends-Package line and did the mentioned conversions regarding
C++ libraries.

Still, the build on i386 fails since the symbols file looks different on
i386 than it does on amd64. See https://salsa.debian.org/debian/gensio/-/jobs/3093727

The repository can be inspected at https://salsa.debian.org/debian/gensio/-/tree/master

I guess this behavior is expected since you can have symbols file per
arch as debian/libgensio0.symbols.$ARCH. But how do I generate those?

Do I really need to build on all arches and/or guess what's needed in
the arch-dependent symbol file from the logs of failed buildd runs? This
looks like an awful lot of work that has to be repeated for every
upstream update?

Or am I missing something here?

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 11, 2022 at 02:22:25PM +0200, Marc Haber wrote:

Hi,

my package gensio, which generates a library package, has recently
thrown a few lintian warnings regarding missing symbols files. I read
the wiki page and the manual page of dpkg-gensymbols and had
dpkg-gensymbols generate a debian/libgensio0.symbols file, added the Build-Depends-Package line and did the mentioned conversions regarding
C++ libraries.

Still, the build on i386 fails since the symbols file looks different on
i386 than it does on amd64. See https://salsa.debian.org/debian/gensio/-/jobs/3093727

The repository can be inspected at https://salsa.debian.org/debian/gensio/-/tree/master

I guess this behavior is expected since you can have symbols file per
arch as debian/libgensio0.symbols.$ARCH. But how do I generate those?

Do I really need to build on all arches and/or guess what's needed in
the arch-dependent symbol file from the logs of failed buildd runs? This looks like an awful lot of work that has to be repeated for every
upstream update?

Or am I missing something here?

My experience with symbol files and C++ is: It's a nightmare.

I tried them on a few occasions only to drop them a few uploads later, as
they add a lot of maintainance burden. They will frequently break, as some other package or toolchain might have influences, are
architecture dependent and once you think you've got it you'll get the
next breakage… I'd just override the warning and be done.

--
tobi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 2022-08-11 at 16:10 +0200, Tobias Frost wrote:

I tried them on a few occasions only to drop them a few uploads later, as they add a lot of maintainance burden. They will frequently break, as some other package or toolchain might have influences, are
architecture dependent and once you think you've got it you'll get the
next breakage… I'd just override the warning and be done.

What do you do for the library shlibs in that case? Use == $version?

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmL1rjIACgkQMRa6Xp/6 aaO8Sw/9FBUzZYbfnyjdNFdzuwisGTKNaLEv3RZqndHiONdm79hyUYoLMHIAl0Qo 2DGNNzU/8ngpOkNZstNTxU/h4kZSMTklm3nGwGtbJcY8aD16n+Ejtwm303px9mq8 hnxr94UhqygILBUi6UBr9PTnLWmv/bhiljyJZRkRyKAR1dxWG8igIhLnC8seA6Ub Wm/GxMOCCv8itH0AcadYFgUe6oL7b02xFfOlwk4pPDzVnqIzjjeT2njtdVl6gGK8 PrqXIsC5/HnljXxUdyFCulWimV5yqLFXjymIp86rJNLMVukTMLCEz2eHmcCa1b0a 66mVkiFV7mF+Zn6H42hixPEvZdVMpDp1vlBNu85+nyVS+8v2bGFDOYMs+4ExEPVK UxC0jV6MHtE/gEqHBht7cq3sBRB8RAoDA+6FMCvhi5TP33LR1CvGKSCqSgJQ/cMK jd86YFEcS1F5iHx4egRkDLaNcRVHvtI22Uyl+7bPORZjAONdHPFLwxzPg/BRoYvV y/+AlX2Y6VtGWHS4uAMXC92Wa/ENMaFQCOAv0y7bD6YZpfpcnVEfsYju/dYGMIsC bRCfuYYUZexnur0i5MEhP3v1xPks6ClINRoQLMHdDzdygWdrP31k2/vkSYfy2rT4 d0IdVfcoy3LrqE5KKQpYCUOD2Y/WXj5/xgip/jMWJwY0XN3c9r8=
=Hjh6
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Marc,

Em qui., 11 de ago. de 2022 às 09:22, Marc Haber <[email protected]> escreveu:

Hi,

my package gensio, which generates a library package, has recently
thrown a few lintian warnings regarding missing symbols files. I read
the wiki page and the manual page of dpkg-gensymbols and had
dpkg-gensymbols generate a debian/libgensio0.symbols file, added the Build-Depends-Package line and did the mentioned conversions regarding
C++ libraries.

Still, the build on i386 fails since the symbols file looks different on
i386 than it does on amd64. See https://salsa.debian.org/debian/gensio/-/jobs/3093727

The repository can be inspected at https://salsa.debian.org/debian/gensio/-/tree/master

I guess this behavior is expected since you can have symbols file per
arch as debian/libgensio0.symbols.$ARCH. But how do I generate those?

Do I really need to build on all arches and/or guess what's needed in
the arch-dependent symbol file from the logs of failed buildd runs? This looks like an awful lot of work that has to be repeated for every
upstream update?

I suggest uploading new upstream releases to experimental to know the
behavior in each architecture. For MISSING lines, an easy fix is to
exclude the fault architectures. E.g. to exclude i386 and x32:

(arch=!i386 !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
gensios::gensio_log_levels, char const*, __va_list_tag*)@Base"

Cheers,

Eriberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 12, 2022 at 09:34:42AM +0800, Paul Wise wrote:

On Thu, 2022-08-11 at 16:10 +0200, Tobias Frost wrote:

I tried them on a few occasions only to drop them a few uploads later, as they add a lot of maintainance burden. They will frequently break, as some other package or toolchain might have influences, are
architecture dependent and once you think you've got it you'll get the
next breakage… I'd just override the warning and be done.

What do you do for the library shlibs in that case? Use == $version?

${shlibs:Depends}

--
bye,
pabs

https://wiki.debian.org/PaulWise

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 12, 2022 at 12:43:23AM -0300, Eriberto Mota wrote:

I suggest uploading new upstream releases to experimental to know the behavior in each architecture. For MISSING lines, an easy fix is to
exclude the fault architectures. E.g. to exclude i386 and x32:

(arch=!i386 !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
gensios::gensio_log_levels, char const*, __va_list_tag*)@Base"

But isn't that as bad as maintaining a package.symbols.$ARCH for every
arch?

And what's the benefit in having a symbols file? People on IRC tell me
that's only important for big libs with a huge number of reverse
dependencies.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2022-08-12 at 07:00 +0200, Tobias Frost wrote:

${shlibs:Depends}

I mean for the library, what do you set debian/$package.shlibs to?

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmL2JaUACgkQMRa6Xp/6 aaPkxg/+K8OQkgHhVMenrFLlFo9XbOEhD3yTrGHpXWaI01OA2ivLo6nfZMza2odN gyY0p7Xio6IBfpdgAmvlUwWHTRJft6InIdookiVjpMzWSFSFUuUk+R2AYViM4nLN 25AuNwESlOAY4etxjArCs/uEaJnlhqPAWQuGaHzzBTREhl23Ito5poBS91v+Q+OG wMNiX084frF+o/a1wgqEHfEv6qAAhJQIvyOkvnOYGzCMS4s/z7I1OQxfoxkgg+QN A+6TrkL83DGvLlS31JQPlUw3yelBnkqwFlsWrag8fDn9WY0t0OeI+8koooLCrk5T PcSyugNSZDzZyN9cCjwcz6RQMX99UAEfxBpGHFzeOTU2MhbREP1cPtrMZWHIKkLS EUg7nbmVH5gd5pSOTbgYnVpMeHq4AZ83MiTmZPlLyp3ZFkj3jKJwO7Pj2F+y0vUa Gg4rbX1JdltJUibEYu6ZxU340gRYQfKr1FU00+uS8dbSB0JsILc/McKVYhtqFC6o tU8X5Fk5j/IWg5bjgvk/rEKxpZn1P/K9Xuq/X9r8+nSdidXYjTnTiHlBEvBnrenw VCZgGSDfn1IpvBqLznL5EJ5iNpJaDtG9EXGWAGSbu4UuudmHYLpgZe/GCWYfODel 5xU8l7Cji80Hrv77Q1Yaz7dtd7UNVFKeekaCJQmlui7Kr9aJIzw=
=sqDb
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hej Marc,

the following page might help you: https://qt-kde-team.pages.debian.net/symbolfiles.html

In short: The Qt/KDE team has a couple of helpers that simplify handling symbolfiles significantly. The page explains when you can use them and
how you can use them.
The helpers also take care of the differences between the different architectures (no need for multiple files per library as others have mentioned), though you need a buildlog for each architecture. But you
can let the buildds do that for you.


--
Med vänliga hälsningar

Patrick Franz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 2022-08-12 at 12:06 +0200, Marc Haber wrote:

what's the benefit in having a symbols file?

It means that packages depending on a library can relax their version dependencies on that library to the oldest version that supports all
the symbols they use. Until the symbols mechanism was invented,
whenever a library added a symbol, it bumped its shlibs and after that
packages built against the library would require the new version.
That made it harder to do (partial) upgrades, testing migration etc.

https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmL3GDwACgkQMRa6Xp/6 aaMfSg/9FR2hjbQvx6esKXPEJtQVgS/ratToqTjEBWE540rHDE3cMT1uu+zV72nk ZOwspen34xdBHW/lASf3hE4i/VbmrVec0jLoWkZqBdPLe40/i0IseDP9LPO/k//v xFz9JHOUTYYtSjRxkrzPzjukWcyitDwp0AjzbSZPqBmbnpVd6FrF8hcswp44SwUb fd1q81vwHvrHQ8Swz9NysL3fqFyTz15776o6/dYroxBf2DXeuoKJdGgeNyLilNEh IqqO4Rd6EYi4dCRl6NUoSPbeXeeaaJ8yhES2gQDpmRbPmE+4R+TPYBa05PfpkHpR vsrK4iPQawbdtppxgzIQ9tTUgIpaAcAK7cQcshQ57IRlgzDlTtbG04AfG3xV2SEx mhhbGl6/2fOMR7F4PXkZT7u7kw8sL8fz7JkO/B7dWIGK417O60G8ZGPnbK/Pr7fB PzuIWTX5SmsrddiXns760yyZ7oNxMqc+weEAyizMrnOa9n83WfYH6ulE9Po5eWgw MhREg73vyE3sHGVcEgyAscf1PdXkkzK3IE/UBtVbnTlKrl4pJuCZhObbBuWmUrC8 e/ypBo0ktuX6/st2Kpb6QY/hY34NZmAg3xtYT5WsgNWAlJv/Im/XKZdewBR/3Mjt xxOHRotgnKezyTjgCSW2ynC2FEbi7GKsXhixVTtpw7eBNs9EuhA=
=Nr2R
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Aug 13, 2022 at 11:19:24AM +0800, Paul Wise wrote:

On Fri, 2022-08-12 at 12:06 +0200, Marc Haber wrote:

what's the benefit in having a symbols file?

It means that packages depending on a library can relax their version dependencies on that library to the oldest version that supports all
the symbols they use. Until the symbols mechanism was invented,
whenever a library added a symbol, it bumped its shlibs and after that packages built against the library would require the new version.
That made it harder to do (partial) upgrades, testing migration etc.

https://wiki.debian.org/Projects/ImprovedDpkgShlibdeps

That sounds to me like vitally important for important libraries such as
libc6, OpenSSL, curl, xml etc bla, but a fix for a non-problem for my
package.

I think this is worth doing only if the number of your reverse depends
is well in the two-digit range or above that. That doesn't apply (yet)
to gensio, so I'm likely to remove the symbols file from my package
again and override the lintian warning.

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Eriberto,

On Fri, Aug 12, 2022 at 12:43:23AM -0300, Eriberto Mota wrote:

I suggest uploading new upstream releases to experimental to know the behavior in each architecture. For MISSING lines, an easy fix is to
exclude the fault architectures. E.g. to exclude i386 and x32:

(arch=!i386 !x32)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*,
gensios::gensio_log_levels, char const*, __va_list_tag*)@Base"

Just in case I want to use this opportunity to get a feeling for symbols
files, can I also specify architectures for which a line holds, like:

(arch=!arm64)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*, gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1
(arch=arm64)(c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*, gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1

dpkg-gensymbols does not seem to be willing to grok the second line ("gensio_log_levels, not a valid version").

Also, the arch extension does not seem to be in deb-symbols(5).

What am I missing here?

Greetings
Marc

-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2022-08-13 at 11:31 +0200, Marc Haber wrote:

I think this is worth doing only if the number of your reverse depends
is well in the two-digit range or above that. That doesn't apply (yet)
to gensio, so I'm likely to remove the symbols file from my package
again and override the lintian warning.

Looks like you only have one reverse dep (ser2net) so that sounds fine.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmL4VZgACgkQMRa6Xp/6 aaOw6w/9H7IfpRQrkyGODVkEPXYOzmN6DT7/Ei3tiXFiRb0VGcmXrczJVRfZgveV e8unV6pAyCPP8Fi7qSRjRRIS9r7tN5KRi5BpNBaTqG39MDgaUrgifVFupcz4qtk1 XO41yBJKwiE4UZBbo6LJ4NxWK5KX70nuWjRnjyHNdGxtDNyjuKWbDNF7LUBhfDLR 2QkIKuHMXTY0lD+r86KOSY2sA0GA6x5t0lAEFRg/NZ4VDjv63Cy/jzjHPagf8fW0 qWvXl7uwJ9KATpTkV1coetJx4/txGS0CVGPYwTZJAlEBOSg1/m+EpF9BQrnzjrM7 Ma6Wgxz3EUsVqIzb1x+l/fXZPYYd6olRME8XRgItsbhDGLMkXkISGIrc0LSMJO4q UXPhgy9EkO3420B0GhmypOAka13qoBoYkso7AOa43zSUcctcIZ80r+xRfxNoWJsh 9CBtvgEccSZoitxPvTvVBXdYr9JyRWnWZmvaeX2akVK0uxwoDYKU/vSZmp+S4eKq KuvxVd1UkSNdeJeIK+KD3FYW/rduIhKRz4lvr8iQxCdYKUQy6XPYydm6aZE5ds4o D7kaE4BOEWjUYPiIDZLv0pQNW/eaoWcxVRfDk60bBLH2O7kz2b2I7YI5UYfgYqlY CxYHnZVUrKkn2IzNwE0crDG4zEGmsAKWp69Rnk3u1/QDtVV0tPw=
=NIdr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Aug 14, 2022 at 09:53:49AM +0800, Paul Wise wrote:

On Sat, 2022-08-13 at 22:19 +0200, Marc Haber wrote:

dpkg-gensymbols does not seem to be willing to grok the second line ("gensio_log_levels, not a valid version").

Also, the arch extension does not seem to be in deb-symbols(5).

See the deb-src-symbols(5) manual page, I think you want this:

(arch=!arm64|c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*, gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1
(arch=arm64|c++)"gensios::gensio_cpp_vlog_handler(gensios::gensio_os_funcs*, gensios::gensio_log_levels, char const*, __va_list_tag*)@Base" 2.5.1

Yes, thanks.

Greetings
Marc



-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)