public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Important note on tinderbox behavior
@ 2024-02-23 14:35 Agostino Sarubbo
  2024-02-23 19:51 ` James Le Cuirot
  0 siblings, 1 reply; 2+ messages in thread
From: Agostino Sarubbo @ 2024-02-23 14:35 UTC (permalink / raw
  To: gentoo-dev@lists.gentoo.org

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




^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [gentoo-dev] Important note on tinderbox behavior
  2024-02-23 14:35 [gentoo-dev] Important note on tinderbox behavior Agostino Sarubbo
@ 2024-02-23 19:51 ` James Le Cuirot
  0 siblings, 0 replies; 2+ messages in thread
From: James Le Cuirot @ 2024-02-23 19:51 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-23 19:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-23 14:35 [gentoo-dev] Important note on tinderbox behavior Agostino Sarubbo
2024-02-23 19:51 ` James Le Cuirot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox