all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Csepp <raingloom@riseup.net>
Cc: "Maxim Cournoyer" <maxim.cournoyer@gmail.com>,
	"Andy Tai" <atai@atai.org>,
	"Maxime Devos" <maximedevos@telenet.be>, 宋文武 <iyzsong@envs.net>,
	"Bruno Victal" <mirai@makinata.eu>,
	65391@debbugs.gnu.org
Subject: bug#65391: People need to report failing builds even though we have ci.guix.gnu.org for that
Date: Mon, 11 Sep 2023 09:58:44 +0200	[thread overview]
Message-ID: <CAJ3okZ1XsNiTr6V4b0ogzVbrrXwfhfssWxEFS5q3BuD-Y1xX3Q@mail.gmail.com> (raw)
In-Reply-To: <cuc34zl6u64.fsf@riseup.net>

Hi,

On Mon, 11 Sept 2023 at 09:33, Csepp <raingloom@riseup.net> 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




  reply	other threads:[~2023-09-11  8:00 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
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 [this message]
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=CAJ3okZ1XsNiTr6V4b0ogzVbrrXwfhfssWxEFS5q3BuD-Y1xX3Q@mail.gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=65391@debbugs.gnu.org \
    --cc=atai@atai.org \
    --cc=iyzsong@envs.net \
    --cc=maxim.cournoyer@gmail.com \
    --cc=maximedevos@telenet.be \
    --cc=mirai@makinata.eu \
    --cc=raingloom@riseup.net \
    /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.