Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Package: lintian Version: 2.77.0 Severity: serious Sigh, So the problematic --fail-on default change never got actually reverted as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e omitted the relevant part that would make it work. :( None of the previous arguments against the default change brought up in #962158 have stopped being relevant (also contrary to the commit message…). Worse, this sneaked in what has shipped now in a stable Debian release. :( So any errors found in CI systems and through other tooling has been silently ignored since then. :/ Only noticed now due to #994414, a great excuse to now keep the broken behavior I guess. (Where the --help output still does not match…) Unamused, Guillem
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi! On Tue, 2022-06-14 at 01:26:02 +0200, Axel Beckert wrote: > Guillem Jover wrote: > > So the problematic --fail-on default change never got actually reverted > > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e > > omitted the relevant part that would make it work. :( > > Can you please elaborate what exactly is the bug? You refer to > something being problematic without explaining what actually is > problematic. > > You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and > https://bugs.debian.org/962158 which has been closed about 2 years and > ca. 35 Lintian releases ago. That thread in #962158 is quite long and > difficult to grasp. lintian used to exit with a non-zero value when it emitted at least one error tag. This was changed, for some reason, and then it stopped doing that, instead requiring users to specify --fail-on=error. This was supposedly reverted, but the patch that got applied that fixed this at the time of submission did not apply at the time it got committed due to refactoring, and it was ineffective. As such the --help output now is misleading, mentioning that the default --fail-on is "error" when it is not. The above caused the below problems. ↓ > > None of the previous arguments against the default change brought up > > in #962158 have stopped being relevant (also contrary to the commit > > message…). Worse, this sneaked in what has shipped now in a stable > > Debian release. :( So any errors found in CI systems and through other > > tooling has been silently ignored since then. :/ > > This doesn't really makes the issue easier to understand. I don't ask > for a patch, but at least for a list of defects what is wrong where > and probably why. > > So far I got that there is an issue with the exit codes having changed > to be somewhat less helpful for automatic usage. (When did it change > and how? Do you happen to know a commit id? What condition should in > your opinion cause which exit code?) I'd have to re-dig all this. I might just try to provide a patch, I think should probably be a one-liner. > > Only noticed now due to #994414, a great excuse to now keep the broken > > behavior I guess. > > So this bug report actually should no more be fixed?!? The point of that comment, was that because Felix was pushing for that behavior change even when no apparent good reasons were given, and then after the behavior was supposedly reverted (but in fact it was not), when that bug report about the man page also mismatching the current behavior was filed, instead of properly fixing the behavior, he used the opportunity to keep pushing for the IMO broken behavior. > > (Where the --help output still does not match…) > > So --help seems outdated. At which line or option exactly and what > should it say instead? IMO it should stay as it is and the behavior reverted. But if you also disagree, then it should reflect reality. Thanks, Guillem
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 - moreinfo Hi Guillem, Guillem Jover wrote: > > Can you please elaborate what exactly is the bug? You refer to > > something being problematic without explaining what actually is > > problematic. > > lintian used to exit with a non-zero value when it emitted at least > one error tag. This was changed, for some reason, and then it stopped > doing that, instead requiring users to specify --fail-on=error. This > was supposedly reverted, but the patch that got applied that fixed > this at the time of submission did not apply at the time it got > committed due to refactoring, and it was ineffective. As such the > --help output now is misleading, mentioning that the default --fail-on > is "error" when it is not. Thanks for that summary, it helped a lot. I'll have a look. > I'd have to re-dig all this. I might just try to provide a patch, I > think should probably be a one-liner. A patch of course would be nice, but I won't mind if you don't provide one. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 patch Control: forwarded -1 https://salsa.debian.org/lintian/lintian/-/merge_requests/414 On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > Guillem Jover wrote: > > I'd have to re-dig all this. I might just try to provide a patch, I > > think should probably be a one-liner. > > A patch of course would be nice, but I won't mind if you don't provide > one. I've sent an MR now, which passes the test suite locally, and seems to work on a manually modified package too. Thanks, Guillem
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi Guillem, Guillem Jover wrote: > Control: tag -1 patch > Control: forwarded -1 > https://salsa.debian.org/lintian/lintian/-/merge_requests/414 > > On Mon, 2022-06-27 at 15:14:10 +0200, Axel Beckert wrote: > > Guillem Jover wrote: > > > I'd have to re-dig all this. I might just try to provide a patch, I > > > think should probably be a one-liner. > > > > A patch of course would be nice, but I won't mind if you don't provide > > one. > > I've sent an MR now, which passes the test suite locally, and seems to > work on a manually modified package too. Thanks! Much appreciated. Will merge once we got Salsa CI autopkgtest working again. Currently fails because of dpatch removal _and_ the emacs 27.1 to 28.1 upgrade. *sigh* Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Control: tag -1 + moreinfo Control: severity -1 important Hi Guillem, I'm trying to catch up with that chaos which is in lintian's current state. Guillem Jover wrote: > So the problematic --fail-on default change never got actually reverted > as the patch applied in commit 3758bfafd5dd742c327f2312dac8e3a71b1f036e > omitted the relevant part that would make it work. :( Can you please elaborate what exactly is the bug? You refer to something being problematic without explaining what actually is problematic. You refer to 3758bfafd5dd742c327f2312dac8e3a71b1f036e and https://bugs.debian.org/962158 which has been closed about 2 years and ca. 35 Lintian releases ago. That thread in #962158 is quite long and difficult to grasp. > None of the previous arguments against the default change brought up > in #962158 have stopped being relevant (also contrary to the commit > message…). Worse, this sneaked in what has shipped now in a stable > Debian release. :( So any errors found in CI systems and through other > tooling has been silently ignored since then. :/ This doesn't really makes the issue easier to understand. I don't ask for a patch, but at least for a list of defects what is wrong where and probably why. So far I got that there is an issue with the exit codes having changed to be somewhat less helpful for automatic usage. (When did it change and how? Do you happen to know a commit id? What condition should in your opinion cause which exit code?) > Only noticed now due to #994414, a great excuse to now keep the broken > behavior I guess. So this bug report actually should no more be fixed?!? > (Where the --help output still does not match…) So --help seems outdated. At which line or option exactly and what should it say instead? Downgrading to import for now as I can't really fix something which is totally unclear, both, the how and the why. P.S.: Sorry if you explained that in the past, but the whole situation in general and with this issue in specific is quite tangled, so that I'd really appreciate a summary to get an idea what this bug report exactly is about. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#995492: lintian: Broken --fails-on=none as default never got reverted
Hi Guillem, On Fri, Oct 1, 2021 at 6:57 PM Guillem Jover wrote: > > Unamused, I am sorry that happened. Did I not accept your patch in full? [1] Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/3758bfafd5dd742c327f2312dac8e3a71b1f036e
