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

Previous Next

Full log

Message #71 received at 65391 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: Csepp <raingloom <at> riseup.net>, Maxim Cournoyer
 <maxim.cournoyer <at> gmail.com>, 宋文武 <iyzsong <at> envs.net>,
 Bruno Victal <mirai <at> makinata.eu>, Andy Tai <atai <at> atai.org>
Cc: 65391 <at> debbugs.gnu.org
Subject: Re: bug#65391: People need to report failing builds even though we
 have ci.guix.gnu.org for that
Date: Wed, 30 Aug 2023 00:52:38 +0200

[Message part 1 (text/plain, inline)]

> [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 (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.