<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 <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>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>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 gnu-system.am. <alezost>isd: is your feh.scm in the gnu/packages/ dir? <isd>should it be somewhere else? <alezost>isd: hey, it should be (define-public feh ...) not (define feh ...). <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. <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... <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. *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 <davexunit>I just successfully built the eventmachine gem from sources. <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. <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. <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. <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. <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. ***tschwing_ is now known as tschwinge
<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 "configure.ac" 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>that's not what we aimed for, is it? :-) <civodul>perhaps i should have discussed on list, apologies if you felt offended <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 <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 <civodul>mongrol__: then perhaps you could installed Guix on top of your other distro? <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 <mongrol__>yeah, tried a VM but the qemu/kvm console is buggy so hard to install when text is upside down :) <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>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 <mongrol__>I have an ARM board coming this week, might look into cross compiling for it <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 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 <davexunit>hmm, the gems I'm building are mising files... *civodul does groundwork to implement "grafts", for fast security updates <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>and then start writing a package definition, to get a feel of it <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 <Elzair>Thanks. I am currently building guix. <Elzair>BTW, can guix also serve as a language package manager for Guile? <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 rubygems.org 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 <davexunit>this gemspec is nonsense. I'm going to find an easier gem to package. <civodul>davexunit: it's removed because it's contents are not predictable, IIRC <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 rubygems.org 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>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. <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" <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>because dbus-daemon will try to listen to /var/dbus/... <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>this particular problem can probably be fixed in the dbus package <bavier>I just have session.conf, and system.conf <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 <DusXMT>bavier: that reminds me of what happens when I try to run gnumeric <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. <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 <civodul>davexunit: might be better to let gems rest for a while ;-) <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>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 <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>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>(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>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 rubygems.org provides for building and installing gems from source. <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. <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 :-) <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. :) <cmhobbs>i know little to nothing about guix, how can i help! <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>any particular distro worth trying it on? <civodul>Guix installs packages in its own place <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. <_`_>with nix, while it was possible to install the store elsewhere, I encountered a lot of problems. <_`_>oh okay, glad you guys have that working. ***philed` is now known as philed
<a_e>Hello, guix hackers! <a_e>Quite well. You saw I checked in my one-line fix that took me a day to work out ;-) <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>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 <a_e>Following the manual, it should be easy peasy. <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. <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? <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>yeah, it kicks me out of xubuntu as well <cmhobbs>i ran it in a tmux session so i'll see if it killed tmux, too <cmhobbs>going to see if i can pull it off via ssh and capture the stack trace <cmhobbs>any way to get more debugging info from it? <cmhobbs>it killed the daemon (with no output) as well <cmhobbs>sudo guix-daemon --build-users-group=guix-builder <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 <davexunit>it sounds like a rather nasty crash, I don't know how much info you can get out. <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>run 'guix archive --authorize < hydra.gnu.org.pub' from the root of the guix source tree <cmhobbs>i assume that hydra.gnu.org.pub is a gpg pubkey <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. <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. <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>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 <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 <davexunit>there's a snippet in the docs that will make a pool of usrs <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. <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 alpha.gnu.org <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. <mark_weaver>cmhobbs, davexunit: I just downloaded guix-0.7.tar.gz and unpacked it, and hydra.gnu.org.pub 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 <civodul>davexunit: the problem is we can't really unset or override GUILE_LOAD_PATH in test-env, because it might be useful <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 <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>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>hopefully i'll learn enough to add packages and maybe contribute some code <mark_weaver>hmm, that page renders as two blank pages, side by side, on GNU IceCat. <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 :( <mark_weaver>well, looks like the right page is the one I want to read anyway :) <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>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. <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>i'll dig through the docs. i need to run out the door <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>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 <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 <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>'sudo guix archive --authorize < hydra.gnu.org.pub' <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). <civodul>alezost: of course i've already tried it :-) <civodul>in shell-mode and while editing a .drv <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. <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. <davexunit>I haven't ventured into how themes work so I don't know how to tweak them to my liking <civodul>we need a screenshot section on the web page <a_e>The culprit is FIND_PACKAGE(X11 REQUIRED). <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>but it looks like that is not working for you <a_e>There is documentation. I need to look into FindX11.cmake. <a_e>Right at the beginning, there isL <a_e>set(X11_INC_SEARCH_PATH <a_e> /usr/pkg/xorg/include <a_e> /usr/openwin/include <a_e> /usr/openwin/share/include <a_e> /opt/graphics/OpenGL/include <a_e>set(X11_LIB_SEARCH_PATH <a_e> find_path(X11_X11_INCLUDE_PATH X11/X.h ${X11_INC_SEARCH_PATH}) <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??? <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>libQtCore.so.4: 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 x.org 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! <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! <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 <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... <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. <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 *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>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>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. <RISCi_ATOM>guix pull : error symlink : No such file or directory :\\ <mark_weaver>(that's fixed in a recent guix, but you've got an old one for now) <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 <mark_weaver>so it's not sufficient to log in to a shell and then see what "which guix" says. <jxself>Ah. Well, the great question of if 3.17 would be released today or there would be another release candidate has been answered. <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? <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) <mark_weaver>I don't remember seeing any recent libgcrypt advisories. <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 <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)