<civodul>mark_weaver: re maxconcurrent: sometimes the problem is that hydra.gnu.org gets overloaded simply due to offloading, when maxconcurrent is too high ***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<organixpear>Hello! I am having trouble installing guix. Specifically, in config.scm <organixpear>I don't understand in (file-systems ... (device "root") <organixpear>Should that be /dev/sdX, where that partition contains my root fs? <isd>Is there an easy way to have sets of packages maintained outside of the mainline source tree? I have a handful of on-off utilities that aren't general or interesting enough to make sense to push upstream, but I'd like to have them in proper packages on my local system at least <isd>with more mainstream package managers (rpm, apt...) this is pretty easy, but I can't find any documentation about how to do it with guix (or nix for that matter). <mark_weaver>isd: there's a GUIX_PACKAGE_PATH environment variable. set it to a directory that contains *.scm files with your package recipes. <isd>mark_weaver: thanks for the tip <mark_weaver>note that there's also a far more flexible method: build guix from git, and maintain your own private branch, periodically rebasing your branch on our upstream (or periodically merge our upstream into your branch, if you prefer). <isd>mark_weaver: I'll keep it in mind. thanks for your help <alezost>In synopses/descriptions we have both "-ise" and "-ize" forms ("organise" vs. "organize"). Should we prefer any of it? <alezost>I would like to replace one of the form by the other everywhere. (And "-ize" is my favourite) <civodul>alezost: i typically use US spelling, but i'm not sure we want to start a debate about it ;-) <civodul>maybe it's OK to leave things as is in that respect <civodul>though i understand your point and i'm sorry to hurt your sense of consistency ;-) <mark_weaver>civodul: so, I won't be able to work on Guix much today, but there are some remaining issues in core-updates: the subversion builds are failing, and on armhf I'm getting a bus error during the openssl test suite. <mark_weaver>if no one else has time to look at them, it'll have to wait until tomorrow <civodul>mark_weaver: i can't help with the armhf one, but i'll see what i can do with svn <mark_weaver>that compares current core-updates to where it branched off from master <mark_weaver>in the libgnome build log, I don't see 'popt' paths mentioned in the relevant environment variables. I wonder if something went wrong with the scalability work? <civodul>mark_weaver: the problem is that there are two 'propagated-inputs' fields, and the last one wins <civodul>(ideally define-record-type* would raise a syntax error) <mark_weaver>lzo was a case where the build succeeded but was recorded as a failure, perhaps because of a network error near the end. I restarted it. <civodul>we have a problem: ath9k doesn't work with Linux-libre 4.1 <civodul>"cfg80211: Exceeded CRDA call max attempts." <civodul>ACTION is glad he could boot into the previous configuration instead of looking for an ethernet cable :-) <civodul>ooh, or could it be that GCC 4.9 miscompiles the firmware? ***boegel is now known as boegel|afk
<amz3>civodul I saw your answer about the new command I started a while back. I will finish it one day, hopefully.. <phant0mas>I have a problem with both cross-building and natively building perl, and they are probably related <phant0mas>in perl's configure phase libc evaluates to #f <amz3>phant0mas: maybe I can help, what command do you use? <amz3>I will try to compile perl againt master <phant0mas>amz3: I am using ./pre-inst-env guix build --target=i586-pc-gnu -c 8 perl on wip-hurd <phant0mas>but I am afraid you won't be able to reproduce it currently <civodul>phant0mas: are you rebased on top of current core-updates? <phant0mas>amz3: you probably won't be able to reproduce it because there are some patches from core-updates you will need <civodul>phant0mas: well, don't do it right away <rekado>ghostscript conversion from postscript to png fails here. <rekado>(this also means that lilypond doesn't work) <civodul>DocView works here, and DocView uses Ghostscript PDF(->PS)->PNG no? <civodul>(BTW, what's the status of the Emacs PDF Tools patch?) <rekado>DocView works for me, too. It's just lilypond that fails. <rekado>and it fails trying to convert stuff with ghostscript. <rekado>the PDF tools patch is just waiting for someone else to say "okay". <rekado>this very command is spawned by lilypond. <civodul>can you strace it to see what leads to ENOENT? <civodul>re PDF tools, i thought alezost had okayed it <rekado>it's looking for IdiomSet in various directories. <civodul>would be nice, i've been wanting to give it a try <rekado>it's looking in the ghostscript search path. <rekado>for example: /gnu/store/ad15kgxkl3h49kldd4bf0ycd7h9nn69z-ghostscript-9.14.0/share/fonts/default/TrueType/IdiomSet <rekado>or this: /gnu/store/ad15kgxkl3h49kldd4bf0ycd7h9nn69z-ghostscript-9.14.0/share/ghostscript/9.14/lib/IdiomSet <rekado>I searched through the whole store and could not find this file. <rekado>it's also looking in /usr/openwin/lib/X11/fonts/Type1/IdiomSet <rekado>I don't know. I haven't used lilypond in a long time. <rekado>btw, these are all "openat" calls, so I think this means this is a directory. <rekado>but that's not the only thing it's missing. <civodul>openat is to open a file relative to a directory <rekado>another one is this: /gnu/store/ad15kgxkl3h49kldd4bf0ycd7h9nn69z-ghostscript-9.14.0/share/ghostscript/9.14/Resource/Init/ProcSet/CIDInit <rekado>building gs-fonts now; maybe it's part of that? <civodul>a recent change in Ghoscript was the addition of the "doc" output <rekado>can I build a particular output with "guix build"? <civodul>ghostscript:doc contains HTML files that mention IdiomSet <civodul>could it be that lilypond wants an older version? :-) <rekado>I'll try to build unstable lilypond 2.19.23; maybe this works better <civodul>ACTION struggles with a subversion test case <civodul>at least the two of us are having a wonderful time ;-)