IRC channel logs

2014-11-16.log

back to list of logs

***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>Hmm. Don't do that then. :)
<davexunit>but, I have a reason for doing it!
<jxself>From "Doctor, it hurts when I do this."
<jxself>:)
<davexunit>I need guile to be able to find a library via the dynamic-link procedure.
<civodul>Hello Guix!
<davexunit>hey civodul
<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 :-)
<civodul>relying on RUNPATH is superior
<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"
<davexunit>like: (dynamic-link "libfreeimage")
<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>the former might work, the latter will not.
<davexunit>since there's no recipe to run.
<davexunit>what's weird is that '(dynamic-link "libgslcblas")' works without issue in the environment.
<davexunit>not sure why.
<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>
<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>list
<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>:-)
<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>hmm, ok
*civodul tries
<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.
<mark_weaver>s/keyword-argument/keyword-value/
<jmd>Anyway, at least I've had some success with arm.
<mark_weaver>that's good
<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>s/on/in/
<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>+ (arguments
<jmd>+ `((#:configure-flags "--disable-werror")))))
<jmd>
<civodul>indeed
<mark_weaver>jmd: ah, good!
<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?
<mark_weaver>I guess I should just file a bug
<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)
<jmd> ;;
<jmd>
<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
<jmd>
<mark_weaver>tar should be among the bootstrap binaries that you built for arm.
<mark_weaver>*static bootstrap binaries
<jmd>I haven't done that yet.
<mark_weaver>did you read the "Porting" section of the manual?
<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>lock acquired ;-)
<civodul>jmd: no; what use case do you have in mind?
<davexunit>civodul: okay! sorry for not getting to it first.
<civodul>np!
<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>sure!
<civodul>jmd: i see
<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
*davexunit is too
<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.
<civodul>ok
<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>OK.
<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
*davexunit reads docs
<civodul>i have zero experience with CVS hooks
<civodul>there's possibly useful info at http://sourceforge.net/p/forge/documentation/CVS%20Hook%20Scripts/
*davexunit can't find the hook
<civodul>uh
<davexunit>hmm?
<civodul>i was just expressing my sympathy regarding your quest for the CVS hooks :-)
<davexunit>oh okay :)
<davexunit>I think a cron job was hanging or something.
<civodul>oh you found the culprit?
<davexunit>not sure.
<davexunit>but maybe.
<civodul>ok
<davexunit>I restarted cron.
<civodul>good
<civodul>web pages that had their cron job fail may have to be updated manually, i guess?
<civodul>anyway, will see tomorrow
<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>civodul: it should just work
<civodul>davexunit: it's unnecessary
<davexunit>and the cvs repo will update
<civodul>good
<davexunit>as long as commits to the cvs repo have been working
<davexunit>they have been, right?
<civodul>yep
<civodul>good day/night!
<davexunit>okay
<davexunit>good night