* Re: Debugging Guix packages?
2016-01-21 0:21 ` Jookia
@ 2016-01-21 1:27 ` Leo Famulari
2016-01-21 1:59 ` Ben Woodcroft
` (2 subsequent siblings)
3 siblings, 0 replies; 14+ messages in thread
From: Leo Famulari @ 2016-01-21 1:27 UTC (permalink / raw)
To: Jookia; +Cc: guix-devel
On Thu, Jan 21, 2016 at 11:21:34AM +1100, Jookia wrote:
> On Wed, Jan 20, 2016 at 11:26:14PM +0100, Ludovic Courtès wrote:
> > Yes, I agree that this would be nice.
>
> I wonder how this could be implemented, any ideas?
>
> > OTOH, for things like GCC, once you start fiddling with the build tree,
> > you quickly lose track of what state you’re in.
> >
> > My workflow has been:
> >
> > guix build foo -K
> > # build fails
> > cd /tmp/guix-build*
> > source environment-variables
> > # Fiddle with the build tree to get additional info about the problem
> > # and a possible fix.
> > # Write a phase that hopefully fixes the issue.
> > # Try again.
> >
> > Since the ‘environment-variables’ file always contains the value of
> > environment variables at the time where the build failed (rather than
> > their initial value), it usually works quite well.
>
> This could be good enough for now but again this doesn't work with this like
> builds that don't fail. My concrete example is wanting to patch software but not
> knowing how to get to the pre-patch state so I can then work from that in
> testing which patches apply and which don't, or make my own.
My workflow for creating patches:
$ tar xf $(guix build --source foo)
# or, if the package is in your local source tree:
$ tar xf $(./pre-inst-env guix build --source foo)
$ cd foo && git init && git add -A && git commit -m "Initial commit"
# make edits and commit them. Then:
$ git format-patch
It's not necessary to use git but it helps me keep track of my changes.
>
> > My 2¢,
> > Ludo’.
>
> Cheers,
> Jookia.
>
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Debugging Guix packages?
2016-01-21 0:21 ` Jookia
2016-01-21 1:27 ` Leo Famulari
@ 2016-01-21 1:59 ` Ben Woodcroft
2016-01-21 20:55 ` Ludovic Courtès
2016-01-21 20:58 ` Ludovic Courtès
3 siblings, 0 replies; 14+ messages in thread
From: Ben Woodcroft @ 2016-01-21 1:59 UTC (permalink / raw)
To: Jookia, Ludovic Courtès; +Cc: guix-devel
Hi there,
On 21/01/16 10:21, Jookia wrote:
> On Wed, Jan 20, 2016 at 11:26:14PM +0100, Ludovic Courtès wrote:
>> OTOH, for things like GCC, once you start fiddling with the build tree,
>> you quickly lose track of what state you’re in.
>>
>> My workflow has been:
>>
>> guix build foo -K
>> # build fails
>> cd /tmp/guix-build*
>> source environment-variables
>> # Fiddle with the build tree to get additional info about the problem
>> # and a possible fix.
>> # Write a phase that hopefully fixes the issue.
>> # Try again.
>>
>> Since the ‘environment-variables’ file always contains the value of
>> environment variables at the time where the build failed (rather than
>> their initial value), it usually works quite well.
> This could be good enough for now but again this doesn't work with this like
> builds that don't fail. My concrete example is wanting to patch software but not
> knowing how to get to the pre-patch state so I can then work from that in
> testing which patches apply and which don't, or make my own.
Can I ask, why Ricardo's suggestion does not address this concern? This
approach makes builds fail, so then you can inspect. I often use this.
My 2c here, would it be possible to echo any system* commands used in
the build to the log? This would help make things concrete and put flags
in the build log sand.
Thanks,
ben
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Debugging Guix packages?
2016-01-21 0:21 ` Jookia
2016-01-21 1:27 ` Leo Famulari
2016-01-21 1:59 ` Ben Woodcroft
@ 2016-01-21 20:55 ` Ludovic Courtès
2016-01-22 4:13 ` Pjotr Prins
2016-01-21 20:58 ` Ludovic Courtès
3 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-01-21 20:55 UTC (permalink / raw)
To: Jookia; +Cc: guix-devel
Jookia <166291@gmail.com> skribis:
> On Wed, Jan 20, 2016 at 11:26:14PM +0100, Ludovic Courtès wrote:
>> Yes, I agree that this would be nice.
>
> I wonder how this could be implemented, any ideas?
Vague ideas. :-)
Roughly, we could generate a Scheme file containing the list of phases
(the generated build script contains them, but it immediately passes
them to ‘gnu-build’ or similar), which could be loaded into Guile. From
there we could explicitly manipulate the list of phases and run them.
There are complications though, such as the fact that build systems can
lack the notion of phases altogether (this is the case of
‘trivial-build-system’, but it may be the only one.) I wonder if we
should move phases from the build side to the host side at some point…
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Debugging Guix packages?
2016-01-21 20:55 ` Ludovic Courtès
@ 2016-01-22 4:13 ` Pjotr Prins
2016-01-22 4:53 ` Jookia
2016-01-22 17:05 ` Ludovic Courtès
0 siblings, 2 replies; 14+ messages in thread
From: Pjotr Prins @ 2016-01-22 4:13 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Thu, Jan 21, 2016 at 09:55:32PM +0100, Ludovic Courtès wrote:
> > I wonder how this could be implemented, any ideas?
>
> Roughly, we could generate a Scheme file containing the list of phases
> (the generated build script contains them, but it immediately passes
> them to ‘gnu-build’ or similar), which could be loaded into Guile. From
> there we could explicitly manipulate the list of phases and run them.
>
> There are complications though, such as the fact that build systems can
> lack the notion of phases altogether (this is the case of
> ‘trivial-build-system’, but it may be the only one.) I wonder if we
> should move phases from the build side to the host side at some point…
How about extending the -K switch with a build phase option where it
should stop?
I think the container thing is nice, but not really suitable for
fixing stuff (as Chris notes, it ends up read-only in the store). I am
pretty happy with -K.
Pj.
--
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Debugging Guix packages?
2016-01-22 4:13 ` Pjotr Prins
@ 2016-01-22 4:53 ` Jookia
2016-01-22 17:05 ` Ludovic Courtès
1 sibling, 0 replies; 14+ messages in thread
From: Jookia @ 2016-01-22 4:53 UTC (permalink / raw)
To: Pjotr Prins; +Cc: guix-devel
On Fri, Jan 22, 2016 at 05:13:02AM +0100, Pjotr Prins wrote:
> On Thu, Jan 21, 2016 at 09:55:32PM +0100, Ludovic Courtès wrote:
> > > I wonder how this could be implemented, any ideas?
> >
> > Roughly, we could generate a Scheme file containing the list of phases
> > (the generated build script contains them, but it immediately passes
> > them to ‘gnu-build’ or similar), which could be loaded into Guile. From
> > there we could explicitly manipulate the list of phases and run them.
> >
> > There are complications though, such as the fact that build systems can
> > lack the notion of phases altogether (this is the case of
> > ‘trivial-build-system’, but it may be the only one.) I wonder if we
> > should move phases from the build side to the host side at some point…
>
> How about extending the -K switch with a build phase option where it
> should stop?
>
> I think the container thing is nice, but not really suitable for
> fixing stuff (as Chris notes, it ends up read-only in the store). I am
> pretty happy with -K.
This might be good enough, but if you change options in the configure phase
you'll probably want to see what's happening in the check phase.
I like the idea of refactoring build scripts in to multiple functions that can
be run in a Guile prompt and have Guix or someone in a Guile prompt use those.
> Pj.
> --
Cheers,
Jookia.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Debugging Guix packages?
2016-01-22 4:13 ` Pjotr Prins
2016-01-22 4:53 ` Jookia
@ 2016-01-22 17:05 ` Ludovic Courtès
1 sibling, 0 replies; 14+ messages in thread
From: Ludovic Courtès @ 2016-01-22 17:05 UTC (permalink / raw)
To: Pjotr Prins; +Cc: guix-devel
Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> On Thu, Jan 21, 2016 at 09:55:32PM +0100, Ludovic Courtès wrote:
>> > I wonder how this could be implemented, any ideas?
>>
>> Roughly, we could generate a Scheme file containing the list of phases
>> (the generated build script contains them, but it immediately passes
>> them to ‘gnu-build’ or similar), which could be loaded into Guile. From
>> there we could explicitly manipulate the list of phases and run them.
>>
>> There are complications though, such as the fact that build systems can
>> lack the notion of phases altogether (this is the case of
>> ‘trivial-build-system’, but it may be the only one.) I wonder if we
>> should move phases from the build side to the host side at some point…
>
> How about extending the -K switch with a build phase option where it
> should stop?
I’m really skeptical about the usefulness of such a feature. As Ricardo
suggested earlier, stopping at a specific phase is really easy to do by
hand, on the rare occasions where you actually want that. (Not to
mention that one can also simply hit C-c while the thing is building.)
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Debugging Guix packages?
2016-01-21 0:21 ` Jookia
` (2 preceding siblings ...)
2016-01-21 20:55 ` Ludovic Courtès
@ 2016-01-21 20:58 ` Ludovic Courtès
2016-01-21 22:10 ` Jookia
3 siblings, 1 reply; 14+ messages in thread
From: Ludovic Courtès @ 2016-01-21 20:58 UTC (permalink / raw)
To: Jookia; +Cc: guix-devel
Jookia <166291@gmail.com> skribis:
> This could be good enough for now but again this doesn't work with this like
> builds that don't fail. My concrete example is wanting to patch software but not
> knowing how to get to the pre-patch state so I can then work from that in
> testing which patches apply and which don't, or make my own.
To get the unpatched source, you can always comment out the ‘patches’
field, and then run, say:
tar xf $(guix build -S my-package)
Or do I misunderstand?
Ludo’.
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Debugging Guix packages?
2016-01-21 20:58 ` Ludovic Courtès
@ 2016-01-21 22:10 ` Jookia
0 siblings, 0 replies; 14+ messages in thread
From: Jookia @ 2016-01-21 22:10 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
On Thu, Jan 21, 2016 at 09:58:38PM +0100, Ludovic Courtès wrote:
> Jookia <166291@gmail.com> skribis:
>
> > This could be good enough for now but again this doesn't work with this like
> > builds that don't fail. My concrete example is wanting to patch software but not
> > knowing how to get to the pre-patch state so I can then work from that in
> > testing which patches apply and which don't, or make my own.
>
> To get the unpatched source, you can always comment out the ‘patches’
> field, and then run, say:
>
> tar xf $(guix build -S my-package)
>
> Or do I misunderstand?
One difficulty with the approach of modifying the package is that in a lot of
cases Guix is read-only in a store. So I guess the right way to do this
patching is to modify packages and have Guix use that, though this solution
applies to everything. Maybe a debugger isn't needed? I find it hard to justify
outside 'it makes it easier to try new things quickly'.
> Ludo’.
Cheers,
Jookia.
^ permalink raw reply [flat|nested] 14+ messages in thread