all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* In need for a simple "join build container"
@ 2017-06-06 11:21 Hartmut Goebel
  2017-06-06 14:16 ` Roel Janssen
  0 siblings, 1 reply; 3+ messages in thread
From: Hartmut Goebel @ 2017-06-06 11:21 UTC (permalink / raw)
  To: guix-devel

Hi,

I find myself debugging some package test-cases quite often. This is
*very* time-consuming, esp. if compiling the source takes several minutes.

So what I need is something to drop me into an interactive shell if the
build fails.

At the moment for these cases I try setting of an environment (see my
other post just a few minutes ago). But this setup is quite complicated
(so I wrote a wrapper-shell-script) and error-prone. And I assume,
others packagers will need this, too.

My ideal solution would be something like

    guix build --shell-on-failure mypackage

Should I open a bug-report for this?

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: In need for a simple "join build container"
  2017-06-06 11:21 In need for a simple "join build container" Hartmut Goebel
@ 2017-06-06 14:16 ` Roel Janssen
  2017-06-07 12:30   ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Roel Janssen @ 2017-06-06 14:16 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: guix-devel


Hartmut Goebel writes:

> Hi,
>
> I find myself debugging some package test-cases quite often. This is
> *very* time-consuming, esp. if compiling the source takes several minutes.
>
> So what I need is something to drop me into an interactive shell if the
> build fails.
>
> At the moment for these cases I try setting of an environment (see my
> other post just a few minutes ago). But this setup is quite complicated
> (so I wrote a wrapper-shell-script) and error-prone. And I assume,
> others packagers will need this, too.
>
> My ideal solution would be something like
>
>     guix build --shell-on-failure mypackage
>
> Should I open a bug-report for this?

I would find this really useful as I usually do the manual steps:
guix build -K <package>
cd <package-build-dir>
bash
. environment_variables
cd <actual_source_dir>

Which is suboptimal because then you're not the build user in an
isolated environment.

Kind regards,
Roel Janssen

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: In need for a simple "join build container"
  2017-06-06 14:16 ` Roel Janssen
@ 2017-06-07 12:30   ` Ludovic Courtès
  0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2017-06-07 12:30 UTC (permalink / raw)
  To: Roel Janssen; +Cc: guix-devel

Heya,

Roel Janssen <roel@gnu.org> skribis:

> Hartmut Goebel writes:
>
>> Hi,
>>
>> I find myself debugging some package test-cases quite often. This is
>> *very* time-consuming, esp. if compiling the source takes several minutes.
>>
>> So what I need is something to drop me into an interactive shell if the
>> build fails.
>>
>> At the moment for these cases I try setting of an environment (see my
>> other post just a few minutes ago). But this setup is quite complicated
>> (so I wrote a wrapper-shell-script) and error-prone. And I assume,
>> others packagers will need this, too.
>>
>> My ideal solution would be something like
>>
>>     guix build --shell-on-failure mypackage
>>
>> Should I open a bug-report for this?
>
> I would find this really useful as I usually do the manual steps:
> guix build -K <package>
> cd <package-build-dir>
> bash
> . environment_variables
> cd <actual_source_dir>
>
> Which is suboptimal because then you're not the build user in an
> isolated environment.

Did you see the suggestions we recently added to the manual?

  https://www.gnu.org/software/guix/manual/html_node/Debugging-Build-Failures.html

The instructions are reasonable IMO.

The proposed ‘--shell-on-failure’ could automate this though, and I
agree it’d be nice.  Technically it could be surprisingly difficult to
implement, for instance because the daemon doesn’t communicate in a
machine-readable way the name of the failed build directory, and also
because the directory name “outside” might differ from the directory
name “inside” (/data/tmp/guix-build-foo.drv-7 vs /tmp/guix-build-foo.drv-0).

Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2017-06-07 12:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-06-06 11:21 In need for a simple "join build container" Hartmut Goebel
2017-06-06 14:16 ` Roel Janssen
2017-06-07 12:30   ` Ludovic Courtès

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.