Re: 'CONFIG_HEADER not defined' during sed compile during 'guix pull'

2019-02-03 Thread Nathan Valentine
Just to round this one out, I was able to get things working in a Fedora29 VM 
by relying on Substitutes. I found the 'Binary Installation' docs to be 
somewhat misleading but I wrote a BASH script (wrapped in a Vagrantfile) which 
details my working setup. I'm not sure its worth sharing here since it relies 
on VirtualBox which has some non-free aspects to its licensing.

If there's any interest in the above then I'll spend some time converting it to 
use KVM and then share here.

Thanks for the help, Ricardo.



Re: 'CONFIG_HEADER not defined' during sed compile during 'guix pull'

2019-01-30 Thread Ricardo Wurmus


Hi Nathan,

> I have all of the available selinux devel packages installed: […]

What you have installed on your system does not affect the build.
That’s by design.  All builds happen in isolated environments where only
declared packages are available.  Your system files are not available
during the build.

> I'm trying to ease into GuixSD by first installing Guix on top of Fedora29. 
> Following through the docs for 'Binary installation', when I do a 'guix pull' 
> I'm eventually getting this error during the sed compile:
>
> inplace-selinux.sh: set-up failure: CONFIG_HEADER not defined
> ERROR: testsuite/inplace-selinux.sh
>
> which causes the pull to fail.

That’s not good but I cannot reproduce this as of Guix
ba123b6dda3afb84c457f9e68c20eeff61e2c740.  I ran “guix build --check
sed” to build sed.  (Are you running the daemon on a system where
SELinux is enabled?)

I also wonder why you’re building things from source when you can get
binaries from the build farm instead.  Did you forget to authorize the
build farm public key or are you purposefully building everything from
source?

--
Ricardo




Re: 'CONFIG_HEADER not defined' during sed compile during 'guix pull'

2019-01-30 Thread Nathan Valentine
Thanks for looking at things, Ricardo.


> That’s not good but I cannot reproduce this as of Guix
> ba123b6dda3afb84c457f9e68c20eeff61e2c740. I ran “guix build --check
> sed” to build sed. (Are you running the daemon on a system where
> SELinux is enabled?)


I get no output and a 0 exit code when I run the --check but some information 
about the VM I'm using is below. I started out with SELINUX enabled but have 
since disabled it in the VM thinking that perhaps that was a source of problems:


$ dnf copr list ;  rpm -qa | grep guix ; selinuxenabled; echo "selinuxenabled: 
$?"
copr.fedorainfracloud.org/lantw44/guix
guix-0.16.0-2.fc29.x86_64
selinuxenabled: 0


The first few lines of the guix pull command output are:


Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   24886c1
substitute: guix substitute: warning: ACL for archive imports seems to be 
uninitialized, substitutes may be unavailable
building /gnu/store/x96jqkjd7jagszan8srmqblhgx1g6qmc-sed-4.5.drv...


> I also wonder why you’re building things from source when you can get
> binaries from the build farm instead. Did you forget to authorize the
> build farm public key or are you purposefully building everything from
> source?

The docs mention Substitutions being disabled for binary installations...


Substitutes from the official build farm are enabled by default when using the 
Guix System Distribution (see GNU Distribution). However, they are disabled by 
default when using Guix on a foreign distribution, unless you have explicitly 
enabled them via one of the recommended installation steps (see Installation). 
The following paragraphs describe how to enable or disable substitutes for the 
official build farm; the same procedure can also be used to enable substitutes 
for any other substitute server.


I (incorrectly) assumed that was because on a Binary Installation the Guix 
install must rely on some local packages during pull. I'll enable substitutions 
and report the outcome.