On Tue, Jul 28, 2020 at 10:51:06PM -0300, Eriberto wrote:
> Hi Simon,
>
> (trying again because the last message was sent when being edited)
>
> Em seg., 27 de jul. de 2020 às 03:10, escreveu:
>>
>> Did you look at my approach about embedding the ignores inside
>> the build log? This should work
Hi Simon,
(trying again because the last message was sent when being edited)
Em seg., 27 de jul. de 2020 às 03:10, escreveu:
>
> Did you look at my approach about embedding the ignores inside
> the build log? This should work for local builds, CI and
> automatic build log parsing. And it can be
Hi Simon,
Em seg., 27 de jul. de 2020 às 03:10, escreveu:
>
> Did you look at my approach about embedding the ignores inside
> the build log? This should work for local builds, CI and
> automatic build log parsing. And it can be fully controlled by
> the package maintainer. However, I never used
On Sun, Jul 26, 2020 at 12:25:23PM -0300, Eriberto Mota wrote:
> Em dom., 26 de jul. de 2020 às 03:27, escreveu:
>> Please have a look at the attached patch. It permits embedding
>> the "blhc: ignore-line-regexp: REGEXP" in the build log. All
>> lines (fully) matching REGEXP are then ignored (just
Updating... The /etc file is interesting because I will can provide
patches in Debian package to solve some bugs related to false
positives until you release a new upstream version.
Em dom., 26 de jul. de 2020 às 03:27, escreveu:
> my first approach was that all false-positives should be
> handled/fixed in blhc so that nobody can simply "ignore" missing
> flags. But this approach doesn't scale.
>
> Please have a look at the attached patch. It permits embedding
> the "blhc:
On Sat, Feb 15, 2020 at 07:41:09PM +0100, nicoo wrote:
> Would it be possible to embed the overrides into the build log itself?
Hello nicoo,
my first approach was that all false-positives should be
handled/fixed in blhc so that nobody can simply "ignore" missing
flags. But this approach doesn't
Hi Jari,
Sorry to comment on an old bug, but this is still an issue.
If there's no way for package maintainers to automatically ignore false
positives, this tremendously reduces the usefulness of blhc, by causing a
form of alarm fatigue:
People and processes (like CI) will ignore blhc failing,
Hi Simon, could you take a look at this and know what you
think:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725484
I think the request is for reading configuration file at startup:
/.blhc-ignore OR if not exists, search ...
$HOME/.blhc-ignore
An idea for the file format:
Package: blhc
Severity: wishlist
There are lot of them, without good
workarounds (see e.g. #712485). As blhc is a kind of
standard tool for the Debian QA - I think it's a good
time to add support for lintian-overrides-like mechanism.
--
To UNSUBSCRIBE, email to
10 matches
Mail list logo
