Re: Parallel guix builds can trample?

2022-01-18 Thread Ludovic Courtès
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

Re: Parallel guix builds can trample?

2022-01-18 Thread Phil Beadling
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

Re: Parallel guix builds can trample?

2022-01-18 Thread Phil
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

Re: Parallel guix builds can trample?

2022-01-18 Thread Maxime Devos
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-

Re: Parallel guix builds can trample?

2022-01-18 Thread Phil
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

Re: Parallel guix builds can trample?

2022-01-17 Thread Maxime Devos
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

Re: Parallel guix builds can trample?

2022-01-17 Thread Phil Beadling
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

Re: Parallel guix builds can trample?

2022-01-12 Thread Phil
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

Re: Parallel guix builds can trample?

2022-01-12 Thread Ricardo Wurmus
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

Re: Parallel guix builds can trample?

2022-01-11 Thread Philip Beadling
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

Re: Parallel guix builds can trample?

2022-01-11 Thread Ricardo Wurmus
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

Parallel guix builds can trample?

2022-01-11 Thread Phil
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