Re: make packagers life easier

[ludo@gnu.org (Ludovic Courtès)]

Sree Harsha Totakura <sreeharsha@totakura.in> skribis:

> I have a similar feature request.  Long time ago when I was packaging
> gnunet and curl, I had to spend a lot of time trying to understand why
> `make check` phase fails in the build environment.  More often than not,
> I had to extensively study the test cases and the testing mechanism
> being used to understand and then resolve the failures, much to my
> chagrin, by trail-and-error as I did not have access to the build
> environment.
>
> Sure, `guix build -K` helped to some extent but there were some
> hard-to-debug cases which only failed in the build environment due to
> separate network and filesystem namespaces.

On GuixSD, there are few differences between the build environment and
the “real” environment, which makes ‘guix build -K’ probably more
useful.  Notable differences are that the real environment has network
access and /bin/sh.

The /bin/sh thing is usually easily fixed.  Problems related to separate
network name spaces can be more difficult as you noticed, although it’s
also always possible to run ‘strace’ in the build process or some Guile
snippet to get a better understanding of what’s going on.

However, when using Guix on another distro, then of course, in addition
to /bin/sh and networking, you get an FHS tree, which makes a
significant difference compared to the build environment.

> I discussed this with Christian and his suggestion was to implement a
> debug shell which the guix builder will bail out to when a phase fails.
>  The packager can then examine the environment right at the moment where
> the failure happens.
>
> I know that since the build happens in a separate namespace this can be
> hard to implement, but one idea is to configure the build environments
> network namespace to accept connections from localhost and spawn sshd
> when the build fails.
>
> WDYT?

I think it’s a nice idea, but it’s easier said than done.  :-)

An option would be to make do without the daemon’s help.  But then, do
we add lsh/OpenSSH as a dependency of every build?  And more
importantly, can we actually open connections available from the
outside?

The other option is to handle it within the daemon, which would do all
the container-with-ssh-daemon setup by itself when needed.  That seems a
bit heavyweight to do there, and perhaps more investment than desirable
in this C++ code base.

If container support was librarified, akin to what David suggested for
GSoC¹, it would be easy for users to start a container that is really
comparable to that created by guix-daemon.  Then that would make this
sort of debugging much easier, among other benefits.

My 2¢,
Ludo’.

¹ http://www.gnu.org/software/soc-projects/ideas-2015.html#guix