IRC channel logs


back to list of logs

***anthk_ is now known as anthk
<davexunit>this bootstrap bash business is killing me
<davexunit>I mount the thing at /bin/sh in the container, but (system) returns #f, meaning that something is not working
<davexunit>is the bootstrap bash incapable of being used as a command processor? seems unlikely.
<davexunit>ah, I think I found the issue.
<davexunit>the guile process running in the container uses a different shell to make the 'system' calls
<davexunit>I think we need to stop using 'system' and start using 'system*'
<davexunit>but how to make that syntax work in the 'guix environment' command-line syntax is beyond me.
<davexunit>guix environment --ad-hoc guile -- guile -c '(display "hello\\n")'
<codemac>My rc shell religion is tingling
<codemac>davexunit: is the concern about splitting arguments correctly, thus the -- to signify more? I think it's the right way to go, it's how many other programs handle this.
<civodul>Hello Guix!
<mthl>Hello civodul!
<civodul>i wonder how 'guix graph' could take advantage of
<civodul>maybe by grouping nodes by source file name (for '-t packages')
<rekado>I found that some python modules don't work (any more?). All those that install just egg archives along with pth files can no longer be imported.
<rekado>One example is h5py.
<rekado>The fix seems to be to patch to use distutils.core rather than setuputils.
<rekado>the result is that no egg archive is produced but an inflated directory containing source files.
<rekado>I wonder if this is indicates a problem with our python-build-system.
<civodul>rekado: isn't it an instance of ?
<civodul>i fixed it for python-pillow but i'm sure there are many packages hit by this bug
<rekado>I don't know if this is related. It's not so much about references being dropped (I think), but about Python complaining that it doesn't know how to import the library.
<rekado>other libraries could be coerces to forego building the egg and just install the source files directly.
<rekado>right now with h5py I get this error on import: "ImportError: No module named pkg_resources"
<rekado>but I'll try the same fix that you used for python-pillow. Let's see if this works.
<rekado>no, this doesn't work :(
<rekado>as of version 0.6.1 "zip_ok" defaults to False, according to the setuputils documentation.
<rekado>in the case of h5py the solution is to just not have setuputils in the native-inputs.
<civodul>rekado: ok, good to know
<civodul>probably the importer needs to be fixed as well
<civodul>because i think it adds setuptools by default
<rekado>(gah, why do I always write "setuputils" when I mean "setuptools"?)
<rekado>in the case of h5py the script tries to load "setuptools" first and only when this fails uses "distutils", which results in no egg archive to be built.
<rekado>I'll send two patches to the ML that fix h5py. The only controversial part might be the commit message.
<rekado>Sent out the patches. I'd be happy for a review.
<civodul>rekado: done!
<rekado>civodul: thanks! I sent another email shortly after the first containing the second patch that I forgot to add in the first email.
<rekado>pushed the fixes for h5py.
<davexunit>civodul: turns out that srfi-37 doesn't distinguish between operands before and after the '--' token.
<davexunit>SHA-1 collisions found.
<civodul>not a second preimage though
<civodul>so it's still better than MD5 :-)
<davexunit>civodul: :)
<davexunit>my knowledge of cryptographic hashing is weak. I don't even know what a preimage is.
<civodul>oh this article mentions that md5 is not as bad as i thought
<davexunit>civodul: guess we need to organize GuixConf!
<alezost>There is "The sorry state of Python packaging and how it reflects in Nix" there :-) no sign of Ruby though
<davexunit>Ruby is even more sorry than Python!
<davexunit>and Node even sorrier!
<alezost>why is Nix logo made of "λ"-s?
<remi`bd>alezost: because it’s a “functional package manager” with the same “functional” as “functional programming”, and lambda (λ) is kind of a symbol for functional programming.
<alezost>remi`bd: thanks, I should have guessed
<civodul>davexunit: yeah i know, i was invited as a Nix* contributor :-)
<civodul>i'm a bit jealous i must say ;-)
<davexunit>yes, of course. they have seen a lot more growth.
<civodul>in particular i've seen it grow noticeably since i left
<civodul>i don't know if there are conclusions to be drawn ;-)
<taylanub>[something about a possibly inverse relation between quality and popularity] :P
<taylanub>Nix just downloads binaries for some things, right? that's just Not OK...
<rekado>it sure makes things a lot easier when it comes to Java. But this comes at the loss of "practical software freedom".
<mark_weaver>civodul: problem on core-updates:
<mark_weaver>results in about 1200 dependency failures
<civodul>mark_weaver: thanks for the heads-up
<civodul>i wonder what happened
<paroneayea>you can tell a project is cool if its logo has lambdas in it, right? ;)
<paroneayea>ACTION says this joke, having contributed a logo to a project built out of lambdas
<civodul>oops i messed up with my branches, commit 14f8dae shouldn't have been there
<civodul>mark_weaver: i reverted the offending patch and asked for a new evaluation of core-updates
<civodul>sorry for the mess!
<civodul>paroneayea: which project was it? :-)
<paroneayea>civodul dropped off, but Hy
<paroneayea>sneek: later tell civodul I made the initial lambda in parens logo for that, it's a bit more refined now tho
<sneek>Will do.
<davexunit>hmm, looks like we never changed our git-download method to use shallow clones
<efraim>to build an out-of-tree package i do ./pre-inst-env guix package -f file.scm ?
<paroneayea>davexunit: sorry, I wanted to work on deployment in guix stuff this week and promised that while in boston, but basically the federation work we're doing is being pseudo-threatened... I have to hack up some stuff to push the standards forward
<davexunit>paroneayea: no pressure from me. take care of urgent work. :)
<davexunit>good luck!
<davexunit>efraim: yes, that is one valid way.
<alezost>efraim: nope, "guix package -f" is to install, not to build
<davexunit>sorry, I read 'install' not 'build'
<davexunit>efraim: I need to write 'guix build -f', but for now you can do it long-hand: guix build -e '(primitive-load "file.scm")'
<alezost>in emacs (with guix-devel-mode) it is possible to "C-c . b" to build the current package using a Geiser REPL
<efraim>davexunit: thanks
<efraim>alezost: i'm actually not using emacs, haven't gotten into it yet
<davexunit>alezost: that's awesome
<efraim> guix build -e '(primitive-load "file.scm")' didn't work for me :(
<efraim>...and now i'm going to check that I didn't mess up writing my package
<davexunit>efraim: well, is file.scm a file in the current directory?
<davexunit>is the last expression in that file a package expression?
<efraim>started with video.scm as a template
<davexunit>my guess is that you don't have a package expression at the end of the file
<davexunit>and you probably define a guile module
<davexunit>which you don't want
<efraim> minus the (c) at the top
<davexunit>okay so both problems are present
<alezost>davexunit: thanks
<alezost>efraim: perhaps you just want to add that file to GUIX_PACKAGE_PATH and build in a usual manner
<davexunit>1) you aren't using this file as a module, so remove the module stuff and import modules you need with 'use-modules'
<efraim>my plan B was to just have a branch with my own packages insterted
<davexunit>2) the last expression isn't a package expression, it's a variable definition expression, whose return value is unspecified
<ngz>Hmm I can't compile csound after guix pull && guix package -u. I get "ld: CMakeFiles/csound-bin.dir/csound/csound_main.c.o: undefined reference to symbol '_ZGVcN4vv_pow@@GLIBC_2.22'". Any idea about what is wrong?
<efraim>i think the problem is csound. It hasn't compiled correctly since at least september 26th
<efraim>actually it looks like it might have never built correctly on x86_64
<ngz>It definitely built correctly at some point since I could update guix. Maybe not the 6.05 version though.
<efraim>it builds correctly on i686, armhf and mips64el
<ngz>Apparently, -lpthread needs to be moved at the end of the command line.
<civodul>in general one should use "-pthread" (both CFLAGS and LDFLAGS) rather than "-lpthread"
<sneek>civodul, you have 1 message.
<sneek>civodul, paroneayea says: I made the initial lambda in parens logo for that, it's a bit more refined now tho
<civodul>paroneayea: oh, i remember now; that's fun!
<ngz>civodul: To tell the truth, I don't know either -pthread or -lpthread. I'm just trying to find solution to the csound problem.
<civodul>i wasn't sure if my comment would be helpful ;-)
<ngz>Now, you know :)
<civodul>the error is " error adding symbols: DSO missing from command line", right?
<civodul>that's a libc 2.22 goodie
<civodul>(so to speak)
<ngz>So, would you happen to know what can be done about it?
<civodul>looks like there's a missing "-lm" on this command line
<civodul>same command line on i686, but no problem there
***francis7 is now known as francis
<civodul>that's because there's no libmvec on i686
***francis is now known as francis7
<mark_weaver>civodul: I have a vague recollection of you changing offloading to use gzip instead of xz, to reduce the load on hydra, but hydra seems to be using xz
<mark_weaver>is this expected?
<civodul>mark_weaver: yes it uses gzip when compressing, and xz to uncompress stuff received from build machines
<civodul>it's unclear to me what's causing the high load currently
<mark_weaver>ah, okay
<civodul>'top' says the machine is somewhat idle
<mark_weaver>yeah, I'm not sure either. I already stopped the evaluator.
<civodul>yet the load is very high
<mark_weaver>the hydra-server processes seem bloated up. maybe time to restart them.
<civodul>i wonder if /proc/loadavg accounts for other stuff on the Xen thing
<mark_weaver>I'll try
<civodul>i wonder if there are Xen commands that could allow us to know what's going on on the physical machine
<mark_weaver>good question. dunno!
<codemac>/proc/stat's last 3 numbers are steal, guest, and guest_nice
<codemac>steal is how much time has been spent on OSs
<codemac>*other OSs
<mark_weaver>civodul: restarting hydra-server seems to have helped a lot. the load dropped from about 20 to about 10
<mark_weaver>and still dropped
<mark_weaver>still dropping
<mark_weaver>ACTION goes afk
<civodul>mark_weaver: great, thanks!
<civodul>codemac: on the "cpu" lines?
<civodul>thanks for the tip
<codemac>yeah, it's been really useful on ec2
<codemac>guest / guest_nice are when Linux is the hypervisor
<civodul>steal/guest = 1% here
<civodul>so i guess we're good
<codemac>yeah, usually it's not what you expect. Not to mention load values in general spike up during I/O load along with compilation load merely because it makes scheduling queues longer as they wait for r/w's to come back
<codemac>it doesn't actually mean your cpu is backed up.
***davi_ is now known as Guest79609
<Steap>Wasn't there a Guix package for Fedora, once upon a time ?
<gp5st>sorry if this is covered somewhere and I didn't understand. Do guix packages have install scripts that run or does it simply describe dependencies and the package's files?
<civodul>not sure
<civodul>Steap: ↑
<civodul>gp5st: you mean packages themselves or package recipes?
<civodul>Steap: ?
<gp5st>civodul: a final package I would install on my machine. I was just curious if package installs were fully deterministic
<gp5st>(that's the word I've been searching for!)
<civodul>gp5st: installing a package does not modify anything on the system, except the ~/.guix-profile symlink
<civodul>so it's "deterministic" in that sense
<gp5st>civodul: other than downloading and placing the package's files on disk (sorry to be pedantic)?
<Steap>civodul: oh, nice
<Steap>civodul: doesn't seem to be part of Fedora though
<Steap>not sure what copr is, exactly
<Steap>Who's Ting-Wei Lan ? The name does not ring a bell
<civodul>gp5st: yes, right
<gp5st>civodul: awesome :)
<civodul>gp5st: there's an overview at
<civodul>Steap: dunno; you're the Fedora expert here :-)
<Steap>civodul: yeah I started writing a package so my coworkers could easily try Guix
<Steap>and also because there might be Fedora users at PyConFR
<Steap>but this is quite a pain
<Steap>though it's better than Debian's packaging
<civodul>yes, that's my impression
<Steap>(also I'm compiling on a one-core VM, so it's slow)
<civodul>did you try the binary install?
<Steap>why would I want to do that ?
<Steap>I think Fedora people would rather have maintainers compile their stuff
<civodul>yeah sure
<civodul>but i mean, the binary install is quite simple
<Steap>can you easily uninstall ?
<civodul>rm -rf /gnu /var/guix /etc/guix :-)
<Steap>That is outside of the scope of "simple uninstallation"
<Steap>people want to do "dnf install" and "dnf remove"
<civodul>that is *not* simple
<Steap>not have to see where files have been added, etc.
<Steap>yeah ;)
<Steap>civodul: dnf is the new yum
<civodul>and yum was the new rpm?
<Steap>civodul: I installed Fedora yesterday, I ended up using this new tool, and systemd to enable SSH at boot
<lfam>So, once core-updates is built and merged, can I use it on my Debian systems by bootstrapping from the binary installation?
<Steap>Felt weird.
<Steap>civodul: I will email this guy, I think
<Steap>if his package works, might as well push it upstream
<civodul>lfam: yes
<lfam>civodul: Can't wait! I only used guix for a few weeks but I am already addicted ;)
<civodul>heh :-)
<civodul>lfam: yet you didn't want to deal with the locale business? ;-)
<lfam>Can't see myself ever manually managing installation of in-development software by hand again
<Steap>oh, I'm getting warnings on my Debian system about the locales
<lfam>What do you mean? The locale issue makes it unusable for me right now.
<lfam>I have too much non-C locale data to work with
<lfam>If I had the skills to help you solve the locale problems, I would have jumped in
<mark_weaver>lfam: a workaround for now is to leave LOCPATH unset, and to make /run/current-system/locale a symlink to a directory with locales for glibc-2.22
<lfam>mark_weaver: I just could not get that to work, but since you are still recommending it, I will try it again now.
<mark_weaver>sounds good
<lfam>mark_weaver: It failed again. Can you take a look at this and tell me if I'm doing it right?
<mark_weaver>ACTION looks
<mark_weaver>lfam: looks like your guix-daemon is linked with the old glibc, 2.21
<mark_weaver>bah, what a mess :-(
<mark_weaver>lfam: is guix-daemon from the binary tarball, or what?
<civodul>mark_weaver: : not guix-daemon but rather the guile that runs 'guix substitute'
<civodul>the daemon must be started in an environment where LOCPATH is unset
<lfam>Well, the guix-daemon is indeed linked against glibc 2.21. I started with the binary tarball but I thought I had used that to bootstrap a source install
<mark_weaver>civodul: right, but I was assuming that 'guix-daemon' runs a 'guix' via an absolute file name; one that's linked with the same glibc.
<lfam>My daemon is started by systemd, which does exec an absolute file name in /gnu/store
<mark_weaver>civodul: if we set LC_ALL=C in the environment for 'guix-daemon', will that propagate to the 'guix substitute' call?
<mark_weaver>lfam: I see two options: have systemd run a newer 'guix-daemon' that's linked with glibc-2.22, or arrange to set LC_ALL=C before running 'guix-daemon'.
<lfam>I would prefer the former option
<civodul>all this is terrible
<civodul>hopefully we'll soon be out of the quagmire
<civodul>ACTION -> zZz
<mark_weaver>civodul: yeah, in retrospect we never should have merged this core-updates cycle :-(
<lfam>I really appreciate your efforts. This is uncharted territory for libc
<mark_weaver>civodul: good night!
<civodul>mark_weaver: yeah :-/
<civodul>good night/day!
<lfam>Au revoir
<lfam>mark_weaver: Can you recommend a method for me to get a guix-daemon that is linked against glibc-2.22? Many of the guix operations are failing for me right now
<lfam>Hm, now that I think about it, I wonder if I was able to get a newer guix-daemon and just forget to update the systemd target
<mark_weaver>lfam: for now, set LC_ALL=C instead
<mark_weaver>(for guix-daemon)
<mark_weaver>there's a directive in systemd service files to set environment variables. I forget off hand what it is.
<Steap>Hm, guix environment seems to be stuck on my machine
<Steap>I passed --verbosity=10 and it is not even printing anything