<ixtlan>So.. I'm attempting to customize my sortofworking guix system. Package manager recommended me to set my GUIX_PROFILE, but the commands suggested only sets it temporarily. That does not seem to make sense. I looked up where it's set, in .guix-pro../etc/profile, but it's kinda.. root-only, and even root can only read, not write. Normally I take that kind of thing to mean 'you should not mess with this'. On the other hand stuff in i3 seems to fail because it
<ixtlan>can't find dmenu which is searched as /run/currentsystem/etc.. the 'default' path set by the system. Presumably it'd work if I changed the profile file. Just checking though: Is there another place I should set that kind of thing, and is the 'profile' in fact system-generated from this?
<roptat>fps, if you didn't install the package in any profile, you can run "guix gc -D `guix build foo`" to remove foo, then you can run "guix build foo --rounds=4" if you want
<roptat>ixtlan, I'm not an i3 user, I'm sure there are some here though, but I can suggest sourcing your .guix-profile/etc/profile from your .bash_profile, or setting your PATH in your i3 configuration maybe
<roptat>but I'm pretty sure guix does that already, maybe you only need to reboot for new environment variables to take effect everywhere?
<ixtlan>i3 is where I can see something fail - I am worrying that probably i3 isn't the only thing that would fail, given that the guix package manager is also taking notice. So I see it as a general, system problem?
<ixtlan>I thought, am thinking, also, that .guix-profile/etc/profile is run automatically.
<ixtlan>However, as far as I know, environment variables are not preserved at shutdown. At least for all other systems I know of, they're set anew at startup, often from .profile files.
<fps>.bash_profile is only used when run interactively i think
<roptat>.guix-profile/etc/profile is generated automatically by guix and it should be loaded at startup
<roptat>.guix-profile/etc/profile is part of the current generation of your profile, it's generated whenever you create a new generation of the profile (when you make a transaction with guix package, guix upgrade, guix install or guix remove)
<ixtlan>As it's a symlink.. the root ownership makes sense. And I'm thinking that I could copy that file, use that locally and from it first source the system profile, then overwrite the GUIX_PROFILE variable.
<roptat>I've never had to change any of these on the guix system though...
<ixtlan>Well.. I'd like to know what your GUIX_PROFILE is then, and how it was set for you?
<ixtlan>Erh. And also which command you use to do a shutdown in the nice way. I've been using the power button. So if there's anything triggering a preservation of environment variables, they could have been inadvertently circumvented that way.
<roptat>ixtlan, I'm not on the guix system right now
<civodul>in "normal" mode (no --check), --rounds does work as expected
<ixtlan>Back. I tried something else in the end - and it turns out dmenu was not installed. Installing it -did- help matters.. there's still other things though. It's like i3 was not properly installed somehow.
<ixtlan>Is there any system definition around for 'base minimal system' that I can then extend on after reconfiguring to it?
<fps>civodul: --rounds is also not doing anything when the package is already built
<fps>btw: how long can one expect a guix system vm-image to run at the least?
<civodul>fps: when the package is already built, it's expected that --rounds does nothing
<civodul>it's really only for when you're building something for the first time
<truby>I'm having a bit of trouble with the linker wrapper when building something with clang, it seems to be passing the linker flags as strings which then get interpreted as libraries with that name to link against. E.g. its looking for a library file called lib-pic.so because "-pic" is being passed as a string. Any ideas?
<shrdlu68>How can I append entries to ~/.bashrc via skeletons?
<shrdlu68>Can I petition for a colored $PS1 in guix?
<shrdlu68>/etc/bash//bashrc in Gentoo has some code to only enable it for terminals that support it.
<leoprikler>talking about shells, why does zsh not load site-functions from the system profile by default?
<jlicht>I am trying to package something which runs the generated `./configure` script as part of the autogen.sh script, but this script still has a `/bin/sh` reference by default. What would be the nicest way to deal with this?
<jlicht>so configure is generated with /bin/sh and immediately executed :/
<roptat>jlicht, use substitute* in a phase before bootstrap?
<roptat>ah, you mean bootstrap generates a configure script that contains /bin/sh, and then calls it?
<roptat>then you can patch the call to configure out
<jlicht>roptat: yes, that is a much better way to describe my issue :P
<bdju>looks like the Kakoune editor is a release behind
<jlicht>I am working on packaging https://github.com/nm-l2tp/NetworkManager-l2tp, but there is a big mean warning about some licensing issues in serving binaries of it with openssl < 3.0.0 due to an incompatibility. Would it suffice for me to mark this package as non-substitutable, or are there bigger issues here?
<leoprikler>my reading of this is, that you can build the source against earlier versions, but not distribute binaries produced through such builds
<leoprikler>that would translate to "no substitutes if openssl < 3.0.0"
<utraz>When i install glibc-locales and export GUIX_LOCPATH it goes away, but comes back when rebooting
<mbakke>utraz: the daemon also needs GUIX_LOCPATH; you can edit '/etc/systemd/system/guix-daemon.service' to point it to your user profile (instead of root's)
<utraz>i should've clarified i'm using guix system!
<pinoaffe>when I try to install this package http://dpaste.com/1YKZ6GM I get an error ERROR: In procedure primitive-load: In procedure scm_lreadr: /gnu/store/7x3ydg9yld0jc0vymkf378gm3z2pa292-i3-gnome-3.34.0-guile-builder:1:10239: Unknown # object: #\<
<dongcarl>mbakke: I do apologize for rushing the patch last time, I will do better next time. I'm actually struggling with a problem right now that only you can answer... My technique of picking out `mingw` paths from non-CROSS_ env vars and putting them in CROSS_ variants seems to have been broken by the core-updates merge...
<dongcarl>For some clarity, I used to do it to "CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_PATH", and I've tried switching to just "CPATH" and "LIBRARY_PATH", but that triggers the `include_next` `stdlib.h` problem