rpmlint time measurement leads to a new release?
Hi, since recently a current rpmlint under Factory/TW on OBS leads to the fact that a final compare finds a difference and thus a new release is created, because the timing of rpmlint differs from the old build. Is this intentional and reasonable? eg. https://build.opensuse.org/package/live_build_log/home:munix9/android-tools/... [ 400s] rpmlint.log files differ: [ 400s] --- /tmp/tmp.yUsDRbZz79 2021-09-04 10:10:33.236000000 +0000 [ 400s] +++ /tmp/tmp.CRk2h2aSLQ 2021-09-04 10:10:33.236000000 +0000 [ 400s] @@ -13,7 +13,7 @@ [ 400s] /opt/testing/share/rpmlint/security.toml [ 400s] /opt/testing/share/rpmlint/users-groups.toml [ 400s] /opt/testing/share/rpmlint/world-writable-whitelist.toml [ 400s] - 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.1 s [ 400s] + 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.2 s
On Sat, Sep 4, 2021 at 6:19 AM munix9 <munix9@googlemail.com> wrote:
Hi,
since recently a current rpmlint under Factory/TW on OBS leads to the fact that a final compare finds a difference and thus a new release is created, because the timing of rpmlint differs from the old build. Is this intentional and reasonable?
eg. https://build.opensuse.org/package/live_build_log/home:munix9/android-tools/...
[ 400s] rpmlint.log files differ: [ 400s] --- /tmp/tmp.yUsDRbZz79 2021-09-04 10:10:33.236000000 +0000 [ 400s] +++ /tmp/tmp.CRk2h2aSLQ 2021-09-04 10:10:33.236000000 +0000 [ 400s] @@ -13,7 +13,7 @@ [ 400s] /opt/testing/share/rpmlint/security.toml [ 400s] /opt/testing/share/rpmlint/users-groups.toml [ 400s] /opt/testing/share/rpmlint/world-writable-whitelist.toml [ 400s] - 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.1 s [ 400s] + 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.2 s
Yes, with how build-compare works today, it is. I certainly won't accept any bug reports caused by build-compare in upstream rpmlint. -- 真実はいつも一つ！/ Always, there's only one truth!
On 9/4/2021 8:39, Neal Gompa wrote:
On Sat, Sep 4, 2021 at 6:19 AM munix9 <munix9@googlemail.com> wrote:
Hi,
since recently a current rpmlint under Factory/TW on OBS leads to the fact that a final compare finds a difference and thus a new release is created, because the timing of rpmlint differs from the old build. Is this intentional and reasonable? ...
Yes, with how build-compare works today, it is. I certainly won't accept any bug reports caused by build-compare in upstream rpmlint.
New releases being created with no change whatsoever, only dependent on fractions of a second difference in rpmlint run time is "intentional and reasonable"? I can't speak to intent but that doesn't sound reasonable to me. -- Jason Craig
On Sat, Sep 4, 2021 at 6:17 PM Jason Craig <os-dev@jacraig.com> wrote:
On 9/4/2021 8:39, Neal Gompa wrote:
On Sat, Sep 4, 2021 at 6:19 AM munix9 <munix9@googlemail.com> wrote:
Hi,
since recently a current rpmlint under Factory/TW on OBS leads to the fact that a final compare finds a difference and thus a new release is created, because the timing of rpmlint differs from the old build. Is this intentional and reasonable? ...
Yes, with how build-compare works today, it is. I certainly won't accept any bug reports caused by build-compare in upstream rpmlint.
New releases being created with no change whatsoever, only dependent on fractions of a second difference in rpmlint run time is "intentional and reasonable"? I can't speak to intent but that doesn't sound reasonable to me.
build-compare shouldn't be comparing the output of rpmlint that way in the first place. Since rpmlint is a standard Python application, build-compare should import rpmlint and do its own representation of the output in a more machine-friendly form. The time it takes to run through the package can also vary on a variety of factors, so using that as a knob to trigger publishing rebuilds is stupid. -- 真実はいつも一つ！/ Always, there's only one truth!
On 9/4/2021 16:32, Neal Gompa wrote:
build-compare shouldn't be comparing the output of rpmlint that way in the first place. Since rpmlint is a standard Python application, build-compare should import rpmlint and do its own representation of the output in a more machine-friendly form.
The time it takes to run through the package can also vary on a variety of factors, so using that as a knob to trigger publishing rebuilds is stupid.
OK, I see what you are saying now. thanks, -- Jason Craig
Am Sat, 4 Sep 2021 10:39:13 -0400 schrieb Neal Gompa <ngompa13@gmail.com>:
I certainly won't accept any bug reports caused by build-compare in upstream rpmlint.
Do you happen to know how such a bugreport may look like? Just curious how these two unrelated projects actually may clash... Olaf
On Sat, Sep 4, 2021 at 6:19 AM munix9 <munix9@googlemail.com> wrote:
[ 400s] - 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.1 s [ 400s] + 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.2 s
wut ? the time it took should not count as a "difference" .. that's.. mad. File a bug report upstream..
On 04/09/2021 12.19, munix9 wrote:
https://build.opensuse.org/package/live_build_log/home:munix9/android-tools/...
[ 400s] rpmlint.log files differ: [ 400s] - 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.1 s [ 400s] + 4 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 2.2 s
I made a possible fix: https://github.com/openSUSE/build-compare/pull/41 but did not test it.
Am Sun, 5 Sep 2021 21:51:03 +0200 schrieb "Bernhard M. Wiedemann" <bernhardout@lsmod.de>:
Can not be submitted because openSUSE:Factory and openSUSE:Tools are disconnected... Olaf
participants (6)
-
Bernhard M. Wiedemann -
Cristian Rodríguez -
Jason Craig -
munix9 -
Neal Gompa -
Olaf Hering