Verification of the correct rpmlint-mini in a project
Hello, we have got an open security issue [0] in the package tuned (only s390x). I am asked now whether the project setup has been done correctly and whether perhaps an old rpmlint-mini is used there. How can I verify the version (and the correct one) of rpmlint-mini? I don't have so much experience with such setups at the moment. Best regards, Sarah [0] https://bugzilla.opensuse.org/show_bug.cgi?id=1186912
Hi, On Wed, Jun 9, 2021 at 11:11 PM Sarah Julia Kriesch <ada.lovelace@gmx.de> wrote:
Hello,
we have got an open security issue [0] in the package tuned (only s390x). I am asked now whether the project setup has been done correctly and whether perhaps an old rpmlint-mini is used there. How can I verify the version (and the correct one) of rpmlint-mini? I don't have so much experience with such setups at the moment.
You can use "osc buildinfo" command to see what binaries are pulled in for build: ; cd openSUSE:Factory:zSystems/tuned/ ; osc buildinfo -d standard s390x | less which shows: <bdep name="rpmlint-mini" notmeta="1" version="1.10" release="23.3" arch="s390x" project="openSUSE:Factory:zSystems" repository="standard"/> Regards, ismail
On Wed, 2021-06-09 at 23:11 +0200, Sarah Julia Kriesch wrote:
Hello,
we have got an open security issue [0] in the package tuned (only s390x). I am asked now whether the project setup has been done correctly and whether perhaps an old rpmlint-mini is used there. How can I verify the version (and the correct one) of rpmlint-mini? I don't have so much experience with such setups at the moment.
I just opened up that bug to the public - there is no security concern in there (even if tuned failed to build for the detected security issue: it was never published and as such could not cause a sec issue). All in all: ignored build failures of rpmlint-mini lead to the state. Interested parties can read up everything on the bug. cheers Dominique
On Thu, Jun 10, 2021 at 08:50:15AM +0200, Dominique Leuenberger / DimStar wrote:
On Wed, 2021-06-09 at 23:11 +0200, Sarah Julia Kriesch wrote:
Hello,
we have got an open security issue [0] in the package tuned (only s390x). I am asked now whether the project setup has been done correctly and whether perhaps an old rpmlint-mini is used there. How can I verify the version (and the correct one) of rpmlint-mini? I don't have so much experience with such setups at the moment.
I just opened up that bug to the public - there is no security concern in there (even if tuned failed to build for the detected security issue: it was never published and as such could not cause a sec issue).
All in all: ignored build failures of rpmlint-mini lead to the state. Interested parties can read up everything on the bug.
FWIW, not doing transitive rebuilds led to this problem. CIao, Marcus
On Thu, 2021-06-10 at 09:24 +0200, Marcus Meissner wrote:
On Thu, Jun 10, 2021 at 08:50:15AM +0200, Dominique Leuenberger / DimStar wrote:
On Wed, 2021-06-09 at 23:11 +0200, Sarah Julia Kriesch wrote:
Hello,
we have got an open security issue [0] in the package tuned (only s390x). I am asked now whether the project setup has been done correctly and whether perhaps an old rpmlint-mini is used there. How can I verify the version (and the correct one) of rpmlint-mini? I don't have so much experience with such setups at the moment.
I just opened up that bug to the public - there is no security concern in there (even if tuned failed to build for the detected security issue: it was never published and as such could not cause a sec issue).
All in all: ignored build failures of rpmlint-mini lead to the state. Interested parties can read up everything on the bug.
FWIW, not doing transitive rebuilds led to this problem.
Either that, or, as I noted in the bug, the fact that OSRT:Config was incomplete. I doubt we will ever go back to transitive rebuilds for Tumbleweed. Cheers, Dominique
On Thu, 2021-06-10 at 11:04 +0200, Jan Engelhardt wrote:
On Thursday 2021-06-10 09:31, Dominique Leuenberger / DimStar wrote:
I doubt we will ever go back to transitive rebuilds for Tumbleweed.
Whenever glibc or gcc changes though, most things rebuild, and that should be sufficient number of times.
That statement is false Correct is: whenever glibc or gcc have major updates, we trigger a full rebuld. Or when the release mamnagers have other reasons to do full rebuilds (errors included) Otherwise we'd have had 7 full rebuilds for glibc alone in 2021:
osc log openSUSE:Factory glibc | grep ^r.*2021- r250 | dimstar_suse | 2021-06-02 20:10:31 | c17a2c0f60a604fdff5fdf03289c1873 | 2.33 | rq895837 r249 | dimstar_suse | 2021-05-11 21:03:28 | 74f659a880ea4341c9472b3e83413068 | 2.33 | rq890996 r248 | dimstar_suse | 2021-04-18 19:43:55 | 6a71f9cbca7ba11988be4bbcb743250c | 2.33 | rq885031 r247 | dimstar_suse | 2021-03-11 19:06:59 | 4592cbb2c37c0b43be462bd6aa2e5677 | 2.33 | rq878145 r246 | dimstar_suse | 2021-03-07 14:19:35 | 11fa913258f46f4524553ba20db6deb8 | 2.33 | rq876231 r245 | dimstar_suse | 2021-02-23 19:20:01 | 57db9b72f1e33dd5a134659a04021080 | 2.33 | rq873392 r244 | dimstar_suse | 2021-02-11 11:44:35 | 74d4932d779727126ce71c4031322bd2 | 2.33 | rq868600
Cheers, Dominique
On Thu 2021-06-10, Dominique Leuenberger / DimStar wrote:
On Thu, 2021-06-10 at 11:04 +0200, Jan Engelhardt wrote:
Whenever glibc or gcc changes though, most things rebuild, and that should be sufficient number of times. Correct is: whenever glibc or gcc have major updates, we trigger a full rebuld. Or when the release mamnagers have other reasons to do full rebuilds (errors included)
Otherwise we'd have had 7 full rebuilds for glibc alone in 2021:
And as a user I am grateful we did not. :) And I did not count, but the number of times in the last half year, year a `zypper dup` pulled in more than 600MB, or more than 1GB, felt high already. So definitely happy about the release managers limiting that. Gerald
Gesendet: Donnerstag, 10. Juni 2021 um 13:34 Uhr Von: "Gerald Pfeifer" <gp@suse.com> An: factory@lists.opensuse.org Betreff: Re: Verification of the correct rpmlint-mini in a project
On Thu 2021-06-10, Dominique Leuenberger / DimStar wrote:
On Thu, 2021-06-10 at 11:04 +0200, Jan Engelhardt wrote:
Whenever glibc or gcc changes though, most things rebuild, and that should be sufficient number of times. Correct is: whenever glibc or gcc have major updates, we trigger a full rebuld. Or when the release mamnagers have other reasons to do full rebuilds (errors included)
Otherwise we'd have had 7 full rebuilds for glibc alone in 2021:
And as a user I am grateful we did not. :)
And I did not count, but the number of times in the last half year, year a `zypper dup` pulled in more than 600MB, or more than 1GB, felt high already. So definitely happy about the release managers limiting that.
Gerald
I want to add that I prefer such rebuildings (as a minimum) for all failed packages, updated packages and packages with dependencies to such updated packages (not for all). The background is that I was allowed to see many broken (and additionally old) packages, which were able to build after a manual rebuild. Additionally there were others (without any automatical rebuild) which a new rebuild has included additional packages for Python 3.9. That wasn't done before. So you were not able to use these packages with Python 3.9 until now. But I agree that it is not necessary for all packages (without any reason). Best regards, Sarah
participants (6)
-
Dominique Leuenberger / DimStar -
Gerald Pfeifer -
İsmail Dönmez -
Jan Engelhardt -
Marcus Meissner -
Sarah Julia Kriesch