Hi,
Maxime Devos skribis:
> Phil Beadling schreef op ma 17-01-2022 om 17:23 [+]:
>> For each build that is kicked off in quick succession the local cache
>> of the repo required updated by update-cached-checkout
>> * https://github.com/guix-
>> mirror/guix/blob/9f526f5dad5f4af69d158c50369e1
Hi all,
The issue also exists when using --with-commit - see below for a refined
test that makes it trivial to demonstrate with any package where the source
is retrieved from git.
On Tue, 18 Jan 2022 at 10:10, Phil wrote:
>
> > Philip Beadling writes:
>
> >No, and we probably should do, even
Ricardo Wurmus writes:
> Philip Beadling writes:
>
>> The source in each one will be slightly different and although I only
>> specify commit id in the package
>
> How are you using Guix with this? Do you generate Guix package
> expressions? Do you use “guix build --with-commit”?
No, and we
Phil schreef op di 18-01-2022 om 09:28 [+]:
> To mitigate performance concerns, I think it's possible to set the
> branches and depth in git such that we only clone the bare-bones only?.
IIUC libgit2 and the Guile bindings guile-git do not currently support
shallow clones (depth, etc.). Bare-
Maxime Devos writes:
> Maybe 'latest-repository-commit' and 'update-cached-checkout' commit
> can be modified to not use 'switch-to-ref', and instead directly ask
> libgit ‘what's the tree structure of commit cabba9e’ and call a
> procedure like 'add-file-tree-to-store'. That would avoid lock f
Hi,
Phil Beadling schreef op ma 17-01-2022 om 17:23 [+]:
> For each build that is kicked off in quick succession the local cache
> of the repo required updated by update-cached-checkout
> * https://github.com/guix-
> mirror/guix/blob/9f526f5dad5f4af69d158c50369e182305147f3b/guix/git.sc
> m#L4
Hi Ricardo, all,
I think we’ve worked out what the issue is, and have a proposed workaround,
and perhaps a case for solving the problem in Guix itself (depending on
what you people think!).
The issue is that despite each build being performed in its own isolated
container, these containers ar
Hi - more details below.
Ricardo Wurmus writes:
>
> How are you using Guix with this? Do you generate Guix package
> expressions? Do you use “guix build --with-commit”?
>
The situation is like this - if we had a directory of clones of my
channel:
- pr-1
- pr-2
- pr-3
- pr-4
... and so on
Ini
Philip Beadling writes:
> The source in each one will be slightly different and although I only
> specify commit id in the package
How are you using Guix with this? Do you generate Guix package
expressions? Do you use “guix build --with-commit”?
If the hash in the “source” field corresponds
epeat.
It won't solve the problem but will remove any other source of the problem,
and can be left running in fast succession.
From: Ricardo Wurmus
Sent: Tuesday, 11 January 2022, 23:17
To: Phil
Cc: guix-devel@gnu.org
Subject: Re: Parallel guix builds c
Phil writes:
> I update the same single package on each channel locally with a
> different git commit id and package version. So 12 variations of the
> same package, accessing different commit ids, in the same package's
> source repo, and having different package versions in Guix.
Do they hav
Hi all,
I'm seeing strange issues when running many "guix build" commands of the
same package simultaneously on the same linux account/server at the same
time.
Tracing this requires a lot of detective work, so for now I've omitted
the logs - my initial question is - am I doing something which is
12 matches
Mail list logo