IRC channel logs


back to list of logs

<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
<Emulatorman>s|thanks|thanks for
<civodul>GRUB on ARM would be neat
<civodul>ACTION -> zZz
<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
<civodul>Hello Guix
<rekado>Could someone please confirm that python-numpy is broken?
<rekado>./pre-inst-env guix environment --ad-hoc python python-numpy -E python
<rekado>import numpy
<rekado>this throws an error: "ImportError: cannot import name multiarray"
<civodul>ACTION tries
<civodul>you could check with --pure to be sure
<rekado>oh, right. I'll do that.
<rekado>okay, it's my fault. Phew!
<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>right, that's what happened
<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>rekado: a GuixSD bug?
<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>(i assume you're not on GuixSD)
<civodul>the locales?
<civodul>there's a substitute for glibc-locales
<civodul>x86_64-linux at least
<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
<rekado>taylan: ^^
<taylan>I see
<civodul>rekado: ah ok, well let us know if it turns out to be a Guix bug
<rekado>oh, seems like this was the last message on that bug report:
<rekado>nscd is not running on this system. I'll see if that fixes it.
<rekado>yes, the error disappears when nscd is running.
<rekado>I'll reply to the bug report.
<civodul>rekado: BTW, could you cook us a section on cluster setup in the manual? :-)
<xd1le>hi guix
<xd1le>so there's a new icecat release now:
<xd1le>as in a major version
<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.
<xd1le>i'm reading this:
<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.
<xd1le>yes that's what i thought
<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.
<xd1le>ah i see.
<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>i think this makes sense.
<xd1le>yep, that makes sense. thanks.
<rekado>declaring numpy as a propagated input automatically performs the latter.
<xd1le>a lot.
<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.
<xd1le>yes of course
<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.
<xd1le>yes i know
<xd1le>there's a whole phase
<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
<xd1le>that meant.
<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.
<xd1le>yes exactly..
<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"
<rekado>ACTION goes afk for a while
<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>Hello all!
<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>hey, toothbrush0!
<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>ah! i did indeed run a GC, thought that was safe
<toothbrush0>(also, hi civodul :) )
<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*
<davexunit>it shouldn't do that
<civodul>toothbrush0: "head config.log" will tell you what those flags were :-)
<davexunit>ACTION upgrades his profile and system
<civodul>my guess is that the thing wasn't in use, as in there was no running process using it
<toothbrush0>indeed i just discovered config.log
<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'
<civodul>it'll pick up the right thing
<civodul>yeah, progress! :-)
<taylan>neat :)
<toothbrush0>ah, okay, yay!
<toothbrush0>brb configging then!
<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.
<toothbrush0>davexunit: yeah, fair enough
<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>civodul: okay, looking good, no more error!
<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.
<davexunit>it's not.
<toothbrush0>is this not an exponentially increasing complexity issue?
<civodul>hey, howdy effa
<davexunit>toothbrush0: I don't understand.
<civodul>doesn't 'guix import hackage' do something with those version specs?
<davexunit>in guix, all dependencies are precise.
<effa>civodul: Hi :-)
<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?
<toothbrush0>(very stupid question alert)
<davexunit>toothbrush0: that ',name' is a variable reference
<davexunit>to a package object
<toothbrush0>but that object might change in the future, right?
<toothbrush0>breaking somehting that depends on it
<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.
<toothbrush0>effa: good to know.
<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
<toothbrush0>so, a double-edged sword?
<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>not if someone does a fresh install
<davexunit>toothbrush0: this is what CI is for.
<toothbrush0>unless i'm misunderstanding something, taylan
<toothbrush0>davexunit: but currently everything looks broken on hydra, no?
<toothbrush0>that's good news
<toothbrush0>yesterday it did
<toothbrush0>(to my untrained eyes)
<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
<toothbrush0>just a sec
<toothbrush0>hm, okay, now it's just 502'ing
<davexunit>hydra is overloaded right now
<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
<mark_weaver>please try again
<toothbrush0>mark_weaver: roger
<toothbrush0>better :)
<toothbrush0>davexunit: here,
<toothbrush0>that's saying success 0%
<toothbrush0>yesterday, that led me to believe stuff was severly broken
<civodul>guix -> success 200%!
<davexunit>toothbrush0: you are looking at the wrong thing
<toothbrush0>davexunit: egg on my face
<toothbrush0>okay, that looks less pessimistic indeed.
<davexunit>it's okay, easily confusable.
<civodul>the /guix thing should be fixed someday tho
<toothbrush0>what was it supposed to refer to? the guix binary?
<civodul>Guix itself
<civodul>i.e., building Guix from source
<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>this is when running from within emacs shell mode.
<civodul>but the daemon runs in the C locale
<mark_weaver>with UTF-8 locales. I see non-ASCII characters nicely just about everywhere else.
<mark_weaver>ah, okay
<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
<civodul>but guix-devel is behind
<mark_weaver>ah, okay
<davexunit>ah yeah I see that ? stuff a lot
<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>ah, cool!
<civodul>running "guix graph python2-bandit" led to pretty interesting results before :-)
<bavier>I can imagine
<davexunit>nice use of memoize!
<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>so yay!
<civodul>and less work for
<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.
<taylan>anyone encountered something like yet? I pulled master and updated everything earlier today.
<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?
<taylan>guix on Debian
<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?
<taylan>I run this from rc.local, or manually as root (after 'sudo -i') when restarting the daeomn which I did earlier today:
<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?
<mark_weaver>(I'm guessing "no")
<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).
<mark_weaver>taylan: time to restart your daemon
<civodul>mark_weaver: things referenced from running programs are protected, see nix/scripts/
<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>taylan: how was Guix installed?
<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.
<taylan>s/use run/run/
<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?
<rekado>toothbrush0: by compiling.
<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?
<rekado>toothbrush0: e.g. run "make"
<toothbrush0>rekado: okay, thanks!
<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"
<toothbrush0>" messages, is that a problem?
<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)
<mark_weaver>anyway, it should be irrelevant to this issue, yes.
<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
<toothbrush0>rekado: hm, perhaps. i'll have a look a bit later.
<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>taylan: no it wasn't GCd
<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?
<goglosh>.... perhaps
<goglosh>I probably did
<goglosh>do they interfere?
<mark_weaver>okay, that explains it
<goglosh>didn't know that
<goglosh>well now I know :)
<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.
<goglosh>pure functional of course
<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.
<Bliss`C>how to install i3wm in guix
<mark_weaver>Bliss`C: the package is called 'i3-wm'
<goglosh>In have another question
<Bliss`C>thank you!
<goglosh>I was reading the source for the iso installer and thought
<goglosh>if I made a scm file with an OS declaration
<goglosh>and defined a service in that file
<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)
<davexunit>ACTION needs to learn the new service API
<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
<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>ACTION works on updating to icecat-38.3
<davexunit>happy to see that it was finally released.
<mark_weaver>me too
<mark_weaver>this is going to be a bit of work...
<davexunit>what has changed to make it more difficult?
<mark_weaver>davexunit: some of the phases need to be adjusted to the new version. maybe not a big deal, we'll see.
<mark_weaver>hi corriera27!
<corriera27>no hablo inglis
<davexunit>no hablo espanol. lo siento.
<corriera27>y como estas escribiendo
<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