IRC channel logs


back to list of logs

<civodul>Hello Guix!
<duncankl>welcome back civodul
<nkar>duncankl: any progress?
<duncankl>still stuck at the same point as before :(
<duncankl>I'm moving to a vm to make testing easier
<Sleep_Walker>can I somewhere specify, which temporary dir should be used for build?
<Sleep_Walker>my yesterday attempt failed on not enough disk space
<Sleep_Walker>I'm also concerned that my /gnu store is not part of /guix FS I'm trying to build...
<Sleep_Walker>(but I hope that simple move of that directory in the end will fix it)
<civodul>Sleep_Walker: no, it always uses /tmp
<civodul>but you can mount whatever you like on /tmp
<civodul>duncankl: i wonder if it couldn't be due to the lack of /dev/mapper/control
<Sleep_Walker>I should probably take the documented approach - unpack tarball and do all in chroot
<civodul>duncankl: something like this:
<civodul>Sleep_Walker: are you trying to build Guix from source?
<duncankl>sounds good, how could I test that change? would it need a new vm image to be built?
<civodul>alternately, you could try that from the REPL, if that's not too inconvenient
<civodul>just the (mknod "/dev/mapper/control" ...) thing
<duncankl>just type in the lines added?
<duncankl>ok, I'll give it a shot soon
<duncankl>civodul: if I enter that snippet into the repl, scope is unbound. Do I need to add the full definition from linux-boot.scm or is there a shortcut?
<Sleep_Walker>civodul: well, yes, my intention was do something similar to debootstrap
<Sleep_Walker>prepare linux root filesystem from another running linux
<Sleep_Walker>I prepared partition for root filesystem, created config.scm and called `guix system init /guix/etc/config.scm /guix'
<Sleep_Walker>I tried it at 3am so I may not be fully conscious though :)
<duncankl>oh wait, looks like /dev/mapper/control already exists. hmm...
<civodul>duncankl: you would replace (scope "...") by "/dev/mapper/control"
<civodul>does it already exist, really?
<duncankl>the error was: "In procedure mknod: File exists", then I tested it with file-exists?
<duncankl>this was after trying to run cryptsetup from the repl
<civodul>oh, but cryptsetup may have created an empty file with that name
<duncankl>try again before cryptsetup?
<civodul>what does (stat:type (stat "/dev/mapper/control")) say?
<civodul>ok, sounds good
<civodul>but cryptsetup still fails in the same way, right?
*civodul searches the Internet for better ideas
<duncankl>same result when /dev/mapper/control is created manually before running cryptsetup
<civodul> mentions other modules
<duncankl>can readline be enabled in the repl btw?
<civodul>that's a very old report, though
<civodul>not really in the initrd Guile, because it's statically linked
<duncankl>oh well, hopefully I won't be in there much longer :)
<civodul>actually i'm unsure: ",use(ice-9 readline)" doesn't work there, does it?
<duncankl>unfortunately not
<duncankl>libguilereadline-v-18, message "file not found"
<civodul>the infamous error message comes from
<civodul>is there any interesting message on tty12?
<duncankl>how do you switch tty in the early boot repl?
<civodul>ah no, very good point :-(
<civodul>well i guess useful messages just go to the console at that stage
<civodul>on my machine with an encrypted home, "lsmod | grep aes" shows a whole bunch of modules
<civodul>aesni_intel ablk_helper cryptd lrw glue_helper aes_x86_64
<duncankl>mine shows: aesni_intel aes_x86_64 lrw glue_helper ablk_helper cryptd
<duncankl>oh yeah, the same
<civodul>so it would be nice to re-install with that list of modules added to the initrd
<civodul>yeah :-/
<duncankl>I'll try adding as many as possible, I know already that aesni_intel causes problems
<duncankl>(mentioned it on the bug report)
<duncankl>but maybe I just didn't have them all so that was the issue
<civodul>duncankl: just replied to your message
<duncankl>oh wow, didn't expect that the order in config.scm would matter
<civodul>yes, that sucks
<civodul>well it's OK when there's just a handful of modules
<civodul>but we're beyond that here :-)
<duncankl>looks like the dependencies go deeper:
<duncankl>lrw: Unknown symbol gf128mul_free_64k (err 0)
<duncankl>if lrw depends on gf128mul, which goes first in the list?
<duncankl>looks like gf128mul goes first, makes sense
<civodul>hmm ok
<civodul>i think i have a plan to handle module dependencies magically, à la modprobe
<duncankl>very glad I switched to a vm, snapshotting saved so much pain
<duncankl>now I'm getting a kernel error that's not very descriptive:
<duncankl>ERROR: In procedure load-linux-module: Unknown error -1
<duncankl>my current module list is:
<duncankl>"dm-crypt.ko" "cryptd.ko" "aes-x86_64.ko" "ablk_helper.ko" "gf128mul.ko" "lrw.ko" "glue-helper.ko" "aesni-intel.ko" "crc32.ko" "pcbc.ko" "xcbc.ko" "sha256-ssse3.ko"
*duncankl afk for a little while
*Sleep_Walker used unshare to move /tmp for builders and feels dirty now
<duncankl>I'm off to sleep, too bad our timezones have minimal overlap :(
<duncankl>next steps are probably tweaking the kernel module list, so many combinations to try
<taylanub>nmap defines make directives like install-nmap, install-ndiff, install-zenmap etc., so I'm thinking of replacing the normal 'install' phase with one that runs e.g. 'make prefix=blah install-nmap', 'make prefix=blub install-zenmap', etc. to separate the outputs; is this a good idea?
<civodul>taylanub: it may be a good idea, but you'll have to make sure that the binaries installed don't record the "wrong" prefix
<civodul>(it's customary to have the configure-time prefix recorded in binaries, via some cpp definition in a .h file, for instance)
<jmd>I'm going from bad to worse.
<jmd>Why would this happen:
<jmd>In execvp of tar: No such file or directory
<jmd>phase `unpack' failed after 0 seconds
<jmd>note: keeping build directory `/tmp/nix-build-make-boot0-4.1.drv-4'
<civodul>the joy of bootstrapping, jmd!
<civodul>does the 'tar' bootstrap binary work?
<civodul>that's on ARM, right?
<taylanub>is there a way I can make 'guix gc' not remove stuff I need to build packages? depends on the packages of course, but e.g. 'gnu-build-system' dependencies would be a start
<civodul>you need to run guix-daemon with --gc-keep-outputs --gc-keep-derivations
<taylanub>neat, thanks
<jmd>civodul: The bootstrap binaries work fine.
<jmd>Execpt possibly the guile one.
<civodul>"In execvp of tar: No such file or directory" means that either 'tar' is not in $PATH, or it is in $PATH but has an invalid ELF interpreter
<civodul>e.g., its ELF interpreter is /lib/, and that file doesn't exist in the chroot
<civodul>normally, the bootstrap binaries should all be statically linked and self-contained, with no ELF interpreter
<jmd>I'm crossbuilding. I have no elf interpreter.
<civodul>i don't have an ELF interpreter either ;-), but what about that 'tar' binary?
<jmd>What about it?
<jmd>This is the build of gcc-cross-armel-linux-gnueabihf-4.8.3
*civodul is confused
<civodul>you did cross-build bootstrap-tarballs successfully, didn't you?
<jmd>I am also confused.
<taylanub>after updating guix (git pull, make, make install) it tends to complain about .../share/guile/site/2.0/guix/config.go being outdated. anyone else have this?
<jmd>It seems that the bootstrap guile is not capable of building guix. Hence I've gone back to the crossbuilding approach.
<jmd>What is it that is trying to exec the non-existant tar. I cannot work it out from the log and the build dir is completely empty.
<civodul>taylanub: yes, but i rarely use "make install"; instead, i use "guix pull" when i have my end-user hat on
<civodul>so to speak
<civodul>jmd: yes, the bootstrap Guile is a statically-linked, hacked-up Guile
<jmd>So make-boot0 is failing in the unpack stage. What is it trying to unpack?
<civodul>so you copied the bootstrap tarballs to ARM, under gnu/packages/bootstrap/arm-xxx
<civodul>you updated gnu/packages/bootstrap.scm to use them
<civodul>and then you tried to ./pre-inst-env guix build foo on that ARM machine?
<jmd>No. Should I have?
<civodul>so what are you doing exactly? :-)
<civodul>i wanna make sure i understand where you are, before making a silly guess ;-)
<jmd> /home/john/guix-armel/gnu/packages/bootstrap/i686-linux has only four binaries.
<jmd>bash mkdir xz and tar
<jmd>I copied the same for arm
<jmd>I'm not exactly sure what you mean by "updated gnu/packages/bootstrap.scm to use them" - I saw the same words in the manual, but I don't know what this means.
<jmd>gtg. Back in about an hour
<jmd>So where was I?
<jmd>civodul: What are the changes I'm supposed to make in gnu/packages/bootstrap.scm ?
<jmd>The manual just says I must edit it to tell guix about the new architecture.
<jmd>What part(s) must I edit? What exactly does it want to know?
<Sleep_Walker>chm, build failure
<Sleep_Walker>guix system: error: build failed: build of `/gnu/store/z9sflbbrfxx7cd4nm81nz88ss1bipb4i-system.drv' failed
<jmd>Anyone know where the build system for make-boot0 is defined?
<bavier>I have a perl package from clan that I need to package whose license is "unknown". do I need to request the author for an explicit license before packaging it?
<jmd>bavier: I would assume that the answer is "yes", since Guix is supposed to be only free software.
<bavier>jmd: thanks
<jmd>Why do we have three gcc versions in guix ?
<taylanub>jmd: many distros offer several GCC releases, though I'm not sure why. or do you mean different builds of the same version?
<jmd>Yeah, but it seems that different things actually depend on different versions.
<civodul>4.8 is the build compiler; 4.9 is the one that users want; and 4.7 is there for "historical reasons"
<alezost>I'm currently on GNU/Guix system and am trying to build guix from git, but ./bootstrap fails with " error: possibly undefined macro: PKG_CHECK_MODULES If this token and others are legitimate, please use m4_pattern_allow." Did I miss to install some tool?
<davexunit>alezost: pkg-config
<davexunit>alezost: 'guix environment guix' will spawn a shell with all the necesary things to build guix
<alezost>davexunit: it is installed
<davexunit>have you set the necessary environment variables?
<davexunit>`$(guix package --search-paths)
<alezost>davexunit: Ah, sure, that's what I forgot; thank you!
<alezost>(those were ACLOCAL_PATH and PKG_CONFIG_PATH)
<davexunit>there we go
<alezost>davexunit: also thank you for reminding about "guix environment", I forgot everything, I think it's time to sleep
<alezost>ouch, that PKG_CHECK_MODULES error is even described in HACKING!! that's enough for today → Zzz
<davexunit>it's all good :)