IRC channel logs


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.
<sneek>Will do.
<Apteryx_>sneek: later tell dfens: This is at least wrong: (device "/dev/sdX")
<sneek>Got it.
<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?
<brendyn>Digit: Yeah it's still a beta:
<civodul>Hello Guix!
<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`>hi there akk
<az`>why guix package -u got me:
<az`>updating list of substitutes from ''... 100.0%
<az`>Downloading (212KiB installed)...
<az`>guix substitute: error: download from '' failed: 404, "Not Found"
<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?
<efraim>'guix package --fallback -u'
<efraim>az`: ^
<htgoebel>Hmm, running check-system hangs since 10 Minutes now, after copying the initrd to the dest-disk.img What's going on here?
<htgoebel>Oh, my /-fs is full :-(
<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>heya ngz
<rekado_>az`: you can use as an additional substitute server.
<civodul>ngz: we've had reports of problems on foreign distros with programs that embed Python
<civodul>similar to what you describe
<civodul>but i don't think people came up with a workaround
<civodul>could you strace the thing?
<rekado_>az`: you need to authorize this key first:
<rekado_>(the link to the public key on is 404 at the moment)
<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?
<civodul>that vaguely rings a bell
<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"))
<ngz>err getenv
<rekado_>ngz: is LD_LIBRARY_PATH set in your environment?
<ngz>rekado_: No, it isn't.
<rekado_>okay, good
<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.
<rekado_>oh, it’s 1.5.2.
<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)
<civodul>ngz: previous discussion on this topic:
<civodul> has possible hints
<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
<civodul>ACTION goes for lunch
<ngz>I have to go. I will be back later if you have more specific investigations to do. Thank you.
<jlicht>hi guix
<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.
<Apteryx_>It should be straight-forward to customize some more for anyone wanting to use it. It's available here for now:
<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>Apteryx_: sounds pretty cool!
<civodul>should we make it part of debbugs proper, or should we host it elsewhere?
<civodul>emacs-guix maybe?
<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 :-)
<bavier>civodul: yup!
<civodul>really happy you're looking into it
<civodul>GPCE talk is on-line:
<civodul>and all the SPLASH talks actually:
<civodul>lots of good stuff in there!
<civodul>my favorite one at GPCE, around Scala:
<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>Of course :)
<lfam>A silly combination, anyways
<civodul>heya lfam!
<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
<civodul>indeed, good point
<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>Am I missing something or is this bug report accurate?
<lfam>It seems like ~/.guix-profile/etc/profile gets sourced on my system, but I'm not sure how, given that report
<bavier>different shell?
<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?
<bavier>civodul: I think it's accurate
<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
<rekado_>I just finished building it
<rekado_>started a couple of hours ago
<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
<ng0> <- great stuff already, rekado!
<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
<bavier>lfam: according to variable assignments are done after variable expansions
<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?
<lfam>You might want to report the bug to Fedora, or follow the steps in our manual:
<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
<bavier>setting realistic goals :)
<civodul>lfam: oh!
<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, 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_>you can play with mumi here:
<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!
<ng0>great work :)
<rekado_>thanks :)
<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 write USER <at> 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?
<bavier>rekado_: cool
<lfam>jmarciano: There are few different types of graphs available. This is the documentation for the `guix graph` command:
<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?
<warreq>Is there a good way to dump a keyfile into the initramfs in GuixSD? I imagine someof you running libreboot have done something similar. Basically, I want to do this:
<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
<jlicht>you can either put that path somewhere in your startup scripts, or just follow the GUIX_PROFILE thing mentioned here:
<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
<reed_>That worked. Thank you!
<jlicht>reed_: yw. Happy hacking :-)
<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 :/