From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: Heads-up: transition to Guile 2.2 Date: Mon, 15 May 2017 09:26:26 +0200 Message-ID: <20170515072626.GA963@thebird.nl> References: <87bmt28qnm.fsf@gnu.org> <87k26chy16.fsf@gnu.org> <87y3u5wwsi.fsf_-_@gnu.org> <20170514135041.GA29369@thebird.nl> <871srrruvi.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAAP4-0002L2-6H for guix-devel@gnu.org; Mon, 15 May 2017 03:26:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAAP0-0007MN-W6 for guix-devel@gnu.org; Mon, 15 May 2017 03:26:50 -0400 Content-Disposition: inline In-Reply-To: <871srrruvi.fsf@gnu.org> 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: Ludovic Court??s Cc: guix-devel Hi Ludo, On Sun, May 14, 2017 at 11:28:17PM +0200, Ludovic Court??s wrote: > > Starting from running 'guix pull' twice and essentially following the section > > 'Building GNU Guix from source (using Guix)' in > > > > https://gitlab.com/pjotrp/guix-notes/blob/master/INSTALL.org#building-gnu-guix-from-source-using-guix > > > > which used to work reliably. It all has to do with the guile upgrade. Even from > > a clean git clone it won't work as expected. > > Apparently I cannot access that page without logging in. For Sorry. I am migrating repositories from github and while gitlab imports even the issue trackers (cool!) it set repos to private by default. Go figure. Fixed access. But don't look at it now, I need to fix the text. > developers, the instructions at > > are still valid, AFAIK. 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. > > Typical errors during build are > > > > Backtrace: > > GUILEC gnu/packages/fcitx.go > > Exception thrown while printing backtrace: > > GUILEC ERROR: gnu/packages/figlet.go > > In procedure public-lookup: Module named (system repl debug) does > > not exist > > Weird. Was it with Guile 2.0 or 2.2? What was on GUILE_LOAD_PATH? I know, can't reproduce it now. > > But I got it somehow to build. guix now lacks a version number: > > > > ./pre-inst-env guix --version > > guile: warning: failed to install locale > > warning: failed to install locale: Invalid argument > > guix (GNU Guix) UNKNOWN > > > > probably because bootstrap never did the right thing. Bootstrap passes, but > > That???s because build-aux/git-version-gen didn???t find ???git??? in $PATH. Git was in the path, for sure. But obviously my system was unsettled. > > ./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 ;) > > And during installation: > > > > ERROR: In procedure stat: > > ERROR: In procedure stat: No such file or directory: > > "/gnu/store/q5kdj7gpawi94pqd15x3wizjq0nx4zhx-python-2.7.13/share/man/man1/python.1" > > During installation of what? 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 # ...] 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-profile-builder"] In ./guix/build/profiles.scm: 133: 8 [build-profile "/gnu/store/2qnn7divxnh5phd1k8sq7g9p29y1vapc-profile" # ...] 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/share/man/man1/python.1" ...] In unknown file: ?: 2 [partition # #] 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. > > In all, the system feels flaky at this point. I wish we had found a > > way of upgrading guile with backward compatibility. Maybe temporarily > > naming it guile2.2 with matching paths would have been better. > > IIUC this does not relate to ???guix pull??? since you???re building from Git. The tooling I am using to build from git is coming from a guix pull. > FWIW I had been running Guix in my checkout with Guile 2.2 long before > this ???guix pull??? transition. It required making sure that all the 2.2 > dependencies were in the environment (not the 2.0 dependencies), but > apart from that that went fine. > > I???m afraid I don???t have enough info to debug the issues you mention here > though. :-/ 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. Pj.