Acknowledgement sent
to Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Tue, 19 Sep 2017 12:11:02 GMT) (full text, mbox, link).
Hi,
On Tue, 19 Sep 2017 at 14:09, Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> 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 build -S guile-git --with-source=guile-git
> Backtrace:
Still failing. In ’compute-derivation’, this
(s
(list (package-source-derivation store s)))))
returns a list of string instead of a derivation, so then
(for-each show-derivation-outputs drv)
fails because it expects a derivation or a derivation-input (see in
(guix ui)).
Well, I am not sure where the error should be handled. In (guix ui) and
in (guix scripts build)? WDYT?
Cheers,
simon
Added tag(s) easy.
Request was from zimoun <zimon.toutoune@gmail.com>
to control@debbugs.gnu.org.
(Wed, 24 Mar 2021 22:10:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Mon, 19 Sep 2022 17:39:01 GMT) (full text, mbox, link).
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:
(use-modules (gnu packages) (guix packages) (guix gexp))
(package
(inherit (specification->package "hello"))
(source (local-file "a.scm")))
guix build -f a.scm --source
Greetings,
Maxime.
Hi everyone,
Maxime Devos <maximedevos@telenet.be> 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 that package-source-derivation in guix/packages.scm doesn't
actually always yield a derivation, since lower-object isn't guaranteed
to do that: here the gexp compiler for local-file only returns a string
denoting the file path of the interned store file. `guix build` relies
on the (wrong) assumption that everything that it will build will end up
being a derivation in some way or another, so just calls
show-derivation-outputs on that, which then errors as above.
build-derivations, contrary to its name, can also pass simple file names
to build-things, and since the file will already be interned in the
store at that point, it won't need to do anything, and there won't be
any errors there.
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.
What do people think?
--
Josselin Poiret
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Tue, 20 Sep 2022 17:36:02 GMT) (full text, mbox, link).
Hi,
On Tue, 20 Sep 2022 at 11:19, Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org> 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 [1]. :-) Because does
“guix build foo --source --with-source=bla” make sense? What is the
use-case for such command?
1: <https://issues.guix.gnu.org/28510/#1>
Cheers,
simon
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Tue, 20 Sep 2022 19:43:02 GMT) (full text, mbox, link).
To: zimoun <zimon.toutoune@gmail.com>, Maxime Devos
<maximedevos@telenet.be>, Jérémy Korwin-Zmijowski
<jeremy@korwin-zmijowski.fr>, 28510@debbugs.gnu.org
Hi Simon,
zimoun <zimon.toutoune@gmail.com> 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 be unexpected: if I have a package with a
source, I expect to be able to get that source, whatever the source may
be. Maxime's minimal example shows that it could happen for a variety
of different reasons, not just a --with-source= flag. I don't know what
a proper fix for it would be though, since we're passing things around
that we pretend are derivations but are not, and in many places.
Best,
--
Josselin Poiret
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Fri, 07 Oct 2022 08:42:01 GMT) (full text, mbox, link).
Le 2022-09-20 21:42, Josselin Poiret a écrit :
> Hi Simon,
>
> zimoun <zimon.toutoune@gmail.com> 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 be unexpected: if I have a package with a
> source, I expect to be able to get that source, whatever the source may
> be. Maxime's minimal example shows that it could happen for a variety
> of different reasons, not just a --with-source= flag. I don't know
> what
> a proper fix for it would be though, since we're passing things around
> that we pretend are derivations but are not, and in many places.
>
> Best,
Hi !
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 implement the error handler, making the previous test to
pass.
As the test checks the behaviour, it will let enough space to change
implementation later without invalitating the test.
Cheers,
Jérémy
Hi Jérémy,
On Fri, 07 Oct 2022 at 10:41, jeremy@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 implement the error handler, making the previous test to
> pass.
> As the test checks the behaviour, it will let enough space to change
> implementation later without invalitating the test.
Nice to start by the test! :-)
> (define-module (tests scripts build)
> #:use-module (srfi srfi-64)
> #:use-module (ice-9 exceptions)
> #:use-module (guix scripts build)
> #:use-module (srfi srfi-34))
>
> (test-begin "scripts")
>
> (define DUMMY_DEFINITION_PATH "/tmp/a.scm")
>
> (define (create-dummy-definition)
> (call-with-output-file DUMMY_DEFINITION_PATH
> (lambda (port)
> (format port
> "(use-modules (gnu packages) (guix packages) (guix gexp)) (package (inherit (specification->package \"hello\")) (source (local-file \"a.scm\")))"))))
>
> (define (delete-dummy-definition)
> (delete-file DUMMY_DEFINITION_PATH))
>
> (test-group-with-cleanup "build"
>
> (create-dummy-definition)
>
> (test-equal "package definition as only source"
> "/gnu/store/7mnkrg9bmybgyf1dn5n67di6ng6qvhkz-a.scm"
> (guard
> (ex
> ((exception? ex) #f))
> (guix-build "-f" DUMMY_DEFINITION_PATH "--source")))
Well, this test looks good to me. However, I would lower what the
procedure under test. For instance, package-source-derivation in
guix/packages.scm or show-derivation-outputs, as Josselin pointed [1].
1: <https://yhetil.org/guix/87k05y2yjc.fsf@jpoiret.xyz>
>
> (delete-dummy-definition))
>
> (test-end "scripts")
Cheers,
simon
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Sat, 22 Jun 2024 16:56:01 GMT) (full text, mbox, link).
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
On Sat, Jun 22, 2024 at 4:54 PM Vincent Legoll <vincent.legoll@gmail.com>
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 args `("match" "no matching pattern"
"/gnu/store/kp25y6nll418j0l5kissbbvynl47mzhz-a.scm")'.
--
Vincent Legoll
Hi Vincent,
On Sat, 22 Jun 2024 at 16:54, Vincent Legoll <vincent.legoll@gmail.com> 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 failure of “guix build --source foo
--with-source=bar” but the poor error handling. However, if the aim to
be able to pass such command-line, then indeed that’s not easy because
it’s about some guarantee that the transformation is sound and that’s
hard for the generic case, IMHO.
Cheers,
simon
Information forwarded
to bug-guix@gnu.org: bug#28510; Package guix.
(Wed, 10 Jul 2024 20:30:02 GMT) (full text, mbox, link).
Hello Simon,
On Wed, Jul 10, 2024 at 6:40 PM Simon Tournier <zimon.toutoune@gmail.com>
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 able to pass such command-line, then indeed that’s not easy because
> it’s about some guarantee that the transformation is sound and that’s
> hard for the generic case, IMHO.
>
Well let's hope few such easy bugs linger for so long without being fixed
;-)
--
Vincent Legoll
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.