Your message dated Wed, 20 Mar 2024 00:06:15 +0100
with message-id <zfoaz19brpoy_...@thunder.hadrons.org>
and subject line Re: Bug#1066952: Defaulting to
-Werror=implicit-function-declaration might not be a good idea
has caused the Debian Bug report #1066952,
regarding Defaulting to -Werror=implicit-function-declaration might not be a
good idea
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.)
--
1066952: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066952
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: dpkg-dev
Version: 1.22.6
Severity: serious
X-Debbugs-Cc: Steve Langasek <vor...@debian.org>
There are at least 3 different ways how -Werror=implicit-function-declaration
breaks packages:
1. Code that did emit implicit-function-declaration warnings during
compilation before and does FTBFS now
2. Code that does FTBFS now due to other breakage caused by
-Werror=implicit-function-declaration, e.g. in autoconf tests
3. Code that does still compile with -Werror=implicit-function-declaration
but behaves differently, e.g. due to failing autoconf tests silently
disabling features
Cases from point 1 were always(?) bugs and it is good that
they get fixed.
The real-world effect of these bugs can be everywhere from
"completely harmless" to "that was always broken".
Debian has automation listing implicit-function-declaration warnings
in all packages already running for several years:
https://qa.debian.org/bls/bytag/W-implicit-declaration.html
My main worry is point 3, issues like #1066394.
#1066394 was found due to causing a FTBFS in a different package,
but the more common case is likely that a program has some
feature/plugin disabled and this won't be spotted until much later.
"Much later" might be after the release of trixie a user upgrading
to bookworm who uses this feature.
Or it might result in a program silently using an insecure legacy codepath,
e.g. after a test for getentropy() failed.
A large part of the packages in unstable might not get recompiled
between now and the release of trixie, creating the additional
issue that any such problem might occur only after a security update
or point release update if this is the next rebuild of the package
in trixie.
--- End Message ---
--- Begin Message ---
Hi!
On Sat, 2024-03-16 at 01:57:16 +0100, Guillem Jover wrote:
> On Sat, 2024-03-16 at 02:18:22 +0200, Adrian Bunk wrote:
> > Package: dpkg-dev
> > Version: 1.22.6
> > Severity: serious
> > X-Debbugs-Cc: Steve Langasek <vor...@debian.org>
>
> > 3. Code that does still compile with -Werror=implicit-function-declaration
> > but behaves differently, e.g. due to failing autoconf tests silently
> > disabling features
>
> > Debian has automation listing implicit-function-declaration warnings
> > in all packages already running for several years:
> > https://qa.debian.org/bls/bytag/W-implicit-declaration.html
>
> > My main worry is point 3, issues like #1066394.
> >
> > #1066394 was found due to causing a FTBFS in a different package,
> > but the more common case is likely that a program has some
> > feature/plugin disabled and this won't be spotted until much later.
> >
> > "Much later" might be after the release of trixie a user upgrading
> > to bookworm who uses this feature.
> >
> > Or it might result in a program silently using an insecure legacy codepath,
> > e.g. after a test for getentropy() failed.
>
> Not enabling this -Werror might imply ABI breakage for the time64
> transition, which seems pretty terrible too. The way I see it, and
> given the timing, effort and preparation necessary for this transition,
> both options (enabling or not enabling the fatal warning) are potentially
> bad in their own way.
>
> But given that these are clearly bugs, that not enabling them can imply
> ABI breakage, that if things go according to plan (AFAIK) this will be
> made the default anyway with gcc-14, that we can track those down, and
> people have already been doing that for the Modern-C effort, see:
>
> https://fedoraproject.org/wiki/Changes/PortingToModernC
> https://wiki.gentoo.org/wiki/Modern_C_porting
>
> I think we might as well just cope with this anyway right away.
>
> > A large part of the packages in unstable might not get recompiled
> > between now and the release of trixie, creating the additional
> > issue that any such problem might occur only after a security update
> > or point release update if this is the next rebuild of the package
> > in trixie.
>
> AFAIUI (and I'd expect) the whole distribution needs to be rebuilt
> anyway as part of the time64 transition, otherwise the 32-bit ports
> that are affected by it, will not benefit from it. So I don't think
> this should be a concern.
>
> So I'm inclined to close this, and consider the current state, the
> less bad one. :/
I'm thus going to close this now.
Thanks,
Guillem
--- End Message ---
