<davexunit>I think it might still be useful to have the package->derivation procedure. <davexunit>well, bags make guix environment pretty easy to write. <jxself>Time to get busy with 3.17 work. <paroneayea>out of curiosity, why not allow individual calls to a command? <davexunit>paroneayea: some guix subcommands do not require the daemon <davexunit>but the daemon is required for certain anything that involves derivations *paroneayea reading the manual now! <davexunit>building, downloading sources and putting them in the store, installation, rollbacks, etc. <paroneayea>davexunit: did I remember you saying you use guix for local development also? <davexunit>paroneayea: that's what I'm working on, yeah. <davexunit>'guix environment' is a WIP script to re-create the build environment for a given package. <davexunit>it can either augment your current environment, or create a 'pure' environment that clears almost every environment variable. <jxself>Okay, I have a potential 3.17 kernel config now. Time to go compile the kernel and try it out first. ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | things to package: http://libreplanet.org/wiki/Group:Guix/Wishlist'
<Ulrar>Mh, I'm sure I saw something on the mailing list about the no code for json problem while guix pulling, but I can't remember what the solution was ? <civodul>would be nice to have something equivalent at the command line <civodul>actually it's not unlike 'guix package -u .', now that i think of it <civodul>i wanted to factorize 'bag-search-paths', but there were efficiency concerns <davexunit>civodul: it's not a pretty implementation yet, and I already had a bunch of it written from before. <DusXMT>If I want to build a custom kernel (I need to enable some by-default disabled options), where should I begin? <civodul>DusXMT: you could write your own package definition, presumably inheriting from linux-libre, and then drop that in GUIX_PACKAGE_PATH <DusXMT>civodul: Good idea. Is there a field for a custom config file, or does one need to write a patch for the package? <davexunit>civodul: I compute derivations for 'bag-transitive-inputs', and then use the derivation output paths for building search paths. <civodul>DusXMT: but if you think it can be of general interest, this can be discussed with jxself :-) <civodul>DusXMT: linux-libre has its config file in 'native-inputs', see linux.scm <davexunit>civodul: I realized that inputs can be origins or packages, so I filtered the inputs to only include packages. I think that is the right thing, but I wonder what your thoughts are. <civodul>you mean when computing search paths? <civodul>i think it doesn't hurt to iterate over all the inputs, if that makes code simpler and not noticeably less efficient <davexunit>civodul: I don't see a reason to build the derivations for origins <davexunit>there's nothing to do for origins regarding search paths, so it seems okay to leave them out. <civodul>it's just a matter of choosing the right code complexity/efficiency tradeoff <davexunit>it's trivial to filter them out of the inputs, so I guess that's what I will continue to do. <davexunit>the script is pretty cool so far. you can augment your current environment with the new search paths or create a "pure" environment that unsets (almost) everything first. <civodul>i realize i often clobber my main profile with tools/libs that i only need for specific developments <civodul>whereas i could keep it clean and just use 'guix environment' <davexunit>I opted to add the current working directory to the package search paths so that there could maybe be a 'package.scm' file in the root of a project's source tree and 'guix environment' will automagically read it. <civodul>so package.scm would typically contain a package definition, right? <civodul>i wonder if this should be the default, from a security perspective <civodul>in case it contains (system "rm -rf /") <davexunit>initially I had it return a package, but now I make it a module so I can use the existing package search path code. <davexunit>I just want a way for things to 'just work' so that the user doesn't have to specify extra command line arguments for a common use-case. <civodul>i sympathize with the idea of having something that "just works" <civodul>in general, search paths never include '.' by default, for that reason <davexunit>maybe 'guix environment -l package.scm' isn't so bad :) <civodul>options could be to pass "-L .", or "package.scm", or add a safe-load-search-path in the user's config (à la GDB) <davexunit>'guix environment package.scm' would be cool, though I want 'guix environment emacs' to work as well. <davexunit>where emacs is the package in the 'emacs' variable. <civodul>one of them will need an extra option :-) <davexunit>I'm curious about how to make 'development packages' like this. I don't know what to put in 'source' field, for example. <davexunit>(source ".") or does the origin record account for this? <civodul>the downside is that, if you actually try to build it that way, all the garbage found in the directory will be part of the source <civodul>origin now supports file names as well, but it's not needed here <davexunit>I'm not sure how reconcile it, because for development we don't care about the source at all since we have it. <davexunit>though, I guess it should just include the regular 'origin' record as if there was a release. <davexunit>when the software is released, the package definition in the repo can be built. <davexunit>'guix environment' won't even try to build the derivation for the source. <civodul>(source ".") should be fine, except that "." is resolved relative to the cwd of the 'guix' command <civodul>but we could use current-source-location and in-vicinity to work around that <civodul>(define-syntax-rule (current-source-directory) (or (assoc-ref (current-source-location) 'filename) ".")) <jxself>dusxmt: What do you need to change? Maybe it makes sense to include those changes in the typical version, depending on what they are. <davexunit>civodul: okay. I'll see how that goes, thanks. <DusXMT>And I agree, it would probably be good to include the option by default, because it prevents the operation of fatfs, and you sometimes need to use it <DusXMT>s/it prevents/the lack of it prevents/ <civodul>i think we're missing some kernel/udev magic somewhere <civodul>we need the expertise of jxself here :-) <DusXMT>Yes, it's exactly that. I guess I should check the bug tracker more often <DusXMT>jxself: The module is built, but simply not loaded by default, so sorry for bothering <jxself>OK, good good. I try to make the kernel as universal as possible to support as much as possible. :) ***DusXMT is now known as TMXsuD
<davexunit>sigh, it looks like the GNOME team is trying to tackle package management and continuous integration with solutions that aren't that great. <davexunit>and then of course there's their 'sandboxing' work. <jxself>Well, at least it's no t an official GNOME thing. That's good but sometimes I wonder if the GNOME people forget that they're part of GNU and, according to the GNU mainttainer info, are supposed to try to fit in. <davexunit>I like GNOME as a DE, but some of these additional projects they take on seem counter-productive. <civodul>OSTree and jhtree have been around for some time <civodul>jxself: and yes, i think GNOME developers don't feel ties with the GNU community <civodul>this is one of those recurring discussions at GHMs ;-) <davexunit>sorry for the distractions, I was just reading about a GNOME hackathon at MIT this weekend that RMS will be speaking at. <civodul>it's interesting to see what they're up to anyway <civodul>davexunit: perhaps you should chime in and shout "Guix!" <taylanub>sandboxed "apps" with a clearly defined API for communicating with the OS about certain high-level "application" concerns[*] a la Mac OS X / iOS would be pretty great actually. [*] actually only use-case I can think of thus far is reporting "I finished initializing" to the OS <taylanub>my family uses Ubuntu, and when I use their PC once in a while I have to notice how annoying it is to click on e.g. the Firefox icon then wait for several seconds with nothing happening on the screen, wondering if I misclicked :P <tadni_>Is there a reason "clear" doesn't seem to ship with GNU Distro? <tadni_>I can't seem to find it in packages either. <civodul>tadni_: it's part of ncurses, i think <tadni_>Weird. Maybe something that should ship with the distro then -- is this something people expect? <tadni_>I've never been on a distro, besides GNU, without it. <tadni_>Well, will do -- I'm just saying, you think this would be in the standard install. :^P <taylanub>tadni_: not sure if other distros install that via another package than ncurses... <taylanub>tadni_: I guess we'd eventually have ncurses among the standard installation, as other distros *tadni_ is trying to figure out how he can version control a single file in a directory. <davexunit>you could make a git repo that has a script to install the file in /etc <tadni_>taylanub: Seeing that there's been talk of a ncurses installer eventually, one way or another, yeah, ncureses will probably end up in the base install. <jxself>bzr init and then bzr add config.scm? <tadni_>I mean, I supose the only thing I'd be keeping track of in /etc is just config.scm ... so I guess I could just use a vc directly from there. <jxself>Nah. bzr would just ignore the other files since they weren't added. <jxself>Maybe git wouldn't, but then again git's strange. <tadni_>I mean, really since you can define where the config file ... I could just keep it in my home directory instead of /etc and track it there. <jxself>Like with git if I modify a file I have to go and "git add" it again when I want to commit the change. Huh? I've already added it into version control. Having to re-add it every time makes no sense to me. <tadni_>jxself: Yeah, I started using git for my main vc system and I found that odd. <paroneayea>jxself: git's staging area makes a lot more sense when you start using magit :) <davexunit>you're not adding the file, you're adding the changed hunks of that file. *tadni_ is essentially grabbing as much guile software as possible in this config.scm <jxself>BuTt if I have modified a file I am clearly going to want to commit the changes. The only benefit I can see is if you want to modify files not but not commit them until some as-yet-undefined future point which I don't ever want to do. <davexunit>not necessarily. I often commit only pieces of changed files. <davexunit>and sometimes revert the changes to other pieces. the staging area is a nice place to do this sort of surgical work. <jxself>Maybe civodul can be convinced to fly in from France. <jxself>Looks like the new linux-libre is queued because it can't connect to hydra.gnunet.org. <jxself>Why doesn't it try another machine? <jxself>Looks like it just keeps trying over and over. <davexunit>paroneayea: I'm going to propose a talk about guix for LP <davexunit>but I need to come up with an attractive description and tie it into the theme <civodul>jxself: good question, it should normally try another one <civodul>jxself: so it just keeps trying to use the only machine that's free, hopeing it'll eventually become available <jxself>Stuff's been building for almost 8 hours? <civodul>jxself: it's the transfer of TeXLive that takes time <civodul>and transfers are a criticial section <jxself>Well, eventually wildebeest will free up then. <jxself>And here I was thinking wildbeest would make things super fast. I guess it's not beast enough. :) <civodul>bandwidth is a bottleneck for TeX Live <civodul>we should really package it differently, so it's not so big <jmd>civodul: Are the docs separate? They take up a large amount of space. <jmd>Then I would recommend having a separate output for docs or something. <jmd>So there is a separate "doc" ?? <civodul>then there's 1.4 GiB in texmf-dist/fonts <jmd>civodul: tex is indeed strange. <jmd>But I'm sure Karl Berry would give advice if needed. <jmd>Why is there no installable image for mips64-el ? <jxself>It's not bootable yet, as I understand things. <jxself>The kernel doesn't build. I'm not sure what other problems there are. <civodul>jmd: if GRUB works on those machines, that should be easy; otherwise not <jxself>And I don't have one of those machines to play around with to make it work. <jxself>I think mark_weaver is our resident expert. :) <mark_weaver>last I checked, linux-libre compiled with gcc newer than 4.7.x produces a kernel that fails to boot. <mark_weaver>also, the Yeeloong requires lots of patches that aren't yet upstream <mark_weaver>also, I remember having problems with 3.15.x so I'm still on 3.14.x. <mark_weaver>GRUB does work on the Yeeloong 8101B (the one I have), and in fact it can (optionally) be used as the BIOS itself, replacing the one that comes with the machine. <mark_weaver>however, I haven't yet had the courage to flash it, since I lack the tools to recover if I bricked the machine, and it's still my primary machine for many tasks. <mark_weaver>also, we can't currently build grub in guix on mips64el, because our recipe depends on qemu which fails to build on mips. <mark_weaver>so many problems on mips, and I have very limited time to work on it (and waning interest) <civodul>i don't get why QEMU fails to build on MIPS, weird ld error <tadni>Reconfiguring this config.scm file, and it fails trying to compile net-tools. <davexunit>civodul: to what procedure(s) do I pass the values of the standard build options ('substitutes?', 'cores', etc.)? I'm not working on code now but I remember being slightly confused last night trying to identify the place where it all happens. <davexunit>sorry if the question is silly. I can just read the code some more. <jmd>What does ,@ indicate ? <davexunit>unquote-splicing is like unquote, except that it splices the unquoted list into the result. <davexunit>whereas regular unquote would yield (1 2 3 (4 5 6)) <jmd>Then why not write '(1 2 3 4 5 6) <davexunit>the above example is just to demonstrate the function. <jmd>Oh your second example makes that clearer. <jmd>What would `(1 2 3 ,(list 4 5 6)) do? <davexunit>but yeah, rather than having a nested list, it is spliced into the current list. <davexunit>I'm guessing you found some guix code that uses it? it's used a lot. <civodul>davexunit: set-build-options, from (guix store) <civodul>for 'guix environment' you may want to use set-build-options-from-command-line, from (guix scripts build) <davexunit>oh that's perfect. can't belive I missed that. <tadni_>So, very odd ... letting my config build again, inside an Emacs session ... and it seems to have made it past compiling net-tools. <tadni_>Doesn't seem to make much sense. <civodul>the log of the failed build should still be under /var/log/guix <jmd>"boost" should be renamed "beast" <civodul>tadni_: yes, but you can look for */*-net-tools* in there <tadni_>Just grep'd the directory, and there's no net-tools in there. :^P <civodul>you should use "find -name \\*net-tools\\*", not "grep" <civodul>now, if the failure was during a substitute download, there won't be any log, i think *tadni_ really needs to take an intro to unix course, or something. <tadni_>I mean, I assume it compiled now? It's been compiling for like 3 times as long in Emacs as the original time it took fail in a plain tty... <tadni_>If that is the case, that's very odd. <tadni_>Maybe having a graphical session is radically slowly down the compiltatin process on this old machine and it just hasn't even gotten there yet... <civodul>having a graphical session shouldn't have a noticeable effect on compilation time <tadni_>civodul: Well, I assume it would have a slight one on this machine. It's maxed out on 2gb of ram and is running a 4 year old, 1 core celeron. <tadni_>So why is the Linux-libre kernel even building in the first place, because it got updated recently, and the binary/substitutes aren't yet available on hydra? <jxself>3.17 is finished for x86-64 though. <tadni_>Yup, just took much -- much longer to get to net-tools, as expected, it failed. <civodul>tadni_: net-tools should be fixed now <davexunit>does anyone know if any of our 'guix system' commands behave like 'nixos-container'? <davexunit>I know that we can create a vm that shares the store with the host system, but I don't think that we can actually create containers. *tadni_ wasn't even aware. <davexunit>once I get 'guix environment' upstream, I want to work on other tools to further automate development environment setup. <davexunit>the next step is to create a script to replace vagrant :P