* Theodore Ts'o <tytso@mit.edu> [250530 02:15]:

On Thu, May 29, 2025 at 10:53:20PM +0200, Aurelien Jarno wrote:

Package: e2fsck-static
Version: 1.40.4-1
Severity: serious
Justification: Policy 7.8

Dear maintainer,

The e2fsck-static package provides /usr/sbin/e2fsck.static which is
statically linked against glibc.

glibc is mostly is mostly licensed under the LGPL, which requires that
the full source code of the incorporating binary package be made
available. According to Debian Policy §7.8 [1] such a binary package
MUST list the glibc source package (and possibly others) in the
Built-Using: field.

Is there an idiomatic way to automatically determine in debian/rules
what version of glib was used to build the binary package, so the
exact version can be specified in Built-Using?

Here's an example I found using codesearch, from the grub package:

https://sources.debian.org/src/grub2/2.12-7/debian/rules/?hl=593#L593

BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), \n' -W liblzo2-dev)

...

override_dh_gencontrol:
dh_gencontrol -- -VBuilt-Using="$(BUILT_USING)"

Surely there must be a
standard way to do this, since if it's hard-coded as a constant value,
the probability that this value will be incorrect when future updates
are done, perhaps as part of an NMU, will be incorrect.

Worse, if there is an architecture specific NMU rebuild, the version
used for one architecture might be different than another, which meas
the control file would rapidly become unmaintainable and a complete
mess if it needs to be hard-coded and the maintainer has to manually
update.

For that matter, when we do a source upload, the version of glibc that
might be on a particular build server might be different over time
(for example if FTP Masters takes months to approve a package after we
bump the major version number of a shared library, reasulting in a
"new" package being created which requires manual processing...)

What a mess. Surely e2fsprogs isn't the only package that has this >requirement; is there a stock way to address this?

I will note that this information is already uploaded in the buildinfo
file, and given that we have Debian Snapshots, it's not like there
neeeds to be any special processing to make sure the exact version of >corresponding source will be preserved. So requiring maintainers to
manually update the Built-Using field in debian/control seems to be >hopelessly busy bureaucratic work.

Please don't manually mantain a field in the source package's
d/control that's supposed to exist only in binary packages.

Chris

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

On 2025-05-30 11:19, Aurelien Jarno wrote:

control: tag -1 + patch

Hi,

On 2025-05-30 09:00, Chris Hofstaedtler wrote:

* Theodore Ts'o <tytso@mit.edu> [250530 02:15]:

On Thu, May 29, 2025 at 10:53:20PM +0200, Aurelien Jarno wrote:

Package: e2fsck-static
Version: 1.40.4-1
Severity: serious
Justification: Policy 7.8

Dear maintainer,

The e2fsck-static package provides /usr/sbin/e2fsck.static which is statically linked against glibc.

glibc is mostly is mostly licensed under the LGPL, which requires that the full source code of the incorporating binary package be made available. According to Debian Policy §7.8 [1] such a binary package MUST list the glibc source package (and possibly others) in the Built-Using: field.

Is there an idiomatic way to automatically determine in debian/rules
what version of glib was used to build the binary package, so the
exact version can be specified in Built-Using?

Here's an example I found using codesearch, from the grub package:

https://sources.debian.org/src/grub2/2.12-7/debian/rules/?hl=593#L593

BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), \n' -W liblzo2-dev)

...

override_dh_gencontrol:
dh_gencontrol -- -VBuilt-Using="$(BUILT_USING)"

Yep, that's the way to do it, but you also need to define Built-Using in debian/control. Please find attached a full patch to do that.

I have been pointed out at dh-builtusing, which is another way to
achieve the same result. I have attached a patch with that alternative,
at the end it's mostly a question of taste.

Regards
Aurelien

--
Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net

--- e2fsprogs-1.47.2/debian/control
+++ e2fsprogs-1.47.2/debian/control
@@ -2,7 +2,7 @@
Section: admin
Priority: important
Maintainer: Theodore Y. Ts'o <tytso@mit.edu>
-Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkgconf, libarchive-dev <!nocheck>, libfuse3-dev [linux-any kfreebsd-any] <!pkg.e2fsprogs.no-fuse2fs>, debhelper-compat (= 12), dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-
any], systemd-dev [linux-any], cron [linux-any], dh-sequence-movetousr +Build-Depends: dpkg-dev (>= 1.22.5), gettext, texinfo, pkgconf, libarchive-dev <!nocheck>, libfuse3-dev [linux-any kfreebsd-any] <!pkg.e2fsprogs.no-fuse2fs>, debhelper-compat (= 12), dh-exec, libblkid-dev, uuid-dev, m4, udev [linux-any], systemd [linux-
any], systemd-dev [linux-any], cron [linux-any], dh-sequence-movetousr, dh-sequence-builtusing
Rules-Requires-Root: no
Standards-V