UGFja2FnZTogZTJmc2NrLXN0YXRpYwpWZXJzaW9uOiAxLjQwLjQtMQpTZXZlcml0eTogc2VyaW91 cwpKdXN0aWZpY2F0aW9uOiBQb2xpY3kgNy44CgpEZWFyIG1haW50YWluZXIsCgpUaGUgZTJmc2Nr LXN0YXRpYyBwYWNrYWdlIHByb3ZpZGVzIC91c3Ivc2Jpbi9lMmZzY2suc3RhdGljIHdoaWNoIGlz CnN0YXRpY2FsbHkgbGlua2VkIGFnYWluc3QgZ2xpYmMuCgpnbGliYyBpcyBtb3N0bHkgaXMgbW9z dGx5IGxpY2Vuc2VkIHVuZGVyIHRoZSBMR1BMLCB3aGljaCByZXF1aXJlcyB0aGF0CnRoZSBmdWxs IHNvdXJjZSBjb2RlIG9mIHRoZSBpbmNvcnBvcmF0aW5nIGJpbmFyeSBwYWNrYWdlIGJlIG1hZGUK YXZhaWxhYmxlLiBBY2NvcmRpbmcgdG8gRGViaWFuIFBvbGljeSDCpzcuOCBbMV0gc3VjaCBhIGJp bmFyeSBwYWNrYWdlCk1VU1QgbGlzdCB0aGUgZ2xpYmMgc291cmNlIHBhY2thZ2UgKGFuZCBwb3Nz aWJseSBvdGhlcnMpIGluIHRoZQpCdWlsdC1Vc2luZzogZmllbGQuCgpSZWdhcmRzCkF1cmVsaWVu CgpbMV0gaHR0cHM6Ly93d3cuZGViaWFuLm9yZy9kb2MvZGViaWFuLXBvbGljeS9jaC1yZWxhdGlv bnNoaXBzLmh0bWwjYWRkaXRpb25hbC1zb3VyY2UtcGFja2FnZXMtdXNlZC10by1idWlsZC10aGUt YmluYXJ5LWJ1aWx0LXVzaW5nCg==

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

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? 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.

- Ted

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

Processing control commands:

tag -1 + patch

Bug #1106799 [e2fsck-static] e2fsck-static: statically linked against glibc without a Built-Using: field
Added tag(s) patch.

--
1106799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106799
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

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

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.

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
@@ -46,6 +46,7 @@

Package: e2fsck-static
Build-Profiles: <!pkg.e2fsprogs.no-static>
+Built-Using: ${misc:Built-Using}
Priority: optional
Depends: ${misc:Depends}
Recommends: sash | bash-static | zsh-static | busybox-static
--- e2fsprogs-1.47.2/debian/rules
+++ e2fsprogs-1.47.2/debian/rules
@@ -195,7 +195,7 @@
override_dh_gencontrol:
dh_gencontrol -pcomerr-dev -- -v${COMERR_VERSION}-${DEB_VERSION} -VmainBinary=${DEB_VERSION}
dh_gencontrol -pss-dev -- -v${SS_VERSION}-${DEB_VERSION} -VmainBinary=${DEB_VERSION}
- dh_gencontrol --remaining-packages
+ dh_gencontrol --remaining-packages -- -Vmisc:Built-Using="$(shell dpkg-query -f '$${source:Package} (= $${source:Version})' -W libc-dev-bin)"

override_dh_auto_test:
ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))

--- SoupGate-Win32

On Fri, May 30, 2025 at 09:00:35AM +0200, Chris Hofstaedtler wrote:

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

Thanks for the example. I tried doing a Google search, but I couldn't
find anything relevant, perhaps because of robot.txt constraints. In particular there was nothing in Debian Policy, or in Debian Wiki's
description of static linking[1].

[1] https://wiki.debian.org/StaticLinking

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

I agree; which is why I was pushing back on the Built-Using
requirement when there was zero support or explanation I could find
for how to do this. At the very list, a warning against manually
encoding the Built-Using in Debian Policy would have been helpful. In
fact, the examples given in Debian Policy seem to imply that manually
encoding the field in the source package was considered a good thing...

The e2fsck-static package is supplied in the hopes of being helpful to
users who are trying to cover a corrupted root file system, since it
avoids dependencies that might not be available. But if this was
going to be super painful, I was getting very tempted just to yank e2fsck-static as not being worth it, given that we've been shipping
without Built-Using for over a decade without anyone saying boo, and
in my opinion, not really preventing any kind of User Freedom. I
acknowledge that technically speaking that the LGPL requires it, but
it's the sort of thing which is actively making me rethink the value
of Copyleft as requiring bureaucratic nonsense. It just made me super cranky....

Thanks to Aurelien to supplying a patch.

- Ted

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

On Sat, May 31, 2025 at 01:58:33PM +0200, Aurelien Jarno wrote:

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.

Thanks for this patch. Note that you need to add dh-builtusing to the Build-Depends (not just dh-sequence-builtusing) so that automated
builders that use a minimal build-chroot (i.e., sbuild) knows that
they need to install dh-builtusing. It's also helpful for users who
are confused why dpkg-buildpackage doesn't work.

The other problem with using dh-builtusing is that it is only
available in Debian trixie. So if you want to be able to build
e2fsprogs on Debian stable or oldstable, using dh-builtusing will make
life very difficult wanting to build e2fsprogs for Debian stable, or
Ubuntu LTS.

Cheers,

- Ted

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

Hi,

On 2025-06-03 22:26, Theodore Ts'o wrote:

On Sat, May 31, 2025 at 01:58:33PM +0200, Aurelien Jarno wrote:

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.

Thanks for this patch. Note that you need to add dh-builtusing to the Build-Depends (not just dh-sequence-builtusing) so that automated
builders that use a minimal build-chroot (i.e., sbuild) knows that

That should not be the case, or it's a bug in the builder that should be reported. At least sbuild is able to handle that correctly.

they need to install dh-builtusing. It's also helpful for users who
are confused why dpkg-buildpackage doesn't work.

That's indeed can be confusing at a first glance. That said both apt
install and apt satisfy are able to determine that
dh-sequence-builtusing is provided by dh-builtusing.

The other problem with using dh-builtusing is that it is only
available in Debian trixie. So if you want to be able to build
e2fsprogs on Debian stable or oldstable, using dh-builtusing will make
life very difficult wanting to build e2fsprogs for Debian stable, or
Ubuntu LTS.

You are fully correct. The possibility of backports is definitely a good
reason to not use dh-sequence-builtusing.

Regards
Aurelien

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

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

On Wed, Jun 04, 2025 at 10:21:32PM +0200, Aurelien Jarno wrote:

they need to install dh-builtusing. It's also helpful for users who
are confused why dpkg-buildpackage doesn't work.

That's indeed can be confusing at a first glance. That said both apt
install and apt satisfy are able to determine that
dh-sequence-builtusing is provided by dh-builtusing

Ah, I got the failure from dpkg-buildpackage, and I was then trying
things like "apt-cache show" and doing Google searches, and I couldn't
find anything about dh-sequence-builtusing. (And dh-builtusing didn't
show up anything because Google thought this was a typo for
"dh-building" and so you'd got web pages for things like "DH Building
& Landscape LLP")

Having more references for dh-builtusing in Debian Policy and the
Debian Wiki would solve the web search challenges, and it certainly
will make it easier to promote using Built-Using header.

Cheers,

- Ted

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

This is a multi-part message in MIME format...

Your message dated Tue, 10 Jun 2025 01:53:41 +0000
with message-id <E1uOoBJ-00CRRV-Ti@fasolo.debian.org>
and subject line Bug#1106799: fixed in e2fsprogs 1.47.2-2
has caused the Debian Bug report #1106799,
regarding e2fsck-static: statically linked against glibc without a Built-Using: field
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


--
1106799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106799
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

Received: (at submit) by bugs.debian.org; 29 May 2025 20:53:23 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
(2024-03-25) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-123.0 required=4.0 tests=BAYES_00,
BODY_INCLUDES_PACKAGE,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,DKIM_VALID_EF,FOURLA,FROMDEVELOPER,HAS_PACKAGE,
SPF_HELO_NONE,SPF_NONE,UNPARSEABLE_RELAY,USER_IN_DKIM_WELCOMELIST,
XMAILER_REPORTBUG autolearn=ham autolearn_force=no
version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 13; hammy, 150; neutral, 34; spammy,
0. spammytokens:
hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin,
0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311,
0.000-+--H*RT:311, 0.000-+--H*RT:108
Return-path: <aurel32@debian.org>
Received: from stravinsky.debia