Re: Heads-up: transition to Guile 2.2

[Ludovic Courtès]

Hi,

Pjotr Prins <address@hidden> skribis:

> The good news is that I got a build of a recent guix with
>
>   env -i /bin/bash --login --noprofile --norc
>   ~/.guix-profile/bin/guix environment guix --ad-hoc help2man git strace 
> pkg-config
>   rm -rf autom4te.cache/ # to be sure
>   make clean
>   ./bootstrap
>   ./configure --localstatedir=/var
>   make clean # to be sure
>   make
>
> which is *nice*. It is clear my environment is somewhat unstable - a
> combination of PATH pollution and (I think) recent tools mixed into the
> build process.
>
> And this is what my message is about, the tooling in my guix environment is
> old. Checking inside above environment
>
>   gcc --version
>     gcc (GCC) 5.4.0
>
>  guile --version
>    guile (GNU Guile) 2.0.14
>
> So, what is happening is that I am building a recent tree with an old
> toolset. This is exactly what I meant! I don't dare do a guix pull
> now, to avoid the tree build failing again(!). Heh.
>
> Everyone, I mean everyone, is building guix with different toolsets, i.e,
> combinations of tools and versions.
>
> This is wrong and unguixy.

Yes, I kinda agree, though again, we need to distinguish between
developers and users (I know I know, the deficiencies of ‘guix pull’
gives users an incentive to do use the
checkout/autoreconf/configure/make dance, but let’s put that aside for
now.)

As a developer, it’s important to be able to choose the tools that you
use.  For instance, to “port” Guix to Guile 2.2, I needed to build it
and run it with 2.2, but of course I couldn’t force it to users before
it was ready.  Thus, I believe the normal ./configure && make approach
makes sense in this developer context.

As a user though, I clearly don’t want to worry about these
shenanigans.  I want to be able to get the latest Guix and package set,
and I don’t care about what it involves behind the scenes.

>> >   ./configure --localstatedir=/var
>> >
>> > complains with 
>> >
>> >   configure: error: C preprocessor "/lib/cpp" fails sanity check
>> 
>> What does config.log say?
>
> It was a whole range of gcc 7.10 errors, looking for limit.h etc. Lost the 
> log in anger ;)

Lack of limits.h, could it be that you had ‘gcc’ in your profile instead
of ‘gcc-toolchain’ (the latter brings in the libc and Linux headers,
including <limits.h>, while the former does not)?

> It was during profile path resolving of Guix. I happen to have this in
> a screen. The full trace is
>
>   warning: collision encountered: 
> /gnu/store/b11lvv9x75jgiiw7rpyb53vj8j57jrw6-mysql-5.7.17/share/man/man1/mysqltest.1.gz
>  
>   
> /gnu/store/vdvwj57w1rnay7khvi0c4wp05f35gqcl-mysql-5.6.25/share/man/man1/mysqltest.1.gz
>   warning: arbitrarily choosing 
> /gnu/store/b11lvv9x75jgiiw7rpyb53vj8j57jrw6-mysql-5.7.17/share/man/man1/mysqltest.1.gz
>   Backtrace:
>   In ice-9/boot-9.scm:
>    160: 17 [catch #t #<catch-closure 8cac60> ...]
>   In unknown file:
>      ?: 16 [apply-smob/1 #<catch-closure 8cac60>]
>   In ice-9/boot-9.scm:
>     66: 15 [call-with-prompt prompt0 ...]
>   In ice-9/eval.scm:
>    432: 14 [eval # #]
>   In ice-9/boot-9.scm:
>   2404: 13 [save-module-excursion #<procedure 8ea7c0 at 
> ice-9/boot-9.scm:4051:3 ()>]
>   4056: 12 [#<procedure 8ea7c0 at ice-9/boot-9.scm:4051:3 ()>]
>   1727: 11 [%start-stack load-stack #<procedure 8fcae0 at 
> ice-9/boot-9.scm:4047:10 ()>]
>   1732: 10 [#<procedure 8fd6f0 ()>]
>   In unknown file:
>      ?: 9 [primitive-load 
> "/gnu/store/v9h4yaza43hi1780piyvvjsn5ba43hbn-profile-builder"]
>   In ./guix/build/profiles.scm:
>    133: 8 [build-profile 
> "/gnu/store/2qnn7divxnh5phd1k8sq7g9p29y1vapc-profile" # ...]
>   In unknown file:
>      ?: 7 [hash-for-each #<procedure d3f3f0 at ./guix/build/union.scm:143:21 
> (file dirs-with-file)> ...]
>      ?: 6 [hash-for-each #<procedure b92b10 at ./guix/build/union.scm:143:21 
> (file dirs-with-file)> ...]
>      ?: 5 [hash-for-each #<procedure eabd80 at ./guix/build/union.scm:143:21 
> (file dirs-with-file)> ...]
>      ?: 4 [hash-for-each #<procedure f24720 at ./guix/build/union.scm:143:21 
> (file dirs-with-file)> ...]
>   In ./guix/build/union.scm:
>    110: 3 [union 
> "/gnu/store/2qnn7divxnh5phd1k8sq7g9p29y1vapc-profile/share/man/man1/python.1" 
> ...]
>   In unknown file:
>      ?: 2 [partition #<procedure file-is-directory? (file)> #]
>   In ./guix/build/union.scm:
>     49: 1 [file-is-directory? 
> "/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12/share/man/man1/python.1"]
>   In unknown file:
>      ?: 0 [stat 
> "/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12/share/man/man1/python.1"
>  ...]
>
>   ERROR: In procedure stat:
>   ERROR: In procedure stat: No such file or directory: 
> "/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.12/share/man/man1/python.1"
>   builder for `/gnu/store/ssqb8qmdna28yjq2ggy5bxiy2wn5q1k7-profile.drv' 
> failed with exit code 1
>   guix package: error: build failed: build of 
> `/gnu/store/ssqb8qmdna28yjq2ggy5bxiy2wn5q1k7-profile.drv' failed
>
> but, lets not focus on that right now.

Hmm that looks like a genuine bug.  Could you email the details to
bug-guix if possible, ideally with a simple way to reproduce it (like
take commit XYZ, run “./pre-inst-env guix package -p new -i python …”)?

> No need. What I am suggesting is that we create an environment with a recent
> and *tested* set of tools to build the source tree. If that build is
> reproducible with recent tooling it will be easy to hunt down bugs. Currently
> we can pull a guix environment, but point me where we have an automated build
> of that to prove that it is working. Tell me how *you* can recreate
> the exact same build environment that I am using. Above environment
> isolation feature is useful, but does not guarantee reproducible
> builds from source. The point is that we *can* do it.
>
> I suggest to create a guix-build package which is tested against every commit
> that updates guix itself on the build farm. We don't have to trigger for
> updated packages. Just for commits to the core.
>
> Do you get what I mean? I think it is fairly trivial to achieve, If you agree
> this is important I may even have a go at it at some point. 

Yeah, I get what you mean.

Currently we have the ‘current-guix’ package, which is the ‘guix’
package built from the current Git checkout.  I think it’s pretty much
what you have in mind?  It’s fully specified in a “guixy” way, which is
to say that the ‘guix’ package specifies precisely the dependency graph.

The GuixSD installation tests are the only things that use
‘current-guix’ right now.

The future pull/channel command, though, will probably use something
similar to ‘current-guix’, as opposed to the terrible dependency mixture
that ‘guix pull’ uses.

Thanks for your feedback,
Ludo’.