<nlyy>1. guix package -S 1(or the oldest gen around) then 2. guix package --rollback (now you have a blank env) 3. guix package - i emacsy (install a guile library) 4. emacsy-gtk-webkit (run code that uses guile lib)
<rvgn>nckx Ah I see. It's about my issue with inputattach-service-type. Can I CC you in an email?
<str1ngs>#I'm not in the mood for arguing. I have a patch that fixes this already that's been ignored. and now I need to determine which is at fault guix or emacsy. so if you don't want to be help test
<nckx>str1ngs: I am helping, impatient person. I also want to know what you mean by ‘[--pure] means that your profile is still used’, since that makes no sense to me.
<Minall>Which one do I try? welp, I'll go with wgetpaste first
<nckx>Either wgetpaste or manually pasting it into a pastebin in a Web browser is fine, I just thought wgetpaste might be ‘easier’.
<nckx>As the topic mentions, we encourage the use of paste.debian.net (which is also what wgetpaste uses now IIRC) because it's friendly to Tor users; I don't know that about bin.disroot.org but would be disappointed if they weren't.
<civodul>you can run "herd statistics nscd" to see what's up
<davexunit>civodul: what happens is that upon login my custom pam module will validate the user account using a custom remote data source, but at some point after login when I try to run a command the shell responds with something along the lines of "I don't know who the heck you are".
<davexunit>running "id my-user-account" results in calls that lookup user info again and I continue my session until the next time it forgets.
<davexunit>so it seems like I am missing something in the shared library that implements all the _nss_* functions
<davexunit>unfortunately this low-level stuff is mostly undocumented. the glibc manual has a small section about it but mostly I had to crib from other modules that figured some of it out already.
<davexunit>anyway, not looking for anyone to solve this problem for me. but if anyone happens to know of good reference material for this sort of stuff, I'd be happy to receive a link to it. :)
<civodul>documentation is not that bad (info "(libc) Extending NSS")
<rekado_>I’m comparing potential build nodes and one of the options has a dual CPU (24 core per CPU) AMD EPYC 7451. I wonder a) if maximizing cores is a good idea for the build farm, and b) whether I should pick 128GB RAM or 256GB.
<rekado_>we have a big spreadsheet where we compare AMD and Intel server CPUs by price/100MHz
<rekado_>jonsger: yeah, it’s too bad, but we have to spend the money now or not at all :-/
<jonsger>oke, then the 7451 is maybe a good choice
<rekado_>Marlin1113: there’s an EPYC variant with 32 cores which we are also considering, but the base frequency is quite a bit lower, which would probably be noticeable in the many builds that are single core only.
<jonsger>are you intending to make the build workers only with one core or with more?
<jonsger>maybe it would be an option two have to machines or so with EPYC 7371 16x3.1/3.6/3.8GHz to get some builds faster
<ItsMarlin>i don't know if EPYCs also do it, but threadrippers have a way of boosting single core by using multiple cores
<sammich>i was looking to write a zig package for guix, it has a check if the running system is guix and uses $NIX_LDFLAGS and $NIX_CFLAGS_COMPILE does guix set equivalent flags does anybody know?
<rvgn>Do you anyone know free software desktop client for facebook?
<nckx>sammich: No, just use CFLAGS &c. zig using NIX_* is probably a bad idea.
<nckx>Goes to show that if you expose something, people will use it...
<sammich>nckx: ah cool, does guix set LDFLAGS i presume it does it seems like a normal thing to set
<nckx>sammich: I don't *think* so. Is it? When you build a package by hand there's no global LDFLAGS floating around either. It should be set by the package's build system. That said, some packages do need tweaks added so you'll find plenty of LD/CFLAGS examples in gnu/packages/*.scm.
***nckx changes topic to 'GNU Guix | 1.0.1 is out! get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs and patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guixsd.org | This channel is logged: http://logs.guix.gnu.org/'
<sebboh>hi all. I don't think I know how to handle my guix environment variables. I'm using guix on a foreign distro. I especially don't know how to handle the environment variables when I'm using `sudo guix ...`.
<sebboh>I have to manually export GUIX_LOCPATH= periodically to silence some 'guile: warning: failed to install locale' messages. But even when I silence them successfully during normal operation, they come back when I use `sudo guix ...`. I could surely tell sudo to preserve the environment, or manually pass some variables, or whatever, but I thought I'd check here for advice first.
<sebboh>Frankly I don't like having two copies of guix installed on this foreign distro.. one for uid=1 and one for uid=1001...
<ngz`>I just had an idea about "guix search". Once the list of matches is built, would it make sense to re-order them by graph depth, i.e., with those that are not inputs of any result above, then those inputs of one result, etc.
<ngz`>For example "guix search ivy" should return "emacs-ivy" before "emacs-ivy-yasnippets".