IRC channel logs
2017-10-30.log
back to list of logs
<Apteryx_>eh; I've just done "guix environment guix" not using ./pre-inst-env, and it's touching things in my ~/src/guix. Hmm? <Apteryx_>maybe I had sourced something in that term. Cannot reproduce. <Apteryx_>later, tell civodul: I tested v4 patch on master. I'll retest against core-updates and let you know how that goes. <Apteryx_>sneek: later tell civodul: I tested v4 patch on master. I'll retest against core-updates and let you know how that goes. <Apteryx_>sneek: later tell dfens: This is at least wrong: (device "/dev/sdX") <Digit>hi. forgive my have-not-been-paying-attention question, but... how long do you think until next versioned guix/guixsd release? and will it still be called a beta? <sneek>civodul, you have 1 message. <sneek>civodul, Apteryx_ says: I tested v4 patch on master. I'll retest against core-updates and let you know how that goes. <az`>why guix package -u got me: <az`>killing process 5692 <az`>killing process 5692: No such process <az`>guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/ij9ccdz9igw2j2x2n18allscc6zakwk0-slim-1.3.6.tar.xz.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source <az`>how to fix this? start my own build server? <htgoebel>Hmm, running check-system hangs since 10 Minutes now, after copying the initrd to the dest-disk.img What's going on here? <az`>how we can radically improve packages download and reduce compilation time? <ngz>Hmmm there is a problem with the Scribus package I updated recently. With "guix environment --pure --ad-hoc scribus -- scribus" the software runs flawlessly. However in a "regular" environment (foreign distribution), the software spits out an error about Python. It sounds like it picks up the wrong Python. <ngz>I tried to wrap PYTHONPATH around the program, without success. <civodul>ngz: we've had reports of problems on foreign distros with programs that embed Python <civodul>but i don't think people came up with a workaround <ngz>civodul: For example, I get lines similar to stat("/gnu/store/snk1lslg3ykmxmf2qjf13x59d6krpkv1-python-2.7.13/lib/python2.7/site-packages/_sysconfigdata_nd", 0x7fff10fb42d0) = -1 ENOENT (No such file or directory). Then it seems to fallback to "/usr/lib/python2.7/..." <az`>@rekado_ Thank you! Glad to see you here! <civodul>Steap: you mentioned _sysconfigdata_nd recently no? <htgoebel>ngz: It should not fall back to "/usr/lib/python2.7/..." except for two reasons: <htgoebel>a) its on $PYTHONPATH? or b) /usr/bin/python is used. <htgoebel>Maybe scribus is searching python on $PATH? <ngz>htgoebel: I used "(wrap-program (string-append out "/bin/scribus") `("PYTHONPATH" ":" prefix (,path)))" to set PYTHONPATH in package definition. <ngz>I couldn't find any direct "python" call in Scribus' source code. <ngz>(in the code above, path is the binding for (getven "PYTHONPATH")) <rekado_>ngz: is LD_LIBRARY_PATH set in your environment? <ngz>rekado_: No, it isn't. <htgoebel>ngz: I assume scribus is dynload-ing libpython, correct? <ngz>I think so (but I'm not sure). It definitely needs Python library because it complains if I replace python-2 input with, e.g., python-wrapper. <ngz>My understanding of the problem, however, is very limited, as you can guess. <rekado_>ngz: FWIW I cannot reproduce this on Fedora. <ngz>You mean Scribus 1.5.3 is running properly in Fedora? <rekado_>I ran “guix environment --ad-hoc scribus”, then ran “scribus” and opened a new document. <ngz>I don't think it makes a difference. I had the same issue with 1.5.2, IIRC. <ngz>In any case, I have the same issue with "guix environment --ad-hoc scribus" in Debian stable. <htgoebel>ngz: strace -e trace=%file scribus should show if libpython is loaded and from where <htgoebel>How can I list a source package and the build-requirements in an operation-system declaration? (I need to hack a test-case) <htgoebel>Re scribus: what does not fit here is: If it loads libpython from /gnu/store/…, why does is try to find python on $PATH? <htgoebel>Maybe libpython is not initialized properly?! <civodul>yeah this is weird, further investigation needed <htgoebel>How can I list a source package and the build-requirements in an operation-system declaration? (I need to hack a test-case) <civodul>htgoebel: i think you can use (package-origin the-package) in the 'packages' field <ngz>I have to go. I will be back later if you have more specific investigations to do. Thank you. <Steap>civodul: yeah, it may not be included in our Python package for some reason <Apteryx_>civodul: I invested some time (more than I'm willing to admit ;) in customizing that debbugs-gnu-apply-patch function. The only reason the original function fails is because it tries to expand a lisp subdirectory in the compile command... So at first I made an advice to disable compile for that function. It works but I wasn't entirely satisfied so I customized it. <Apteryx_>It automates some things such as: 1) apply any patch(es) from a message, whether they come as attachments or in the body. 2) Clean up the debbugs metadata from the subject line. 3) run make in a ./pre-inst-guix guix environment. 4) Shows the compilation buffer & magit. <jlicht>Apteryx_: wow, does this allow you to easily manage patches from the emacs debbugs interface? <jlicht>If so, that is very cool indeed :-) <civodul>should we make it part of debbugs proper, or should we host it elsewhere? <Digit>ACTION ponders a kind of meta-package that defines version ranges. Digit floats away, day-dreaming. <divansantana>how does one do the guile equivelent of describe-variable or describe-function for the guile code of guix, within emacs? <civodul>divansantana: in Geiser you can use C-c C-d on a symbol <civodul>though it's often been broken for me lately, not sure why <civodul>Apteryx_: should i go ahead and apply the gcc man page patch on core-updates? <civodul>sounds like a reasonable thing to do no? <bavier>oh, the gnulib old test-lock test seems to only hang inside a "container" <bavier>e.g. the tests in libunistring pass normally, but inside the build environment or 'guix environment --container' they hang <civodul>bavier: that's still enough of a reason to skip it IMO :-) <lfam>Is it expected that #:tests? #f has no effect when the check phase is replaced with modify-phases? <bavier>lfam: right, unless the new check phase accepts the keyword itself <lfam>A silly combination, anyways <civodul>i'm tented to go ahead and apply the gcc man-page patch by Apteryx_ <civodul>Apteryx_ tested it on master, so It Should Be Fine <lfam>I'm not familiar with the dependency graph at that level, so I don't know if this matters, but I would lean towards adding perl to #:disallowed-references <lfam>Assuming it was not previously referenced... <lfam>This could protect us from accidentally introducing a reference later on <bavier>oh right, duh, in 'guix environment --container' the test links against our glibc@2.25, but outside it links to the system's glibc@2.22, and IIRC one of the issues is with glibc@2.25's rw lock algorithm <lfam>It seems like ~/.guix-profile/etc/profile gets sourced on my system, but I'm not sure how, given that report <lfam>I'm trying it out in bash, dash, and zsh <bavier>well, in my shell 'foo="bar" echo $foo' does indeed print nothing <lfam>Yeah, I can't make a test case work, but for some reason the Guix profile stuff is set in my login environment <bavier>is GUIX_PROFILE already set somehow in your case? <civodul>lfam: i think the comment about GUIX_PROFILE expansion is wrong, no? <lfam>I'm still digging into it, but doing a simple test case with a file that exports FOO=bar shows that it seems to be accurate <lfam>I realized that on a foreign distro machine where everything works, I was not using the example from the manual, but instead doing GUIX_PROFILE=$HOME/.guix-profile . $HOME/.guix-profile/etc/profile <lfam>So, perhaps I noticed this long ago and worked around it <rekado_>building wine sure takes a long time <lfam>Yeah... I trust that Rutger tested it <lfam>civodul, bavier: I can't find a specification of when shell variables are expanded in the POSIX shell spec, but in bash, dash, and zsh, the following prints nothing: $ foo=bar echo $foo <ays>hi! I am trying to install guix, and I am getting the error: unknown location: error: no 'ungexp' substitution (ungexp %utils-module) <ays>ice-9/psyntax.scm:1558:32: Syntax error <lfam>ays: Can you give more detail about what you are doing? How are you trying to install guix? <ays>I installed guix from the fedora repo at lantw44/guix <ays>The installation didn't show me any errors, but when I try to run `guix package -i guile`, this error comes up <lfam>ays: Huh, I'm not familiar with that method of installing Guix <ays>How do you recomend I insatll guix? <ays>Thank you. I'll try the binary installation. <ng0>ACTION needs a GuixSD server again… trying to install Mailman3 on Debian is just too much custom hackery I've done half way already for Guix <ng0>motivation to finish my debbugs + mailman3 packages in the next 12 months <lfam>bavier: Ah, it's clear then <civodul>damn it, i should really learn that shell thing <lfam>I like the reporter's suggestion to simply not define $GUIX_PROFILE <civodul>lfam: if we don't define it, then we get /gnu/store/...-profile <civodul>that's no good, because when you change your profile, then all your env vars become outdated <ng0>bavier: yeah :) my realistic correction for Guix through GNUnet is 'somewhere between now and post-master studies depending on the sun, moon and advanced witchcraft and it takes just time and reading and lots of debugging and learning' <civodul>rekado_, ng0: great stuff here! (re mumi.png) <lfam>In 'Invoking guix package' we offer a different command that does work <ng0>I'm not so sure what's good about debbugs. The code doesn't seem that big. Is it still maintained, even if just a few minor corrections and features updates once in a while, or legacy maintenance? Maybe rewriting it in some other language and adding features if we really rely on it longterm would be good. Okay, we use the GNU hosted one, but just wild associations.. <ng0>even the installation on debian is not that complicated or feature-complete <ng0>"here, have some files, now configure the stuff in /etc/debbugs/ and configure again" <rekado_>what’s good about debbugs is that it works <ng0>oh.. this is in no way related to your work on the debbugs thing <ng0>I was just trying to get debbugs + mailman3 running on my Debian <efraim>the debbugs irc channel is #debbugs in irc.oftc.net, according to the debconf videos it's still maintained <ng0>right, debian is just switching to (trying to…?) pagure for the git part of their work <ng0>not for the bug tracking <efraim>i set bash to use vi mode, but I don't know how to make it use vim instead of vi :/ <efraim>perl-http-cookies source failed from cpan <rekado_>note that the email database won’t update. It’s just a fixed set of emails downloaded from debbugs. <ng0>I want mumi to have a tuxified mummy icon somewhere… it's not professional clean but the name! <rekado_>it doesn’t do much and it’s a bit slow because mu doesn’t index the headers that debbugs uses. <ng0>does the original debbugs on gnu.org write USER <at> foohost.org for the rendered html of the messages? <jmarciano>I remember seen a relationship graph for guix packages. I wish to know the name of type of such graph, one sample, and which library was used to create such. Anybody knows? <lfam>jmarciano: The 'package' and 'reverse-package' graphs are probably the most commonly used <jmarciano>I see it is DAG graph (directed acyclic graph) and that graphviz input format is used. That is exactly what I wanted. Thanks. <jlicht>rekado_: wow, mumi is looking really slick already <jlicht>rekado_: is there some source to play with? <reed_>Hi all, I wasn't sure if I should ask this in #guix or #guile, but when I install a guile module on guixsd with "guix package -i ..." how do I tell guile where to look for that module when I want to use it? <jlicht>reed_: "guix package -i" should (on foreign distro's at least) print some GUILE_LOAD_PATH or something similar on completion <reed_>jlicht: even if I'm using GuixSD and not a foreign distro? <jlicht>reed_: I am not sure in that case. It all depends on if your "guix package -i"-invocation mentioned anything about the GUILE_LOAD_PATH (or GUILE_LOAD_COMPILED_PATH). <reed_>jlicht: I think I may have figured out the problem. The module I'm trying to use is in the guile-2.0 folder in the profile but I have both guile 2.2 and 2.0 installed. When I run guile, do you know how to tell it which version to use? <jlicht>afaik, if you just run `guile' from your PATH, it should be one or the other <jlicht>if you want to change this, you could do something like `guix environment --ad-hoc guile@2.0' or with 2.0 replaced by 2.2 <jlicht>guix environment does not alter your profile though, so if you want to work with a specific version most of the time it makes sense to just `guix package -i guile@<your-version>' that instead <reed_>oops thought I was in my terminal. I see, I'll try to mess around with the environments a little <jlicht>besides Danny's work on rust, has anyone gotten the current packed version of rustc to work since the most recent merge with core-updates? Both the hydra build and my own seem to fail :/ 