all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Baines <mail@cbaines.net>
To: Josselin Poiret <dev@jpoiret.xyz>
Cc: 63263@debbugs.gnu.org
Subject: [bug#63263] [PATCH] gexp: Stop generating unreadable builder scripts.
Date: Sat, 06 May 2023 09:05:43 +0100	[thread overview]
Message-ID: <87lei12820.fsf@cbaines.net> (raw)
In-Reply-To: <87y1m33o5e.fsf@jpoiret.xyz>

[-- Attachment #1: Type: text/plain, Size: 1408 bytes --]


Josselin Poiret <dev@jpoiret.xyz> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> I guess my perspective on this is more from the operation of the guix
>> data service, which is carefully computing and storing all of these
>> broken derivations (and there's a lot, like 10,000+ per revision at the
>> moment, since they change every time you compute them).  This then
>> propagates down to the build coordinator as well, since there's builds
>> being submitted for all these broken derivations. I have considered
>> trying to detect these breakages in the data service, but I'm not sure
>> how to do it while removing the possibility of false positives.
>
> I guess you already read the derivations from the data service to find
> out what has changed, right?  Would you also be able to try to read the
> builder script from there, before trying to build?  And if the
> derivation is bad, signal it somehow and flag it for some sort of gc?
> Although then, all other derivations depending on it would also need to
> be gc'd, which might be annoying.
>
> I don't know if the data service's architecture would allow this to be
> done before trying to build derivations though, sorry in advance if that
> would be too much work.

It would do, but I'm not sure this would be as reliable as doing the
check from Guix, especially since the version of Guile used for the
checking might be different.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

  reply	other threads:[~2023-05-06  8:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 11:24 [bug#63263] [PATCH] gexp: Stop generating unreadable builder scripts Christopher Baines
2023-05-04 12:47 ` Ludovic Courtès
2023-05-04 12:57   ` Christopher Baines
2023-05-04 19:14     ` Josselin Poiret via Guix-patches via
2023-05-06  8:05       ` Christopher Baines [this message]
2023-05-05 21:45     ` Ludovic Courtès
2023-05-06  7:39       ` Christopher Baines
2023-05-10 15:22         ` Ludovic Courtès
2023-05-10 16:02           ` Christopher Baines
2023-09-01 14:16             ` Maxim Cournoyer
2023-09-02 10:36               ` bug#63263: " Christopher Baines
2023-09-03 14:54                 ` [bug#63263] " Maxim Cournoyer

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=87lei12820.fsf@cbaines.net \
    --to=mail@cbaines.net \
    --cc=63263@debbugs.gnu.org \
    --cc=dev@jpoiret.xyz \
    /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.