bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Mon, 11 Sept 2023 at 09:33, Csepp  wrote:
>
>> That is not a package problem but a Guix interface problem.  I have been
>> saying for a while that there needs to be an option to disable all
>> non-trivial local builds by default when you know your machine can't
>> handle them.
>
> IMHO, your proposal is orthogonal with the issue at hand: broken
> packages.  Other said, the issue is: how to deal with the set of
> packages that will not build and we already know it (since weeks,
> months or even years for some).
>
> My workstation can handle all the compilations that are required.  My
> laptop is able offload to it.  The issue about broken packages is not
> about the resources.  It is about burning resources for nothing.
>
> About the issue you are speaking about, we already had discussions in
> this direction -- you are not the only one saying "the fix needs to do
> X" for a while but please keep in mind that "talking does not cook the
> rice". ;-)  Well, maybe you could open a ticket with a concrete
> use-case.
>
> Cheers,
> simon

I was hoping to get some consensus on whether this is actually a
bug/feature that others consider worth tracking, so I kept discussion of
it mostly to guix-devel, but sure, I can make a proper issue for it.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Simon Tournier]

Hi,

On Mon, 11 Sept 2023 at 09:33, Csepp  wrote:

> That is not a package problem but a Guix interface problem.  I have been
> saying for a while that there needs to be an option to disable all
> non-trivial local builds by default when you know your machine can't
> handle them.

IMHO, your proposal is orthogonal with the issue at hand: broken
packages.  Other said, the issue is: how to deal with the set of
packages that will not build and we already know it (since weeks,
months or even years for some).

My workstation can handle all the compilations that are required.  My
laptop is able offload to it.  The issue about broken packages is not
about the resources.  It is about burning resources for nothing.

About the issue you are speaking about, we already had discussions in
this direction -- you are not the only one saying "the fix needs to do
X" for a while but please keep in mind that "talking does not cook the
rice". ;-)  Well, maybe you could open a ticket with a concrete
use-case.

Cheers,
simon

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

(changing the subject back to the intended one.  I think the fact that
someone replies to an automated acknowledgement email like once a week
says indicates that the emails are not communicating clearly what their
purpose is. anyways, on to the actual issue at hand.)

Simon Tournier  writes:

> Hi,
>
> On Tue, 29 Aug 2023 at 10:45, Maxim Cournoyer  
> wrote:
>
>> It's frustrating for users when a package is missing, but it's also
>> frustrating/inefficient for maintainers to stumble upon broken packages
>> when checking if an upgrade broke dependent packages (it takes time to
>> build them just to find out they fail, and researching they already
>> did), so a balance is needed.
>
> There is nothing worse as an user to have this experience:
>
> guix search foobar
>
> oh cool, foobar is there, let try it,
>
> guix shell foobar
>
> … wait …
> … stuff are building …
> … laptop is burning …
> … wait …
> Bang!
>
> Keeping broken packages is just annoyances.  Contributor are annoyed
> because as said by the paragraph above.  And user are annoyed as
> described just above.
>
> I am in favor to set a policy for removing then.
>
> The question is the way to detect them.  QA can do whatever we want but
> until people are helping Chris because, IMHO, Chris is already enough
> busy to keep stuff running, we probably need to keep our process simple
> enough in order to stay actionable and avoid some vacuum of “coulda,
> shoulda or woulda”.  For what my opinion is worth on that. :-)
>
> Cheers,
> simon

That is not a package problem but a Guix interface problem.  I have been
saying for a while that there needs to be an option to disable all
non-trivial local builds by default when you know your machine can't
handle them.
Alternatively the CI could record some basic resource utilization
information, so users could for example set a limit on RAM.  (Although
this gets tricky for parallel builds.)

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxim Cournoyer]

Hi Maxime,

Maxime Devos  writes:

[...]

> (I usually don't respond to e-mails I agree with except for
> superficialities, but I was wondering if such non-replies are actually
> interpreted as such, or as disagreements, or neither.)

I'd say it's safer to assume neither, though perhaps with a slight bias
toward agreement, especially if the person was otherwise actively
participating in the conversation (as I would expect people are most
likely to post a reply when they disagree with something).

-- 
Thanks,
Maxim

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxime Devos]

> [Two mails previously]
> Also the CI UI could use some improvements.  I'm pretty sure I've
> mentioned this before, but there is no easy way to find out which
> inputs I need to fix to make a dependency failure disappear.


[...]
That is precisely what the linear search algorithm is.  I should not
have to look through the dependency tree to figure out if two package
failures have the same cause, or to know how many (possibly indirect)
dependencies of a package are failing.
As an example, pandoc often fails to build on i686, but when you look at
the CI page, you see that it was caused by several of its inputs
failing, all due to some of *their* dependencies.
Now, you could dig down on one branch of the dependency DAG and find one
failing package, but that doesn't *actually* answer the question: "what
packages do I need to fix to enable this one?", because it could have
multiple failing inputs instead of just one.  The only way to tell is to
look at each page, that means having to visually find each failing input
on the page, wait for their CI pages to load, and repeat the whole
process.
If your browser is not particularly fast or you aren't so quick at
navigating a webpage, this can take a while.
But for the CI server, generating this information would take less than
a second > Maybe some people value their time so little that they are fine with
doing this the manual way, but personally I have better things to do.


ci.guix.gnu.org loads fast enough for me in my experience, but I do 
agree that more automation is good!


(I usually don't respond to e-mails I agree with except for 
superficialities, but I was wondering if such non-replies are actually 
interpreted as such, or as disagreements, or neither.)


Best regards,
Maxime Devos.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Giovanni Biscuolo]

Bruno Victal  writes:

> On 2023-08-27 02:13, 宋文武 wrote:
>> 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?

maybe precedeed by an automated email notification (to guix-bugs) so
that interested people have the chance to step in and fix it?

> I'm not so sure about removing packages, personally if I'm in need of
> a package that happens to be broken I find it easier to fix it given
> that some work has already been put into writing the package definition
> than starting from scratch.

You don't need to start from scratch if you want, you just have to
checkout the right git commit (before the package was deleted) and start
from that, if needed: WDYT?

Happy hacking! Gio'

[...]

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Bruno Victal]

On 2023-08-27 02:13, 宋文武 wrote:
> 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?

I'm not so sure about removing packages, personally if I'm in need of
a package that happens to be broken I find it easier to fix it given
that some work has already been put into writing the package definition
than starting from scratch.


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxim Cournoyer]

Hi again,

宋文武  writes:

> Maxime Devos  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.

Another idea I had was we could add some feature to Cuirass where it'd
notify a team (by email) when a package under their scope has been
broken on the master branch.

-- 
Thanks,
Maxim

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxim Cournoyer]

Hello,

宋文武  writes:

> Maxime Devos  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 .)
>
> 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=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).

Maybe we should open Cuirass feature requests on our bug tracker to
remember what would be valuable to implement.

>> 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?

That's sounds reasonable to me.

> 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?

I'm not against, though that sounds like a lot of work unless automated.

-- 
Thanks,
Maxim

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[宋文武 via Bug reports for GNU Guix]

Maxime Devos  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 .)

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=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?
aarch64-linux-gnu.gcc
abjad-ext-ipython
adms
aegis
anubis
aoflagger
apache-commons-parent-pom
apricots
arachne-pnr
arcan-sdl
arcan
archivebox
arm-linux-gnueabihf.gcc
arpack-ng-openmpi
asignify
asmjit
avro-cpp
azimuth
balsa
barectf
beignet
blacksmith
boinc-server
bonnie++
boost-signals2
btar
burp
cc65
cedille
chaiscript
chezmoi
clang
combinatorial-blas
commoncpp
confusion-mdl
coq-ide
coturn
cpplint
cssc
ctl
cube
darkice
dbus-cxx
ddcci-driver-linux
debops
deluge
dolphin-emu
dosbox-staging
dovecot-trees
d-tools
duc
dvdstyler
dxvk
ecl-april
ecl-binding-arrows
ecl-canonicalized-initargs
ecl-cl-form-types
ecl-cl-gserver
ecl-closure-template
ecl-cl-prevalence
ecl-cmd
ecl-coalton
ecl-coleslaw
ecl-conium
ecl-hdf5-cffi
ecl-lispbuilder-sdl
ecl-mito
ecl-nodgui
ecl-prometheus
ecl-radiance-contribs
ecl-schemeish
ecl-supertrace
ecl-trivial-octet-streams
ecl-trucler
ecl-typo
ecl-yxorp
edi
efilinux
elemental
elpa-openmpi
elpa
emacs-next-pgtk
emacspeak
emacsy
emilua
emulation-station
enblend-enfuse
eog-plugins
epic5
epour
eternalterminal
evdi
fanc
fasthenry
fenics
fiano-fmap
flowee
freedink-engine
freeorion
frotz-dumb-terminal
fulcrum
ganeti
gash-utils
gcc-objc++
gcc-objc
gcc-stripped-tarball
gcc-toolchain
gcc
gcc
ghc-ncurses
ghc-next
ghmm
gimagereader
gitile
gitless
glibc
glibc
glusterfs
gmime
gnash
gnaural
gnome-dictionary
gnucap
go-github-com-charmbracelet-glamour
gourmet
goxel
guile2.0-commonmark
guile2.0-gcrypt
guile2.0-redis
guile2.2-fibers
guile2.2-ics
guile2.2-pfds
guile2.2-xapian
guile-emacs
guile-gnunet
guile-goblins
guile-irc
guile-sparql
guile-static-stripped
guix-minimal
gx-saturator-lv2
gx-slow-gear-lv2
gx-vbass-preamp-lv2
h5check
harminv
hash-extender
hdf5-parallel-openmpi
hdf-eos2
hdf-eos5
hdf-java
hikari
hosts
ht
hydrus-network
hyperledger-iroha
hypre-openmpi.skylake-avx512
i3lock-blur
i586-pc-gnu.gcc-stripped-tarball
i586-pc-gnu.gcc
i586-pc-gnu.gcc
i586-pc-gnu.glibc
i686-linux-gnu.gcc-stripped-tarball
i686-linux-gnu.gcc
i686-linux-gnu.gcc
i686-w64-mingw32.coreutils
i686-w64-mingw32.diffutils
i686-w64-mingw32.findutils
i686-w64-mingw32.gawk
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gcc
i686-w64-mingw32.gdb-minimal
i686-w64-mingw32.gettext
i686-w64-mingw32.glibc
i686-w64-mingw32.grep
i686-w64-mingw32.guile
i686-w64-mingw32.guix
i686-w64-mingw32.gzip
i686-w64-mingw32.patch
i686-w64-mingw32.sed
i686-w64-mingw32.xz
insight-toolkit
insight-toolkit.haswell
insight-toolkit.ivybridge
insight-toolkit.skylake
insight-toolkit.skylake-avx512
insight-toolkit.westmere
irram
itk-snap
java-asm-tree
java-commons-compress
java-eclipse-jetty-util-ajax
java-eclipse-lsp4j-common
java-fasterxml-jackson-databind
java-geronimo-xbean-asm-util
java-geronimo-xbean-bundleutils
java-janino
java-jgit
java-jsch-agentproxy-jsch
java-objenesis
java-sonatype-aether-api
java-sonatype-spice-parent-pom
java-surefire-logger-api
java-xom
java-xsdlib
js-context-menu
jucipp
julia-calculus
julia-deepdiffs
julia-genericschur
julia-infinity
julia-wcs
kalendar
kbd-neo
khmer
launchmon
leptonica
libfreenect-examples
libiax2
libnfsidmap
libpsyc
libsigrokdecode
libstdc++
libtcod
libtmcg
libtorrent-rasterbar

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> Op 23-08-2023 om 01:45 schreef Csepp:
>> I tried signing up to the CI mailing list and it immediately became
>> overwhelming.
>
> If the CI list was split in ‘broken’ and ‘fixed’, such that you have
> the option to only subscribe to ‘broken’, would that help?  A large
> fraction of messages is for fixed packages, which do not need to be
> acted upon.

Yup, that would be an improvement.  Or some way to group messages by
package.

>> One possible improvement I have been thinking about is making it easy
>> for users to filter CI output to the packages in their profile closure,
>> so for example they would get advance notice of any broken packages
>> *before* attempting to install them.
>
> I assume you meant s/install/update.
>
> How is this an improvement?  I mean, how does this make
>
> ‘People need to report failing builds even though we have
> ci.guix.gnu.org for that.’
>
> less true?
>
> Best regards,
> Maxime Devos.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

A user is more likely to be able and motivated to fix a package that
they are using.  Getting notifications as a stream is a recipe for alert
fatigue.  There needs to be a way to at the very least move actionable
alert to the top of the list and to deduplicate alerts.
TLDR: alert fatigue is bad and it should not be the casual contributor's
job to fight it on their own.  If its filtering and grouping is expected
to be done on the client side then there should be guides for setting
those filters up.
Personally, it already takes enough time for me to read the bug
discussions.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
>
>
> Op 23-08-2023 om 01:45 schreef Csepp:
>> Also the CI UI could use some improvements.  I'm pretty sure I've
>> mentioned this before, but there is no easy way to find out which inputs
>> I need to fix to make a dependency failure disappear.  I think everyone
>> has better things to do than perform a linear search by hand.
>
> Go to the package of a failed build, e.g.
> . The dependencies you
> need to fix are marked with a red cross or a red danger triangle. In
> case of a danger triangle, you need to look at the dependencies of the
> dependency, which you can visit via the hyperlink.
>
> I don't see any linear search here.
>
> Best regards,
> Maxime Devos.
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

That is precisely what the linear search algorithm is.  I should not
have to look through the dependency tree to figure out if two package
failures have the same cause, or to know how many (possibly indirect)
dependencies of a package are failing.
As an example, pandoc often fails to build on i686, but when you look at
the CI page, you see that it was caused by several of its inputs
failing, all due to some of *their* dependencies.
Now, you could dig down on one branch of the dependency DAG and find one
failing package, but that doesn't *actually* answer the question: "what
packages do I need to fix to enable this one?", because it could have
multiple failing inputs instead of just one.  The only way to tell is to
look at each page, that means having to visually find each failing input
on the page, wait for their CI pages to load, and repeat the whole
process.
If your browser is not particularly fast or you aren't so quick at
navigating a webpage, this can take a while.
But for the CI server, generating this information would take less than
a second.
Maybe some people value their time so little that they are fine with
doing this the manual way, but personally I have better things to do.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Simon Tournier  writes:

> Hi,
>
> On Wed, 23 Aug 2023 at 01:45, Csepp  wrote:
>
>> One possible improvement I have been thinking about is making it easy
>> for users to filter CI output to the packages in their profile closure,
>> so for example they would get advance notice of any broken packages
>> *before* attempting to install them.
>> Teams could also have their own filters.
>
> Maybe I am missing what you would like, from my understanding, that’s
> already possible using time-machine and weather.  For example,
>
>guix time-machine -- weather -m manifest.scm
>
> allow to know the status of the last commit.  What is missing is a clear
> return code for chaining.  For instance, see this proposal:
>
> subject: guix weather exit status?
> from: Leo Famulari 
> date: Thu, 08 Jul 2021 16:35:03 -0400
> message-id: id:yodhd7ffmovkj...@jasmine.lan
> https://yhetil.org/guix/yodhd7ffmovkj...@jasmine.lan
>
> However, I agree that the next step (find the log of the broken package)
> for teams is a bit convoluted.
>
> Cheers,
> simon

Thanks, I was not aware of this solution, but it also kind of isn't a
complete solution.
A pull is a quite costly operation, why should I have to perform one on
my netbook when what I'm trying to find out is which commit is actually
worth pulling to?

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxime Devos]

Op 23-08-2023 om 01:45 schreef Csepp:

I tried signing up to the CI mailing list and it immediately became
overwhelming.


If the CI list was split in ‘broken’ and ‘fixed’, such that you have the 
option to only subscribe to ‘broken’, would that help?  A large fraction 
of messages is for fixed packages, which do not need to be acted upon.



One possible improvement I have been thinking about is making it easy
for users to filter CI output to the packages in their profile closure,
so for example they would get advance notice of any broken packages
*before* attempting to install them.


I assume you meant s/install/update.

How is this an improvement?  I mean, how does this make

‘People need to report failing builds even though we have 
ci.guix.gnu.org for that.’


less true?

Best regards,
Maxime Devos.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxime Devos]

Op 23-08-2023 om 01:45 schreef Csepp:

Also the CI UI could use some improvements.  I'm pretty sure I've
mentioned this before, but there is no easy way to find out which inputs
I need to fix to make a dependency failure disappear.  I think everyone
has better things to do than perform a linear search by hand.


Go to the package of a failed build, e.g.
. The dependencies you 
need to fix are marked with a red cross or a red danger triangle. In 
case of a danger triangle, you need to look at the dependencies of the 
dependency, which you can visit via the hyperlink.


I don't see any linear search here.

Best regards,
Maxime Devos.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Simon Tournier]

Hi,

On Wed, 23 Aug 2023 at 01:45, Csepp  wrote:

> One possible improvement I have been thinking about is making it easy
> for users to filter CI output to the packages in their profile closure,
> so for example they would get advance notice of any broken packages
> *before* attempting to install them.
> Teams could also have their own filters.

Maybe I am missing what you would like, from my understanding, that’s
already possible using time-machine and weather.  For example,

   guix time-machine -- weather -m manifest.scm

allow to know the status of the last commit.  What is missing is a clear
return code for chaining.  For instance, see this proposal:

subject: guix weather exit status?
from: Leo Famulari 
date: Thu, 08 Jul 2021 16:35:03 -0400
message-id: id:yodhd7ffmovkj...@jasmine.lan
https://yhetil.org/guix/yodhd7ffmovkj...@jasmine.lan

However, I agree that the next step (find the log of the broken package)
for teams is a bit convoluted.

Cheers,
simon

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Csepp]

Maxime Devos  writes:

> [[PGP Signed Part:Undecided]]
> 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, there is a delay, but that doesn't matter at all, as there's
> this dashboard .)
>
> 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?
>
> Best regards,
> Maxime Devos
>
> [2. OpenPGP public key --- application/pgp-keys; 
> OpenPGP_0x49E3EE22191725EE.asc]...
>
> [[End of PGP Signed Part]]

I tried signing up to the CI mailing list and it immediately became
overwhelming.
Also the CI UI could use some improvements.  I'm pretty sure I've
mentioned this before, but there is no easy way to find out which inputs
I need to fix to make a dependency failure disappear.  I think everyone
has better things to do than perform a linear search by hand.
So I rely on my own installations for detecting errors, that way I at
least know that I don't get flooded with notifications for packages I
know nothing about.
One possible improvement I have been thinking about is making it easy
for users to filter CI output to the packages in their profile closure,
so for example they would get advance notice of any broken packages
*before* attempting to install them.
Teams could also have their own filters.

bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that

[Maxime Devos]

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, there is a delay, but that doesn't matter at all, as there's this 
dashboard .)


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?


Best regards,
Maxime Devos


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature