<char[m]>is it guix acceptable to pass the LIBRARY_PATH environment variable to ldd -rpath?
<dust_>I'm getting 'Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS' when invoking guix pull. I'm looking at irc logs for solution. I have 24GB of ram, so ram is not the problem I believe. Can anyone help ?
<dust_>lfam: I have asked this before in the chat. I have made 20+ package defs for haskell. And one of them seems to use different version that guix channel provide. And this is for testing. So should I skip testing ?
<lfam>dust_: The choice is yours. You should test your packages "in practice". Check if they work for your use case
<efraim>civodul: %final-inputs-riscv64 is a hack, it adds (list gcc-final "lib") to %final-inputs. The %current-system check has to come in (guix build-system gnu) because of when it re-evaluates %current-system from x86_64-linux to riscv64-linux.
<efraim>I do wonder if it's related to some of the issues we've been seeing with guix deploy on the aarch64 boxes getting x86_64 binaries
<AwesomeAdam54321>Does anyone know how to solve this problem? 'gnustep-config --objc-libs' needs make at runtime, and it works since gnu-make is a propagative-input of my gnustep-make package definition
<AwesomeAdam54321>But when gnustep-base has gnustep-make as an input, during configure 'gnustep-config --objc-libs' outputs nothing, and that only ever happens if make isn't available
<civodul>efraim: following up: could you check "gcc -dumpspecs" on riscv with Guix's gcc?
<jpoiret>AwesomeAdam54321: can't you patch gnustep-make to directly refer to the make of gnu-make, instead of relying on PATH?
<attila_lendvai>nckx, have you finished your experiments with channel dependencies? i'd like to delete the test commits from my channel...
<efraim>on Debain ld-linux is at /usr/lib/ld-linux-riscv64-lp64d.so.1, so I'm guessing with a name like that I'll need to tell it to search a little harder before I can remove all the (add gcc:lib) phases I've added in commencement.scm
<efraim>gcc:lib is at /gnu/store/cgxghxvqds82d64mjg01wy0vb597vx88-gcc-10.3.0-lib
<gnoo>package `firstname.lastname@example.org' has an invalid input: #<package email@example.com gnu/packages/glib.scm:539 7efd5206b1e0
<tschilptschilp23>Hi! I just set up a fresh headless guix and am having troubles with guix home. I am very confident, that I have 'gnu packages guile' in the 'use-module' section of my configuration, however I keep getting 'unbound variable guile, did you forget to put ...'! Does anyone have a hint for this?
<efraim>tschilptschilp23: try 'guile-3.0', I don't think we actually have 'guile' itself defined
<tschilptschilp23>Probably worth mentioning, the above is a VM. My Laptop does not even need 'gnu packages guile' to install guile via guix home... But maybe there are some remainders somewhere from my pre-huix-home setup, that I am not aware of.
***attila_lendvai_ is now known as attila_lendvai
<jeko>Hey Guix ! I have the package `guile` installed in my profile but I can't see its info documentation in Emacs info mode
<jeko>Do I need an extra step to make it available from Emacs ?
<tschilptschilp23>efraim: thank you, your comment made me double-check. All on my side - I just didn't quote the packages!!!
<civodul>jeko: hi! if you're on a "foreign distro", make sure INFOPATH contains ~/.guix-profile/share/info
<jeko>civodul: hey! INFOPATH does contains ~/.guix-extra-profiles/jeko/jeko/share/info and I can see guile.info-##.gz into it
<tschilptschilp23>But now I run into another thing- at guix home reconfigure the last step ('building /gnu/store/xyz-home.drv") fails with 'guix home: error: mkdir: Permission denied'. I guess one could sudo that, but that's not exactly what I want to Do...
<tschilptschilp23>OK, found it thanks to bug-report 50941. Setting XDG_RUNTIME_DIR in the home-configuration does what I was searching for on a 'headless' (%base-services only in the 'global configuration') system.
<AwesomeAdam54321>jpoiret: setting the GNUMAKE variable to configure solved the problem with gnustep-make, but I've yet to figure out why gnustep-base still fails
<civodul>leinad: yes, usually to indicate a "special" global variable
<attila_lendvai>leinad, it is. in lisp %foo is something that is private and usually has a public, slightly different version under the name foo. in Guix it's more like a general "this thing is special in some way".
<sneek>whound, podiki[m] says: I have all of the haskell gi (and taffybar) package defs, but working on cleaening up to submit them; it needs a different gobject-introspection for cairo (I think same error you're seeing)
<rekado_>gordon1: you do have an influence on that. Just not when you use an unmodified Guix package from the default channel.
<rekado_>the implied order in your question, however, is never how it would be done. You wouldn’t edit whatever has been built. You’d rather make it build from different instructions.
<gordon1>rekado_: sure, maybe i just formulated my question incorrectly, i'm perfectly fine of being able to specify my modified package somewhere in config to make it build new version of guix, the issue is here that i didn't find that place where i can specify my modified package, it looks like the only way of doing that is specifying a for of guix's repo with modified (guix packages package-management), no
<gordon1>yeah, see, in ideal world i would like to avoid that
<apteryx>civodul: copying /var/cache is going to take a couple more days, it seems. do you think we could mount what we have (> 10 TiBs), shadowing the curret /var/cache, and keep the sync in the background? Or would that cause too much disruption?
<gnucode>also my autocomplete (I'm going doom emacs) is pretty annoying right now. Typing "one" then RET results in "clone1".
<gnucode>there's probably a clone1 in the chatroom. ahhhhaa.
<rekado_>gnoo: we don’t have a foo package, so I guess you’d have to fix your problem on your side.
<gnoo>rekado_: i stupidly removed the package name thinking talking about propretary packages is not allowed. but it is actually free software
<gnoo>the actual error is: guix build: error: /home/me/.cache/guix/my-packages/pidgin-sipe.scm:10:2: package `firstname.lastname@example.org' has an invalid input: #<package email@example.com gnu/packages/glib.scm:539 7f34738d71e0>
<gnoo>this happened when i had: (inputs (list intltool))
<rekado_>zap: I have a solution that works for me but is probably both primitive and overly complex. I have a manifest in .emacs.d, which installs to .emacs.d/.guix-profile, and I use direnv so that when I enter the directory that profile’s etc/profile is loaded.
<rekado_>there I start emacs, so EMACSLOADPATH is set to the location of the profile
<rekado_>when I install new packages they are readily available in the running Emacs, because EMACSLOADPATH doesn’t need to change.
<zap>pinoaffe: yea I do change these manually time to time but I'm getting tired of it :)
<zap>rekado_: Hm.. This is exactly what I do (appart from direnv). I just load it with "guix environment -p ~/.emacs.d/.guix-profile -- emacs"
<zap>Im not sure what subdirs.el does but it contains full paths to store