*gzg is on and currently setting up his parabola-hybrid bootstrap-esque guix box right now. :^) <gzg>I still need to see if he can figure out how to get xserver working, without just pulling from Parabola's repo though. <gzg>Eh, I'll figure it out next time I'm off (probably) -- I just gave in, for now, and I just sided with Parabola's xorg meta-pakage. I'll brb, via it. <solrize>i looked at j. shutt's dissertation which was kind of cool but i was like, if you want a call by name language why not just use haskell? <mst>solrize: fexpr based lisps are even less like haskell than a normal lisp <solrize>i've never used fexprs... it looked to me like the idea was to have unevaluated parameters so you could write stuff like IF without macros <solrize>why does guix use scheme instead of whatever nixos used? <schjetne>What's an f-expr if I may ask? I've only ever used s-exprs and m-exprs. <solrize>fexprs are functions that take unevaluated arguments <solrize>sort of like macros except the output isn't then re-run through the evaluator, if i understand it right <solrize>so you could define IF as something like (vau (condition x y) (cond ((eval condition) (eval x)) (#t (eval y)))) <solrize>where vau is like lambda except for fexprs instead of functions <solrize>vau is an ancient greek letter (aka digamma) <solrize>apparently predated the version of the greek alphabet usually used in math <ArneBab_>solrize: guix uses guile scheme, because one of its goals is to create a package manager for the GNU system which can leverage the power of guile scheme. As I understand it, that Guile is the canonical extension mechanism for GNU, that’s quite reasonable. See http://www.gnu.org/software/guix/ <ArneBab_>solrize: but civodul (as the main dev) can give you a better answer. <ArneBab_>civodul: the qemu image worked out-of-the-box — nice! <civodul>dmd was in a bad state in Sep., so that's certainly improved ;-) <ArneBab_>yepp. I’m currently testing guix pull in qemu ☺ <ArneBab_>(my local guix install had some problems, but I currently do not have the time to check things more extensively) <ArneBab_>(no time and no free buffer space in the mind ☺) <ArneBab_>civodul: I got a segfault when running guix pull as root in the pristine qemu image <ArneBab_>to reproduce: wget ftp://alpha.gnu.org/gnu/guix/gnu-system-demo-0.5.qcow2.xz ; xz -d gnu*qcow*xz ; qemu-system-x86_64 -m 256 -net nic,model=e1000 -net user gnu-system-demo-0.5.qcow2 ; # login as root, run guix pull <ArneBab_>glad to - thanks for working on guix; and happy hacking! <ArneBab_>civodul: would it be possible to configure guix to notify some server everytime a derivation fails? Something like build-bot-stats, but for all guix users? <ArneBab_>that could provide direct feedback to packagers that something is wrong - and due to the functional approach of guix, it would actually allow to exactly reproduce the problem. <civodul>currently we don't have per-package 'maintainers' fields <ArneBab_>civodul: What I mean is that when my guix fails to update, it should inform Hydra (was this what you meant?). <civodul>no, i meant that when a package fails to build, Hydra should let the developers know <ArneBab_>can Hydra do the tests? (did it show the breakage?) <civodul>ArneBab_: the "guix pull" segfault is an OOM condition (see on tty12) <civodul>it almost completes with, ahem, -m 512 <ArneBab_>→ the release email needs an update (or rather a new release email which then gets linked on the website) <civodul>ok we'll go back in history and modify the email <ArneBab_>I don’t see the change - maybe a proxy on my side <civodul>no it's not even enough for "guix pull" :-/ <civodul>(the change is the instructions under "Downloading Guix") <ArneBab_>so the release notification stays non-working? <ArneBab_>I know - you can easily send a corrected email and then link to that. <civodul>you don't email info-gnu@gnu.org every day <ArneBab_>you could also just mail guix-devel and link there. <civodul>could be but you see, that's not very nice <civodul>but later today because i'm supposed to do my day work now :-) <ArneBab_>(same for me - but testing whether guix is already suitable to install a local overlay is roughly part of my PhD task: make my work easier to reproduce for others. At least that’s my interpretation, and I have the freedom to schedule my time myself to some degree… <ArneBab_>If guix had already been capable to provide a high-performance-computing user-level overlay (which does not require root) 2 years ago, that could have saved me 3 months of work ☺ <civodul>you should tell people not to use that <ArneBab_>yepp - and not natively supported in numpy, so I had to patch numpy, then scipy and then everything which used numpy <ArneBab_>I learned a lot about autotools during that (which is actually good ☺) <ArneBab_>problem: the intel compiler is faster than gcc - for fortran by some margin. And with model runtimes of 3-7 days, 20% performance improvement actually matters a lot. <civodul>obviously i'm more interested in freedom <ArneBab_>(a recent sensitivity study I did consumed so much power that my guess of the total cost of it is 1000€) <civodul>so you get the usual answer: help improve gcc <ArneBab_>civodul: I try to make my environment as free as possible, but there are still decisions I can’t change easily. <jmd>civodul: Thanks for that libxml2 solution. <jmd>I need to do the same trick for tar, but there doesn't seem to be a "cross-tar" package. <civodul>jmd: libc/gcc/binutils the only exceptions, i think; the others keep their original name <civodul>so you shouldn't need any special case for 'tar' or anything else <jmd>It would seem to be necessary when cross-compiling tzdata <jmd> 360: 3 [#<procedure 8825120 at /nix/store/d1qnsj2wf59m067qilasi61kgqs5wy3p-module-import/guix/build/gnu-build-system.scm:356:9 (expr)> #] <jmd> ?: 0 [system* "tar" "xvf" #f] <civodul>so it's either "source" or "tzcode" that's missing from 'inputs', no? <jmd>I didn't realise these were package names. <jmd>Jawohl. Ein kleines Bißchen. <jmd>Presumably propagate-input implies input ? <civodul>damn, i started an IceCat build with 4.5G, it's been running for ~2.5 hours, and it'll run out of disk space very soon <jmd>I have similiar problems. <jmd>I've been doing a lot of -K builds <jmd>soon I shall run out of /tmp space <civodul>well, just sudo rm -rf /tmp/nix-build-* <jmd>I can't from this terminal <jmd>I'm thinking of writing a package "linter" - do you think it would be useful? <Steap>jmd: I do not really know Scheme, so I haven't tried todo this myself <jmd>I'm by no means an expert. <Steap>but I'd really love to be able to write a package, "lint" on the file, and fix the common mistakes <Steap>like "no period in the synopsis" for instance <Steap>I always forget, and this forces me to amend the patch later <Steap>But I guess that parsing the mailing-list could give us a lot of ideas <jmd>... or inputs which almost certainly should be native-inputs. <Steap>yes, that could be more useful :) <Steap>Given the nature of Scheme, I think parsing the definition of a package should bestraight-forward <jmd>Certainly easier than other languages. <civodul>basically 'fold-packages' from (gnu packages) <civodul>some of it, like period at end of synosis, can even be checked at compile-time <jmd>aspell the description? <jmd>civodul: I have a patch with about 400 lines which moves various dependencies from inputs to native-inputs. Do you want it as one big patch, or should I split it? <civodul>jmd: assuming it's *just* this kind of change, one patch is good <civodul>but make sure it doesn't trigger any core rebuild on master <jmd>Hmm. I think there is a change in base.scm - I must check. <civodul>well, just try ./pre-inst-env guix build coreutils -n <civodul>and see whether it would build everything, or download everything <jmd>Looks like it would, unfortunately. <jmd>I'll find out what is responsible and put that in a separate patch. <jmd>If I have already built coreutils locally, that command wouldn't tell me anything usefull would it? <civodul>sorry, it would print the directory name and return 0 <ArneBab_>civodul: the article in linux magazin sounds like a summary of your mail. <ArneBab_>civodul: with qemu -m 1024 I now get “guix pull: error: No such file or directory” <mark_weaver>jmd: if you had changed anything that coreutils depends on, then it would rebuild. <sbp>is the build process for the guix test image documented anywhere? <sbp>as in, how the image itself was made <civodul>sbp: it's not written anywhere, except here: ./pre-inst-env guix build -e '(@ (gnu system vm) system-qemu-image)' :-) *jmd gets confused between git and guix! <sbp>alias them to `version-control --torvalds` and `version-control --courtès` respectively <sbp>on a fairly clean Debian, the deps for guix seem to be guile-2.0-dev libgcrypt11-dev libsqlite3-dev <sbp>not yet, still in make <sbp>this box is slow. instead of a CPU it has a cutout giraffe from the back of a cereal box <sbp>civodul: there's a lot of "nix" hangover. are you going to s/nix/guix/g it all out by the time it gets to 1.0? or are you sticking with some nix parts for backwards compatibility with e.g. file paths? ***chaoflow_ is now known as chaoflow
<sbp>"Still here? Then perhaps by now you’ve started to wonder: when do we reach a fixed point? That is an interesting question! The answer is unknown, but if you would like to investigate further (and have significant computational and storage resources to do so), then let us know." — hehe <sbp>just use a fixed-point combinator <elly>oh, this is not parallelizable, heh <sbp>sure it is, just 3d print some more computers <sbp>wondering how guix will work with pip <sbp>probably need to try it out to figure it out <sbp>(and gems and so on) <civodul>sbp: yes, i think we'll switch to /gnu/store Real Soon <sbp>ah, /gnu instead of /guix? I like that <civodul>yes, i think /gnu makes more sense no? <civodul>it could be used for other things as well, who knows <jxself>I had to put a space 'cause my IRC objected to an unknown command. *jxself is happy for /gnu <civodul>i wonder if we should get Karl's approval or something ;-) <sbp>send him a nice cake with "we're using /gnu" writing in icing on the top <sbp>the problem is that pip and gem and so on are still going to work as non-functional systems. I wonder if it would be possible to extend them individually so that they had hooks to interface the guix-daemon? then pip et al. would be compatible with guix, and the Functional Way™ <sbp>(then you have virtualenv which will probably be a whole new kettle of fish) <sbp>also, if you're using /gnu, you should also reserve a gnu command. so then you could type `gnu install python` instead of `guix package -i python`. yes? yes? no? fine... <civodul>i was thinking of perhaps using the 'gnu' command for system-wide things <sbp>installed. now, will it run... *sbp does the groupadd guix-builder stuff <sbp>huh. the daemon doesn't daemonise itself <sbp>and now, guix package -i python as user... <sbp>error message comes up only after a long pause. error: while creating directory `/home/sbp/usr/var/nix/profiles/per-user/sbp': Permission denied <sbp>that's presumably something that can be checked at init pretty much <sbp>(also, blast, I should have configured the store location better. oh well) <sbp>how's that going to work on a mutli-user machine though? <sbp>because presumably /nix/profiles/per-user should belong to root <sbp>then the symlink goes in .guix-profile <sbp>but how does root know when to make new profiles? <sbp>if you adduser, you'd have to remember to do guix stuff too <sbp>whereas really, optimally it would be fully automatic <sbp>it did create the symlink, /home/sbp/.guix-profile -> /home/sbp/usr/var/nix/profiles/per-user/sbp/guix-profile <sbp>but I get "guix package: error: build failed: unexpected end-of-file" trying to guix package -i python <sbp>weird, ran the command again and now it works. transient error! <sbp>the download status of this file is bring printed over and over and over again <sbp>should use \\r to conserve space <a_e>sbp: It depends pn the width of your terminal. Just try it in full screen mode. We already shortened the file names... <sbp>the width of my terminal is 80, as all good terminals are... :-) <sbp>the install failed with: guix package: error: build failed: builder does not have write permission to `/nix/store'; try `chgrp 1001 /nix/store; chmod 1775 /nix/store' <sbp>I don't know whether this refers to ~/usr/var/nix/store or if it's trying to use the actual, absolute /nix/store <sbp>either way, since the daemon is running as root, it should have permission to do whatever it wants <a_e>The daemon is root, but the builder should normally be (if you followed the instructions) be a special build user, inside the group guix-builder. <a_e>This is why /nix/store is group writable. <sbp>drwxr-xr-x 25 root root -> drwxrwxr-t 25 root guix-builder <a_e>Yes, that is what I have. <sbp>I think this should be checked as soon as a command is invoked, as with the profiles/per-user directory permissions <sbp>possibly even a guix doctor command, à la brew doctor <sbp>going through a long installation process just for it to fail because of something that could have been simply and automatically checked before the installation is a bit annoying :-) <klrr_>18:04 < sbp> also, if you're using /gnu, you should also reserve a gnu command. so then you could type `gnu install python` instead of `guix package -i python`. yes? yes? no? fine... <klrr_>doesnt make sense honestly, naming the directory might be ok (i dont really have a opinion regarding that) <klrr_>but guix is the package manager it would just be confusing to change its name from guix to gnu imo <sbp>yeah, it was tongue in cheek. I mean, the fact that /gnu is being discussed for storage shows the primacy of the idea, the weight it holds within the GNU ecosystem. so `gnu` as a command was a reference to that too <sbp>ideally, `guix install python` would be acceptable <sbp>I don't really understand hiding package management commands behind a "package" sub-command in a command which is already for package management. seems a little bit tautological <sbp>plus then it has conceptual regularity with just about every other package manager in existence <sbp>python installed, I declare victory <a_e>sbp: No; think of "apt-get install". <sbp>a_e: yes, that's what I was thinking of <sbp>along with e.g. brew install, pip install <a_e>And you can do much more than installing packages; you can remove them, you can update them. <a_e>guix package -r python -i scheme <sbp>"And"? I still don't get your "No"... <sbp>-r and -i chaining is handy, indeed. well you wouldn't break backawards compatibility <sbp>install would be an alias for package -i <sbp>if it were a *true* alias, then you could still do `guix install scheme -r python` <sbp>don't mind either way on that; but people will try using `guix install`, and swearing if it's not available <a_e>Sorry, "apt-get install" was a bad example. <a_e>But the fact that each "guix package" invocation is atomic is meaningful. <a_e>apt-get install a; apt-get install b <a_e>guix package -i a -i b <a_e>guix package -i a -i b <a_e>(Not even speaking of removing packages.) <sbp>I assume you mean -i b -i a in the latter case? <sbp>you just typed the same line twice, heh <a_e>Sorry, I meant guix package -i a; guix package -i b <sbp>okay, well I have no problem with guix install a b working like guix package -i a -i b, if that's the sane choice. as long as it's documented and people understand what it means <sbp>what sort of problem would it cause if somebody expected it to work like the install a; install b case? <a_e>Well, it could work like either; several invocations are much slower. <a_e>There is no real need to add functionally equivalent subcommands to guix, however. <a_e>Users get used to the commands. <sbp>conceptual regularity is a real need. new users will never get used to commands and there will always be new users. so there's a continual conceptual tax being paid <a_e>Much harder, as jmd stated, is to distinguish guix and git. <sbp>package -i is like Orwell's boot stamping on the face of humanity forever! or... maybe not that bad. but still *pretty bad* <a_e>New users always get used to commands; it used to be called "apt-get", and now it is called "guix"; this means changing your habits anyway... <a_e>Did you notice there are other families of subcommands to guix? <sbp>true, but they won't just be coming from apt-get. they may be familiar with many package managers for many platforms and languages—all of which use "install" as a subcommand <a_e>guix is not only the package manager in the sense that it manages packages in the user profile (which is the "guix package" part). <sbp>yes, but why not huffman code the most common cases? <sbp>huffman coding is logical. it's ergonomic. it's the right thing to do <a_e>It also handles the store (via "guix gc") and package creation (via "guix build"). <sbp>love the huffman coding! it's good UX! <a_e>I am not sure that adding lots of new subcommands for special cases is a good idea. <sbp>it's not a special case. you're comparing by frequency; you're weighting by frequency <a_e>You will want "guix remove a" for "guix package -r a", no? <sbp>access to the most heavily used commands should be simpler and more regular <sbp>that would be logical, assuming that -r is used on a similar magnitude to -i; it may not be the case <sbp>it would be worth gathering user statistics for that <a_e>I will stop bike shedding; once I learnt that you can have several packages installed and removed in one go, I understood the usefulness of "-i" and "-r". <sbp>good design is worth debating :-) <sbp>cf. Quality Without a Name, on c2.com <mark_weaver>fwiw, I think it's worth considering making "guix install a b c ..." an abbreviation for "guix package -i a -i b -i c ...". <sbp>"easy_install" was, as a name, clearly a mistake compared to "pip" <a_e>I think it is bad design to add more commands; you think it is good design to add more commands for common options. There is nothing to debate. Create an alias, probably. <mark_weaver>partly because it would be nice to be able to install multiple packages without either multiple '-i's or putting the list of packages within {}. <sbp>git even has a command to add aliases... <mark_weaver>if we supported "guix package -i a b c ..." syntax, I would probably think that was good enough, but I'm not very happy with the current interface. <a_e>mark_weaver: That was what I was just thinking, one could see "-i" and so on as modifying the "state" of the command for the subsequent parameters. <a_e>guix package -i a b c -r d -i e -u f <a_e>could be reasonable. <mark_weaver>unfortunately, the current library (an SRFI) that we're using for option parsing doesn't support that kind of syntax, as I recall. <mark_weaver>I suspect that's the main thing blocking that change. <mark_weaver>probably we should enhance the option parsing library to support this somehow. <sbp>could do it like this: <sbp>guix main = do aResult <- installPackage a \\ <sbp> bResult <- installPackage b \\ <sbp> cResult <- removePackage c \\ <sbp> putStrLn \\("Installation results:" ++ aResult ++ bResult ++ cResult\\) <sbp>shouldn't have added the Store Monad if you wanted it to be atomic! :-) <mark_weaver>changes to the user's profile have nothing to do with the store, apart from building a new profile and adding it to the store. <sbp>(joke about monads being used for side effects. not all are used for side-effects) <sbp>the overall joke was originally going to be that if you want to inform users of the pure-functional approach of guix on the command line, you could embed a pure-functional language in the command syntax <sbp>or, better yet, guix functional-package-installation -i a -i b -i c <sbp>guix functional-package-installation --fully-atomic-have-no-fear -i a -i b -i c <mark_weaver>hmm, I think I was wrong about SRFI-37 not being powerful enough to implement this semantics. <sbp>. o O ( if it is atomic, then you could retry automatically ) *mark_weaver doesn't remember <sbp>I expect, thinking about it, that combinations of -i are going to be far more common than -i admixtured with non-i commands. so -i a b c, as you say, at the least would be handy. still think install is a good alias <sbp>this is my cause now. I think I can gather 5000 troops before the weekend <sbp>oh crap, no, it's Friday <mark_weaver>sbp: well, if it helps, the 'guix' command is easily extensible, and you could add your desired 'install' command by simply adding a (guix scripts install) module somewhere in your guile load path. <sbp>sure, and I'll put it up on github and it'll be the #1 downloaded repo and what's next? a ticker tape parade for sbp, that's what <sbp>I'll mention it to civodul anyway. he might love the idea <sbp>I actually made a list of things to ask him <sbp>a concise list, so that he doesn't have to wade through several pages of sbp jokes like I just dragged you guys through... :-) <mark_weaver>well, while it's *possible* to do this with SRFI-37, it's not entirely pretty. <mark_weaver>one of the seeds will have to be the "current option to be applied to bare arguments" <sbp>er... why does SRFI-37 have a final status date that precedes the draft status? <sbp>so the dates (1999 and 2000) were added between 2002 and 2004, which adds to the mystery <sbp>probably some kind of migration from a pre-srfi.schemers.org host? <mark_weaver>would you like to report it to srfi-editors@srfi.schemers.org ? <mark_weaver>I take back everything I said about SRFI-37 not being sufficient. It seems well designed. I can do what I need quite nicely. *sbp tries guile --use-srfi=37, notes the success <mark_weaver>okay, I have a patch to implement the "guix package -i a b c -r x y x" style syntax. <a_e>mark_weaver: Interesting, that was a quick thing! <a_e>Can you also have -u? And -i a -r b -i c? <mark_weaver>I haven't fully tested it, and some doc changes will be needed also, and tests. but before I polish it too much I want to know what civodul thinks of the basic idea. <mark_weaver>(it could be made a bit simpler if it assumed that my multiple-args patch was already applied) <mark_weaver>a better implementation would handle some options, or at least error out gracefully if you tried to pass options, etc. <mark_weaver>actually, instead of calling 'run-guix-command' from (guix ui), I probably should have just called 'guix-package' from (guix scripts package) directly. <mark_weaver>this one at least handles options that don't take arguments, passing them directly to guix package.