Re: [gentoo-dev] Important note on tinderbox behavior

2024-02-23 Thread James Le Cuirot
On Fri, 2024-02-23 at 15:35 +0100, Agostino Sarubbo wrote:
> Dear all,
> 
> TL;DR: tinderbox will skip packages with know failures
> 
> it's a matter of fact that on bugzilla there are hundreds of bugs that 
> tinderbox continues to reproduce.
> 
> That results in a waste of resources and time.
> 
> What was done to improve this situation:
> in the past few months I launched few tinderbox environments with the scope 
> of 
> collect the known failures.
> These failures, that have an open bug, have been noted on a list. 
> When tinderbox starts, it queries bugzilla to understand the status of the 
> bug 
> and in case of open bugs it passes the package names to emerge as 
> --exclude $PACKAGE
> That save a lot of time because emerge FOO --exclude FOO hangs immediately.
> 
> Imagine a scenario where a broken package has no DEPEND. The waste of 
> resource 
> is very minimal.
> 
> Imagine another scenario where:
> - the package FOO is broken
> - the package BAR has 100 depend
> - the package FOO is a depend of BAR
> - the package FOO is at position 100 of the depend order
> 
> that results in build 99 packages for nothing.
> 
> In short the problem is not in the package itself, but when a lot of DEPEND 
> are involved.
> 
> This behavior, *that was already experimented in the latest few months* does 
> not change anything on your side.
> 
> The only con that comes in my mind is that when a version bump silently fixes 
> an issue and maintainer is not aware about that.
> The bug still remains as open and as a consequence, the package continues to 
> be excluded.
> 
> For this reason, please be pay more attention to open bugs.
> 
> As a side note, bugs are obviously categorized. For example a build failure 
> for a package FOO on musl, will produce '--exclude FOO' only on musl.
> Same thing for doc brokeness.
> 
> For this reason please expect less 'tinderbox has reproduced this issue with 
> version "${VERSION}" - Updating summary.' and not seeing anymore this message 
> is not a symptom of 'this is fixed now' ( https://bugs.gentoo.org/770889#c6 )
> 
> Failures regarding Modern C porting are excluded from this behavior. Instead 
> '-fpermissive' will be used to build as much as possible.
> Tests failures have also no influence on that, but keep in mind that packages 
> with known test failure(s) are not built by default.
> 
> Thanks
> Agostino
> 

You've made the right call here. Sorry for not fixing the many bugs you've
reported. It's not that I don't care, it's very hard to find the time,
especially for the musl and Clang ones. I certainly won't assume the issues
have magically gone away. Thanks for your continued hard work in this area.


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: dev-libs/zlog

2024-02-23 Thread Arthur Zamarin
# Arthur Zamarin  (2024-02-23)
# A library without any reverse dependencies in tree. Maintainer-needed
# package. Has open security bug without handling. Has open bump for a
# long time.
# Removal: 2024-03-24.  Bugs #925342, #837518.
dev-libs/zlog


OpenPGP_signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Important note on tinderbox behavior

2024-02-23 Thread Agostino Sarubbo
Dear all,

TL;DR: tinderbox will skip packages with know failures

it's a matter of fact that on bugzilla there are hundreds of bugs that 
tinderbox continues to reproduce.

That results in a waste of resources and time.

What was done to improve this situation:
in the past few months I launched few tinderbox environments with the scope of 
collect the known failures.
These failures, that have an open bug, have been noted on a list. 
When tinderbox starts, it queries bugzilla to understand the status of the bug 
and in case of open bugs it passes the package names to emerge as 
--exclude $PACKAGE
That save a lot of time because emerge FOO --exclude FOO hangs immediately.

Imagine a scenario where a broken package has no DEPEND. The waste of resource 
is very minimal.

Imagine another scenario where:
- the package FOO is broken
- the package BAR has 100 depend
- the package FOO is a depend of BAR
- the package FOO is at position 100 of the depend order

that results in build 99 packages for nothing.

In short the problem is not in the package itself, but when a lot of DEPEND 
are involved.

This behavior, *that was already experimented in the latest few months* does 
not change anything on your side.

The only con that comes in my mind is that when a version bump silently fixes 
an issue and maintainer is not aware about that.
The bug still remains as open and as a consequence, the package continues to 
be excluded.

For this reason, please be pay more attention to open bugs.

As a side note, bugs are obviously categorized. For example a build failure 
for a package FOO on musl, will produce '--exclude FOO' only on musl.
Same thing for doc brokeness.

For this reason please expect less 'tinderbox has reproduced this issue with 
version "${VERSION}" - Updating summary.' and not seeing anymore this message 
is not a symptom of 'this is fixed now' ( https://bugs.gentoo.org/770889#c6 )

Failures regarding Modern C porting are excluded from this behavior. Instead 
'-fpermissive' will be used to build as much as possible.
Tests failures have also no influence on that, but keep in mind that packages 
with known test failure(s) are not built by default.

Thanks
Agostino