IRC channel logs


back to list of logs

<civodul>mark_weaver: re maxconcurrent: sometimes the problem is that gets overloaded simply due to offloading, when maxconcurrent is too high
<civodul>so we'll have to monitor that
***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>see section 6.5 of the manual
<mark_weaver>the second footnote there is important
<mark_weaver>there's also a -L option to guix, if you prefer
<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).
<mark_weaver>this is what I do
<isd>mark_weaver: I'll keep it in mind. thanks for your help
<civodul>Hello Guix!
<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 ;-)
<alezost>no problem :-)
<paroneayea>hello #guix!
<civodul>hello, paroneayea!
<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>oh sorry, that's not right
<mark_weaver> is the right one
<civodul>ok, thanks!
<mark_weaver>civodul: hmm, libgnome can't find popt, even though it is in propagated-inputs:
<mark_weaver>in core-updates, I moved popt from 'inputs' to 'propagated-inputs':
<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>that would be annoying ;-)
<civodul>mark_weaver: the problem is that there are two 'propagated-inputs' fields, and the last one wins
<civodul>i'll fix it
<mark_weaver>oh, oops. thanks!
<civodul>(ideally define-record-type* would raise a syntax error)
<mark_weaver>my bad
<civodul>i've been bitten by this once
<mark_weaver>other breakage includes clisp, libsoup, and libpsl
<mark_weaver>and lzo
<mark_weaver>and ninja
<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>anyone seen that?
<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>héllo guile
<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
<phant0mas>in cross-building
<amz3>phant0mas: maybe I can help, what command do you use?
<amz3>at least to reproduce
<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>civodul: no, I will do that
<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
<civodul>i mean, one problem at a time ;-)
<rekado>ghostscript conversion from postscript to png fails here.
<rekado>(this also means that lilypond doesn't work)
<rekado>it tries to find "IdiomSet".
<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>here's the error I get:
<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
<civodul>should i look into it?
<civodul>rekado: open("IdiomSet")?
<rekado>yes, alezost said it was okay.
<rekado>I'll push it then.
<rekado>it's looking for IdiomSet in various directories.
<civodul>would be nice, i've been wanting to give it a try
<civodul>but which directories?
<civodul>does it look like a font?
<rekado>it's looking in the ghostscript search path.
<rekado>one moment.
<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
<civodul>that's a new failure?
<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.
<civodul>it's not in my store either
<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>yeah i checked it before
<civodul>a recent change in Ghoscript was the addition of the "doc" output
<civodul>not sure if it could be related
<rekado>can I build a particular output with "guix build"?
<civodul>"guix build" builds all the outputs
<rekado>oh, yes, just noticed.
<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
<rekado>same problem with 2.19.23.
<civodul>ACTION struggles with a subversion test case
<civodul>at least the two of us are having a wonderful time ;-)