Hello Simon,
On Wed, Jul 10, 2024 at 6:40 PM Simon Tournier
wrote:
> I removed the tag easy.
Thanks
> Well, I still think it’s an easy fix because to
> me the issue is not the failure of “guix build --source foo
> --with-source=bar” but the poor error handling. However, if the aim to
> be a
Hi Vincent,
On Sat, 22 Jun 2024 at 16:54, Vincent Legoll wrote:
> Looking at the comments in this issue, and the commenters list,
> I propose to remove the "easy" tag, if the issue is still there.
I removed the tag easy. Well, I still think it’s an easy fix because to
me the issue is not the f
tags 28510 - easy
quit
On Sat, Jun 22, 2024 at 4:54 PM Vincent Legoll
wrote:
> Looking at the comments in this issue, and the commenters list,
> I propose to remove the "easy" tag, if the issue is still there.
>
Looks like it is, the above reproducer from Maxime is still failing:
[...]
Throw to key `match-error' with
Hello,
Looking at the comments in this issue, and the commenters list,
I propose to remove the "easy" tag, if the issue is still there.
WDYT ?
--
Vincent Legoll
Hi Jérémy,
On Fri, 07 Oct 2022 at 10:41, jer...@korwin-zmijowski.fr wrote:
> I feel not able to take decision about the proper way right now.
> So as a step forward I wrote a test to capture the behavior expected.
> Please have a look at it as it's the starting point for me.
> Next, I can impleme
Le 2022-09-20 21:42, Josselin Poiret a écrit :
Hi Simon,
zimoun writes:
Well, I would add an error handler; as proposed [1]. :-) Because does
“guix build foo --source --with-source=bla” make sense? What is the
use-case for such command?
My bad, I didn't see the previous discussion on the
Hi Simon,
zimoun writes:
> Well, I would add an error handler; as proposed [1]. :-) Because does
> “guix build foo --source --with-source=bla” make sense? What is the
> use-case for such command?
My bad, I didn't see the previous discussion on the subject. To me, the
lack of generality would
Hi,
On Tue, 20 Sep 2022 at 11:19, Josselin Poiret via Bug reports for GNU Guix
wrote:
> The simple fix would be to add another band-aid cond at the
> show-derivation-outputs call in build.scm, but it doesn't seem to be
> enough in the long term.
Well, I would add an error handler; as proposed
Hi everyone,
Maxime Devos writes:
> Here is a simpler reproducer for that error:
>
> file a.scm:
> (use-modules (gnu packages) (guix packages) (guix gexp))
> (package
>(inherit (specification->package "hello"))
>(source (local-file "a.scm")))
>
> guix build -f a.scm --source
The issue is
On 19-09-2022 19:38, Jérémy Korwin-Zmijowski wrote:
Hello,
Today, I followed this steps to try to reproduce : [...]'.
So, still failing but I don't get the same error… Is it valid according
to the bug declaration ? I'm not sure haha
Here is a simpler reproducer for that error:
file a.scm:
Hello,
Today, I followed this steps to try to reproduce :
jeko@slim guix ±|master ✗|→ git pull
jeko@slim guix ±|master ✗|→ guix shell -D guix help2man git strace --pure
[dev] jeko@slim guix ±|master ✗|→ make
[dev] jeko@slim guix ±|master ✗|→ git clone
https://gitlab.com/guile-git/guile-git.git
Hi,
On Tue, 19 Sep 2017 at 14:09, Ricardo Wurmus
wrote:
> The command “guix build -S guile-git --with-source=guile-git” crashes
> instead of failing gracefully:
>
> rwurmus@bimsb-sys02 in code: git clone
> https://gitlab.com/guile-git/guile-git.git
[...]
> rwurmus@bimsb-sys02 in code: guix bu
The command “guix build -S guile-git --with-source=guile-git” crashes
instead of failing gracefully:
--8<---cut here---start->8---
rwurmus@bimsb-sys02 in code: git clone
https://gitlab.com/guile-git/guile-git.git
Cloning into 'guile-git'...
remote: Counting obj
14 matches
Mail list logo