Hi, Pjotr Prins <pjotr.publi...@thebird.nl> 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’.
