public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Agostino Sarubbo <ago@gentoo.org>
To: "gentoo-dev@lists.gentoo.org" <gentoo-dev@lists.gentoo.org>
Subject: [gentoo-dev] Important note on tinderbox behavior
Date: Fri, 23 Feb 2024 15:35:33 +0100	[thread overview]
Message-ID: <6674250.4vTCxPXJkl@fcf> (raw)

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




             reply	other threads:[~2024-02-23 14:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 14:35 Agostino Sarubbo [this message]
2024-02-23 19:51 ` [gentoo-dev] Important note on tinderbox behavior James Le Cuirot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6674250.4vTCxPXJkl@fcf \
    --to=ago@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox