***tschwing_ is now known as tschwinge
***iyzsong`` is now known as iyzsong
<roptat_>hey, I am using the distribution and managed to compile openbox. How can I make slim choose the correct window manager? I tried specifying it in xinitrc and xsession <viric>I put it in system packages and call it from ~/.xsession <roptat_>I am not very familiar with scheme. What is (cons) and how can I put two packages and %base-packages in it? <roptat_>no luck so far… What is the #:startx argument in the slim-service procedure? <davexunit>hmmmm, setting LD_LIBRARY_PATH as a native search path crashes guix environment. <jxself>From "Doctor, it hurts when I do this." <davexunit>I need guile to be able to find a library via the dynamic-link procedure. <davexunit>civodul: is it bad for a package ot have a native-search-path for LD_LIBRARY_PATH? <davexunit>I just discovered that it's a reason why guix environment is crashing for me when I try to make an environment for my project. <civodul>davexunit: roughly yes, it's Bad :-) <davexunit>okay. so, I'm trying to make a guix environment that allows Sly to build without any special modifications. I need to make a call to dynamic-link "just work" <civodul>it would be nicer to use (dynamic-link "/path/to/libfreeimage") <civodul>so you could either use AC_SUBST & co., or patch things specifically in the Guix recipe <davexunit>what's weird is that '(dynamic-link "libgslcblas")' works without issue in the environment. <jmd>I'm getting an odd error cross building gcc-toolchain <jmd>Does it work for anyone else, or is it just me? <jmd>In guix/build-system/gnu.scm: <jmd> 392: 0 [gnu-cross-build #<build-daemon 256.14 25309c0> "gcc-4.9.2" ...] <jmd>guix/build-system/gnu.scm:392:0: In procedure gnu-cross-build: <jmd>guix/build-system/gnu.scm:392:0: In procedure #<procedure gnu-cross-build (store name #:key target native-drvs target-drvs guile source outputs search-paths native-search-paths configure-flags make-flags out-of-source? tests? test-target parallel-build? parallel-tests? patch-shebangs? strip-binaries? strip-flags strip-directories phases system imported-modules modules substitutable? allowed-references)>: Odd length of keyword argument <jmd>Why should it matter if the argument list is odd or even? <mark_weaver>jmd: *keyword* argument list. that's the key word (no pun intended) <civodul>jmd: i've never tried to cross build gcc-toolchain, but let me see <civodul>jmd: it's not very useful to cross-compile gcc-toolchain, though <civodul>that doesn't give you a cross toolchain <civodul>that gives you a cross-compiled toolchain <jmd>That's what I wanted. <civodul>jmd: "./pre-inst-env guix build --target=mips64el-linux gcc-toolchain -n" works for me <civodul>everything works for me though, so it's not very informative ;-) <jmd>I must have broken something then. <jmd>Which list exactly is it that it wants to be even? <mark_weaver>jmd: you probably messed up an 'arguments' list somewhere. <jmd>mark_weaver: I will check. Thanks for the tip. <mark_weaver>jmd: since those argument lists are composed of keyword-argument pairs, they should end up with an even number of arguments. <jmd>Anyway, at least I've had some success with arm. <mark_weaver>civodul: maybe we should check the 'arguments' list of packages at an earlier stage, to provide a more helpful error message on this case? <mark_weaver>I guess it's a bit trickier since it's a thunked field. <civodul>mark_weaver: yes, that would be nice (as long as it performs well) <jmd>Oh maybe here's the problem: <jmd>+ `((#:configure-flags "--disable-werror"))))) <mark_weaver>civodul: btw, I frequently run into the problem where dbus fails to start because of a stale /var/run/dbus/pid. have you not run into that? <jmd>Release still happening this week? <mark_weaver>or better yet, fix it myself, but I've been low on free time lately, and trying to focus more on Guile, since it seems more starved for attention at the moment. <jmd>How does guix know what its native architecture is? <mark_weaver>jmd: Guix's configure script arranges for it to be put in %system in guix/config.scm. <mark_weaver>see guix/config.scm.in and GUIX_SYSTEM_TYPE in m4/guix.m4 <mark_weaver>I guess you'll need to add another case in there for arm. <mark_weaver>hmm, well, maybe not. we didn't need a case for mips <jmd> case "$guix_system" in <jmd> x86_64-linux|i686-linux|mips64el-linux) <mark_weaver>I guess we only needed it for i*86 because it could be 486/586/etc, and for x86_64 because it's called amd64 in the GNU triplet. <mark_weaver>right, well, that's in GUIX_ASSERT_SUPPORTED_SYSTEM, whereas I was looking at GUIX_SYSTEM_TYPE <mark_weaver>GUIX_ASSERT_SUPPORTED_SYSTEM is not critical for now, because you can always add --with-courage to the configure arguments, as I did while the mips port was in development. <jmd>Whats the make-boot0 package and where is it defined? <mark_weaver>it's the very first package that's built during the bootstrap, defined in gnu/packages/commencement.scm. <jmd>I'm gettin an error building it. <jmd>starting phase `unpack' <jmd>In execvp of tar: No such file or directory <jmd>phase `unpack' failed after 0 seconds <mark_weaver>tar should be among the bootstrap binaries that you built for arm. <jmd>I haven't done that yet. <jmd>Briefly. Maybe I should read it again. <jmd>So far, I've just been getting the compiler to work and checking that cross-compiled packages work on the target. <civodul>jmd seems to be doing cool stuff :-) <civodul>mark_weaver: yes, i think i've seen it before (the dbus PID file) <civodul>probably best to remove it in 'start' <jmd>glibc-dynamic-linker is going to have to be rethought, though. <jmd>guix package doesn't accept --target <civodul>davexunit: i'm starting the doc on "guix import" <civodul>jmd: no; what use case do you have in mind? <davexunit>civodul: okay! sorry for not getting to it first. <jmd>I wanted to pre-install onto a profile which will get NFS mounted onto the target achitecture. <davexunit>civodul: I'm going to push a small typo patch to the NEWS file. s/pipy/pypi/ <davexunit>I figure it's trivial enough to not need to post on the ML. <civodul>jmd: you could build the profile programmatically, but 'guix profile' doesn't help here *civodul is concerned by the brokenness of www.gnu.org <civodul>for the last 3 days or so, updates to the web page repo don't show up on the web site <davexunit>I don't know how deep the problem goes. if I already knew where to look for the problem, I just might be able to fix it. <jxself>davexunit: I don't have shell access to wildbeest (the one that runs gnu.org, not my wildebeest. A post-commit hook on Savannah is supposed to somehow cause something on wildebeest to update its CVS checkout. <jxself>If you have shell access, perhaps looking into that woul be good. Or maybe Lisa can. <jxself>But that's the general process flow. :) <davexunit>I have access. I'm looking right now, I found a cron job, but running it manually does nothing <jxself>The website's not updated via cron. Symlinks are, so that might be what you're looking at. <jxself>Last I heard the symlink thing is run every 5 minutes? <davexunit>there's a job called update-cvs that's run every 2 minutes <jxself>Interesting. I've not heard of this one before. <jxself>If there's something being done via cron, what's the post commit hook on Savannah for? <davexunit>not sure. I'm trying to locate the post commit hook. <jxself>I don't have shell access to Savannah so can't be much help there. :( <davexunit>does anyone with cvs knowledge have an idea of what to search for? <davexunit>in git, the hooks are files with particular names <civodul>i have zero experience with CVS hooks *davexunit can't find the hook <civodul>i was just expressing my sympathy regarding your quest for the CVS hooks :-) <davexunit>I think a cron job was hanging or something. <civodul>web pages that had their cron job fail may have to be updated manually, i guess? <davexunit>civodul: regarding my irrlicht patch, since I changed the license field of all those packages, do I need to mention them all in the commit log or is that unnecessary? <davexunit>as long as commits to the cvs repo have been working