Source: glib2.0 Version: 2.84.4-3~deb13u3 Severity: important Justification: Debian Policy § 7.8 Control: affects -1 libsysprof-capture-4-dev
Hello,
In Trixie and unstable, GLib appears to statically link with
/usr/lib/${DEB_HOST_MULTIARCH}/libsysprof-capture-4.a from
libsysprof-capture-4-dev based on the build logs. My usual helper tool for
tracing binaries back to sources, 'eu-srcfiles', seems not to handle this
gracefully for the C/C++ sources (†), but it at the very least recognizes the
headers are used:
> $ eu-srcfiles -e /usr/lib/$(dpkg-architecture -q
> DEB_HOST_MULTIARCH)/libglib-2.0.so | grep -F sysprof
> /usr/include/sysprof-6/sysprof-capture-types.h
> /usr/include/sysprof-6/sysprof-clock.h
> /usr/include/sysprof-6/sysprof-collector.h
I haven't made certain that artifacts from the static library are ultimately
incorporated into GLib's binary packages, but seeing that the headers are used,
I hope, substantiates my concern.
The sysprof debian/copyright file doesn't make it obvious, but these files
appear to be under a BSD-two-clause-style license. Regardless though we still
have the obligation to retain the sysprof sources in the archive which
correspond to GLib binary package builds, because GLib is GNU LGPL. This is
kind of a corner case and the "why" may not be intuitive. Fortunately the
Debian Policy language is succinct and helpful here [1]:
> Some binary packages incorporate parts of other packages when built but do
> not have to depend on those packages. Examples include linking with static
> libraries or incorporating source code from another package during the build.
> In this case, the source packages of those other packages are part of the
> complete source (the binary package is not reproducible without them).
Here sysprof is being "incorporated" and GLib is doing "the incorporating".
*Emphasis* is mine:
> When the license of *either* the incorporated parts *or the incorporating
> binary package* requires that the full source code of the *incorporating*
> binary package be made available, the Built-Using field must list the
> corresponding source package for any affected binary package incorporated
> during the build, including an “exactly equal” (“=”) version relation on the
> version that was used to build that version of the incorporating binary
> package.
I suggest using dh-builtusing because it's challenging to get Built-Using
correct. Also, I believe it uses a substvar to populate the field, so when
building for architectures that don't use sysprof anyway the Built-Using will
magically be omitted. I'd be happy to send a merge request, but am filing this
because discussion beforehand is important 🙂
Also I suggest checking with the Release Team folks about if they'd like this
fixed in Trixie. This class of problem doesn't come up very often and I don't
know any precedent for or against addressing it, so 🤷
† It's not apparent that there's any package providing debug symbols for this
static library (no -dbgsym is generated and the object files inside appear to
be mostly stripped and not have Build-IDs generated), so this is probably the
culprit, and one to be dealt with another time.
[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using
Thanks
P.S. I haven't researched other reverse build dependencies of sysprof yet;
webkit2gtk is probably also affected (debian/copyright says
Source/WTF/wtf/glib/SysprofAnnotator.h is itself LGPL-2+).
-- System Information:
Debian Release: 13.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security-debug'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.96+deb13-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
smime.p7s
Description: S/MIME cryptographic signature
