unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Jookia <166291@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Debugging Guix packages?
Date: Thu, 21 Jan 2016 11:21:34 +1100	[thread overview]
Message-ID: <20160121002134.GA14628@novena-choice-citizen.lan> (raw)
In-Reply-To: <874me7x4zd.fsf@gnu.org>

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 2¢,
> Ludo’.

Cheers,
Jookia.

  reply	other threads:[~2016-01-21  0:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19  2:42 Debugging Guix packages? Jookia
2016-01-19 14:52 ` Ricardo Wurmus
2016-01-19 15:56   ` Christopher Allan Webber
2016-01-20 22:26   ` Ludovic Courtès
2016-01-21  0:21     ` Jookia [this message]
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-22  4:53           ` Jookia
2016-01-22 17:05           ` Ludovic Courtès
2016-01-21 20:58       ` Ludovic Courtès
2016-01-21 22:10         ` Jookia
2016-01-21 22:28     ` Christopher Allan Webber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160121002134.GA14628@novena-choice-citizen.lan \
    --to=166291@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).