<LeonLainDelysid>Hello! I'm guessing other people have asked this question already, but… I wanted to use gcc and g++, but the Guix package manager doesn't have them. Why is that? Guix doesn't provide them?
<roptat>the thing with the gcc package is that it doesn't work without other stuff, so we disabled gcc (so users don't panick when they install it and it doesn't work) and provide gcc-toolchain, which is a bundle of gcc and the things it needs
<LeonLainDelysid>Why isn't the package named "gcc"? Because the gcc-toolchain package has both the C and C++ compilers? It's like a more general name for them bundled together?
<nckx>(Watch, now it'll succeed; but I won't even mind.)
<blendergeek>How can I use a nitrokey with GNU Guix? I can't find a nitrokey package for Guix, so I tried to manually add a udev rule but I'm not having any luck. Has anybody already solved this problem?
<clodeindustrie>hey guys what's the difference between /root/.guix-profile and /run/current-system/profile ?
<clodeindustrie>I have the first one as GUIX_PROFILE in my bashrc but only the second one load properly my extra channels
<nckx>clodeindustrie: /root/.guix-profile is root's (user) profile, /run/current-system/profile is the system (operating-system) profile, both are just profiles.
<dissoc>okay cool. that's better than what i have been doing
<dissoc>i guess what im confused about is im writing a package that requires jemalloc. but im not sure what path to use. im guessing it would be something like (assoc-ref inputs "jemalloc") but how to get path of libjemalloc.so?
<dissoc>okay i think i figured out a way to find it but i had to follow the directories in the .drv files
<raghavgururajan>Hey! If you are reading this: Do not confuse free speech with hate speech. If you have something to say, then just say it. No one here is gonna ban you, if you conduct yourself in a rational manner. Stop this non-sense of yours.
<civodul>i think Guix is one of the main users of the "save" API :-)
<zimoun>civodul: yes, surely! :-) Hum? on the other hand, it will be hard to push packages with url-fetch to SWH because they will not listen "all" the channels around. Maybe we could propose to "save" URL pointing sources.json and maybe that their WebApp saver accept drop of sources.json file. Adding on our side someting to return sources.json for a given package, maybe under etc/.
<janneke>civodul: just a headsup on the childhurds: i have identified an offloading problem with sqlite3 locking and testing a fix from debian
<nckx>sneek: Hm, any 14-year-olds pop by in my absence?
<nckx>Kimapr: Use sudo cp -a (for ‘archive’) for that. It preserves everything I care about, at least.
<nckx>janneke: Happened to me when I was that age, my reaction was to prove them all wrong. Different streeps for different peeps. I'm envious of any 14yos here: they're ridiculously far ahead of me at 14 (and with much better taste).
<nckx>mbakke, NieDzejkob: Is there a bug for that offload EOF annoyance yet?
<janneke>that's about ~100 dependencies...terrible
<efraim>I don't see libvideogfx or anything like it in debian
<terpri_>nckx, that helped, but solaar has a "def async" which won't fly after PEP 492 :)
<terpri_>i just borrowed a mouse from my roommate, will tinker with this later (might be fixed upstream already)
<janneke>hmm, could it be that our cross-built make is broken?
<janneke>i'm seeing "#f/bin/sh" not sure where that's coming from
<NieDzejkob>I'm doing "guix graph --type=references glibc | xdot -" and "guix graph --type=references gcc-toolchain | xdot -" and while both of them contain glibc-2.31-debug, it depends on gcc-cross-boot0-7.5.0-lib only in the latter graph
<NieDzejkob>why is this? If grafts are involved, how do I tell 'guix graph' to ignore these?
<leoprikler>NieDzejkob: because those are two different glibc inputs
<leoprikler>glibc for gcc-toolchain has a bunch of dependencies injected
<NieDzejkob>you could create it with special-files-service-type
<NieDzejkob>though note that due to a bug, deleting it from your config or rolling back a generation won't automatically delete it
<mwelt>NieDzejkob: I would prefere the ideomatic guix way to install and handle rust. If that is to install rust + cargo via package system - great. As long as I have some way to install rls
<mothacehe>looking at our berlin build farm, I observed that "berlin" itself has guix-daemon max-build-jobs options set to "20" but all other build node have this option unset, which means "1" unless I'm wrong. Is this a voluntary? Some offloading limitation maybe?
<mwelt>NieDzejkob: ok rls doesn't install without rustup, i.e. I have to use this ominous special-files-service-type, but I haven't a clue whicht directory I actually have to link to /lib?
<NieDzejkob>mwelt: (service special-files-service-type `(("/lib64" ,(file-append glibc "lib")))) should work.
<NieDzejkob>Unfortunately, there is no perfect way of installing rust on guix :/
<mwelt>NieDzejkob: I see. Just stumbled across an old nix issue, they had to actually patch rustup for their purposes, since rustup seems to interact with quite a few things, nixOS doesn't have. So I guess it's quite the same for guix then.
<NieDzejkob>the rust packages should get updated to 1.44 relatively soon, but tools like rustfmt, clippy or rls are still missing, and packaging them will take more time than I have to spare right now
<mwelt>That is unfortunate, since I started really loving guix, but w/o rust I am not able to keep it I think.
<NieDzejkob>right now I'd recommend adding the special-files-service-type hack to your config and using rustup
<ryanprior>I've been trying to get up my courage to build a Guix backend for the elementary OS AppCenter.
<ryanprior>raingloom: hypothetical PRs are welcome for this hypothetical GUI =P
<lfam>I feel like the use of multiple profiles is already quite advanced. It could be supported but hidden behind an "advanced mode" switch
<lfam>In any case, the person that does the work will be able to make the decisions
<ryanprior>I don't think it needs to be "advanced," but I do think I'd want to design around specific workflows. Profiles aren't part of the "manage/update my system" workflow. They'd be part of a separate "manage execution environments" workflow.
<lfam>To me, a GUI is not a good fit for that, because it obscures the scope of the environment
<lfam>Whereas it's clear when you do it in a terminal
<ryanprior>That doesn't seem obvious to me, my gut feeling is that a GUI could expose the scope of the environment just fine if you make that a design goal.
<raingloom>lfam: such switches are a bad idea according to the Elementary Human Interface Guidelines
<lfam>And I think that "environments" as a concept are really obscure and difficult. This ends up being the root of so many usability bug reports
<lfam>Okay raingloom. But this is Guix, not Elementary. Anyways, like I said, whoever does the work can choose what to do
<raingloom>lfam: i'm aware, but they have good guidelines.
<lfam>Guix relies heavily on environment variables, and we get bug reports and complaints about them almost every day
<ryanprior>The locales story is bewildering. We need some kind of bash plugin or something to deal with that imo. It exposes a usability issue that isn't totally the fault of Guix or of Bash, but between the two of them the blame is shared.
<lfam>I would place the blame on the entire ecosystem
<lfam>I'm frustrated because we've been trying to solve this problem for years
<civodul>guix keeps track of what user env should be set to what value, which is an advantage compared to many tools
<civodul>for example, "guix environment" just works, roughly
<lfam>Right! Unless people set environment variables in ~/.bashrc. And there are a lot of reasons to do that
<ryanprior>Oh I'm not saying we should determine % blame or anything. I'm saying by taking the system as a collection of components that collectively share the blame we can begin to change the whole system to deliver a great experience.
<lfam>I'm curious what sort of things were doing otherwise
<ryanprior>The pantheon terminal application runs a non-login Bash shell by default, and isn't configurable, so I created a script called `bash` that runs `exec bash -l` and put that on the PATH for when terminal launches.