<lime_>time to destroy this windows install, question is will the gpu be accel by free drivers <lukas__>Is libunistring built with libiconv support by default? <mekeor>lukas__: AFAICS, it depends on your platform: the guix-package for libunistring uses libiconv-if-needed as propagated input. and that means that libiconv is added as propagated-input "for platforms that have an incomplete libc". <mekeor>actually, this probably doesn't exactly answer your question. <mekeor>i think libunistring is built with libiconv support by default by guix. <lukas__>Hmm that's strange. I'm trying to build guile(with tjit support) in x86-64 linux and build fails with libunstring not having libiconv support <lukas__>Is there anyway to force downloading libunstring with iconv support or build it for specific environment? <Apteryx>lime_: chances are that yes, at least for 2D <Apteryx>how can I get the base name of a file-like object? <Apteryx>How are we supposed to find the hash of a git checkout? <laertus>and did a "guix package -i glibc-locales" i got this error: <laertus> /gnu/store/k7029k5va68lkapbzcycdzj7m5bjb4b8-bash-4.4.12/bin/bash: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument <laertus>ok.. i just found this #guix log https://gnunet.org/bot/log/guix/2015-03-24 which mentioned "you definitely cannot link together guix libraries with non-guix libraries into the same process and that also means that LD_LIBRARY_PATH better only include libraries from Guix" <laertus>looks like it's trying to use an old guile i have installed <laertus>i didn't realize i'd need a separate guile apart from what came with guix <lukas__>probably your PATH prioritize your system's guile over guix's <laertus>probably.. but i didn't know an ordinary user needed to set its PATH to anything special <laertus>that's not in the docs either, as far as i can see.. they only mention sourcing root's guix profile <laertus>but thanks.. i'll try messing with my PATH <lukas__>why do you have guile installed in global path tho? <lukas__>thought people use it for embedding lisp into their project <laertus>well, i was using guile before on my OS.. it's something in my OS package manager <laertus>i think some system packages rely on it <lukas__>if you want to play around with repl remove system installed one and install guile on separate environment after you install guix <laertus>i cn't install the system one.. at least not until i fully move on to guix <laertus>err.. i mean i can't uninstall the system one until i fully move on to guix <lukas__>pretty sure my emerge script and python didn't rely on guile last time I used gentoo but <laertus>so until i have those packages from guix i can't uninstall <lukas__>it still sounds strange that your system package installs guile on global path <laertus>there is a guile USE flag for make, so that's not a hard dependency <cbaines>laertus, the guile error seems very odd. Do you have GUILE_LOAD_PATH, or GUILE_LOAD_COMPILED_PATH set? <laertus>cbaines: i don't for the user i'm running guix as.. again, i didn't see such a requirement in the docs <laertus>sorry, for root i had GUIX_PROFILE set, not any GUILE-related env vars <laertus>cbaines: and i take it back.. i guess i do have a GUILE_LOAD_PATH set <laertus>it's just that i didn't set it recently... so i forgot <cbaines>So, if you run guix so that there is no GUILE_LOAD_PATH set, do you still get the weird guile error <cbaines>the one where it appears to be trying to use /usr/share/guile/1.8/ice-9/boot-9.scm <laertus>i presume the "guile: warning: failed to install locale" and "warning: failed to install locale: Invalid argument" are benign <cbaines>yep, I think so, and a little tricky to resolve <laertus>also, i didn't set up substitutes, but guix seems to be using them anyawy <laertus>i didn't want substitutes, because i want to compile all my own stuff ***Guest33228 is now known as sturm
<laertus>or maybe it's just getting the list of substitutes but not using them? <cbaines>did you run the guix archive --authorize step that is given in the binary installation docs? <cbaines>ok, it shouldn't trust any substitute servers then, so it should just download the bootstrap binaries and go from there <laertus>i'm getting some 404's and connections timed out <cbaines>laertus, hopefully, guix has a few options on fetching things which it will try if it gets failures <laertus>it looks like guix is fetching from a bunch of different mirrors <laertus>how does guix know (or does it know) if a file it fetched hasn't been tampered with by one of the mirrors? <laertus>does it have some kind of central checksum or signature registry? <cbaines>laertus, all of the things you'll be downloading will have a known hash, that is specified in the source files <cbaines>on line 234, the expected hash of the tarball is given <laertus>what happens if i interrupt guix during 'guix package -i glibc-locales' ? <laertus>can i restart again without consequence? <civodul>laertus: nothing: it's transactional <laertus>also, i have a zram filesystem that i use for gentoo to compile on <laertus>is there some way i can do the same for guix? <laertus>or if someone could just point me to which temporary directory guix does its compiles in, i could simply try mounting the zramfs over that... <cbaines>laertus, you'll probably see some guix related build directories in /tmp <laertus>yeah, i just did an lsof on one of the guixbuilder processes and found it used /tmp <laertus>is there some way i could tell guix to use a different directory? <civodul>laertus: you can set TMPDIR in the environment of guix-daemon <efraim>actually, its related to grafts, `guix build foo --no-grafts' acted as expected, as shown by `guix build foo -n' <efraim>i forgot the '-n' flag implied --no-grafts <civodul>efraim: you're doing questions & answers :-) <laertus>civodul: i set TMPDIR=/var/tmp/guix in the environment of guix-daemon but while it is using that, it's also still using /tmp <laertus>i'd like to force it to do everything in /var/tmp/guix instead <efraim>with this machine I can eventually try to write an apt-cache-ng server, for when running a "mixed setup" with guixsd and other distros <civodul>normally the "guix-build-" directories end up in $TMPDIR <laertus>civodul: right now, an lsof on one of the guixbuilder process shows: /tmp/guix-build-gcc-5.4.0.tar.xz.drv-0 and /tmp/guix-build-gcc-5.4.0.tar.xz.drv-0/gcc-5.4.0/fixincludes/fixincl.c <civodul>laertus: right, but that's the internal name <laertus>and in my shell i see guix is working on gcc <laertus>you're right.. i see that there's actually nothing in /tmp despite lsof showing that /tmp path <laertus>hmm.. i never realized lsof could be misleading like that <civodul>laertus: it's due to mount namespaces <laertus>this question's not directly guix-related, but you wouldn't happen to know how to get a more accurate view of the real paths a process is using if lsof is misleading like that? <civodul>in theory it should be possible because the kernel has a global view <civodul>(on the Hurd it's not really possible because the file system view is entirely distributed) <cbaines>it's kind of distributed when using linux also, as you'll get a different answer depending on what mount namespace you ask the question in, and relative to <htgoebel>since my last update, bash does not allow line-editing, etc. When stating a bash it errors with: <htgoebel>bash: shopt: no_empty_cmd_completion: invalid shell option name <htgoebel>But according to the manual, this is a valid option. <mekeor>htgoebel: does "shopt -s no_empty_cmd_completion" work? <efraim>civodul: I haven't forgotten, I got distracted when an error popped up and haven't worked on it again yet <Apteryx>What would be a good way to override a single module of guix with my own for testing, such as (gnu services base)? <Apteryx>(My guix install and git checkout don't agree and I don't want to build linux just to test a tiny new procedure added to base.scm) <mekeor>Apteryx: wouldn't that work with the pre-inst-env thing? <Apteryx>mekeor: see my parenthesised addition above :). If I use pre-inst-env it will build many things that I'm not interested in at the moment. So I'd like to do something like this: sudo guix system reconfigure ../guix-config/config.scm -L /gnu/store/zh0lb2g15hirq7zw2477w7s5ww7dxkv0-guix-0.13.0-6.a9468b4/lib/guile/2.2/site-ccache/guix <Apteryx>where the long zh0l... path is my guix pull'd version of Guix. What is missing here is another flag similar to -L which would add a single module in front of %load-*-path <Apteryx>in my case this would be (gnu services base) from ~/src/guix/gnu/services/base.scm <Apteryx>oh, the -L is unnecessary thinking about it more. 'guix' without pre-inst-env does this already. I just need something to force my (gnu services base) in there. <Apteryx>would the "-l" option of Guile help? (load source code from file) <Apteryx>Not sure how to use it from a guix script though. I'd need to hack the guix script shebang... hmm. <ng0>the sample texts are just 1 line always <ng0>which is (probably?maybe?) copyright The Office of the High Commisioner for Human Rights <Apteryx>non-copyleft is a good choice in doubt ***Piece_Maker is now known as Acou_Bass
<ng0>permissions: If UDHR translations or materials are reproduced, users should make reference to this website as a source by providing a link. All suggestions or modifications concerning translations posted on this website can be sent to hredatabase@ohchr.org. <htgoebel>mekero: shopt -s no_empty_cmd_completion doe not work <fredmanglis>Hi. I just did a `guix pull` and now the `guix package --install=...` command give no output, but does not die either <mekeor>hmm. how long did you wait?, fredmanglis <civodul>fredmanglis: i haven't experienced this, sounds weird <civodul>fredmanglis: could you check which process is spinning? <fredmanglis>civodul: Well, op indicates that .guix-real is the one running <civodul>fredmanglis: could you check its arguments? <civodul>where 1234 is the PID of that process <efraim>I've had that before when I was working some grafts <fredmanglis>/gnu/store/yihvhxv3xyyvl1m2cy1lnf1lyi9h76fk-guile-2.2.2/bin/guile--no-auto-compile/gnu/store/7m239pi63wf3naj1g26b4253ykibjw5k-guix-0.13.0-5.228a398/bin/.guix-realpackage--install=python-pycosat--profile=/tmp/test_profile <efraim>Is that --install=python-pycosat and --profile=/tmp/test_profile? <fredmanglis>efraim: Yes. I was creating a throw-away profile for now. <fredmanglis>the --no-grafts option seems to be working... There's output now. <efraim>DNS/connection problems to one of the substitute servers? <efraim>iirc there's no timeout set on those connections <civodul>fredmanglis: could you do without --no-grafts again, and strace the thing? <civodul>"strace -o log guix package -i python-pycosat" <civodul>make sure to C-c hit before it eats your hard disk :-) <civodul>let's see, could you paste it somewhere? <civodul>fredmanglis: hmm it's hard to tell what it's doing towards the end <civodul>does --no-substitutes make a difference? <fredmanglis>I havent't tried that... I tried doing an --upgrade, and the same issue came up, so I did --upgrade --no-grafts --fallback <civodul>fredmanglis: --no-grafts removes critical security updates though, so you don't want to use that in production <fredmanglis>Oooh... My understanding of it was incomplete - for some reason, I thought it would build the entire thing from scratch, including the updates... <thomassgn>Anyone here in Madrid and want to meet with another guix user? <fredmanglis>civodul: --no-substitutes doesn't seem to be making any difference... <fredmanglis>I think I might have broken my guix installation by the pull. Now to try and figure out how to fix it <dvn->hi. I installed guix for the first time in many months, and I am getting a couple tls related errors now <dvn->When I run `guix pull` I get this: warning: TLS 'SERVER NAME' extension not supported <dvn->ERROR: X.509 server certificate for 'git.savannah.gnu.org' does not match: CN=bzr.savannah.gnu.org <lfam>Ironing out the kinks in the go-build-system, I realize I don't fully understand something. The following build phase does not print "FAILED" when the Go build command fails: http://paste.lisp.org/+7NCG <lfam>But, the build phase does fail, causing the derivation build to stop <lfam>So, I think this code still has a ways to go :/ <bavier`>lfam: the derivation stops in that 'build' procedure, or elsewhere? <elc79>hi guys, guix pull was quick, but guix system reconfigure it's very slow, it's building a lot ot packages <lfam>bavier`: The build phase fails and the whole thing stops <elc79>in fact it's building essential packages like parted, networkmanager, etc. <bavier`>lfam: does "go" in fact return a nonzero exit status? <lfam>bavier`: Good question. I think so but I'll confirm <bavier`>I've had to deal with naughty programs that don't do that <lfam>It does print "exit status 1" but I'd better triple-check :) <lfam>I'm running my test now, but I think it must return non-zero, because the build phase does fail, and not due to a Scheme error <lfam>I see some other build systems using apply, as in: (unless (zero? (apply system* command)) (error "'zip' failed")) <lfam>I don't understand the significance of apply here <lfam>Right, I saw that in the preceding code <lfam>My issue is that I don't really understand what apply is for, in general <bavier`>lfam: (system* command) wouldn't work, because system* doesn't know how to operate on a single list argument <bavier`>lfam: so 'apply' applies system* to the list elements, where each list element becomes an argument <lfam>Okay, so it's "unpacking" the list? Sort of similar to unquote-splicing? <bavier`>yeah, unfortunately the guile manual isn't helpful in explaining apply at the abstract level <lfam>Yeah, it's very lightly documented there. That's okay, I often find myself referring to manuals of various Scheme implementations <bavier`>lfam: but I think sicp has a great discussion of 'apply' as a pillar of scheme :) <lfam>I'd better read that book one day :) <lfam>I suppose it's not helpful to use (zero? ...) while debugging this <bavier`>lfam: could you simulate failure in an interactive environment, just invoking "go install" in a way that will definitely fail? <lfam>I'll try again without (zero? ...) <elc79>how many tests have to pass parted build? <lfam>elc79: I'm not sure. If you are worried about building for too long, you might wait a few hours for us to build the binary substitutes <bavier`>lfam: "$?" won't have the exit value in this case, since system* doesn't invoke a shell <elc79>lfam, i started guix system reconfigure 6 hours ago <lfam>elc79: Wow! While it's running, you can re-run the command in another terminal with '--dry-run' to find out how many packages it wants to build <elc79>guix system reconfigure --dry-run? <lfam>elc79: Add --dry-run to whatever command you used before <elc79>haha parted build has completed, now it's time for grub :-p <lfam>elc79: I noticed yesterday you said that GRUB failed to build for you. If that happens again, please give us the details <elc79>it failed before guix pull, i hope this not happen now :-) <lfam>bavier`: I think that `go install` must be returning a non-zero exit code, because how else could the build phase fail? <bavier`>lfam: that should be the only way, yes. <lfam>I think I'd better ask for help on the ML :) <bavier`>"unless" is often mental molasses for me <bavier`>lfam: is an undefined value triggered as a phase failure? <lfam>bavier`: They are the same thing but reversed, right? <lfam>I want to run the first command and, if it fails, run the second command <elc79>i can't make an output of guix system reconfigure to a text file with >> <elc79>but i saw a lot of packages to build <lfam>elc79: Probably you need to redirect the standard error stream in addition to the standard output stream. `guix system reconfigure /path/to/config.scm >file 2>&1` <lfam>bavier`: Do you mean an undefined Scheme value? I think so, but when I've noticed that sort of mistake, I get a Guile backtrace. I'm not seeing that here <bavier`>I ask because the unless sexp here does not return a value <bavier`>lfam: you could pass the truthiness out with something like (or (zero? (system* ...)) (begin (display "FAILED")(newline) #f)) <elc79>lfam, it worked, now i see 107 packages to be builded O_o <lfam>elc79: Okay, so you can either build them yourself, or wait a little while we build them on the build farm, after which you can download them <bavier`>elc79: some of those "builds" might be grafts <lfam>I thought that --dry-run did not include grafting derivations <lfam>The manual doesn't specify <elc79>lfam, if i see the grub build not fails i will be happy :-) <elc79>in other terms this is not different from Gentoo, compiling, compiling, and when you are so tired of compilings then you have more compilings :-) <lfam>nee`: If it works as bz2, could it be a bzip2 archive instead of a zip archive? <nee`>I mean I unpacked it and repacked the folder contents <lfam>bavier`: I tried your (or (zero? ...) (begin ...)) construction, but it still doesn't print anything from within the (begin ...) in case of failure :/ <lfam>Unfortunately, I have to go for a while. I'll keep working on this later <elc79>grub build test phase is here, that was problem yesterday <efraim>nee`: is it a tarbomb? As in, is there a top level folder? <nee`>efraim: it's not a tarbomb, on the top layer it's just one folder in a zip. <nee`>There is also not any output just: <nee`> starting phase `unpack' <nee`>phase `unpack' failed after 0.0 seconds <bavier`>nee`: you need to add "unzip" as a native-input <nee`>bavier`: Thank you, that works! <nee`>Weird, I don't remember doing this before and I thought I packaged things that came in zips previously. I guess I should I submit a bug, because of the lacking error message. <elc79>grub build is done! i feel like Michael Schumacher when he finally won his first championship with Ferrari :-D <cbaines>elc79, you should make sure to enable substitutes from berlin.guixsd.org if you haven't done so already, as I think that is helping with the substitutes situation <elc79>i enabled yesterday but i didn't use this substitutes <lukas__>After creating build environment with guix environment command, what would be the preferred way of adding extra packages to it? <bavier`>lukas__: I usually just exit the subshell and invoke 'guix environment' again <bavier`>lukas__: you might be able to 'guix package -p $GUIX_ENVIRONMENT -i ... && source $GUIX_ENVIRONMENT/etc/profile' <lukas__>hey bavier. So you just set everything up from the scratch? <bavier`>lukas__: yeah, usually doesn't take long, since the previous environment's store items are still available <lukas__>bavier` : I know setting up new environment wouldn't take up that much time (thx to package cache) but my build failed only at the last moment and I would really love to salvage the current environment <lukas__>my machine is pretty weak (dual core 2.8 Ghz) so rebuilding everything from scratch sounds painful :( <lukas__>bavier` : guile branch with tracing jit support <lukas__>building libguile doesn't take long but precompiling contents of ice-9 and bootstrapping procedure took some long time for me <bavier`>lukas__: you wouldn't need to rebuild those things, I think <lukas__>guess I'll try what happens in new environment. I'm new to guile and its internal so not really sure how guile utilize all these .go shared objects