Your message dated Fri, 23 Sep 2022 03:33:06 +0200
with message-id <yy0m0sznjgaon...@thunder.hadrons.org>
and subject line Re: Bug#1020335: Enable lfs (large file support) by default
for building packages
has caused the Debian Bug report #1020335,
regarding Enable lfs (large file support) by default for building packages
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 ow...@bugs.debian.org
immediately.)
--
1020335: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020335
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg
Severity: wishlist
Tags: lfs, hppa
I've seen quite some lfs errors (on 32-bit platform) with packages in the last
weeks.
Isn't it time now (year 2022), to take lfs down from "future" feature to
"standard" feature
and enable it by default?
I mean, instead of requiring package maintainers to add:
DEB_BUILD_OPTIONS="future=+lfs"
or
DEB_BUILD_MAINT_OPTIONS="future=+lfs"
simply enable this feature now by default?
With that everyone (on a 32-bit platform) would e.g. get:
dpkg-buildflags --get CPPFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
I have to admit, that I don't know if some packages would fail to build with it,
but if they do, they should be fixed....
--- End Message ---
--- Begin Message ---
On Tue, 2022-09-20 at 15:44:32 +0200, Helge Deller wrote:
> Just one more question:
> > > > DEB_BUILD_MAINT_OPTIONS="future=+lfs"
> > > > With that everyone (on a 32-bit platform) would e.g. get:
> > > > dpkg-buildflags --get CPPFLAGS
> > > > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wdate-time
> > > > -D_FORTIFY_SOURCE=2
>
> Since many packages just use CFLAGS or CXXFLAGS (but not CPPFLAGS), wouldn't
> it
> make sense that dpkg-buildflags adds
> "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
> to those as well?
This loses the precision of where these apply to, so I'd rather not.
For build systems that lack that distinction, if they are using
something like dh, then this should be handled automatically.
Also BTW, one thing that I tried to do was get this explained and warned
by lintian
(<https://lintian.debian.org/tags/binary-file-built-without-LFS-support>)
so that people could see when they are affected and potentially fix
this once it is safe (say SONAME bump). One problem has been that
lintian.d.o did not run (AFAIR) on non-amd64 systems, so these warnings
were not visible at all. Just realized this for several of the packages
I maintain recently (since I do not tend to routinely build on 32-bit
arches anymore).
The new lintian runs driven by UDD (https://udd.debian.org/lintian) are
done on multiple arches, so that's good, I think we are mostly missing a
tag centric view similar to the old lintian's site one above (#1016188).
Something that could be done, and perhaps you might be interested is
to check for sources producing no shared library packages triggering
that lintian tag, and file bug reports with patches. Which would be
an effective way to push the LFS transition forward. :)
In any case, I'll just close this now.
Thanks,
Guillem
--- End Message ---
