IRC channel logs


back to list of logs

<isd>Nope, still not working. Here's the current error message:
<alezost>isd: could you paste your feh.scm?
<isd>I just pasted the output of sha256sum -- not sure how it's supposed to be formatted.
<isd>(note: I haven't added the dependencies yet, I'll do that before I'm done.)
<isd>(also, probably the "(description synopsis)" thing should change eventually...)
<civodul>isd: use "guix hash" instead of sha256sum
<isd>civodul: ah.
<civodul>it computes the same thing, but prints it in the right format by default
<isd>Yeah, I assumed it had to be something with the formatting.
<isd>Okay, now I'm getting this:
<isd>which looks the same as the thing I hit when trying to install the distro in a vm -- which I left on hold
<isd>Not sure I get what the ~S is supposed to be.
<a_e>Could you maybe post the full recipe?
<isd>a_e: except for the hash it's unchanged from the last thing I posted, but sure:
<alezost>isd: shouldn't it be (@ (gnu packages feh) feh) not (@ (gnu packages feh) feh-2.12) ?
<isd>alezost: if you say so -- I kinda just snagged an example from the manual, which had the version number in it.
<alezost>isd: also i think it's not needed: you can use "./pre-inst-env guix build feh"
<isd>alezost: I get the same error without the version number.
<isd>where is the pre-inst-env script?
<isd>nevermind, found it
<alezost>isd: in the git root dir
<isd>guix build: error: feh: unknown package
<isd>That's I think why I was doing the expression - I bind-mounted the relevant part of the git source tree over the installed version of the packages directory...
<a_e>If you add a new file, you need to mention it in
<isd>good to know
<alezost>isd: is your feh.scm in the gnu/packages/ dir?
<isd>alezost: yes.
<isd>should it be somewhere else?
<a_e>See .
<alezost>isd: no, it should be there
<alezost>isd: hey, it should be (define-public feh ...) not (define feh ...).
<isd>in that case is wrong
<isd>Okay, that fixed the error, looks like it's actually trying to do something.
<bavier>isd: if you use #:export in the module definition, you can use (define feh ...)
<isd>bavier: I mean, either way is fine, but the manual example is wrong.
<bavier>isd: it seems it is
<tahfy>how would you go about trying to package clojure? since it's basically just a java lib?
<davexunit>civodul: thanks for the review. I will address comments soon.
<civodul>tahfy: the problem is that Java is currently missing
<civodul>so that's where one would need to start...
<davexunit>still not sure what's going on re: guix download
<tahfy>civodul: yeah
<civodul>tahfy: so if you're new to Guix, i would suggest starting with something simpler than OpenJDK
<civodul>mark_weaver: bash-cve-next is half-built; any opinion on what to do next?
<a_e>Wait for the next cve.
<civodul>ok, that's it for today
<civodul>good night/day
<civodul>& happy hacking! :-)
<a_e>Good continuation!
*davexunit is working on rubygems
<davexunit>ruby is a bit of weird situation. I'd like to just download the .gem files and build packages from them, but the gem program will try to fetch dependencies from the net.
<davexunit>and the .gem file is an archive, so you can't tweak the source without extracting and rebuildings. so, I guess I need to find source releases.
<davexunit>I need to be sure that rubygems doesn't try to download things. can build processes even access the network? no, right?
<isd>davexunit: davexunit: my ruby knowledge is limited, but I don't suppose there are some libraries for ruby that let you manipulate those? I assume gem itself is written in ruby...
<isd>If I were you I might try bugging people in the ruby community.
<davexunit>isd: the path I'm taking now is to download the source tarball, run "gem build foo.gemspec" followed by "gem install foo.gem"
<isd>Are there other distros that try to do ruby packaging in a general way?
<davexunit>I guess I could see how the debian folks do it.
<bavier>davexunit: if all the dependencies are satisfied in the current environment, does rubygems still try to fetch them from the network?
<davexunit>bavier: no it shouldn't. I just want to make sure that it can't reach out to the network.
<davexunit>I imagine that the daemon already prevents that
<bavier>it does, afaik
<davexunit>I just successfully built the eventmachine gem from sources.
<davexunit>so yay for that
<isd>calling it a night. later.
<mark_weaver>sneek: later tell civodul: regarding the bash fixes: alas, there is now an official 26th patch for bash-4.3, and it includes another "eol_ungetc_lookahead = 0;" that we didn't include, and for some reason they didn't include the parser-oob patch or anything like it.
<sneek>Will do.
<mark_weaver>sneek: also, I don't know about the version number 4.3.27, since it doesn't include all of the fixes of the real 4.3.26, and we don't know what .27 is going to be.
<sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs
<mark_weaver>sneek: later tell civodul: also, I don't know about the version number 4.3.27, since it doesn't include all of the fixes of the real 4.3.26, and we don't know what .27 is going to be.
<sneek>Got it.
<mark_weaver>sneek: later tell civodul: so, I'm thinking that maybe we should _not_ merge the branch, and instead redo it differently and rebuild again.
<sneek>Will do.
<mark_weaver>sneek: later tell civodul: and now there's an official bash-4.3.27 patch, and it still doesn't include parser-oob. instead it has a variant of the variables-affix patch.
<mark_weaver>sneek: later tell civodul: I guess patch 27 makes the parser-oob patch much less important. I would advise scrapping bash-cve-next and just using the upstream bash-4.3.27 as-is.
<sneek>Got it.
<mark_weaver>sneek: later tell civodul: okay, I ended up pushing another branch 'bash-cve-bis' with a modified version of your patch from 'bash-cve-next'. this includes the upstream bash 4.3.27 plus the parser-oob patch. I've deleted the other bash-related jobsets from hydra and added a new one to build the 'bash-cve-bis' branch.
<phant0mas>good morning guix
***tschwing_ is now known as tschwinge
<civodul>Hello Guix!
<sneek>civodul, you have 8 messages.
<sneek>civodul, mark_weaver says: regarding the bash fixes: alas, there is now an official 26th patch for bash-4.3, and it includes another "eol_ungetc_lookahead = 0;" that we didn't include, and for some reason they didn't include the parser-oob patch or anything like it.
<sneek>civodul, mark_weaver says: also, I don't know about the version number 4.3.27, since it doesn't include all of the fixes of the real 4.3.26, and we don't know what .27 is going to be.
<sneek>civodul, mark_weaver says: so, I'm thinking that maybe we should _not_ merge the branch, and instead redo it differently and rebuild again.
<sneek>civodul, mark_weaver says: and now there's an official bash-4.3.27 patch, and it still doesn't include parser-oob. instead it has a variant of the variables-affix patch.
<sneek>civodul, mark_weaver says: I guess patch 27 makes the parser-oob patch much less important. I would advise scrapping bash-cve-next and just using the upstream bash-4.3.27 as-is.
<sneek>civodul, alezost says: Hey, initially I suggested something for "" to take care about the users who don't have Emacs installed, but you said there's no need. And now you are adding "HAVE_EMACS" there. I feel aggrieved :-(
<sneek>civodul, alezost says: Joking :-) Would it be OK if I'll push a couple of small fixes and not interesting internal changes to Emacs UI without mailing to guix-devel?
<sneek>civodul, mark_weaver says: okay, I ended up pushing another branch 'bash-cve-bis' with a modified version of your patch from 'bash-cve-next'. this includes the upstream bash 4.3.27 plus the parser-oob patch. I've deleted the other bash-related jobsets from hydra and added a new one to build the 'bash-cve-bis' branch.
<civodul>mark_weaver: using the official patches is indeed better, thanks!
<civodul>alezost: ok to push small fixes to the elisp code
<civodul>alezost: re HAVE_EMACS, i thought the thing should work for people who don't have Emacs
<civodul>and yesterday we realized "make" would fail with "no: command not found"
<civodul>because $EMACS would be "no"
<civodul>that's not what we aimed for, is it? :-)
<civodul>perhaps i should have discussed on list, apologies if you felt offended
<phant0mas>hey civodul
<phant0mas>working on the crossbase patch so we can merge it as well
<phant0mas>right now in crossbase there are 2 cross-libc, the one about linux and the one I added about hurd named cross-libc/hurd
<phant0mas>I am resending the updated cros-libc/hurd so you can have a look, but I think I should merge those two
<civodul>hey phant0mas
<civodul>ok, we'll see
<mongrol__>is it possible to install tge gnu-system in a chroot?
<civodul>phant0mas: i've just re-rebased wip-hurd on master
<mongrol__>I don't have any spare metal lying around and qemu console is bugged
<phant0mas>civodul: thank you :-)
<civodul>mongrol__: then perhaps you could installed Guix on top of your other distro?
<mongrol__>I was wanting to test the bare gnu-system
<mongrol__>something makes me not want to mix packaging systems on my debian box
<civodul>to really avoid mixing, you'd need either a VM or a separate partition or machine
<civodul>but IMO mixing is OK, but Guix packages go to their own place
<civodul>so they don't interfere
<mongrol__>yeah, tried a VM but the qemu/kvm console is buggy so hard to install when text is upside down :)
<mongrol__>hmm ok, I'll look deeper into it
<civodul>to install the full system, you could also use 'guix system init config.scm /'
<civodul>and make sure there's a GRUB menu entry for the old system
<civodul>but that's more "risky"
<civodul>for instance the system will consider that it owns /etc
<mongrol__>think I'll stick with just the package side of things first
<civodul>so that could mess up with the other distro
<civodul>yes, that's easier :-)
<mongrol__>I have an ARM board coming this week, might look into cross compiling for it
<phant0mas>btw we need an ARM toolchain
<phant0mas>and an AVR
<alezost>civodul: re HAVE_EMACS, actually I knew that it would fail without Emacs since the very beginning and that's why I was surprised that you found it acceptable (apparently it was miss-understanding); but never mind, I'm glad it's fixed now
<davexunit>morning #guix
*davexunit is trying to figuring out a few things about the ruby build system
<davexunit>I have successful gem builds and gem installs, but I can't get irb to load them.
<civodul>alezost: oh ok, sorry for the misunderstanding, i really overlooked that
<civodul>howdy davexunit
<davexunit>hmm, the gems I'm building are mising files...
<Elzair>How goes the hackathon?
*civodul does groundwork to implement "grafts", for fast security updates
<civodul>Elzair: would you like to join? :-)
<Elzair>I don't know. I am just getting started with guix.
<Elzair>Is there anything rather simple to do?
<civodul>you could install it, if you haven't already
<civodul>start fiddling around
<civodul>and then start writing a package definition, to get a feel of it
<civodul> lists some ideas
<DusXMT>Elzair: I'd say the simplest thing to do (the only thing I've done so far myself) is packaging, but it depends on the package. Packages with a built system comformant to the GNU coding standard are primitively easy to package, but it can get tricky still
<DusXMT>especially if the code is old
<Elzair>Thanks. I am currently building guix.
<Elzair>BTW, can guix also serve as a language package manager for Guile?
<Elzair>Similar to npm, gems, et al.?
<davexunit>Elzair: yes
<civodul>Elzair: there are already Emacs, Perl, and Python packages, and davexunit & pjotrp are working on Ruby gems
<davexunit>I thought ruby would be easier to package for... I was wrong. :(
<bavier>I've got about 8 packages that I'd like to polish up by the end of the day
<davexunit>ruby gems are such a nightmare! one gem assumes that building occurs from a git repo!
<davexunit>how am I supposed to deal with nonsense like that?
<davexunit>I can download the .gem release file from and install it easily, but what if the source needs to be patched? ugh.
<bavier>davexunit: could you use git-fetch for the source?
<davexunit>bavier: the .git directory is removed after checkout
<bavier>oh, I see
<davexunit>this gemspec is nonsense. I'm going to find an easier gem to package.
<bavier>that is quite silly
<civodul>davexunit: it's removed because it's contents are not predictable, IIRC
<davexunit>civodul: yes, and that makes perfect sense.
<davexunit>I'll try to package a ruby gem that doesn't require building native extensions
<davexunit>if I can get the build system to work for that, I'll be happy.
<davexunit>I don't know if I should treat the .gem files provided by as the release tarball or if I should find regular source tarballs.
<davexunit>the .gem files are tarballs with some extra meta-data that can be unpacked with 'gem unpack'
<davexunit>anyone have an opinion on this?
<bavier>is the metadata useful?
<davexunit>the metadata is in the regular source too, but the gem feels more like an official release tarball. the source code downloads are typically just git snapshots.
<davexunit>whereas the gem should include only the stuff worth distributing, no .gitignore and such
<bavier>if the .gem files are what developers consider more official, I'd think we should use those.
<davexunit>I'll go with that for now, then.
<civodul>if the .gem is an archive, i imagine it could be used directly, perhaps with a specific 'unpack' phase
<davexunit>civodul: yes, it is an archive. the 'unpack' phase runs "gem unpack foo.gem"
<civodul>sounds good
<davexunit>and then we rebuild the gem with "gem build foo.gemspec" after the usual shebang substitution and such
<davexunit>the problem is that some gemspecs make horrible assumptions like expecting to be within a git repo.
<bavier>does anyone have knowledge about using dbus sessions within guix's build chroot's?
<civodul>i think it's impossible or tedious
<civodul>because dbus-daemon will try to listen to /var/dbus/...
<civodul>and it won't have access to that
<bavier>e.g.: I get:
<bavier>Failed to start message bus: Failed to read directory "/gnu/store/y6n7h8h42r1ipwvwrm24q75sl7wj4c6d-dbus-1.6.4/etc/dbus-1/session.d": No such file or directory
<bavier>EOF in dbus-launch reading address from bus daemon
<bavier>I guess I could disable the tests and hope thing work...
<civodul>session.d is really missing?
<bavier>for me, yes
<civodul>this particular problem can probably be fixed in the dbus package
<bavier>I just have session.conf, and system.conf
<civodul>same here
<civodul>you could try throwing an mkdir and see if that's enough to placate it :-)
<civodul>i suspect it won't be enough, but still worth trying
<bavier>civodul: I'll try that
<bavier>now the tests only segfault ;)
<DusXMT>bavier: that reminds me of what happens when I try to run gnumeric
<bavier>DusXMT: outside of a build?
<DusXMT>bavier:yup, just running the built, installed package. It also wanted a dbus session, and once I created it (mkdir and something else), it worked but segfaults when I try to save or open any spreadsheets
<davexunit>ruby gems are infuriating, going to give up for the day soon and go back to importer fixes.
<bavier>DusXMT: that doesn't sound good
<DusXMT>yup. I should probably consider sending a bug report one day... but I just haven't examined the problem thoroughly enough to do that, I might have done a silly mistake
<DusXMT>s/have done/have simply done/
<civodul>davexunit: might be better to let gems rest for a while ;-)
<davexunit>finally found a well behaved gem.
<davexunit>no native extensions, no dependencies besides ruby, and a proper gemspec.
<davexunit>decided that upstream tarballs were a better way to go than pre-built gems.
<davexunit>so we'll have a build system for gems that actually follow the standard rubygems procedure.
<davexunit>and perhaps pjotrp can expand upon it if he finds limitations.
<civodul>that's nice
<civodul>the intermediate package representation allows me to get rid of a bunch of stuff in build systems
<civodul>now i'm making sure nothing breaks, and that means all build systems + cross-compilation
<davexunit>civodul: oh wow! I'm excited!
<civodul>yeah it feels better than what we had so far
*davexunit is sending a new ruby patchset to the list.
<pjotrp>davexunit: I can understand the frustration - people don't realise it, but Ruby gems have gotten pretty hairy
<pjotrp>I am actually of the opinion we should treat gems just as other software packages
<pjotrp>provide a build for each and deploy them in their own space
<pjotrp>Although we should allow people to install gems locally - because that is what developers want
<davexunit>pjotrp: they can still use bundler for that
<davexunit>I just sent 3 patches to the list. the last one adds our first ruby library package: i18n
<pjotrp>I don't like the way Nix has gone - it provides no guarantees to generate packages automagically
<davexunit>what do you mean?
<davexunit>(I don't know if we can guarantee that, either)
<pjotrp>Still, if someone feels heroic we can add that route
<pjotrp>We can guarantee a package that builds, has controlled dependencies and is tested by someone
<pjotrp>downside is that we won't support thousands of gems
<pjotrp>for now ;)
<pjotrp>And cool about the gem - I hope to add a few soon
<davexunit>ohhh because nix imports a ton of gems that haven't been tested?
<davexunit>pjotrp: I'm interested in what your experience will be adding gems. I think it's important to get the commonly used testing gems packaged first.
<davexunit>otherwise we'll have to disable tests everywhere.
<davexunit>rspec, cucumber, and it's associated dependencies will be plenty of work.
<davexunit>pjotrp: I'm interested in what you think of the ruby build system. it's quite basic, but it follows the steps that provides for building and installing gems from source.
<pjotrp>yes, looks good.
<pjotrp>minitest and rspec are the important ones
<davexunit>I found a circular dependency for minitest...
<davexunit>minitest depends on hoe, and hoe depends on minitest.
<davexunit>not sure how to deal with that
<pjotrp>tah - thank Guix/Nix for bringing that out :). Sound like an upstream fix.
<pjotrp>anyway, I think this weekend gave a great start for future Ruby work
<pjotrp>Maybe some Rails deployment people should take note to speed things up. We actually could bring it up on the ML.
<davexunit>pjotrp: do you think they would be interested? I know a lot of them are OS X users, and I don't know how guix runs on it.
<pjotrp>The Rails deployments are all Linux
<civodul>davexunit: it doesn't, and never will :-)
<pjotrp>Probably using docker and such
<davexunit>pjotrp: good point. we could use their help if they are willing.
<davexunit>being able to deploy rails apps with guix would be a good sell ;)
<pjotrp>let's work on that. First the testing gems, I agree.
<davexunit>pjotrp: a few minor fixes to do and all 3 patches are going upstream. :)
<davexunit>thanks for your help with tihs
<davexunit>taking a break for a bit.
<davexunit>hey cmhobbs
<cmhobbs>hey hey!
<cmhobbs>i know little to nothing about guix, how can i help!
<civodul>hello cmhobbs!
<davexunit>you can download the source code try to get the package manager running.
<cmhobbs>i should probably do that in a vm, yeah?
<cmhobbs>rather than pollute my system here
<cmhobbs>any particular distro worth trying it on?
<civodul>Guix installs packages in its own place
<civodul>so it's not very intrusive
<davexunit>yeah, I run guix on my debian machine
<civodul>you can always choose whether to use packages installed with Guix or with your other distro
<cmhobbs>i'm going to toss it into trisquel, that's what i use most often
<cmhobbs>been considering a move to debian, though. just haven't had the time
<cmhobbs>i'm really excited to try guix out. i've been following it for a while
<_`_>supposing I don't want to use binary packages, can guix be installed completely locally?
<_`_>with nix I had trouble doing that
<_`_>some of the hardcoded stuff was still pointing the store to /nix or whatever even it was configured to have the store elsewhere at compile time
<davexunit>_`_: you don't have to use binary substitutes, if that's what you mean. you can compile everything from source.
<DusXMT>davexunit: I think his question was if he can install it as a non-root user, but I'm not sure if I got it right
<_`_>well no, that's not the question. Do I have to keep the store in a specific location? or is it unproblematic to install it elsewhere within ~ for example.
<davexunit>DusXMT: ah, you were right.
<_`_>with nix, while it was possible to install the store elsewhere, I encountered a lot of problems.
<davexunit>_`_: you can install the store anywhere.
<_`_>oh okay, glad you guys have that working.
***philed` is now known as philed
<a_e>Hello, guix hackers!
<davexunit>hey a_e
<civodul>howdy, a_e
<a_e>Quite well. You saw I checked in my one-line fix that took me a day to work out ;-)
<civodul>yup, nice to see :-)
<a_e>Now my "Hello, world" window in Qt executes without complaining about a missing icu library.
<a_e>Kdelibs compiles, but fails its tests. I am recompiling without test, and will try the KDE Hello world then.
<a_e>It looks like you have been busy with ruby, nice!
<cmhobbs>currently trying to build guix under xubuntu and then i'll make an attempt with trisquel
<a_e>Why trying out several distributions?
<a_e>Guix is quite distribution agnostic, you just need its prerequisites to be installed.
<cmhobbs>a_e, i use trisquel on all of my machines except my mac mini (wireless drivers). i'd like to be rid of this machine but it's what i've got for now
<a_e>Okay. Keep us updated how it goes!
<cmhobbs>will do!
<cmhobbs>i've got a few hours of free time while my wife and son are out. i plan to learn a little more about how guix works so maybe i can contribute some
<cmhobbs>i need a good side project
<a_e>Following the manual, it should be easy peasy.
<cmhobbs>looks easy enough at this point
<cmhobbs>watching the february fosdem guix talk, i just learned that guix can do per-user installations. that's really rad
<a_e>Yes. I think that is one of its major features!
<davexunit>civodul: potential issue with the test suite. The module (guix snix) no longer exists in my source tree, but since I installed guix to my system, the module is still in guile's load path when tests are run.
<davexunit>so, I don't see the test failure that I'm expecting.
<a_e>I think that from time to time, it is good to rm -rf $PREFIX/share/guile.\\
<davexunit>I'd like to alter the test env to make sure this can't happen.
<davexunit>but not sure how...
<a_e>The other day, I had two sqlite packages, for instance: one installed into sqlite.scm; one in the newly consolidated databases.scm.
<a_e>I am not sure which one was selected.
<davexunit>I guess I need to use guix to purify my test env :P
<cmhobbs>i think i have a successful install on xubuntu, reading docs now and nearly have an install up on trisquel
<davexunit>another reason why the world needs 'guix environment' :)
<cmhobbs>how can i run the tests in the source?
<davexunit>make check
<cmhobbs>ah, finally building on trisquel
<cmhobbs>well, in trisquel, guix package --install=hello causes a stack trace to appear quite quickly, then logs me out
<cmhobbs>i'm going to see if that occurs in xubuntu
<cmhobbs>time to find out...
<cmhobbs>yeah, it kicks me out of xubuntu as well
<cmhobbs>i couldn't get a stack trace though
<cmhobbs>i ran it in a tmux session so i'll see if it killed tmux, too
<cmhobbs>it killed the tmux session as well
<cmhobbs>going to see if i can pull it off via ssh and capture the stack trace
<cmhobbs>here's the only output i have:
<cmhobbs>it killed my ssh session
<cmhobbs>any way to get more debugging info from it?
<cmhobbs>it killed the daemon (with no output) as well
<davexunit>cmhobbs: how are you starting the daemon?
<cmhobbs>nothing strange in the logs
<cmhobbs>sudo guix-daemon --build-users-group=guix-builder
<cmhobbs>my user is in that group
<davexunit>I don't think your user needs to be in that group, but that shouldn't have anything to do with the crash.
<cmhobbs>yeah and the output didn't tell much
<cmhobbs>is there a verbose knob?
<davexunit>it sounds like a rather nasty crash, I don't know how much info you can get out.
<cmhobbs>no logs, no core files
<cmhobbs>just kicks me out of my session
<davexunit>it's gotta be an easy fix, but I don't recall anyone running into this.
<cmhobbs>i'm going to try it on my netbook once it's done building but i don't know how much it'll change
<cmhobbs>i did that in a box stock trisquel 6 vm, and on xubuntu 14.04
<cmhobbs>it is currently building on my netbook
<davexunit>cmhobbs: this probably won't help you regarding the crash, but that log message indicates that it's going to build everything from source.
<davexunit>you'll want to authorize binary substitutes
<davexunit>run 'guix archive --authorize <' from the root of the guix source tree
<cmhobbs>where can i find that key?
<cmhobbs>i assume that is a gpg pubkey
<davexunit>wherever you downloaded the guix source
<mark_weaver>cmhobbs: the problem is that your user is in that group. it shouldn't be. it must not be.
<mark_weaver>the daemon considers every user in that group to be under its control.
<cmhobbs>roger that
<cmhobbs>i'll take it out
<mark_weaver>it chooses a user from that group to do builds, and when the build is done, kills all processes by that user.
<mark_weaver>in this case, I guess it chose your user to do the build, and when it was done, killed all your processes.
<davexunit>oh wow. I didn't think that would cause such a crash.
<davexunit>good to know!
<mark_weaver>another user ran into the same problem once. we should probably make it explicit in the manual "do _not_ add any other users to the guix-builder group!
<cmhobbs>i then have this issue: guix package: error: build failed: the build users group `guix-builder' has no members
<mark_weaver>cmhobbs: is there a 'guix-builder' entry in your /etc/group? it should list all of the build users there.
<mark_weaver>also, after making these changes (removing yourself from the group, adding the others), you might been to restart the daemon.
<cmhobbs>there is
<cmhobbs>alright, i'm confused
<cmhobbs>do i need a sole user established for building things?
<cmhobbs>the group exists and i added myself to it. i'm running the daemon as root, specifying that group
<cmhobbs>currently, there aren't any users in that group
<cmhobbs>that's why i intially added myself
<mark_weaver>you need dedicated users for doing the builds, users that don't do anything else.
<cmhobbs>because i got the 'has no members' issue
<cmhobbs>alright, i'll add a guix user then
<davexunit>there's a snippet in the docs that will make a pool of usrs
<davexunit>it's good to have a bunch of them
<davexunit>for simultaneous builds
<cmhobbs>ah right
<mark_weaver>we recommend adding several, so that it's possible to run multiple builds simultaneously. each user can only do one build at a time.
<cmhobbs>looks like i skipped a step there
<mark_weaver>that's by design, to ensure isolation between the build processes.
<cmhobbs>i still can't find that pubkey. i got my copy of guix from
<davexunit>hmm, I guess the release tarball doesn't include the key
<mark_weaver>hmm, I wonder if it was added since the last release, or if it's not included in the dist files.
<davexunit>it's been there well before the last release.
<cmhobbs>davexunit, thank you
<mark_weaver>indeed, and it's in dist_pkgdata_DATA as well
<cmhobbs>well, hello is building
<mark_weaver>I wonder why it's not in the tarball.
<cmhobbs>glad to know i just didn't RTFM
<davexunit>accidental omission, probably.
<mark_weaver>cmhobbs, davexunit: I just downloaded guix-0.7.tar.gz and unpacked it, and is right there in the top-level source directory.
<davexunit>ah, so it is there after all. I didn't actually check.
<cmhobbs>what's the license on the guix logo? i'd like to use it on a blog post
<cmhobbs>mark_weaver, i'm clearly not the most observant of hackers
<cmhobbs>found the license for the logo
<mark_weaver>no worries, glad you got things working!
<civodul>davexunit: the problem is we can't really unset or override GUILE_LOAD_PATH in test-env, because it might be useful
<mark_weaver>also, guile needs to get at it's own modules
<civodul>guile would find its own module even if GUILE_LOAD_PATH is unset, but there could be some other library that would not be found
<civodul>like GnuTLS, guile-json, etc.
<davexunit>civodul: yeah, I couldn't find anyway to prevent those unwanted results.
<mark_weaver>right. I was thinking that if guix was installed in the same prefix as guile, then it would necessary to go further and remove things from %load-path and %load-compiled-path, but that you'd have to somehow include guile's own modules while excluding the older guix installed modules.
<mark_weaver>I don't remember off-hand if the guix installed modules end up in the same place as guile's own modules.
<mark_weaver>(in the same %load-path entry, I mean)
<davexunit>they end up in the site/2.0 dir
<mark_weaver>okay, so in theory you could remove that one, but as civodul pointed out, you'd lose gnutls etc.
<civodul>yes, so not the same place as Guile's modules
<mark_weaver>(assuming that gnutls also installed in site/2.0, which I haven't checked)
<cmhobbs>i think i'm out for the day, thank you all for helping me get guix set up!
<cmhobbs>i wrote a little about my experience today here:
<cmhobbs>i'm going to keep playing with it
<cmhobbs>hopefully i'll learn enough to add packages and maybe contribute some code
<cmhobbs>thanks again!!!
<mark_weaver>cmhobbs: okay, thanks for stopping by!
<civodul>see you later, then!
<mark_weaver>hmm, that page renders as two blank pages, side by side, on GNU IceCat.
<mark_weaver>maybe it's because of some extensions I'm using.
<mark_weaver>works in conkeror
<davexunit>it's an odd page
<mark_weaver>although the left side is off the left edge of my window, so I can't read it. I guess my screen isn't wide enough :(
<davexunit>doesn't render quite right for me either
<davexunit>there's 3 columns that you can scroll
<mark_weaver>well, looks like the right page is the one I want to read anyway :)
<davexunit>cmhobbs: 'Scheme' got truncated to 'S', btw
<civodul>cmhobbs: your wiki system is very nice BTW
<cmhobbs>fixed, thanks. the site is running smallest federated wiki, it's a node application so it's heavy on the javascript
<cmhobbs>civodul, thank you!
<cmhobbs>given it's js heavy, i'm sure it's probably rough to use. i can't use it in midori at all
<mark_weaver>I'm running noscript, but I told it to temporarily allow scripts from your page. no dice though..
<cmhobbs>i use abrowser (trisquel's de-branded firefox)
<cmhobbs>i don't believe i'm pulling scripts from other pages. i may need to comb through and make sure though
<cmhobbs>i got rid of most of the remote scrips
<cmhobbs>i've been experimenting with sfw because of it's json output
<mark_weaver>noscript and requestpolicy are the two likely culprits. either that or icecat is too old.
<mark_weaver>oh, and cookiemonster
<cmhobbs>alright, i'm gone for real. waiting on hello (binary) to install on this machine. it worked (building from source) under xubuntu. i'll report back later once it installs here and then dive into the guix source
<cmhobbs>is there a packaging guide?
<cmhobbs>i'll dig through the docs. i need to run out the door
<cmhobbs>take care, folks!
<mark_weaver>I disabled all extensions, and icecat still renders two blank page areas.
<mark_weaver>speaking of icecat, does anyone know what the deal is with security updates for icecat?
<mark_weaver>the recent NSS signature verification flaw comes to mind, but I suspect there have been others.
<civodul>alezost: woo, i'm impressed once again by your Emacs foo!
<civodul>pretty-sha-path.el is awesome
<jxself>What does it do?
<civodul>it prints ellipses instead of the long hashes in file names
<civodul>and it works anywhere in Emacs: shell, files, etc.
*civodul advertises it on #nixos
<davexunit>heh, guix has a nix package now.
<civodul>i had promised it long ago ;-)
<civodul>and it's useful to test the snix stuff
<davexunit>yes it is. now I don't have to compile it for myself!
<civodul>make sure to "export NIX_REMOTE=daemon"
<civodul>otherwise it'll try to access the db and fail
<davexunit>pushing the ruby stuff to master. woo!
<davexunit>civodul: thanks for the review
<isd>Hey all -- I've got a recipe I'm working on, and am trying to build it (for the first time). I running guix on top of an existing system, and haven't previously built any packages, so it seems to be pulling in everything. It seems to be trying to build everything in /run/user/$UID, which is mounted as a tempfs. That directory seems to be managed by systemd somehow. Unsurprisingly, it's running out of space when building gcc.
<davexunit>isd: did you enable binary substitutes?
<davexunit>'sudo guix archive --authorize <'
<isd>It was giving me some errors about that -- wasn't sure what that meant. That makes sense, I'll try it.
<alezost>civodul: thanks, already tried it? You are fast :)
<alezost>civodul: btw, it does not work everywhere: programmatically generated buffers often does not support font-locking, so "pretty-sha-path-mode" is not enabled in such modes (like help-mode).
<alezost>civodul: Also *Guix Package Info* will work properly with pretty-sha-path-mode after <>
<civodul>alezost: of course i've already tried it :-)
<civodul>in shell-mode and while editing a .drv
<davexunit>civodul is the fastest gun in the west
<civodul>perhaps pretty-sha-path-mode could also be added to the repo
<davexunit>how do y'all use guix.el within the pre-inst-env ?
<alezost>civodul: meh, perhaps it may be a guix package but not in the repo IMHO
<a_e>I do not find a "hello world" for kde4! Clicking on a supposed one slily leads me to an example for kde5.
<a_e>Or so it looks.
<davexunit>alezost: heh, someone's already submitted your elisp package to MELPA.
<alezost>davexunit: My variant of using is strange I think: I modified "emacs/guix-helper.scm" a bit to make 'updates-dir' point to the git repo instead of "~/.config/guix/latest". I did so with "scripts/guix" as well.
<alezost>davexunit: ouch, people are really fast now :-)
<a_e>Hm, I just did not find the header files: KApplication resides inside a subdirectory KDE, and all it does is this:
<a_e>#include "../kapplication.h"
<civodul>writing apps for KDE must be very simple :-)
<davexunit>alezost: what theme is that in your screenshot?
<a_e>Just type "cmake ."!
<a_e>"Could not find X11"
<a_e>I did install libx11 with the same result.
<alezost>davexunit: alect-light from :)
<davexunit>you're an emacs wizard
<davexunit>I haven't ventured into how themes work so I don't know how to tweak them to my liking
<davexunit>and my sense of color isn't very good
<civodul>we need a screenshot section on the web page
<a_e>The culprit is FIND_PACKAGE(X11 REQUIRED).
<civodul>NO NEED TO YELL, CMAKE ;-)
<a_e>I have the suspicion that as usual, it does not honour CPATH and LIBRARY_PATH, but looks for things in /usr/include etc..
<davexunit>yeah, I encountered issues like that with cmake, too
<davexunit>for minetest, I had to modify the CPATH var
<davexunit>but it looks like that is not working for you
<a_e>There is documentation. I need to look into FindX11.cmake.
<a_e>499 lines.
<a_e>Right at the beginning, there isL
<a_e> /usr/pkg/xorg/include
<a_e> /usr/X11R6/include
<a_e> /usr/X11R7/include
<a_e> /usr/include/X11
<a_e> /usr/openwin/include
<a_e> /usr/openwin/share/include
<a_e> /opt/graphics/OpenGL/include
<a_e> /opt/X11/include
<a_e> )
<a_e> /usr/pkg/xorg/lib
<a_e> /usr/X11R6/lib
<a_e> /usr/X11R7/lib
<a_e> /usr/openwin/lib
<a_e> /opt/X11/lib
<a_e> )
<a_e> find_path(X11_X11_INCLUDE_PATH X11/X.h ${X11_INC_SEARCH_PATH})
<civodul>they forgot /home/ludo/share
<a_e>Imagine they do this for each and every package separately, instead of AC_CHECK_HEADERS.
<a_e>How is one supposed to work with such a system???
<mark_weaver>cmake is such a nightmare :-(
<bavier>time to submite a lot of cmake bugs ;)
<a_e>I tried g++ directly, but I do not know which -l to pass; I get an "undefined reference to symbol '_ZN7QString11shared_nullE'
<a_e> error adding symbols: DSO missing from command line
<mark_weaver>maybe we should add some common utilities for fixing things in cmakefiles.
<mark_weaver>e.g. to replace those search paths with directories from the inputs.
<a_e>Nix needs to have solved the problem. I am just trying to compile the KDE Hello world by hand, but the same problems must appear in each and every kde program.
<a_e>mark_weaver: This would only work if we added libx11 as an input to cmake; plus a lot of other libraries, as they are checked for in the remainder of the cmake file. libx11 is just the beginning.
<a_e>This sounds even more like a nightmare!
<bavier>a_e: Found this:
<mark_weaver>a_e: I think you misunderstood my suggestion. I don't mean to modify the cmake package, but rather to add a (guix build cmake) module with some helpers used in recipes. I recently added (guix build emacs) to support convenient editing of emacs variable defaults, for example.
<a_e>mark_weaver: Okay. Indeed one could set a lot of environment variables.
<a_e>bavier: That seems to do the trick, thanks!
<a_e>I set
<mark_weaver>yeah, it might be possible to set more environment vars by default in the cmake build system.
<a_e>export CMAKE_INCLUDE_PATH=$HOME/.guix-profile/include
<a_e>export CMAKE_LIBRARY_PATH=$HOME/.guix-profile/lib
<bavier>a_e: glad it works
<a_e>Now it fails later: missing: AUTOMOC4_EXECUTABLE, so I probably need to install more packages.
<bavier>we should probably amend cmake-build-system to set those variables from the package inputs
<a_e>Maybe it would be enough in our build system to set these two variables to the same thing as CPATH and LIBRARY_PATH, respectively.
<a_e>This rings a bell; I think we already do it...
<a_e>Indeed we do; I added the patch myself...
<bavier>oh, strange
<a_e>It is something to add to one's .bashrc.
<a_e>This is all frustratingly complicated. I just installed libx11, automoc4 and phonon.
<a_e>The result is "missing: PHONON_LIBRARY".
<a_e>Without it, it also missed PHONON_INCLUDE_DIR.
<a_e>This is something for another time.
<bavier>a_e: bye!
<mark_weaver>civodul: what do you suppose happened here?
<civodul>if you do (bytevector->string bv "ISO-8859-1") you'll see it's a signature sexp
<civodul>and the 'hash' data is written as is, instead of as a base16 string
*civodul looks the bug archive
<civodul>wildebeest has libgcrypt 1.5.3-2ubuntu4.1
<civodul>that could be the problem
<mark_weaver>jxself: ^^
<civodul>wait, that needs investigation :-)
*mark_weaver is too impatient :)
<jxself>I have needed to reboot the machine for a kernel upgrade. Is now a good time?
<mark_weaver>spoiled by civodul's legendary responsiveness on all matters guix :)
<jxself>Ah, no - It's busy compiling stuff.
<mark_weaver>jxself: rebuilding with the latest bash patches; hopefully the last ones, since upstream bit the bullet and restricted the set of environment variable names that can hold shell functions.
<mark_weaver> for the latest progress :)
<mark_weaver>civodul: another occurrence of the same problem:
<mark_weaver>also to wildebeest.
<mark_weaver>I don't remember seeing this problem before, and now it happened twice in 40 minutes.
<RISCi_ATOM>I hate to flood the chan with stupid questions, but I'm getting the same unbound-variable : ~S (%base-file-systems) #f) error that I got 3 mo ago when I was playing with guix.
<RISCi_ATOM>I don't remember what the fix was.
<RISCi_ATOM>This was after a clean install. I was attempting to run guix system reconfigure /etc/config.scm
<mark_weaver>RISCi_ATOM: first run "guix pull" to get the latest guix.
<mark_weaver>you might also need to "guix package -i guix", I don't remember.
<mark_weaver>the problem is that guix-0.7 on the USB installer actually ends up installing guix-0.6 on the hard disk.
<mark_weaver>and guix-0.6 doesn't have %base-file-systems
<mark_weaver>(or at least that's my first guess)
<RISCi_ATOM>Sounds about right.
<RISCi_ATOM>I had to put guix down for a bit :\\
<mark_weaver>it's good to see you back here :)
<RISCi_ATOM>guix pull : error symlink : No such file or directory :\\
<RISCi_ATOM>that was with a guix pull
<mark_weaver>interesting: guile-ssh-0.6.0.x86_64-linux built successfully on the bash-cve-bis branch, despite the fact that it has been consistently failing on master.
<mark_weaver>that's the first successful build in 3 months.
<mark_weaver>RISCi_ATOM: mkdir ~/.config
<mark_weaver>(that's fixed in a recent guix, but you've got an old one for now)
<civodul>mark_weaver: re broken signatures:
<RISCi_ATOM>mark_weaver: Ya, when I get this set up I'll make my own install image ;)
<mark_weaver>civodul: hmm, is wildebeest running a very old guix?
<mark_weaver>one issue I ran into when setting up the MIPS build slave is that, by default, ssh sets PATH to some hardcoded value that was causing a different 'guix' to be used than the one I intended.
<mark_weaver>I had installed 'guix' using Guix, so it was in ~/.guix-profile/bin, and I set the PATH in the .bashrc or .bash_profile (don't remember which), but that wasn't sufficient. it was using some ancient guix that I installed long before in /usr/local/bin
<civodul>mark_weaver: i think it's actually a related but different issue
<RISCi_ATOM>mark_weaver: Thanks, it worked :3
<civodul>wildebeest runs a recent guix
<RISCi_ATOM>Are there any other bugs I should be aware of ?
<mark_weaver>so it's not sufficient to log in to a shell and then see what "which guix" says.
<mark_weaver>RISCi_ATOM: nothing comes to mind at the moment :)
<RISCi_ATOM>jxself: Looks like I'm pulling in your kernel.
<jxself>Ah. Well, the great question of if 3.17 would be released today or there would be another release candidate has been answered.
<RISCi_ATOM>(well, he packaged it, right? )
<jxself>Hmm? Oh, in Guix.
<RISCi_ATOM>jxself: Yep. I'm trying to bootstrap it on ARM
<RISCi_ATOM>With libreCMC and its toolchain.
<mark_weaver>civodul: another occurrence of the same problem:
<mark_weaver>it's almost as is something changed recently that made this problem start happening. I don't remember seeing it before, at least not in recent memory.
<jxself>I did do a package upgrade on the machine. Waiting to be able to reboot it to complete that.
<civodul>jxself: do you know if libgcrypt was upgraded?
<jxself>Not offhand.
<mark_weaver>well, I suppose we could remove it from the hydra config, wait for the current jobs to finish, reboot it, and then add it back to hydra.
<mark_weaver>jxself: you could search /var/log/dpkg.log (or whatever it's called)
<civodul>i seem to have a fix, though
<jxself>Yes, it was upgraded.
<mark_weaver>jxself: security update, or something more?
<mark_weaver>I don't remember seeing any recent libgcrypt advisories.
<jxself>Seems minor:
<jxself>2014-09-24 09:36:01 upgrade libgcrypt11-dev:amd64 1.5.3-2ubuntu4 1.5.3-2ubuntu4.1
<jxself>2014-09-24 09:36:02 upgrade libgcrypt11:amd64 1.5.3-2ubuntu4 1.5.3-2ubuntu4.1
<jxself>Okay, a security update.
<civodul>ISTR libgcrypt used to make unwise decisions when it comes to choosing between hexadecimal or raw output for byte strings
<civodul>only in some cases does it actually cause troubles
<civodul>guile: ports.c:2527: scm_i_port_iconv_descriptors: Assertion `pti->encoding_mode == SCM_PORT_ENCODING_MODE_ICONV' failed.
<civodul>there are days where nothing works as expected
<RISCi_ATOM>What xwindows packages would I be missing to get a basic session going (I installed xf86-video-intel , xorg-server, xterm)
<mark_weaver>civodul: hmm, I'll take a look