From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Heads-up: transition to Guile 2.2 Date: Mon, 15 May 2017 17:48:56 +0200 Message-ID: <87fug6f7dj.fsf@gnu.org> References: <87bmt28qnm.fsf@gnu.org> <87k26chy16.fsf@gnu.org> <87y3u5wwsi.fsf_-_@gnu.org> <20170514135041.GA29369@thebird.nl> <871srrruvi.fsf@gnu.org> <20170515072626.GA963@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAIF5-0001X7-E8 for guix-devel@gnu.org; Mon, 15 May 2017 11:49:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAIF1-000157-4C for guix-devel@gnu.org; Mon, 15 May 2017 11:49:03 -0400 In-Reply-To: <20170515072626.GA963@thebird.nl> (Pjotr Prins's message of "Mon, 15 May 2017 09:26:26 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pjotr Prins Cc: guix-devel Hi, Pjotr Prins 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=3D/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 =E2=80=98guix pull= =E2=80=99 gives users an incentive to do use the checkout/autoreconf/configure/make dance, but let=E2=80=99s put that aside = for now.) As a developer, it=E2=80=99s important to be able to choose the tools that = you use. For instance, to =E2=80=9Cport=E2=80=9D Guix to Guile 2.2, I needed t= o build it and run it with 2.2, but of course I couldn=E2=80=99t force it to users bef= ore it was ready. Thus, I believe the normal ./configure && make approach makes sense in this developer context. As a user though, I clearly don=E2=80=99t want to worry about these shenanigans. I want to be able to get the latest Guix and package set, and I don=E2=80=99t care about what it involves behind the scenes. >> > ./configure --localstatedir=3D/var >> > >> > complains with=20 >> > >> > configure: error: C preprocessor "/lib/cpp" fails sanity check >>=20 >> What does config.log say? > > It was a whole range of gcc 7.10 errors, looking for limit.h etc. Lost th= e log in anger ;) Lack of limits.h, could it be that you had =E2=80=98gcc=E2=80=99 in your pr= ofile instead of =E2=80=98gcc-toolchain=E2=80=99 (the latter brings in the libc and Linux= headers, including , 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/b11lvv9x75jgiiw7rpyb53vj8j57= jrw6-mysql-5.7.17/share/man/man1/mysqltest.1.gz=20 > /gnu/store/vdvwj57w1rnay7khvi0c4wp05f35gqcl-mysql-5.6.25/share/man/man1= /mysqltest.1.gz > warning: arbitrarily choosing /gnu/store/b11lvv9x75jgiiw7rpyb53vj8j57jr= w6-mysql-5.7.17/share/man/man1/mysqltest.1.gz > Backtrace: > In ice-9/boot-9.scm: > 160: 17 [catch #t # ...] > In unknown file: > ?: 16 [apply-smob/1 #] > 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 #] > 4056: 12 [#] > 1727: 11 [%start-stack load-stack #] > 1732: 10 [#] > In unknown file: > ?: 9 [primitive-load "/gnu/store/v9h4yaza43hi1780piyvvjsn5ba43hbn-pr= ofile-builder"] > In ./guix/build/profiles.scm: > 133: 8 [build-profile "/gnu/store/2qnn7divxnh5phd1k8sq7g9p29y1vapc-pro= file" # ...] > In unknown file: > ?: 7 [hash-for-each # ...] > ?: 6 [hash-for-each # ...] > ?: 5 [hash-for-each # ...] > ?: 4 [hash-for-each # ...] > In ./guix/build/union.scm: > 110: 3 [union "/gnu/store/2qnn7divxnh5phd1k8sq7g9p29y1vapc-profile/sha= re/man/man1/python.1" ...] > In unknown file: > ?: 2 [partition # #] > In ./guix/build/union.scm: > 49: 1 [file-is-directory? "/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4a= s-python-2.7.12/share/man/man1/python.1"] > In unknown file: > ?: 0 [stat "/gnu/store/q6rbp7s542jkhrhz04hsp2i60gw0h4as-python-2.7.1= 2/share/man/man1/python.1" ...] > > ERROR: In procedure stat: > ERROR: In procedure stat: No such file or directory: "/gnu/store/q6rbp7= s542jkhrhz04hsp2i60gw0h4as-python-2.7.12/share/man/man1/python.1" > builder for `/gnu/store/ssqb8qmdna28yjq2ggy5bxiy2wn5q1k7-profile.drv' f= ailed with exit code 1 > guix package: error: build failed: build of `/gnu/store/ssqb8qmdna28yjq= 2ggy5bxiy2wn5q1k7-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 =E2=80=9C./pre-inst-env guix package -p new -i python = =E2=80=A6=E2=80=9D)? > No need. What I am suggesting is that we create an environment with a rec= ent > 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. Curre= ntly > we can pull a guix environment, but point me where we have an automated b= uild > 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 co= mmit > 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 a= gree > this is important I may even have a go at it at some point.=20 Yeah, I get what you mean. Currently we have the =E2=80=98current-guix=E2=80=99 package, which is the = =E2=80=98guix=E2=80=99 package built from the current Git checkout. I think it=E2=80=99s pretty m= uch what you have in mind? It=E2=80=99s fully specified in a =E2=80=9Cguixy=E2= =80=9D way, which is to say that the =E2=80=98guix=E2=80=99 package specifies precisely the depe= ndency graph. The GuixSD installation tests are the only things that use =E2=80=98current-guix=E2=80=99 right now. The future pull/channel command, though, will probably use something similar to =E2=80=98current-guix=E2=80=99, as opposed to the terrible depen= dency mixture that =E2=80=98guix pull=E2=80=99 uses. Thanks for your feedback, Ludo=E2=80=99.