Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1019321 > unrolled thread

Bug#725484: A way to override blhc false-positives

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#725484: A way to override blhc false-positives simon@ruderich.org - 2020-07-26 08:40 +0200
    Bug#725484: A way to override blhc false-positives Eriberto Mota <eriberto@debian.org> - 2020-07-26 17:30 +0200
      Bug#725484: A way to override blhc false-positives Eriberto <eriberto@eriberto.pro.br> - 2020-07-26 22:10 +0200
        Bug#725484: A way to override blhc false-positives simon@ruderich.org - 2020-07-27 08:20 +0200
          Bug#725484: A way to override blhc false-positives Eriberto <eriberto@eriberto.pro.br> - 2020-07-29 03:50 +0200
          Bug#725484: A way to override blhc false-positives Eriberto <eriberto@eriberto.pro.br> - 2020-07-29 04:00 +0200
            Bug#725484: A way to override blhc false-positives simon@ruderich.org - 2020-07-29 08:10 +0200

#1019321 — Bug#725484: A way to override blhc false-positives

[Multipart message — attachments visible in raw view] — view raw

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 scale.

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 like the
--ignore-line option). What do you think?

Eriberto: Would this also work for the CI issues you mentioned in
#962990?

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[toc] | [next] | [standalone]

#1019357

Em dom., 26 de jul. de 2020 às 03:27, <simon@ruderich.org> 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: ignore-line-regexp: REGEXP" in the build log. All
> lines (fully) matching REGEXP are then ignored (just like the
> --ignore-line option). What do you think?
>
> Eriberto: Would this also work for the CI issues you mentioned in
> #962990?

Hi Simon,

My last suggestion in #962990 is inappropriate because some systems in
Debian, as Salsa CI pipelines, run blhc automatically. Please, see
examples here[1][2][3][4].

[1] https://salsa.debian.org/debian/blhc/-/pipelines/158444
[2] https://salsa.debian.org/debian/blhc/-/blob/debian/master/debian/salsa-ci.yml
[3] https://salsa.debian.org/debian/ngetty/-/pipelines/149456
[4] https://salsa.debian.org/debian/ngetty/-/blob/debian/master/debian/salsa-ci.yml

A manual option as --ignore-line will work for a final user but will
fail for automated systems as Salsa. So, I suggest a configuration
file in /etc/ with some rules. Thus, we will can send new rules to
allow you to release new versions with preinstalled rules. I think
this config file can have two sections, as shown below:

[GENERAL]
# To make blhc ignore this file, change to false.
enable = true

# To disable any blhc option below, change to false.
all = true
debian = true
color = true

[IGNORE]
# All lines matching with the regex shown below will be ignored by blhc.

# blhc
/t/logs/ignore-line --ignore-line.+prepare-script gcc test

# ngetty
^CC = diet -Os gcc -W$


Thanks a lot for your efforts to help.

Regards,

Eriberto

[toc] | [prev] | [next] | [standalone]

#1019392

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.

[toc] | [prev] | [next] | [standalone]

#1019432

[Multipart message — attachments visible in raw view] — view raw

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 like the
>> --ignore-line option). What do you think?
>>
>> Eriberto: Would this also work for the CI issues you mentioned in
>> #962990?
>
> Hi Simon,
>
> My last suggestion in #962990 is inappropriate because some systems in
> Debian, as Salsa CI pipelines, run blhc automatically. Please, see
> examples here[1][2][3][4].
>
> [1] https://salsa.debian.org/debian/blhc/-/pipelines/158444
> [2] https://salsa.debian.org/debian/blhc/-/blob/debian/master/debian/salsa-ci.yml
> [3] https://salsa.debian.org/debian/ngetty/-/pipelines/149456
> [4] https://salsa.debian.org/debian/ngetty/-/blob/debian/master/debian/salsa-ci.yml
>
> A manual option as --ignore-line will work for a final user but will
> fail for automated systems as Salsa. So, I suggest a configuration
> file in /etc/ with some rules. Thus, we will can send new rules to
> allow you to release new versions with preinstalled rules. I think
> this config file can have two sections, as shown below:
>
> [snip]

On Sun, Jul 26, 2020 at 05:05:05PM -0300, Eriberto wrote:
> 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.

I think a file in /etc and manually managing it has the same
issues as managing false positives in blhc itself. It prevents
the package maintainer from handling false positives without
outside help (unlike linitian which can be adapted by the package
maintainer).

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 the Salsa CI
pipeline so feedback if that works (using my patch) is much
appreciated.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[toc] | [prev] | [next] | [standalone]

#1019656

Hi Simon,

Em seg., 27 de jul. de 2020 às 03:10, <simon@ruderich.org> 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 the Salsa CI
> pipeline so feedback if that works (using my patch) is much
> appreciated.


Sorry for my delay and my apologies for don

[toc] | [prev] | [next] | [standalone]

#1019657

Hi Simon,

(trying again because the last message was sent when being edited)

Em seg., 27 de jul. de 2020 às 03:10, <simon@ruderich.org> 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 the Salsa CI
> pipeline so feedback if that works (using my patch) is much
> appreciated.


Sorry for my delay and my apologies for don't understanding your
approach in first time.

I tested your patch and it is wonderful. I think it will work fine in
Salsa but we need a package to be updated there. Can you release a new
version? After this, we can reassign some bugs to the original
packages (as ngetty).

Thanks a lot for this improvement.

Regards,

Eriberto

[toc] | [prev] | [next] | [standalone]

#1019662

[Multipart message — attachments visible in raw view] — view raw

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 for local builds, CI and
>> automatic build log parsing. And it can be fully controlled by
>> the package maintainer. However, I never used the Salsa CI
>> pipeline so feedback if that works (using my patch) is much
>> appreciated.
>
>
> Sorry for my delay and my apologies for don't understanding your
> approach in first time.
>
> I tested your patch and it is wonderful. I think it will work fine in
> Salsa but we need a package to be updated there. Can you release a new
> version? After this, we can reassign some bugs to the original
> packages (as ngetty).

Hello Eriberto,

thanks for checking that it works. I've just released blhc 0.12
with this change and a few more false positives fixed (ngetty is
still open as I think it's a good candidate for the new "inline
ignore").

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web