IRC channel logs


back to list of logs

<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>so, the daemon is required for guix, right?
<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?
<paroneayea>where you're doing it on a your-user level?
<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.
<davexunit>gotta go afk, now.
<paroneayea>later davexunit !
<jxself>Okay, I have a potential 3.17 kernel config now. Time to go compile the kernel and try it out first.
<paroneayea>oh, I didn't know lsh was a thing
<civodul>Hello Guix!
***civodul changes topic to 'GNU Guix | | things to package:'
<davexunit>morning, guix.
<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 ?
<alezost>Ulrar: the solution is to run "guix pull" using "guix" from the git repo:
<Ulrar>I see
<civodul>'^' in the Emacs UI really rocks
<civodul>would be nice to have something equivalent at the command line
<davexunit>what does '^' do?
<civodul>it upgrades all "obsolete" packages
<civodul>actually it's not unlike 'guix package -u .', now that i think of it
<civodul>but it's more visual :-)
<davexunit>civodul: so the bags API is pretty great.
<davexunit>guix environment works now.
<civodul>davexunit: woow, already?
<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.
<davexunit>I just replaced the search path stuff.
<civodul>well, cool!
<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
<civodul>or just use it in the OS config
<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
<DusXMT>excelent, thanks :)
<civodul>davexunit: sounds good
<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
<civodul>so whatever feels right to you :-)
<davexunit>it's trivial to filter them out of the inputs, so I guess that's what I will continue to do.
<civodul>ok, makes sense
<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.
<davexunit>a nifty feature of nix-shell.
<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>well then you're going to like this. :)
<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>or just return a package, even?
<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>yeah, that's why I brought it up.
<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.
<davexunit>but maybe that's just going too far.
<civodul>i sympathize with the idea of having something that "just works"
<civodul>i'm just slightly concerned though
<civodul>in general, search paths never include '.' by default, for that reason
<davexunit>maybe 'guix environment -l package.scm' isn't so bad :)
<civodul>yeah :-)
<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 :-)
<civodul>-l sounds natural to me
<davexunit>that's what I will do, then.
<davexunit>I'm curious about how to make 'development packages' like this. I don't know what to put in 'source' field, for example.
<civodul>you could put "."
<civodul>and i *think* that would work :-)
<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>(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>it's not a release, it's a moving target.
<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>like 'load' does
<civodul>(define-syntax-rule (current-source-directory) (or (assoc-ref (current-source-location) 'filename) "."))
<civodul>something like that
<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>jxself: The proglem I'm having is described here, except in my case a USB stick is in question:
<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>DusXMT: this sounds similar to, no?
<civodul>i think we're missing some kernel/udev magic somewhere
<civodul>same for
<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.
<jxself>What are they doing?
<davexunit>just saw this:
<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.
<davexunit>red hat's influence, I guess.
<civodul>OSTree and jhtree have been around for some time
<civodul>but yeah, they're not so great
<civodul>Nix predates them
<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!"
<davexunit>and then run away with my arms flailing
<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
*civodul has to go
<davexunit>see ya civodul
<tadni_>Yup, it is.
<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.
<davexunit>just add it to your OS config.
<tadni_>davexunit: Being config.scm?
<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.
<tadni_>Like his config.scm, in /etc
<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?
*jxself hug bzr
<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.
<davexunit>it would be awkward
<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.
<tadni_>where the config file is*
<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>the staging area is great.
<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.
*tadni_ will brb.
<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.
<paroneayea>I hope someone proposes a guix talk for LP 2014
<paroneayea>and/or a guile one!
<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
<jxself>Why doesn't it try another machine?
<jxself>Looks like it just keeps trying over and over.
<jxself>Ahoy there good sir.
<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
<jxself>Perhaps you know - Why doesn't it try another machine?
<civodul>jxself: good question, it should normally try another one
<civodul>jxself: that's because the other machine is busy, all its slots are taken:
<paroneayea>davexunit: cool
<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>this one waited for some time for wildebeest to become less loaded
<civodul>jxself: it's the transfer of TeXLive that takes time
<civodul>and transfers are a criticial section
<civodul> is busy transferring the 4+ GiB of TeXLive...
<jxself>Well, eventually wildebeest will free up then.
<civodul>same here, for
<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.
<civodul>jmd: i don't think so
<jmd>Then I would recommend having a separate output for docs or something.
<civodul>oh, ok
<civodul>actually "out" takes just 39 MiB
<jmd>So there is a separate "doc" ??
<civodul>but then "data" takes 3.8 GiB
<civodul>the "data" output, i mean
<civodul>most of which is in 'texmf-dist'
<civodul>oh it's 1.6 GiB of doc, indeed
<civodul>under texmf-dist/doc
<civodul>(what a strange location)
<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.
<civodul>yes, definitely
<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>I seem to have forgotten the details though.
<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)
*mark_weaver goes afk
<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.
<jxself>Poor 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>jmd: unquote-splicing
<jmd>in English ?
<davexunit>jmd: are you familiar with quasiquote?
<davexunit>the backtick `
<davexunit>unquote-splicing is like unquote, except that it splices the unquoted list into the result.
<davexunit>`(1 2 3 ,@(4 5 6)) yields '(1 2 3 4 5 6)
<davexunit>or rather `(1 2 3 ,@(list 4 5 6))
<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.
<davexunit>oh good.
<jmd>What would `(1 2 3 ,(list 4 5 6)) do?
<davexunit>'(1 2 3 4 5 6)
<davexunit>I made a typo in my first example
<davexunit>I forgot the 'list'
<davexunit>but yeah, rather than having a nested list, it is spliced into the current list.
<davexunit>which is frequently very useful.
<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)
<davexunit>civodul: thanks
<davexunit>I missed that
<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.
<davexunit>thanks civodul
<civodul>you're welcome!
<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"
<tadni_>civodul: Just a drvs folder?
<civodul>jmd: :-)
<civodul>tadni_: yes, but you can look for */*-net-tools* in there
<tadni_>In a *.drv.bz2?
<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_>Oh, yeah, it's there.
*tadni_ really needs to take an intro to unix course, or something.
<tadni_>civodul: Kay, thanks.
<tadni_>If anyone is interested.
<civodul>oh yes, there's the same one there:
<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.
*civodul fixes net-tools
<tadni_>Yup, just took much -- much longer to get to net-tools, as expected, it failed.
<civodul>tadni_: net-tools should be fixed now
*civodul -> zZz
<civodul>good night/day!
<davexunit>damn, just missed civodul.
<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_>NixOS has 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