all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Csepp <raingloom@riseup.net>
To: Maxime Devos <maximedevos@telenet.be>
Cc: 65391@debbugs.gnu.org, raingloom@riseup.net
Subject: bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that
Date: Thu, 24 Aug 2023 19:27:35 +0200	[thread overview]
Message-ID: <87cyzcbau0.fsf@riseup.net> (raw)
In-Reply-To: <ad986d87-4da7-3df4-0cd5-0fb156d0498c@telenet.be>


Maxime Devos <maximedevos@telenet.be> 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.
> <https://ci.guix.gnu.org/build/1840209/details>. 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.




  reply	other threads:[~2023-08-24 17:38 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19 23:53 bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxime Devos
2023-08-22 23:45 ` Csepp
2023-08-24  9:57   ` Simon Tournier
2023-08-24 17:23     ` Csepp
2023-08-24 14:52   ` Maxime Devos
2023-08-24 17:27     ` Csepp [this message]
2023-08-29 22:52       ` Maxime Devos
2023-08-30  2:36         ` Maxim Cournoyer
2023-08-24 15:02   ` Maxime Devos
2023-08-24 17:38     ` Csepp
2023-08-27  1:13 ` 宋文武
2023-08-27  3:38   ` Maxim Cournoyer
2023-08-27  8:16     ` bug#65391: [Cuirass] feature requests for dashboard 宋文武 via Bug reports for GNU Guix
2023-08-27  3:39   ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Maxim Cournoyer
2023-08-27  4:30   ` Bruno Victal
2023-08-27 15:07     ` Giovanni Biscuolo
2023-08-27 16:24 ` bug#65391: People need to report failing builds even Andy Tai
2023-08-27 21:26   ` Andy Tai
     [not found] ` <handler.65391.B.169248925726403.ack@debbugs.gnu.org>
2023-08-29 14:03   ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-29 14:45     ` Maxim Cournoyer
2023-08-29 22:44       ` Maxime Devos
2023-08-30  2:28         ` Maxim Cournoyer
2023-08-30 10:39           ` Dr. Arne Babenhauserheide
2023-08-30 19:12             ` Maxim Cournoyer
2023-09-07 11:53             ` Simon Tournier
2023-09-11  8:30               ` Dr. Arne Babenhauserheide
2023-09-11 14:00                 ` Simon Tournier
2023-09-11 23:12                   ` Dr. Arne Babenhauserheide
2023-09-12  0:39                     ` Simon Tournier
2023-08-30 11:50           ` Maxime Devos
2023-09-07 11:32       ` Simon Tournier
2023-09-11  7:28         ` bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that Csepp
2023-09-11  7:58           ` Simon Tournier
2023-09-11 21:52             ` Csepp
2023-09-12 18:43         ` bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that) Maxime Devos
2023-08-30 10:29     ` 宋文武 via Bug reports for GNU Guix
2024-02-14  9:13 ` bug#65391: Close Andreas Enge

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=87cyzcbau0.fsf@riseup.net \
    --to=raingloom@riseup.net \
    --cc=65391@debbugs.gnu.org \
    --cc=maximedevos@telenet.be \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.