***anthk_ is now known as anthk
<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>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>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>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>The fix seems to be to patch setup.py 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>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>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>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 setup.py 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. <rekado>civodul: thanks! I sent another email shortly after the first containing the second patch that I forgot to add in the first email. <davexunit>civodul: turns out that srfi-37 doesn't distinguish between operands before and after the '--' token. <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! conf.nixos.org/ <alezost>There is "The sorry state of Python packaging and how it reflects in Nix" there :-) no sign of Ruby though <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 :-) <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". <civodul>mark_weaver: thanks for the heads-up <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>paroneayea: which project was it? :-) <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. :) <alezost>efraim: nope, "guix package -f" is to install, not to 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>alezost: i'm actually not using emacs, haven't gotten into it yet <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 <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 <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. <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 ;-) <civodul>the error is "libmvec.so.1: error adding symbols: DSO missing from command line", right? <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 <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 <civodul>'top' says the machine is somewhat idle <mark_weaver>yeah, I'm not sure either. I already stopped the evaluator. <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 <civodul>i wonder if there are Xen commands that could allow us to know what's going on on the physical machine <codemac>/proc/stat's last 3 numbers are steal, guest, and guest_nice <codemac>steal is how much time has been spent on OSs <mark_weaver>civodul: restarting hydra-server seems to have helped a lot. the load dropped from about 20 to about 10 <codemac>yeah, it's been really useful on ec2 <codemac>guest / guest_nice are when Linux is the hypervisor <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>gp5st: you mean packages themselves or package recipes? <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: 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>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>though it's better than Debian's packaging <Steap>(also I'm compiling on a one-core VM, so it's slow) <Steap>why would I want to do that ? <Steap>I think Fedora people would rather have maintainers compile their stuff <civodul>but i mean, the binary install is quite simple <Steap>That is outside of the scope of "simple uninstallation" <Steap>people want to do "dnf install" and "dnf remove" <Steap>not have to see where files have been added, etc. <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>civodul: I will email this guy, I think <Steap>if his package works, might as well push it upstream <lfam>civodul: Can't wait! I only used guix for a few weeks but I am already addicted ;) <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>lfam: looks like your guix-daemon is linked with the old glibc, 2.21 <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>hopefully we'll soon be out of the quagmire <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 <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>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