<Emulatorman>mark_weaver:francis7: thanks Andrei Borzenkov, he let us know that we need adjust GRUB_KERNEL_ARM_UBOOT_LINK_ADDR to make sure it matches U-Boot load_addr. it's needed for each SoCs :S <lfam>Hooray for the merge of core-updates \\o/ <efraim>i was about to write a patch to push libgcrypt to 1.6.4, but guix refresh -l lists 901 dependant packages to be rebuilt. Glad I checked that one first <rekado>Could someone please confirm that python-numpy is broken? <rekado>./pre-inst-env guix environment --ad-hoc python python-numpy -E python <rekado>this throws an error: "ImportError: cannot import name multiarray" <civodul>you could check with --pure to be sure <civodul>rekado: i confirm that it works here <civodul>it's Python 3, but with the command you gave, you probably ended up running Python 2 from somewhere else <rekado>it's too bad I cannot yet use GuixSD on this workstation in the office. <rekado>I still have problems with Emacs claiming my user has no home directory. <taylan>am I doing it right by doing 'guix package -p /var/run/current-system/profile -i glibc-locales', then 'ln -s profile/lib/locale/2.22 /var/run/current-system/locale'? or is there a way that won't need me to update the symlink later? <taylan>I set GUIX_LOCPATH in my ~/.profile, but that doesn't affect the substituter processes AFAIUI <civodul>taylan: you can install locales in your profile, forget about the /run symlink hack <civodul>say: guix package -i glibc-utf8-locales ; export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <taylan>civodul: how can I have the substituters pick them up? <civodul>there's a substitute for glibc-locales <taylan>oh I meant the substituter processes launched by the daemon <rekado>civodul: a Guix bug (or maybe a bug in my Emacs configuration exposed by Guix). When I use the Guix-built Emacs (or Guile Emacs) on this Fedora workstation I get an error on the attempt to load my configuration. <civodul>rekado: you need to launch the daemon in an environment with GUIX_LOCPATH set appropriately <civodul>rekado: ah ok, well let us know if it turns out to be a Guix bug <rekado>nscd is not running on this system. I'll see if that fixes it. <rekado>yes, the error disappears when nscd is running. <civodul>rekado: BTW, could you cook us a section on cluster setup in the manual? :-) <xd1le>mark_weaver: ah, looks like you packaged it. <xd1le>so you probably already know, but just fyi :) <rekado>bleh, scipy is broken because it doesn't propagate numpy. <rekado>I think that most python packages that have python* packages as regular inputs are actually broken. <rekado>civodul: it's on my TODO list, but I haven't yet got it to work here. Still waiting for an admin to fix the NFS exports to allow users to modify their own profiles. <xd1le>rekado: I have read the manual, but because I'm a newbie, don't think I <xd1le>fully understand. What is a propagated input, in simple terms? <rekado>xd1le: it's an input that is installed into the same profile as the package itself. <xd1le>so that's what 'force-install' means? <rekado>it's one of those things that I dislike most when dealing with python/ruby/r packages in Guix. <xd1le>so i'm guessing then the headers can be found this way, but otherwise they won't? <xd1le>in the manual it says "force-install", don't know exactly what it means though. <rekado>it's nothing to do with headers. <rekado>in many cases we can get away with patching the path to dependencies, such that they don't have to be in the PATH. <rekado>see for example the recent patch to fix Lilypond. <rekado>but in the case of Python/Ruby/Perl/R packages must all be in a list of directories, such as PYTHONPATH, PERL5LIB, etc. <rekado>I still hope that we can limit propagation to exceptional cases and with brute force patch sources to "import /full/path" instead of just looking up the package name in a search path. <xd1le>so basically a propagated input will be put in the same PYTHONPATH as the package? <rekado>If you install python-scipy which propagates python-numpy, you will have both scipy and numpy in the target profile. <rekado>so you just need to point PYTHONPATH at $profile/lib/python3.3/site-packages <rekado>the union of the outputs of python-scipy and python-numpy will be right there. <xd1le>so what happens if numpy is not propagated? <rekado>"import scipy" will result in an error. <rekado>"ImportError: No module named 'numpy'" <rekado>that's because numpy is not in any of the directories mentioned in the PYTHONPATH. <rekado>to fix this I could run "guix build python-numpy" and add the resulting directory + "/lib/python3.3/site-packages" to my PYTHONPATH; or I could install python-numpy into the same profile. <xd1le>yep, that makes sense. thanks. <rekado>declaring numpy as a propagated input automatically performs the latter. <xd1le>so why do you think it's ugly? <xd1le>i.e. isn't patching the sources arguably uglier? <rekado>it's a bit ugly, because it means that you need to use separate profiles to avoid collisions. <rekado>patching may be ugly for the developers, but it's invisible to users. <rekado>having profile conflicts is a very visible wart. <xd1le>yes good point. actually i imagine it'd be easy to write a script/program <xd1le>to automatically patch the imports <xd1le>at least for python packages... <rekado>we already patch shebangs for shell scripts. <rekado>we might be able to do the same for "import" statements for Python, or for "require" statements in Ruby, etc. <xd1le>yes thanks again. it's been bugging me that i didn't really understand what <rekado>the problem with "require" in Ruby is that it is occasionally used with variables. <xd1le>the wording in the manual isn't too clear imo. <rekado>xd1le: could you point out what exactly is bothering you about the wording? <xd1le>which is when you start going down a rabbit hole <xd1le>basically i guess just using "force-install" <xd1le>it doesn't seem correct to call it "forceful" <xd1le>but then i'm not sure of the alternative. <xd1le>i.e. it just seems like a normal "side-by-side" install, if that makes sense. <xd1le>anyways, it's not a big deal. <toothbrush0>I'm feeling a bit stupid again. My Guix setup was working, but i've just done a `git pull` and now, `./pre-inst-env guix` throws ERROR: In procedure dynamic-link: file: "/gnu/store/zs4jj3h2ndqn5xrng2qsnddl1zils2pc-libgcrypt-1.6.3/lib/libgcrypt", message: "file not found" <civodul>toothbrush0: could it be that that file was GC'd? <civodul>perhaps you need to rerun ./configure so it'll pick the right file name <toothbrush0>but i'm scared of running ./configure since last time i had to provide exotic flags (forget which of course) <toothbrush0>so, the GC Collects not only G but also in-use stuff? *confusion* <civodul>toothbrush0: "head config.log" will tell you what those flags were :-) <civodul>my guess is that the thing wasn't in use, as in there was no running process using it <toothbrush0>and indeed one of the flags was --with-libgcrypt-prefix=/gnu/store/zs4jj3h2ndqn5xrng2qsnddl1zils2pc-libgcrypt-1.6.3 <toothbrush0>i forget why, but a few months ago it was really important i do that? <taylan>toothbrush0: it still is I'm afraid. libgcrypt doesn't use pkg-config. <civodul>actually no, nowadays you can just omit --with-libgcrypt-prefix <davexunit>toothbrush0: oh I see, I misread 'git pull' as 'guix pull' <davexunit>toothbrush0: guix has no way to know that you used that particular configure flag, so 'guix gc' will remove it. <davexunit>remove the store item for libgcrypt that is. <davexunit>civodul: that's a very nice change that makes setting up dev environments easier. <davexunit>'guix environment guix' no longer needs special treatment <toothbrush0>i would've hoped that it'd magically get included in the guix gc root, or something <toothbrush0>does anyone know how Cabal package version constraints are handled? <toothbrush0>i.e. if i package something today, and a dependency gets updated, it's possible the thing i packaged today will be broken <toothbrush0>frequently Cabal dependencies have stuff like package >= 0.6 && package < 0.9 <effa>currently they are not handled automatically in any way. <effa>It's up to the mantainer to check that. <toothbrush0>Hm. This sounds like Cabal dependency hell all over again, but worse: it'll be manual <davexunit>and with guix it is very easy to keep around multiple versions of a package for different pieces of software. <effa>For the key packages, we started by packaging the versions in the "Platform" distribution. <toothbrush0>is this not an exponentially increasing complexity issue? <civodul>doesn't 'guix import hackage' do something with those version specs? <toothbrush0>um, it might get to the point that when somebody wants to upgrade a package somewhere, they'd have to "clone" a whole bunch of other dependencies? <toothbrush0>it's a bit fuzzy in my head, so excuse the accordingly fuzzy explanation <toothbrush0>ah, `guix import hackage`, i'll have to investigate that! :) <davexunit>if the software is incompatible with the version that everyone else is using, yes, we'll need a new package for it. <toothbrush0>davexunit: how are dependencies precise? i see stuff like (inputs .. ("name" ,name)) without versions specified? <davexunit>toothbrush0: that ',name' is a variable reference <davexunit>that package object specifies the version, the source code, and its dependencies <effa>As far as I know NIX did manage the versions of individual packages. However, I believe that recently they stopped doing that because most packages are upward compatible, but the Cabal still sets upper version limits. <davexunit>toothbrush0: in most cases, this is a very good feature. <davexunit>without this, we'd have to upgrade every single package that used a particular dependency. <davexunit>instead, we just alter the package bound to a particular variable and we're done. <toothbrush0>davexunit: but i can see it being tricky since it'll not throw up a warning if i upgrade some library L without noticing that package P depending on it is now broken <davexunit>toothbrush0: it couldn't possibly throw up a warning <taylan>toothbrush0: as long as P it not upgraded, it will refer to the same L <toothbrush0>davexunit: but currently everything looks broken on hydra, no? <davexunit>sorry I have no idea what you are talking about. <taylan>a core-updates merge happened, maybe you saw all the new build tasks that resulted from that? <toothbrush0>davexunit, taylan: i'm looking, but i saw reams of red <davexunit>our build farm frontend is need of upgrading to handle the demand. <mark_weaver>I just restarted postgres and hydra-server, so it was down for a short bit <toothbrush0>yesterday, that led me to believe stuff was severly broken <davexunit>toothbrush0: you are looking at the wrong thing <civodul>the /guix thing should be fixed someday tho <mark_weaver>civodul: when downloading substitutes, I see things like "Downloading vgypka?-linux-libre-4.2.3 (195.2MiB installed)...". Is that "?" supposed to be an ellipsis? <mark_weaver>with UTF-8 locales. I see non-ASCII characters nicely just about everywhere else. <mark_weaver>well, it's not a high priority item obviously, but I wonder if there's a way to make this nicer. <civodul>i changed download.scm in commit fde1783 because of that <davexunit>makes sense that it's the daemon using the C locale <Steap>civodul: oh btw, the Python 2 stuff works well now, cool! <bavier>civodul: ooo, the python2 stuff should help a lot with the 'guix refresh -l' rewrite too <civodul>running "guix graph python2-bandit" led to pretty interesting results before :-) <davexunit>I thought there was some weird 'guix environment' bug the way the report was written. <civodul>it's just the whole approach that was at fault, not 'guix environment' ;-) <davexunit>but that fix reaps rewards all over the stack <davexunit>that's always good, given how starved for resources it is. <rekado>hmm, python-rpy2 fails with "ld: cannot find -lz" --- zlib is in the LIBRARY_PATH at build time, so how can this be? <rekado>oh, never mind, it's overwritten somewhere. <mark_weaver>taylan: does /gnu/store/vgyjrp7cij9h9q77s8kp8gz4arz0xind-bzip2-1.0.6/bin/bzip2 exist? can you run it successfully by hand? <taylan>looks like the whole of /gnu/store/vgyjrp7cij9h9q77s8kp8gz4arz0xind-bzip2-1.0.6 doesn't exist <mark_weaver>taylan: is this guixsd, or guix on top of something else? <mark_weaver>and how are you launching guix-daemon. via a systemd service file? <mark_weaver>if so, does it refer to guix-daemon via an absolute file name in the store? <mark_weaver>taylan: well, I guess you ran the garbage collector, and something wasn't properly protected from GC. <mark_weaver>taylan: and I guess you also updated your root profile since then, right? <mark_weaver>civodul: if a program (e.g. guix-daemon) is running, is it protected from GC? what about the other store items that it contains references for? <taylan>I indeed ran the gc, after temporarily running the daemon with only the build-user-group flag, to make sure nothing unused remains in the store after the core-updates update. and I also did 'guix package -u' with root after pulling master (after the core-updates merge). <civodul>mark_weaver: things referenced from running programs are protected, see nix/scripts/list-runtime-roots.in <mark_weaver>civodul: it seems that something went wrong with that for taylan. <taylan>I can still reproduce the issue after restarting the daemon :\\ <mark_weaver>he ran 'guix-daemon' manually from root's profile (guix on top of debian), and then updated root's profile, and then ran gc, and now the substituter is broken <civodul>the absolute file name for bzip2 is in (guix config) <mark_weaver>civodul: so if you run "make install", does the installed (guix config) still contain the absolute path? will it be registered as a GC root in that case? <taylan>ah, I should perhaps run 'make install' every once in a while? while I use run both 'guix-daemon' and 'guix' from guix profiles, there is also stuff in /var/guix/... after all. (I'm a bit confused, hope that makes sense.) I think I first got the /var/guix from the "drop-in binaries" for other systems a while back. <civodul>mark_weaver: no, it's not registered as a GC root <taylan>(i.e. I run ~/.guix-profile/bin/guix-daemon as root, and ~/.guix-profile/bin/guix as any user, so I usually assume 'make install' isn't necessary, although $XDG_CONFIG_HOME/guix/latest points to the git repo.) <civodul>hopefully that bzip2 is in a profile, so somehow uncollectable <toothbrush0>is there a way to hide the "note: source file .. newer than ...go" messages? <mark_weaver>civodul: but then what happens when the profile is updated? if the reference stored in (guix config) is an absolute filename instead of /home/FOO/.guix-profile/bin/bzip2, there will be trouble, no? <taylan>(FYI, earlier I manually removed a /var/run/current-system/profile but it only contained glibc-locales, so I assume that's irrelevant to the issue) <toothbrush0>rekado: that does make many ";;; ERROR: failed to create path for auto-compiled file "/home/paul/.guix-profile/bin/guild" <mark_weaver>taylan: what do you mean that you "removed a /var/run/current-system/profile" ? I'm not sure why you'd even have such a directory. <mark_weaver>on GuixSD systems, it's in /run/current-system (without the "/var" prefix). on non-GuixSD, normally you wouldn't have that directory at all, except perhaps to work around the locale issues, but then it wouldn't belong in /var/run <taylan>I had one to make substitutor processes see locales, before we got GUIX_LOCPATH <mark_weaver>ah, maybe /var/run and /run are the same directory (due to a symlink) <taylan>oh indeed, Debian's /var/run is -> /run <rekado>toothbrush0: I don't know. I do not see these messages here. <rekado>toothbrush0: permission problem? <toothbrush0>okay. I got rid of them by doing `GUILE_AUTO_COMPILE=0 make`, which so far is looking alright <taylan>when I run 'guix gc -R' for the /gnu/store/...-guix-... which all my users' ~/.guix-profile/bin/guix[-daemon] point to, I get /gnu/store/yq9vkx7f4zw17gs6b09bg4arcgmmjgxn-bzip2-1.0.6. this exists (is different from the one that's looked for). <taylan>this /gnu/store/...guix... doesn't contain any file with the wrong reference, only the reference to the existing bzip2, in its .../share/guile/site/2.0/guix/config.(scm|go). I'm guessing that some old 'config.go' somewhere takes precedence over the config.go there. <taylan>which is perhaps unsurprising since the config.go there is from 1970 :-) <taylan>could it be that config.go didn't use to be in older guix packages, only config.scm, so now I have a config.go in my $XDG_CACHE_HOME which shouldn't be there? yup, I have a config.go for some old /gnu/sture/...guix... there! <taylan>I also remember getting auto-compile messages for config.scm in the past, so I guess that's indeed the issue here. I wonder if this affects all guix users, guix-without-GuixSD users, or just me for some reason. <taylan>mark_weaver: civodul: the issue is fixed after removing $XDG_CACHE_HOME/.../config.go <goglosh>yesterday a package uninstalled for no apparent reason o.O <goglosh>I just reinstalled it but it was strange <taylan>err, my issue isn't fixed after all. there must be another config.go somewhere, if my theory is correct. <taylan>goglosh: how do you mean it uninstalled? if it was removed from /gnu/store, that means it was probably garbage collected because it wasn't installed in any profile. <goglosh>This is what happened. I cannot file it as a bug because I don't know if I'd be able to reproduce it <goglosh>I made a fresh os install and then `$ guix package -i emacs-no-x` <taylan>goglosh: from where was it uninstalled? from your profile? profiles are actually immutable AFAIUI. <goglosh>then I was in emacs looking at the info directory, and I was at the bottom and pressed M-< to get back to the top <goglosh>It got back to the top but it now looked different, the emacs elisp, erc, org, and other manuals weren't there <goglosh>tried navigating into Emacs manual but it didn't find it, so I ran `$ guix package --list-installed` and emacs wasn't there ***davi_ is now known as Guest35802
<goglosh>I did `$ guix package -i emacs-no-x` again and it didn't even have to download anything, as it was in the store already <mark_weaver>goglosh: did you have two "guix package -i" processes running at the same time on the same profile? <mark_weaver>when you modify a profile with "guix package", it looks at the current installed profile and then builds a new profile based on that one. <mark_weaver>so, suppose you start with a profile that contains only "coreutils", and then concurrently run "guix package -i emacs" and "guix package -i bash" simultaneously. <mark_weaver>then there will be two profiles built, one that contains coreutils and emacs, and another that contains coreutils and bash. <mark_weaver>the new profiles are installed atomically, but the one that's finishes last will "win". <taylan>I'm trying to find the config.go that gets loaded by running the daemon with strace, but I guess it's a subprocess that reads the config.go. gotta go AFK for an hour or so now, will continue debugging later. <goglosh>I was reading the source for the iso installer and thought <goglosh>if I made a scm file with an OS declaration <goglosh>as in (define (foo) ...) and use it as a service, the compiled function will be a service? <mark_weaver>goglosh: services can be defined anywhere, including in your OS configuration file, yes. I do that. <mark_weaver>(although services changed recently and now I have to rewrite them) <alezost>ACTION has just finished adapting his services for the new API <taylan>mark_weaver: FYI, seems guix is picking up $XDG_CONFIG_HOME/guix/latest/guix/config.scm (or .go), and running 'make' doesn't always refresh the contents of that (based on config.scm.in). <taylan>I guess this situation doesn't involve any bugs and won't happen to normal users, but I'll post about it on the ML for the sake of documentation... <mark_weaver>davexunit: some of the phases need to be adjusted to the new version. maybe not a big deal, we'll see. <lfam>Trying to corral the bash headers is driving me crazy <lfam>Can someone take a look at bash.scm and help me to alter the install-headers-phase to copy the files from the bash-4.3 tarball's include/ directory into the /gnu/store/...-bash-4.3.39-include/include/bash directory? <lfam>If I don't solve it first <lfam>The bash tarball has a bunch of headers at the top of the source tree, plus a few directories with more headers. The desired action is to copy all the top-level headers into the top-level of the store directory, and to copy the header-directories whole into the store directory. Except for one header-directory (include/) -- the files in this one should be copied into the top-level of the store directory. <lfam>I wonder if this is really "right" but it's what Debian does and it's what recutils expects