Hi Steve,
On Mon, Feb 27, 2023 at 04:39:29PM -0800, Steve Langasek wrote:
> Well, I'm not seeking to stand in the way of the work, so much as trying to
> make sure this is the most useful work to be doing to meet the actual use
> cases.
Thank you. I see that you are seeking a better solution and
On Tue, Feb 28, 2023 at 11:10:24PM +0100, Philipp Kern wrote:
> On 28.02.23 20:34, Steve Langasek wrote:
> > But it's not practical to do CI -Werror builds; when we do
> > out-of-archive rebuilds for all architectures, it's a significant
> > committment of resources and each rebuild takes about a m
On 28.02.23 20:34, Steve Langasek wrote:
This is conceptually interesting to me. In practice, I don't see us using
this in Ubuntu. We have per-architecture differences from Debian (ppc64el
building with -O3 by default; riscv64 being a release architecture where it
isn't in Debian) that make it
On Tue, Feb 28, 2023 at 06:05:13PM +0100, Sven Mueller wrote:
> > It isn't clear to me from the discussion history that this is the actual
> > use case at issue. But supposing it is, that's one use case; and it's a
> > use case that can be addressed without having to make any per-package
> > chan
Am 2023-02-28 01:39, schrieb Steve Langasek:
[some precursor
I can see that for bootstrapping a new architecture, it will sometimes
be
useful to use a toolchain newer than the one that is currently default
in
Debian, and as a result it is useful to also be able to bypass new
stricter
-Werror
On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote:
> > "Steve" == Steve Langasek writes:
> Steve> If this is for people doing out-of-archive builds who don't
> Steve> want to deal with failures from -Werror, I can see how having
> Steve> a single environment toggle is use
> "Steve" == Steve Langasek writes:
Steve> If this is for people doing out-of-archive builds who don't
Steve> want to deal with failures from -Werror, I can see how having
Steve> a single environment toggle is useful to them; but it doesn't
Steve> seem useful to *Debian* when s
On Mon, Feb 27, 2023 at 10:49:48AM -0700, Sam Hartman wrote:
> Helmut> The problem here specifically arises, because we do not have
> Helmut> consensus on -Werror being a bad idea in release builds.
> I agree with your reading of consensus and for that reason support
> registering an opti
Helmut> The problem here specifically arises, because we do not have
Helmut> consensus on -Werror being a bad idea in release builds.
I agree with your reading of consensus and for that reason support
registering an option to say do not use -Werror.
ld with -Werror.
> >
> > DEB_BUILD_OPTIONS=nowerror would imply that building with -Werror
> > by default would be OK, but there are already too many FTBFS due
> > to -Werror.
>
> I would happily agree with all of this, but I do not see consensus on
> either.
My point is that an opt-out DE
On Sun, Feb 26, 2023 at 07:15:45PM +0200, Adrian Bunk wrote:
> What you describe is an RC bug as soon as the more recent toolchain
> becomes default, and the correct solution is to not build with -Werror.
>
> DEB_BUILD_OPTIONS=nowerror would imply that building with -Werror
> by d
mpromise. I also understand
> that packages may fail to build for other reasons with new toolchains
> (e.g. missing #includes). However, -Werror has proven to be quite
> repetitive and seems worthwhile to address to me.
>
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror
On Fri, 24 Feb 2023 at 09:14:15 -0800, Russ Allbery wrote:
> Simon McVittie writes:
> > In a typical build system like Autotools, CMake or Meson, it's going to
> > be much, much easier for the answer to be yes, because the obvious way
> > to make linters easy to run is to implement them as a (slig
Simon McVittie writes:
> In a typical build system like Autotools, CMake or Meson, it's going to
> be much, much easier for the answer to be yes, because the obvious way
> to make linters easy to run is to implement them as a (slightly
> specialized) test.
I agree for separate linters, but I'm n
On Fri, Feb 24, 2023 at 08:27:53AM +0100, Helmut Grohne wrote:
> > Also I think it was recommended to *not* use -Werror by default as it
> > is too fragile. Maybe one should have a "developer mode" flag instead
> > that allows using -Werror?
>
> Well, if we were avoiding -Werror by default, we wou
On Fri, 24 Feb 2023 at 12:11:19 +0100, Helmut Grohne wrote:
> On Fri, Feb 24, 2023 at 10:58:37AM +0100, Johannes Schauer Marin Rodrigues
> wrote:
> > Should other linters like shellcheck be disabled with
> > DEB_BUILD_OPTIONS=nocheck?
>
> I argue for "no" (see above).
In a typical build system l
On Fri, Feb 24, 2023 at 10:58:37AM +0100, Johannes Schauer Marin Rodrigues
wrote:
> I question the conflation of a hypothetical DEB_BUILD_OPTIONS=nowerror with
> other linters like shellcheck (or other tools for other programming
> languages).
I didn't quite reason about that aspe
On Fri, 24 Feb 2023 at 10:58:37 +0100, Johannes Schauer Marin Rodrigues wrote:
> I question the conflation of a hypothetical DEB_BUILD_OPTIONS=nowerror with
> other linters like shellcheck (or other tools for other programming
> languages).
Compiler warnings and lint tools do s
uwsgi/2.0.21-4/debian/rules/?hl=570#L570
I question the conflation of a hypothetical DEB_BUILD_OPTIONS=nowerror with
other linters like shellcheck (or other tools for other programming languages).
I believe that sshcommand and uwsgi should have shellcheck not run with
DEB_BUILD_OPTIONS=nochec
On Fri, Feb 24, 2023 at 2:26 PM Helmut Grohne wrote:
>
> Hi,
>
> I observe a pattern repeated at least twice and probably more often in
> packages.
>
> * A package adds -Werror to the build. When a new toolchain version is
>uploaded, it triggers a new warning and that makes the package FTBFS.
Hi Ansgar,
On Fri, Feb 24, 2023 at 08:02:35AM +0100, Ansgar wrote:
> The name is too specific and can be misread:
>
> - It is specific to -Werror, but other similar systems exist.
>
> - It can be easily read an "now error" (i.e., a warning
> should "now (be an) error").
Fair point. I am unima
Quoting Helmut Grohne (2023-02-24 07:19:41)
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after the
> original observation, but meant to also match other checkers such as
> shellcheck. The general idea should be that a warning should that can be
> non-fatal should
On Fri, 2023-02-24 at 07:19 +0100, Helmut Grohne wrote:
> As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
> the original observation, but meant to also match other checkers such as
> shellcheck. The general idea should be that a warning should that can be
> non-
repetitive and seems worthwhile to address to me.
As such, I propose a generic DEB_BUILD_OPTIONS=nowerror modelled after
the original observation, but meant to also match other checkers such as
shellcheck. The general idea should be that a warning should that can be
non-fatal should be non-fatal if
24 matches
Mail list logo
