El 3/3/24 a las 17:38, Jeremy Bícha escribió:
Control: severity -1 important
Control: affects -1 src:gcr
On Fri, Mar 1, 2024 at 6:36 AM Santiago Vila <sanv...@debian.org> wrote:
Ignore build test failures on s390x (Closes: #1057562)
This is wrong for several reasons.
- The bug report did not say anything about s390x.
s390x is the only architecture where the flakiness of the gcr:gck /
object build test is severe enough to unreasonably interfere with
timely building of gcr & gcr4.
You keep misrepresenting the bug I reported.
The bug report was not about a flaky test in a generic sense.
And it was not about the effect of such flaky test in the official buildds
either.
What the bug report said is that whenever I try to build the package
on several virtual machines from AWS of different types, the build fails.
ALWAYS.
So, this is not about an occasional failure. This is about a permanent failure.
Here is my build history:
Status: failed gcr4_4.1.0-2_amd64-20230322T215308.971Z
Status: failed gcr4_4.1.0-2_amd64-20230322T215447.211Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202053.367Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202058.856Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202121.876Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202342.316Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202518.944Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202604.013Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202834.489Z
Status: failed gcr4_4.1.0-2_amd64-20230922T202921.776Z
Status: failed gcr4_4.1.0-2_amd64-20230930T214526.762Z
Status: failed gcr4_4.1.0-2_amd64-20230930T215238.884Z
Status: failed gcr4_4.1.0-2_amd64-20230930T215413.813Z
Status: failed gcr4_4.1.0-2_amd64-20230930T215359.115Z
Status: failed gcr4_4.1.0-2_amd64-20230930T215627.137Z
Status: failed gcr4_4.1.0-2_amd64-20230930T215937.574Z
Status: failed gcr4_4.1.0-2_amd64-20230930T221515.395Z
Status: failed gcr4_4.1.0-2_amd64-20230930T221739.810Z
Status: failed gcr4_4.1.0-2_amd64-20231130T041100.202Z
Status: failed gcr4_4.1.0-2_amd64-20231205T160411.736Z
Status: failed gcr4_4.1.0-2_amd64-20231213T155044.129Z
Status: failed gcr4_4.1.0-2_amd64-20231213T160911.601Z
Status: failed gcr4_4.1.0-2_amd64-20240129T170626.580Z
Status: failed gcr4_4.1.0-2_amd64-20240129T170930.627Z
Status: failed gcr4_4.1.0-2_amd64-20240129T171059.244Z
Status: failed gcr4_4.1.0-2_amd64-20240129T171811.347Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110606.957Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110607.721Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110608.780Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110608.127Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110609.765Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110718.547Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110719.934Z
Status: failed gcr4_4.2.0-3_amd64-20240301T110721.878Z
This is a violation of a *must* directive in Policy, because
Debian policy says this:
If build-time dependencies are specified, it must be possible to build the
package and produce working binaries on a system with only essential and
build-essential packages installed and also those required to satisfy the
build-time relationships (including any implied relationships).
Debian is full of packages where the build tests and autopkgtests are
flaky enough to be disruptive to someone expecting 100% pass rates.
This is a strawman. I'm *not* expecting a 100% pass rate.
A pass rate of 100% would correspond to a failure rate of 0%.
I do not expect a failure rate of 0%.
I just expect a failure rate which is *not* 100%.
There is currently no one on the Debian GNOME team with the time to
investigate and properly fix these issues.
In such case the failing test is completely useless and even harmful.
When we have unit tests, they are enabled with the aim of
"doing something" when they fail. If we do nothing when they
fail, we are wasting the time of everybody involved.
The occasional failure is enough to remind us of this issue.
If this is really about "reminding", I can put a cron job to
email you a reminder weekly or monthly. Even a postit note in your
monitor would be better than this.
But not this.
I don't
think it's helpful to just disable the test since it may disguise a
real problem that someone can work on once they get sufficiently
annoyed by the issue.
Well, but this is *already* a real problem: The package does not
build in some systems. Not an occasional failure, but not at all.
Also, it may be important to recognize if the
failure rate for this test on official buildds increases
significantly. The failure rate did increase on s390x but we don't
really treat s390x as a supported Desktop architecture and don't have
capacity to spend much time dealing with s390x.
And you keep mentioning s390x when the original bug report did not
mention s390x at all.
In fact, Sebastian Ramacher, I guess that acting as a Release Manager,
restored the serious severity in the past, and when he did he
included a link specifically to the flaky amd64 build, not to the
s390x build.
But you downgraded the bug again.
Please ensure that this package builds from source for everybody,
not only in the official buildds.
Debian is a free software distribution. The end user has the right to
rebuild the package, and to do so without having to jump through hoops.
Thanks.
