Maxime Devos <maximedevos@telenet.be> writes:

> For example, naev used to work just fine, yet apparently it doesn't
> anymore: https://issues.guix.gnu.org/65390.
>
> Given that Guix has ci.guix.gnu.org, I would expect such new problems
> to be detected and resolved early, and it was detected by
> ci.guix.gnu.org, yet going by issues.guix.gnu.org it was never even
> investigated.

Yes, honestly I only look for build failures from bug reports, not from
CI if i'm not doing a "request for merge" from another branch.

>
> (Yes, there is a delay, but that doesn't matter at all, as there's
> this dashboard <https://ci.guix.gnu.org/eval/668365/dashboard>.)

I found the dashboard inconvenient to use, it show failures for both
builds and dependencies in the same red color, and can't be searched.
What I usually do is:

1. download the job status json with:
  wget -O jobs.json 'https://ci.guix.gnu.org/api/jobs?evaluation=692229&system=x86_64-linux'

2. use jq to show package names with build failures:
  cat jobs.json  | jq '. | map(select(.status == 1)) | .[].name' -r

3. select interested one to investigate (if doing merge, diff the failures from
working branch with master).


>
> Do people really need to report 33% of all jobs
> (https://ci.guix.gnu.org/eval/668365/dashboard) before those failures
> are taken seriously, instead of the ‘there don't seem to be that much
> more build failures from the core-updates/... merge, let's solve them
> later (i.e., never)’ that seems to be  status quo?

Maybe we can automatically report the failures as bugs, say every 7
days, and remove a package if it still fail to build in 90 days?

As for now, x86_64 master (eval 668365) has 696 build failures, 604
dependencies failures, 30 unknown (canceld?) failures, total 1330
failures according to the jobs.json data.

Should we open a bug report for each of those 696 build failures?