IRC channel logs


back to list of logs

<vmlinuz88>paroneayea davexunit: Is there perhaps a more stable (less unstable) version of Guix than what is available in its git repo?
<davexunit>vmlinuz88: no, this is alpha software.
<vmlinuz88>davexunit Thank you; I figured as much. Also, I'm running guix as a standalone on Fedora 21; I attempted to install a package (dfc) and received the following error: Failing tests: 17: test_option_b (2 failures).
<davexunit>vmlinuz88: this failure was when compiling dfc?
<vmlinuz88>I also looked at the log for test_option_b, and it said "File archive1.tar has size 3072, expected 2048" and "bsdtar does not pad archives written directly to regular files"
<vmlinuz88>davexunit Yes
<davexunit>vmlinuz88: could you file a bug at
<davexunit>with the relevant details
<vmlinuz88>davexunit Sure thing
<davexunit>reproducibility bug
<jdahm>basic question: I'm trying to install guix from the latest .xz image directly to a virtual machine using gnome-boxes, but that only allows using .iso and devices. I've tried mounting with mount -o loop gsd.... but mount can't determine the fs type that way. I've also tried renaming it to .iso but that leads to a corruption error. Is there an easy way to do this without a thumb drive handy?
<vmlinuz88>davexunit Also, I thought guix retrieves binary packages from hydra by default, but it appears that it is trying to build the dfc package. Is there something I need to do specifically to get binaries?
<davexunit>jdahm: it's a raw disk image, yeah.
<davexunit>we don't yet provide ISOs because no one has done the work to generate one
<davexunit>vmlinuz88: you have to authorize
<vmlinuz88>davexunit Ah, okay thank you.
<davexunit>it only downloads binaries by default in the installation image
<jdahm>davexunit: yep, I got that. Is there a way to mount that in linux so that it thinks that's a device?
<davexunit>jdahm: not sure, I've never tried that.
<jdahm>davexunit: got it! used some trickery
<paroneayea>so, interesting idea I was discussing with a friend: using Guix + Hydra as a continuous integration / pipeline system for a blender free culture film
<paroneayea>why not?
<paroneayea>typically there's a complex depgraph that's more or less handled manually:
<jdahm>davexunit: basically I had to specify an offset following the response by @baumgart here:
<paroneayea>xcf files which render to png files which are used in .blend files that render to a lot of .png files that are brought into ffmpeg into a movie
<kete>you should blog that, jdahm
<jdahm>kete: yeah I've been meaning to begin a blog for this sort of thing... will get around to it soon. Adding it to my queue of posts now
<jdahm>kete: I am very interested to play around with guix, especially once it hits 1.0
<kete>yeah, me too, or .9 even. I couldn't get .8.1 installed on bare metal. A microblog mention would be fine, too. might help someone
<kete>been busy with school
<cmhobbs>is there an off chance that clojure is in guix yet?
<davexunit>cmhobbs: not yet.
<davexunit>paroneayea: that's a good idea!
<davexunit>jdahm: thanks for the link!
<davexunit>we should mention this technique somewhere
<davexunit>until we can provide ISOs
<cmhobbs>davexunit, thanks
<cmhobbs>wishful thinking :D
<davexunit>cmhobbs: someone has been working on openjdk
<davexunit>so maybe we'll see it someday
<davexunit>I imagine we're quite a few dependencies away.
<cmhobbs>i'm hoping guix hits stable before jessie replaces wheezy. my current development projects require guile, ruby, and clojure
<cmhobbs>i can get by without other packages i use
<cmhobbs>well, and emacs
<cmhobbs>yeah, we're probably a long way away
<paroneayea>cmhobbs: before jessie replaces wheezy?
<paroneayea>jessie was released!
*cmhobbs falls over
<cmhobbs>i need to come out of my cave more often
<paroneayea>just last week! :)
<cmhobbs>well, i have to update this box at some point
*cmhobbs dreads that
<cmhobbs>i fear change
<paroneayea>I think it would be great to have a guix package for debian
*paroneayea says, for the 1 millionth time ;)
<cmhobbs>i'm using guix on wheezy
<cmhobbs>not as a debian package though
<davexunit>the .deb would have to be unofficial
<davexunit>since we wouldn't meet the official debian criteria
<paroneayea>right because of the FHS
<paroneayea>davexunit: new debian leader wants to support PPAs anyway :)
<davexunit>later all
<vmlinuz88>is there a way to update or refresh the package derivations in the /gnu/store directory?
<vmlinuz88>I accidentally removed one
<rekado->re clojure: we have the JDK7, but we do not have any of the common Java build tools with the exception of ant.
<rekado->ardour fails with validate-runpaths. I'll fix it tonight.
<rekado->gcj failed in validate-runpath. I thought all gccs had their rpaths fixed.
<rekado->elogind built.
<civodul>Hello Guix!
<vmlinuz88>Hello civodul
<effa>Hi civodul
<effa>thanks for the feedback on hackage importer!
<effa>unfortunately right now I do not have time to work on it.
<effa>But, will come back to it, hopefully in 1--2 weeks.
<effa>I have a question/suggestion:
<effa>In Haskell you can sequence functions in a Monad with
<effa>m >>= f1 >>= f2 ...
<effa>As far as I understand in your guix module
<effa>(>>= m f1 f2 ...)
<effa>is not supported.
<effa>If this is correct, don't you think that it would be helpfull?
<civodul>hi, effa!
<civodul>oh, right
<civodul>it would probably be helpful indeed
<civodul>maybe not too difficult either
<civodul>(actually i mostly use mlet to hide the binds)
<rekado_>I thought it was supported already? I have my own little guile-monad module and I can sequence monadic functions:;a=blob;f=test.scm;h=02f5f0a350a99470f38d74d42a5b39276078b71b;hb=HEAD
<rekado_>isn't everything sequenced in monads? Or do you mean this particular syntax for >>=?
<civodul>oh, another monad implementation :-)
<civodul>the problem is with this particular syntax
<rekado_>I see.
<civodul>but otherwise yes, we can sequence calls with mlet, mbegin, or nested binds
<effa>yes, the question is >>= specific
<phant0mas>hey civodul did you see the updated patch?
<civodul>phant0mas: not yet i guess, but i'll get there! :-)
<civodul>i process messages mostly in FIFO order, sorry for the delay
<phant0mas>no worries, I am working on tar now, waiting for a rebuild to finish :P
<civodul>maybe you could have cheated by applying the patch conditionally
<civodul>depends on what it looks like
<rekado_>flexbar-2.5 fails with linker errors (cannot find tbb symbols), but only mipsel. I don't know how to fix this.
<civodul>no idea
<civodul>i think we should focus on fixing the x86 issues first
<civodul>texlive upgraded once again, yay!
<civodul>one has to be patient, but it eventually succeeds :-)
<rekado_>hmm, I can't seem to fix gcj. When I pass LDFLAGS=-Wl,-rpath=$out/lib as #:make-flags the LDFLAGS aren't actually set.
<rekado_>Is this something to do with the multiple phases of gcc building?
<paroneayea>hey civodul, I'm confused by
<paroneayea>"There are two things to note in the second version: the store parameter is now implicit, and the monadic value returned by package-file—a wrapper around package-derivation and derivation->output-path—is bound using mlet instead of plain let."
<paroneayea>I see no package-file...
<rekado_>paroneayea: there's a package-file in ./guix/packages.scm
<paroneayea>rekado: ah
<mthl>Hello Guix!
<paroneayea>hello mthl !
<mthl>not really interesting, but there is a show that has cited GNU dmd (actually made fun of it)
<paroneayea>oh well, I doubt many understand why dmd is interesting, there's not enough "public" use case yet
<paroneayea>guixsd raising in prominence should help
<mthl>understanding is out of bounds for this kind of show, the view is "Why the hell can't they just accept systemd"
<mthl>without acknowledging the fact that systemd support only linux
<civodul>at least they heard of dmd ;-)
<civodul>rekado_: LDFLAGS handling in GCC is very tricky
<civodul>see the gcc-libvtv-runpath.patch that i ended up with
<civodul>paroneayea: you found another issue/anachronism, i'll take care of it
<paroneayea>civodul: thanks :)
*davexunit watches the linux action show thing
*davexunit can't resist morning rage...
<davexunit>lol it was really a non-story
<davexunit>I don't know why they even brought it up without mentioning guix
<davexunit>"I read the home page summary, so now I'm going to assume that they hate systemd and laugh at it."
<rekado_>at what point did people agree on systemd as the only thing you should ever need? I remember that it was not like that when pulseaudio appeared. I wonder if there's a lesson to be learned.
<paroneayea>davexunit: which is why dmd came after systemd amirite??? ;)
<davexunit>civodul traveled back to 2003 to create dmd under a psuedonym, he then left the project dormant so that he could pick it back up in 2013 to make it seem like he wasn't just another systemd hater.
<civodul>dmd is really old
<civodul>it was very innovating back then, when you think about it
<civodul>which reminds me i never got an okay from rms to rename it to sherpherd, *sigh*
<davexunit>what was deco going to be renamed to? 'herd'?
<civodul>yes, that was the idea :-)
<civodul>rms proposed "pandemonium", which sounded quite negative to me
<davexunit>not a good name
<davexunit>too many syllables, too.
<civodul>rekado_: re, you'll probably have to take the same route as either 21e583de or the libvtv patch
<rekado_>civodul: I'm recompiling with a similar tweak right now.
<civodul>great, thanks
<paroneayea>oh no, herd?
<paroneayea>that's going to be..
<paroneayea>ambigous when spoken right?
<davexunit>whell the project would be 'shepherd'
<davexunit>'herd' is just the client
<rekado_>is the name still in the race or does "never got an okay from rms" mean that it's out already?
<paroneayea>davexunit: how about "sheep" ;)
<paroneayea>I think that herd and hurd is confusing though.
<civodul>rekado_: i think it's still in the race, rms was not opposing it
<civodul>paroneayea: the rationale was that herding is what a shepherd does :-)
<civodul>the the connection with the Hurd is fun i think
<phant0mas>civodul: one note before I leave for class, the problem I have with tar seem to be solved in commit e9ddc08da0982f36581ae5a8c7763453ff41cfe8 in their repo
<civodul>ah, that's good
<civodul>i don't see any commit in release_1_28..HEAD relating to PATH_MAX tho
<civodul>re dmd, i just found that:
<civodul>"daemon hurder", same line of thought ;-)
<rekado_>I *almost* fixed gcj.
<rekado_>oddly, lib/ is still broken while lib/ is fine.
<civodul>maybe you picked the wrong makefile variable to add LDFLAGS?
<civodul>i sympathize with you anyway, i know how it feels to try a one-liner just to get a failure 2.5 hours later :-)
<rekado_>it works for the other libraries, but not for the dummy library. Will investigate more tomorrow. Annoying.
<sirgazil>civodul: the website is in the repo now.
<civodul>oh great, thanks sirgazil!
<civodul>you've been fast
<davexunit>sirgazil: teespring says that I should get my GuixSD shirt by May 15th.
<sirgazil>ten more days? I wish shipping was faster...
*civodul missed the deadline :-/
<sirgazil>Maybe for the next-next release we can sell the shirt again and collect some money for hardware?
<sirgazil>Maybe using GNU shop.
<paroneayea>sirgazil: ooh what's this about the site?
<sirgazil>paroneayea: just a provisional HTML site built with python for the 0.8.2 release. I need more time to be able to do it with SXML.
<paroneayea>sirgazil: cool
<paroneayea>SXML, will that version use davexunit's Haunt? ;)
<davexunit>if anyone here is interested in building static sites with Guile, take a look. :)
<paroneayea>sirgazil: can't speak really for the FSF but it might be worth talking to them about it. I did talk to John recently about the possibility of Guile doing some fundraiser stuff and using the FSF's infrastructure and I know he was interested in talking about htat
<paroneayea>so anyway, I think the possibility of talking about it is open :)
*sirgazil goes check Haunt.
<civodul>sirgazil: Python, really? :-)
<davexunit>he might need some help to get everything fully guile-ified :)
<civodul>yeah, Haunt looks cool!
<civodul>i was telling sirgazil that we could start with just a raw HTML->SXML conversion
<civodul>and then start from there
<civodul>but maybe we should keep the HTML and throw Haunt in?
<civodul>what are your thoughts?
<davexunit>sxml would still be good
<davexunit>most likely
<civodul>SXML becomes interesting (compared to HTML) if we actually factorize things
<davexunit>yes, agreed.
<davexunit>more power there.
<davexunit>I think either way, moving to sxml is a good idea.
<davexunit>haunt might be too much dog fooding
<davexunit>but it would certainly help haunt cover "real world" use cases.
<paroneayea>iterative dogfooding?
<paroneayea>tail recursive dogfooding?
<davexunit>I'm still lacking a markdown parser so that I can convert my own blog.
<paroneayea>davexunit: I still wonder if shelling out to markdown parser might be a good quick-bootstrapping route
<davexunit>paroneayea: yeah, it would work.
<civodul>davexunit: so should we start by converting to sxml, and start using Haunt whenever you think it's appropriate?
<davexunit>civodul: that sounds like a good approach
*paroneayea cheerleads in the background
<sirgazil>I also want to learn doing it with SXML. But a static site builder that lets people write in their prefered format is still useful.
<davexunit>sirgazil: it's good for writing prose, yeah.
<davexunit>but for building themes and such, SXML all the way.
<davexunit>just for reference, here's what a SXML post looks like in haunt:
<davexunit>and raw html
<davexunit>the metadata goes before the "---"
<paroneayea>some day guile-emacs will be at the next stage, then maybe orgmode's parser can be refactored into a way that haunt can call out to it ;)
<davexunit>some day...
<paroneayea>then I can run my blog in orgmode + haunt! ;)
<davexunit>batch mode emacs would suffice until then
<davexunit>my problem with that was org-mode insisting on generating a complete html document, when I only want the body stuff.
<davexunit>someone told me a way around that, though... maybe. can't remember.
<paroneayea>I told you a way around it :)
<paroneayea>but maybe I should prototype it.
<sirgazil>davexunit: I get a syntax error when running haunt's ./configure:
<davexunit>sirgazil: you're missing guile's M4 macros
<sirgazil>Ah, ok.
<davexunit>test for /usr/share/aclocal/guile.m4
<davexunit>or wherever you installed guile
<davexunit>sirgazil: thanks for checking out haunt :)
<zacts>docker sucks really bad
<zacts>I'm sorry man, I had to work with it for a while
<zacts>and man it had some really really braindead bugs
<zacts>especially in regards to mounting subvolumes
<zacts>it would do strange random things
<davexunit>it's "the hottest thing" right now, though!
<zacts>and I narrowed the bug down to a specific thing on github
<zacts>yeah, all of the corporate hype
<zacts>it wasted about three days at least of my time
<davexunit>I saw a slideshow that deconstructed what "containers" really are, there needs to be more material like that.
<zacts>also, the docker build envs can build differently depending on what the host env is like
<davexunit>docker is a crappy high-level layer over namespaces, cgroups, and chroots.
<davexunit>zacts: reproducibility not as high on the priority list as that sweet sweet VC money.
<davexunit>and don't get me started about CoreOS...
<davexunit>so misguided.
<davexunit>why do you want to run an OS that is *completely* different from the OS you are deploying on it?
<davexunit>we could just as well make a small Guix image with just enough stuff to be a remote container host.
<zacts>davexunit: I saw this really great article on hackernews about guix build envs
<zacts>I can't remember the link off-hand
<davexunit>guix? really.
<zacts>davexunit: yeah, let me search for it
<zacts>like reproducible package builds
<davexunit>what is it the "Guix in an HPC environment" article?
<zacts>ah yeah, that was it
<davexunit>rekado_ wrote that. :)
<zacts>oh cool
<davexunit>there's also my older post about 'guix environment'
<paroneayea>oh hey
<davexunit>paroneayea: yessssssss
<davexunit>I can work with this!
<paroneayea>just in time from jim campbell on pump :)
<paroneayea>davexunit: you might want to provide the option to do -q
<paroneayea>since otheriwse it will open a person's *whole* .emacs for each file
<paroneayea>emacs opens fast, faster than python, for "emacs -nw -q", but not when you're opening my whole config ;)
<paroneayea>oh nm!
<paroneayea>it uses --batch.
<davexunit>the one thing I see that I want to change so far is the metadata gathering
<davexunit>it's hardcoded
<davexunit>should be avoidable
<davexunit>depending on the date parsing thing
<davexunit>here's CoreOS' container specification stuff:
<davexunit>just like docker, it's a "shove a copy of the whole distro in an image" thing
<davexunit>instead of the nix/guix route of "deduplicate everything via the store, just mount the system closure"
<sirgazil>davexunit: with haunt, where would one define custom templates and put static assets?
<davexunit>sirgazil: theming is pretty much up to you. I wrote a 'blog' procedure that generates a blog, and for that I defined a <theme> data type that could be used. needs documentation!
<davexunit>as for static assets... let me see if I committed the relevant code!
*davexunit tries to eat some of the dog food out of sirgazil's dish
<davexunit>I wrote an <asset> type
<davexunit>and perhaps more importantly, a procedure called 'directory-assets' that will read all of the files in a directory as assets.
<davexunit>we should take this to #guile, though.
<davexunit>well, I guess this is about the future of the guix website
<davexunit>so it's relevant
<sirgazil>And yes, it's for the website :)
<davexunit>(directory-assets "css" "css") would copy everything in the "css" directory of your project to a "css" directory within the output directory, recursively.
<bavier>guix should have colorized terminal output ;)
<davexunit>bavier: first it's colored text, then it's emoji!
<davexunit>give 'em an inch...
<bavier>davexunit: :P
<civodul>bavier: what makes you say so?
<bavier>civodul: I was playing with Spack, and the colors make it quite a bit easier to find messages that are comming from the builder vs the build output
<civodul>'guix build' essentially writes nothing but the build log
<civodul>but maybe for 'guix package' the messages can be confusing?
<bavier>I've not taken inventory of our different messages, so I have no concrete proposal
<bavier>but yeah, I'm not sure that we'd want the build daemon to generate terminal colors
<civodul>certainly not the daemon, indeed
<civodul>actually, i don't really like the idea of generating colors :-)
<civodul>but maybe there's something we could do in the clients
<bavier>civodul: :)
<civodul>or maybe make colors optional
<civodul>so, you're sold to Spack? :-)
<bavier>like gcc's optional colors
<bavier>civodul: not yet ;)
<bavier>I like some of their developer tools
<bavier>e.g. `spack edit`, and `spack graph`
*civodul looks
<bavier>and their version searching is interesting
<civodul>found it:
<civodul>version searching?
<bavier>I know we could do something similar
<civodul>ah yes, i had noted it in my todo :-)
<civodul>yes, it's interesting
*civodul is a bit jealous
<davexunit>we could totally have that
<bavier>the code is simple enough to read too, wouldn't be difficult to borrow some implementation ideas
<civodul>yeah it seems to be nicely written and designed
<bavier>the difference for us it that we're (usually) interested in the latest package versions, whereas Spack likes to provide access to *all* versions available
<bavier>my todo list for Guix is getting too big ;)
<phant0mas>I think I screwd something up :(
<phant0mas>suddenly lzip fails ./testsuite/ line 120: cmp: command not found
<phant0mas>thank god there is git :P
<davexunit>bavier: I think all of our todo lists for guix are actually infinite series
<davexunit>which conveniently enough we can represent with some Scheme code...
<bavier>davexunit: haha
<davexunit>paroneayea: reading the newish comments here:
<davexunit>I'm pretty sure the "nightmare" scenario is possible with guix.
<civodul>nightmare with Guix?
<davexunit>it might a be a pain to implement, but for C applications, it's already possible to mix libraries/applications that depend on the different versions of the same library.
<civodul>but we could statically check some things
<davexunit>we can totally handle the scenario outlined there.
<davexunit>it's just a matter of writing the implementation, but if npm can do it, it's possible and we can do it, too.
<civodul>"It's a difficult problem and at least npm has a way to not solve it and still get your stuff." :-)
<davexunit>A depends on B, and both A and B depend on different versions of C.
<davexunit>well, maybe this wouldn't work so easily.
<civodul>davexunit: that's a language feature
<davexunit>I could see that being an issue in C.
<civodul>npm has to handle this because JS supports it
<civodul>(which is "nice")
<civodul>but anyway, we can definitely build a DAG with different versions/variants of the same package
<civodul>it's just that usually, things will just crash
<davexunit>but if they don't in JS, then we can accomodate it.
<civodul>except for JS, that i
<civodul>that means 'guix import npm' must pay attention to the versions of dependencies :-)
<davexunit>it's not really great to be using different versions of the same library, though. yuck.
<civodul>yeah, that's terrible
<civodul>i wonder how it works at all
<davexunit>it's a free for all.
<davexunit>but yeah, the packages are namespaced somehow, and you import the library in a special way in your JS code.
<civodul>i mean object slots are referred to by name, so at least that is not sensitive to object layout
<civodul>(unlike guile structs, for instance)
<davexunit>if we start including node packages in our distro, we would of course strive to minimize the number of versions we must keep around for the same library.
<davexunit>yay more extra work
<davexunit>this is what happens when packaging is a free for all, and no one's doing the curation.
<cehteh>thats why we all love PHP :D
<civodul>woow, lots of fun on the web ;-)
<cehteh>no matter how good and experienced a programmer is, PHP makes it impossible to write safe and reliable programs
<cehteh>rasmus should apply it to the underhanded C coding contest
<phant0mas>civodul: a question, gnu-build-system uses %final-inputs to build any package, right?
<civodul>phant0mas: right, unless #:implicit-inputs? #f
<phant0mas>so if I want to patch tar, I need to have patch-final and included it in %boot6-inputs.
<phant0mas>Is my line of thought right?
*civodul looks
<civodul>phant0mas: you shouldn't need to do anything special
<civodul>see findutils for instance
<civodul>it has a 'patches' field, but things just work
<civodul>oooh wait
<phant0mas>when findutils builds, patch already exists
<civodul>phant0mas: could you post the patch and backtrace?
<phant0mas>I will wait for this build to finish and I will
<civodul>maybe you need to have patch-final in %boot6-inputs, as you note