IRC channel logs


back to list of logs

<zerwas>Will there be a guix package for debian in the future?
<handheldCar>I didn't succeed at replacing a script /bin/sh with sh:
<handheldCar>ok, using bash instead worked
<handheldCar>Has anyone had to solve an autoconf that could not be found? I'm confused because it has been available through guix.
<handheldCar>'which autoconf' still points to /usr/bin/autoconf
<civodul>Hello 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>from `'
<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>hey guilers
<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>I thought I was in #guile
*davexunit fails reading comprehension class'
*davexunit curses tab completion
<davexunit>sorry for spam.
<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 :)
<davexunit>it was a simple answer. :)
<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ḿ
<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 not really that bad.
<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.
<xyh>it's a long time !
<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>when posting so much, please use a paste service such as
<mark_weaver>but what we need to see is what's above the first line you posted.
<mark_weaver>what was the first error?
<mark_weaver>no problem :)
<mark_weaver>can you find the first error?
<xyh>is the following is ?
<xyh>.libs/libgmp.a: No space left on device
<xyh>Makefile:746: recipe for target '' failed
<mark_weaver>ah, yes.
<mark_weaver>guix needs a lot of space in /tmp and /nix
<jmd>download more ram!
<mark_weaver>I guess you have a partitioning scheme where one or both of those are on a small partition.
<xyh>i have only one /
<mark_weaver>what does 'mount' report about /tmp ?
<mark_weaver>your distro might make it a ramfs
<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>~ $ df -h
<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
<mark_weaver>/var/tmp might be a good choice.
<xyh>Thanks for your advice
<mark_weaver>glad to help. please let us know how it goes!
<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
<mark_weaver>perhaps. maybe post about it on guix-devel?
<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
<mark_weaver>and I see good reasons to avoid it.
<mark_weaver>but I confess I'm not an expert on this issue.
<jmd>When I was working on the Hurd, the devs said NEVER to build in /tmp -
<mark_weaver>interesting. do you remember the reasons they gave?
<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>well, okay, but that's for developers.
<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>s/whole system/guix-daemon/ (oops)
<mark_weaver>which will hopefully be rare :)
<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>sure, we could build our own auto-cleaning system.
<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.
<mark_weaver>I think Linux does that too.
<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).
<mark_weaver>ah, I wonder what civodul thinks about this! :)
<jmd>The man himself.
<mark_weaver>hi civodul!
<civodul>heheh, hello!
<civodul>what are you up to?
<jmd>mark_weaver wants to rewrite guix in python.
<civodul>what should we do?
<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.
<mark_weaver>haha :)
<civodul>ah, hmm
<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>an old habit that still persists.
<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
<civodul>well, dunno
<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>two things to note
<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.
<civodul>sounds good
<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.
<civodul>it does honor $TMPDIR, right?
<civodul>then yes, agreed
<mark_weaver>oh wait. I misread the source code. now I'm not sure.
<civodul>want to post or push a patch? :-)
<civodul>ah ah
<mark_weaver>I need to investigate further.
<jmd>suck it and see
<mark_weaver>yes, I think it should honor $TMPDIR
<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,
<mark_weaver>but I'm too lazy to test it right now.
<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"
<mark_weaver>xyz: it has to be set for the guix-daemon.
<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>xyh: no, TMPDIR=/var/tmp guix-daemon ...
<mark_weaver>kill the daemon that's already running, and relaunch it with TMPDIR set.
<xyh>ok thanks
<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
<mark_weaver>(apologies if you already knew this)
<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.
<mark_weaver>glad to help, feel free to ask questions anytime :)
<xyh>is is that Ludovic = civodul, which is the guy in the video i am watching now ?!
<xyh>!! cool
<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 ???
<mark_weaver>yes, a joke :)
<civodul>thanks, i'm reassured now
<xyh>you are all scheme hacker right?
<Steap>Oh, we're not rewriting it in Python ?
<xyh>i want to be one
*Steap is disappointed
<jmd>xyh: You want to be one what? A python?
<xyh>a schemer
<civodul>on #nixos there are reguarly people suggesting a Haskell rewrite :-)
<jmd>A scheming python.
<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>jmd: me too
<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>but Texinfo now depends on Perl too
<civodul>xyh: the dependency graph is the set of connections between packages and their dependencies
<civodul>dueno: i think you're in the libssh2 business, so what do you think of libssh (the one from
<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
<mark_weaver>s/that's it/that it's/
<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.
<mark_weaver>or you can use fancier data structures if needed.
<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.
<xyh>yes, you are right.
<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>Scheme has vectors with constant time lookups.
<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.
<mark_weaver>what kind of notation did you have in mind?
<xyh>i know it,
<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>s/it/that variable/
<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>i use ikarus
<civodul>λ in Bitstream Vera is awful
<xyh>what is Bitstream Vera ?
<mark_weaver>It's quite nice in dejavu
<xyh>oh a font , i know
<adhoc>perfect in Monospace
<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
<xyh>elisp can do it too
<zerwas>Is there a prebuilt package of Guix for any linux distribution yet?
<xyh>there are two for archlinux
<civodul>zerwas: i think Fulax did one for Gentoo, and yes there's
<civodul>and NixOS
<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>xyh: Yeah, that would be great
<zerwas>Unfortunately I don't have much experience with packaging
*civodul → zZz
<civodul>good night/day!
<civodul>mark_weaver: BTW, not too cold at your place?
<zerwas>good night civodul!
<zerwas>btw, I watched your GHM 2013 talk today, it was very insightful :)
<zerwas>xyh: Do you have any experience in creating .deb packages?
<civodul>zerwas: thanks
<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 ^_^