IRC channel logs
2014-01-06.log
back to list of logs
<zerwas>Will there be a guix package for debian in the future? <handheldCar>Has anyone had to solve an autoconf that could not be found? I'm confused because it has been available through guix. <xyh>hi! i am in china, and i am try to use guix. but the such as : downloading`/nix/store/d86y86dm0agmgga1m2p81szpxmb61ani-glibc-2.18-locales' <xyh>(100.9 MiB installed)... <xyh>is too slow, is there a mirror i can use ??? <jmd>xyh: Unfortunately not. <jmd>You can pass --no-substitutes, then it won't get used at all. <xyh>ok. by the way, jmd ,are you German? <jmd>But I live in Germany. <davexunit>I've been reading a bit about different git workflows today, and I'm wondering how the Guile maintainers do certain things. <davexunit>there's of course the master branch that as of now contains code that will be in the 2.2 release, but there's also stable-2.0 where bug fixes and some other patches are applied. <jmd>davexunit: Try #guile *davexunit fails reading comprehension class' *davexunit curses tab completion <jmd>No harm done. The occupants of both channels is largely the same set of people. *Steap just joined #guile because he's interested in Git :) <jmd>Steap: Why not join #git ? <Steap>jmd: no, I mean, I'm interested in davexunit's question :) <xyh>with ``sudo guix-deaman --no-substitutes'', <xyh>and then ``guix package --install=hello'', <xyh>guix is still downloading something, but redirection to some chinese mirrors this time, <xyh>and try to compile things after downloading. <xyh>is this the way guix works ? <jmd>Well it would have to download the hello source froḿ ftp.gnu.org <jmd>(or a mirror thereof) <xyh>but it is downloading a lot of things <jmd>Yeah. The source of all the dependencies of hello <jmd>But it won't be downloading anything from hydra I don't think. <jmd>I think one of the plans for the next release is to decentralise hydra so that you won't be dependent on just one server. <xyh>thanks for your answering <xyh> is it that i can't use guix at all for i have no mirror around now ? <jmd>You can use it. But you will end up building *everything* yourself. Which unless you have a very powerful machine will take a long time. <jmd>and, as you have discovered you will have to download the sources. <jmd>However, the sources are generally small. And many of them have mirrors. <jmd>The good news, is, once you have them in your store, you won't have to download them again. <mark_weaver>it's true that it takes a while to compile everything, so you'll need some patience. <xyh>well installing ``hello'' is killing me ~~~ <xyh>i will try to use it for i am a schemer, <xyh>and i love the idea about guix <jmd>It took me about 36 hours when I built glib from scratch. <jmd>nohup guix build hello & <jmd>And then do something else for a day or so! <mark_weaver>or continue to use your machine, if you can tolerate it being busy compiling in the background :) <xyh>but what if the compiling fail ?! <xyh>Makefile:843: recipe for target 'all' failed <xyh>make: *** [all] Error 2 <xyh>phase `build' failed after 236 seconds <xyh>builder for `/nix/store/rddkhbxnba8rpjrpfpmn2cjpxbx1cfsm-gcc-cross-boot0-4.8.2.drv' failed with exit code 1 <xyh>cannot build derivation `/nix/store/rdshfgbdrfjwx5g2njlm5danyxzxdqif-gcc-cross-boot0-wrapped-4.8.2.drv': 1 dependencies couldn't be built <xyh>cannot build derivation `/nix/store/b7bfh9fs2qaps777bjjkjyndiwz31gb3-glibc-2.18.drv': 1 dependencies couldn't be built <xyh>killing process 6610 <xyh>cannot build derivation `/nix/store/mqk4xcylmwry38m5r0nhmhb8skr4pfvl-hello-2.9.drv': 1 dependencies couldn't be built <xyh>cannot build derivation `/nix/store/cw68a1dixb15mjrxgd3qjggbhlxz31v9-profile.drv': 1 dependencies couldn't be built <xyh>guix package: error: build failed: build of `/nix/store/cw68a1dixb15mjrxgd3qjggbhlxz31v9-profile.drv' failed <mark_weaver>but what we need to see is what's above the first line you posted. <xyh>is the following is ? <xyh>.libs/libgmp.a: No space left on device <xyh>Makefile:746: recipe for target 'libgmp.la' failed <mark_weaver>I guess you have a partitioning scheme where one or both of those are on a small partition. <mark_weaver>well, more importantly, what does 'df -h' report about /tmp and / ? how much free space? <jmd>That is just one reason why I think nix/guix abuses /tmp very badly. <xyh>文件系统 容量 已用 可用 已用% 挂载点 <xyh>/dev/sda5 68G 18G 47G 28% / <xyh>dev 960M 0 960M 0% /dev <xyh>run 963M 484K 962M 1% /run <mark_weaver>it looks like you might be able to use a different temporary directory by setting the TMPDIR environment variable for guix-daemon <xyh>tmpfs 963M 0 963M 0% /dev/shm <xyh>tmpfs 963M 0 963M 0% /sys/fs/cgroup <xyh>tmpfs 963M 123M 840M 13% /tmp <xyh>/dev/sda7 94G 31G 59G 35% /home/xyh/ubuntu-home <xyh>/dev/sda2 61G 12G 47G 20% /home/xyh/ubuntu-root <xyh>Thanks for your advice <mark_weaver>jmd: given that guix-daemon looks for TMPDIR (and a few others) before resorting to /tmp as a hardcoded default, do you still think there's a problem to be fixed here? <jmd>Well it's good that it can be overridden, but it would be better IMO if it used some other directory by default. <jmd>/nix/builds for example <jmd>Perhaps I will. It's good that it can be overridden though. <mark_weaver>I'm sympathetic to your position. The thing that holds me back is that I think /tmp is fundamentally the right place for it, given that the build directories are immediately removed by default. <mark_weaver>The reasons for wanting to move it somewhere else have to do with technical limitations of ramfs. <mark_weaver>if the caching in the normal filesystem is good enough, I don't see a reason to use ramfs for /tmp <jmd>When I was working on the Hurd, the devs said NEVER to build in /tmp - <jmd>the reason was that sometimes something the build process did could cause a system crash. <jmd>On reboot, /tmp got cleared and you had no idea what caused the crash. <mark_weaver>I'm not sure the defaults should be based on the needs of developers. <mark_weaver>I see one nice advantage to /tmp, which is that it gets automatically cleaned. <jmd>Anyway I guess that civodul's take willbe that I'd have to persuade the nix maintainers to make the change. <mark_weaver>so casual users of guix don't end up with a space leak. <jmd>Typically /tmp gets cleaned only on boot. <mark_weaver>well, the leak should only happen if the whole system crashes, anyway. <mark_weaver>anyway, cleaning only on boot is better than no cleaning ever, for a directory that casual users may not even know about. <jmd>If such a leak did occur, gc could be trained to clean it. <mark_weaver>devs who want to investigate problems know enough to set an environment variable, and it's easy for them to do. <mark_weaver>I'm not necessarily against moving it elsewhere. I'm just giving some arguments in favor of keeping it at /tmp <mark_weaver>I think it's better to reuse the existing auto-cleaning systems for /tmp (which maybe should be improved) then to build another one for guix. <mark_weaver>and I suspect it's probably just a bad idea to make /tmp a ramfs is 2014. <jmd>It's not uncommon for OSes to make /tmp rather small. <jmd>Doesn't Solaris' /tmp share disk sectors with the swap space ? <mark_weaver>guix packages for common distros can set the environment variable in their guix-daemon launch script. we can mention in the docs that they might need to set the environment variable. it's not as if the current guix-daemon command is very short. <jmd>As you say, it can be overridden. For this reason I don't think it is worth making a big issue about it (although I think it is not ideal). <jmd>mark_weaver wants to rewrite guix in python. <mark_weaver>we were having a discussion about whether the default TMPDIR for guix-daemon should be somewhere else, to make things easier for people who have /tmp on a ramfs. <civodul>actually /tmp in the chroot is not a ramfs <mark_weaver>jmd says that the hurd people are also against building in /tmp in general, so that if there's a system crash, the build directory is left around for investigation. <mark_weaver>civodul: yeah, but the build directories go in the host system's /tmp <civodul>you're free not to use ramfs on /tmp though :-) <mark_weaver>well, yeah, I suspect that running ramfs on /tmp is rarely a good idea in 2014. <jmd>civodul: You might not be. You might not have root access. <mark_weaver>I suspect it's based on performance advantages to tmpfs in ancient linux, before the regular filesystem caching was good enough. <mark_weaver>still, in practice this bites users regularly. maybe people have a small /tmp <jmd>Even if /tmp is not ramfs, it is not uncommon for /tmp to be quite small <mark_weaver>at the very least, I think we should put something in the manual, where it tells how to invoke guix-daemon, showing how to set a custom /tmp (perhaps /var/tmp). <civodul>1. this is part of the read-only C++ blob ;-) <civodul>2. we can choose what to do eventually in GNU <jmd>I even knew a sysadmin who had a cron job clearing /tmp/* every few hours. <mark_weaver>actually, I think that's all we should do. (update the manual, that is) <mark_weaver>just mention that if /tmp is small, put TMPDIR=/var/tmp before the guix-daemon command, or something like that. <mark_weaver>I think the default should remain in /tmp, because we should have auto-cleaning of the temporary build directories, and I'd rather take advantage of the existing mechanisms than invent something new. <mark_weaver>oh wait. I misread the source code. now I'm not sure. <xyh>hi guys, sorry to interrupt. <xyh>how should i change the $TMPDIR to /var/tmp for guix ?? <xyh>after export TMPDIR="/var/tmp", <xyh>and guix package -i hello, <xyh>then i get the same error. <xyh>and for me, originally there is no TMPDIR as an environment variable, echo $TMPDIR give me nothing before i export TMPDIR="/var/tmp" <xyh>do you mean : TMPDIR="/var/tmp" guix package -i hello <mark_weaver>so you need to set them in the shell that launches the guix-daemon, before launching it. <mark_weaver>kill the daemon that's already running, and relaunch it with TMPDIR set. <mark_weaver>environment variables are not global. if you set them in one shell, that's only for that one shell, and for subprocesses subsequently launched from that shell. <mark_weaver>each process has it's own copy of the environment variables, initially inherited from its parent process. <civodul>xyh: note that to know if it works you'll have to run "guix build foo --keep-failed" and have it fail/abort <xyh>i have learned a lot from you today. <xyh>i am going to learn more about guix, maybe after then i can ask some more meaningful questions. <xyh>is is that Ludovic = civodul, which is the guy in the video i am watching now ?! <civodul>i can only imagine the level of coolness that represents, woow <xyh>on another note, you mentioned to rewrite guix in python, is it just a joke ??? <xyh>you are all scheme hacker right? <Steap>Oh, we're not rewriting it in Python ? <jmd>xyh: You want to be one what? A python? <civodul>on #nixos there are reguarly people suggesting a Haskell rewrite :-) <jmd>On a serious note, I wish that perl didn't feature so low in the dependency graph. <xyh>why? isn't scheme is the coolest language? <civodul>you should talk about it with Karl... <jmd>Is Karl the one responsible? <xyh>what is dependency graph ?? <xyh>in scheme or any other languages, how do you guys do digraph processing ?? <civodul>jmd: well, Linux is responsible, since Perl is a dependency of Linux <civodul>xyh: the dependency graph is the set of connections between packages and their dependencies <civodul>i'm asking because that's what guile-ssh uses <mark_weaver>xyh: by digraphs, are you asking how we handle non-ASCII characters? <xyh>i mean directed graph processing <xyh>dependency graph is a kind of directed graph right? <mark_weaver>that's too general an area for me to say much about. there are different ways to represent graphs, and various algorithms, and I don't know that's it much different in scheme than any other language. <xyh>4 ways to represent graphs <xyh>i am try to write a directed graph processing language as my graduation thesis. ^_^ <adhoc>xyh: graphs, specifically directed acyclic graphs are really a list of facts <adhoc>xyh: i'm still learning scheme/guile, but in lisp you have an a-list that is a dictionary of relationships, those facts <mark_weaver>yes, that's a common way to do it, and probably the simplest. <xyh> a-list of points-pairs(adjacency list) is just one way to represent digraphs, other ways are incidence list, adjacency matrix, incidence matrix <mark_weaver>Guile has vhashes, which act kind of like alists except that lookups are much faster for large dictionaries. <mark_weaver>xyh: indeed, there are many representations, and which one to choose depends on the specific algorithms you need to apply to the graphs, how fast you need those algorithms to be, etc. <mark_weaver>Adjacency lists are particularly natural in Scheme, I suppose. <mark_weaver>but any of those representations could be implemented easily in Scheme as well. <mark_weaver>Guile also has multidimensional arrays, hash tables, vhashes, etc. <xyh>In addition to representation, <xyh>more importantly i am trying to design new syntax to make it easyer to processing very small digraphs, <xyh>for i have some math problems which need this kind of operations on digraphs. <xyh>(i think i am generalizing the whole λ-cal theory to form a math background for my language) <mark_weaver>well, a very simple representation would be something like ((a . b) (b . c) (c . a)) to represent a cycle of three directed edges. <mark_weaver>the advantage to the representation I just gave is that it's already standard Scheme syntax. <mark_weaver>but of course if you'll be writing a lot of these graphs, you may want to make the syntax a bit nicer. <xyh>in scheme, i have writen a LISP interpreter support lazy-eval and lexical-scope, <xyh>representation λ-abstractions as digraphs: <xyh>(λ (a) (a (λ (a) (a a)))) ==> #0=(λ (a) ((a . #0#) #1=(λ (a) ((a . #1#) (a . #1#))))) <xyh>in my repl (λ (a) (a (λ (a) (a a)))) is eval to a digraphs <mark_weaver>oh, so every variable reference is represented with a link to the lambda expression that bound it? <mark_weaver>Guile doesn't support that datum label notation yet, but I'm working on fixing that. (I have it working in my machine, but it needs more work before it's ready to push) <mark_weaver>well, each variable reference is _annotated_ with a link to the lambda expression, I meant to say. <xyh>what is Bitstream Vera ? <xyh>i care about my Chinese font, but not Greek font as much. <xyh>by ``datum label'', do you mean ``#1#'' <xyh>so it can't print a list with a loop, mit-scheme and a lot of other scheme implementations also can't do this <xyh>i think, in some scheme implementations, the notation like ``#1#'' is come from common lisp <zerwas>Is there a prebuilt package of Guix for any linux distribution yet? <xyh>there are two for archlinux <zerwas>That's a start :). Any chance we will see a Debian package in the near future? <xyh>we can build a .deb by ourself! and make a link in the page for people to download <civodul>i'm guessing it's against Debian policy to have /nix <zerwas>Unfortunately I don't have much experience with packaging <civodul>mark_weaver: BTW, not too cold at your place? <zerwas>btw, I watched your GHM 2013 talk today, it was very insightful :) <zerwas>xyh: Do you have any experience in creating .deb packages? <xyh>zerwas:I don't have much experience with packaging too, and i am new to guix. <xyh>zerwas: I am going to learn more about guix ^_^