can't get past commencement in test-env
gcc-boot0 in (gnu packages commencement) compiles subtly differently when built in a chroot (for example, by an installed daemon) compared to when built without root privileges (for example, in test-env). Specifically, the presence of this line in the build log: ../../gcc-5.5.0/gcc/genmultilib: ./tmpmultilib: /bin/sh: bad interpreter: No such file or directory This doesn't get caught by the patch-shebangs or patch-generated-shebangs phases because tmpmultilib is both generated and immediately executed by genmultilib in order to, I kid you not, implement recursion in a portable manner by having tmpmultilib run itself. Somehow this works out in the chroot case despite it failing to run, but in the non-chroot case /bin/sh actually exists, at least on Guix System. This ultimately causes two different compilers to be created in the two cases. In the chroot case, 'g++ -print-multi-os-directory' simply gives .; while in the non-chroot case, it gives ../lib64 This means that when the bootstrap continues, libstdc++ is built with its outputs going to different locations (lib/ or lib64/) depending on which of the two compilers builds it. gcc-final assumes it will be in lib, and so it can't find it if libstdc++ was built with a gcc-boot0 built without a chroot. I don't know much about multilib stuff, but it would seem that the "correct" output from gcc's perspective would be one in which its contemplation of the matter isn't interrupted by a "bad interpreter" error. But that's also the opposite of the assumptions we currently make, and changing it would require both rebuilding the world and modifying several packages. At the same time, I'd like to be able to test building derivations in test-env without needing to run it as root (and modifying test-env slightly to remove the --disable-chroot, and choosing between running all those builders as root (yikes) or risking interfering with my installed daemon by using the same build group). I'd also appreciate it if others could test building packages in test-env easily, as it catches an entire class of errors that usually isn't caught otherwise (typically errors caused by assumptions about where the store is). The same issues that plague test-env will also occur in an unprivileged install. What is The Right Thing™ to do here? - reepca
Re: guile-ssh requirement on core-updates
It would also be nice to add lzlib and pkg-config to the list of requirements: @@ -27,7 +27,9 @@ GNU Guix currently depends on the following packages: - [[https://notabug.org/guile-sqlite3/guile-sqlite3][Guile-SQLite3]], version 0.1.0 or later - [[https://gitlab.com/guile-git/guile-git][Guile-Git]] - [[http://www.zlib.net/][zlib]] + - [[https://www.nongnu.org/lzip/lzlib.html][lzlib]] - [[https://savannah.nongnu.org/projects/guile-json/][Guile-JSON]] + - [[//www.freedesktop.org/wiki/Software/pkg-config][pkg-config]] Unless `--disable-daemon' was passed, the following packages are needed: - On Aug 10, 2019, at 9:21 AM, dftxbs3e dftxb...@free.fr wrote: > Hello, > > Now guile-ssh is required to compile GNU Guix (at least on > core-updates), but it's not specified in > https://git.savannah.gnu.org/cgit/guix.git/tree/README?h=core-updates > > I suggest it gets added to avoid confusion to people who compile GNU > Guix without having GNU Guix already and having the ability to run `guix > environment guix`. > > Thank you -- `~Eric
Re: We need your feedback of the documentation videos!
Hi! We now have https://guix.gnu.org/install.sh. You are free to use it. > Uhm I am getting a 404 for this link :/ > > Can you tell me how to reproduce this? Prehaps it’s a problem with our > scripts? > I am attaching the cliSession file (cannot copy/paste it here, it gets broken). You have to generate the cli video, inside the root video directory, with ` ./create-cli-video.sh 01-installation-from-script en_US firstCli 1`. I get question mark symbols instead of the logo, that is why I changed it for *s. Don't pay attention to the mismatch between the audio and the video, it is something to solve later. > > It is confusing, because the user is not supposed to execute the “yes” > command but just to answer “yes” to the question — on the same line. > OK, I removed the #, the 'yes' is still in a newline, is that too bad? > > I’d prefer either a simple ellipsis (“…”) or the actual console output. > OK, will change it for that :) As regards what Tobias said: "- 01:25 ‘The output tells us the signature is good.’ This made me chuckle: in typical GPG fashion, everything in its output implies the opposite unless you're already familiar with it. I realise it's far too late to touch the audio. Could we highlight ‘public key … imported’ after half a second or so? I don't know if the scripts allow easy highlighting of output text like that." Yes, unluckily we should record again the audio to change that. There is still work to do regarding colouring the output. I don't know what the others would like to do (if publishing the videos with the output as it is, or waiting until improving that) Regards :) Laura firstCli Description: Binary data
