<podiki>anyway, shepherd run as user is the same as starting anything else, so you can put it in lots of places
<podiki>there's a difference between login and interactive (and non-interactive non-login) shells; check what you use for the right files and what goes where, i usually look it up if i haven't been tweaking them recently
<podiki>so, shepherd as pid 1 is always run (it is the system), after that it is up to the user
<podiki>("what you use" meaning e.g. bash, zsh, etc.)
<jpoiret>as you highlighted one is sourced on login, the other on each new interactive shell
<jbnote>hi, is the contents of /gnu/store/.links hardlinked? Can I safely trash the directory after adding --disable-dedup as a flag?
<jpoiret>jbnote: general note, you should never touch /gnu/store yourself, all warranties void if you do
<jbnote>jpoiret: I understand this, and that my warranty is void even if I follow advice from here :)
<jbnote>jpoiret: I'm trying to switch from the store's dedup system to btrfs + duperemove. There's a flag in guix-daemon to avoid doing dedup explicitly.
<graywolf>Can I write a service that install a package? So for example I make a service foo-service-type, and it will both do some configuration AND install the package foo so that it is in the $PATH?
<cbaines>install a package in what profile graywolf?
<graywolf>The system one? Basically I want to have a service that does the equivalent of (operating-system ... (packages foo ...) ...)
<graywolf>(Sorry I am unsure what that profile is actually called)
<snape>can you describe your use-case more precisely?
<snape>why do you want the package to be installed?
<snape>you want to be able to call the executable from a shell?
<graywolf>I want to make an emacs-service-type, that would configure emacs as I like it, but that will not be that useful if emacs is not in the $PATH. I *can* add it separately, but I would like to be able to do reduce the chance to forget that when I am making a config for a new machine.
<graywolf>Emacs is not the only example, basically I would like to be able to make a "feature" service that adds some capability into a system, in this case configured editor launchable from shell.
<Altadil>weidtn: I’m not an expert, but I think you can make changes to guix from another distro. You can work directly from your copy of the git repo.
<weidtn>I want to install guix on my computer. But I need distrobox 1.5 So I can use the --nvidia flag. If this does not work, there is no point in installing guix right now. I don't know how to do it and it seems like a lot of work for something that might not work in the end. But it's probably 5 minutes for somebody who is already used to doing this.
<Altadil>weidtn: I don’t know distrobox, but I understand right, you are trying to install guix inside distrobox ?
<weidtn>other way around. I want a stable reproducible system that is guix. And then run distrobox for stuff that is not available/working in guix. Things like cuda and games that need the 1.5 version of distrobox so i can pass my nvidia gpu to it.
<Altadil>oh, I see. Then my guess (again, I’m a noob here ^.^) is that the shortest path is to still install guix first, and then install distrobox using an option to manually change the version. See part 10.1.2 Package Transformation Options of the Guix manual.
<weidtn>okay so I found guix refresh distrobox --update. But it does not work for a system package I guess? sudo -i does not work
<Altadil>weidtn: oh, sorry, I could I forget to mention guix refresh ! You want to use it on a git checkout : see parts 22.1 Building from Git and 22.2 Running Guix Before It Is Installed of the manual
<graywolf>civodul: ah, that is great, thank you :)
<weidtn>snape: I am still stuck cloning guix, just to try to do this version bump. Why do you think this will not work?
<civodul>efraim: dear Rust team :-), the ‘rust-team’ jobset on ci.guix is done!
<snape>because i tried and there is some error with newuidmap being not found
<snape>plus the search and replace regexp that doesn't work anymore (but this is easiliy fixed)
<weidtn>Okay, so I guess I just wasted 2 hours. I don't know how to fix any of that. Seems like I have to wait to install guix on my main machine until somebody who knows what he is doing is fixing that.
<rekado>weidtn: or you could run “guix pull”, which gets you commit dcfd4d9c4827ca6bfebeec46fe6bb8373c425a1c
<RavenJoad>Is it expected that LaTeX compile times increase when using a texlive-scheme? Compile times for a simple exam documentclass have noticably increased after switching from texlive to texlive-scheme-full.
<avalos>Help, I can't reconfigure my home! It says it can't build the directory of Info manuals.
<avalos>I did the reconfigure after running `guix pull` a few minutes ago.
<podiki>(or part of make clean, or make clean-doc to be less invasive)
<dthompson>well at least I'm building again. thanks for the help podiki
<dthompson>I am going to update guile-next to reflect the latest commit in guile's main branch
<podiki>happy to have thrown my usual haphazard steps for consumption
<dthompson>I was told awhile ago that such updates could be done freely as its a leaf package
<jbnote>Hello, i've got a newbie question about system declarations. I'm trying to write a fcgiwrap block in an nginx configuration and I need the full store path to a binary in order to assemble the nginx configuration string. I know how to translate a package name to a string in a gexp context ($#). Can you do the same (package to store path) outside of a gexp in a system declaration? If so, how?
<podiki>dthompson: I don't know about that specific case, but I would say yes, generally the -next packages are for that reason (no dependents)
<podiki>jbnote: you should be able to use gexps in your system config as well, it is built as a derivation like anything else
<dthompson>well guile-next isn't exactly a leaf package but it only has a few dependents
<jbnote>podiki: You mean a gexp can be a value, it is not necessarily a function? Ok, i'll try.
<dthompson>guile-hoot 0.1.0 is in the oven and having an up-to-date guile-next is a pre-req for packaging it.
<dthompson>so I'll update guile-next and make sure its few dependent packages build for me.
<podiki>jbnote: i'm not sure what you mean exactly, but yes try :) the idea of using a gexp to get a store path to use in e.g. string-append in a configuration all sounds good to me
<podiki>gexp and ungexp are like quote and unquote
<dthompson>civodul: oh I'm glad you were able to tune in for a bit! stream had a rough start and died a few minutes in, but despite the issues it was a good time.
<rrobin>avalos: sounds like that binary is broken somehow, i assume the same thing happens if you try to run it. what do you see if you call: file /gnu/store/5mvsq0p6pwfl9lvaixmc0yb58fz2cv35-texinfo-6.8/bin/install-info ; or run it directly
<civodul>dthompson: yeah, i found the new link and was able to follow once it had restarted, it was nice!
<jbnote>Hi, I need help understanding the magic behind (file-append ...). If I use it in some context, for instance to initialize a structure field, it works. If substitute for it a (format ...) call with the same (file-append ...) call as an argument, it prints the procedure. If I use (string-append ... ) with the same (file-append ...) as an argument, it tells me that I have the wrong type. What happens? Is there a way to coerce the output
<ulfvonbelow>file-append is a procedure that produces a <file-append> object. When this object is expanded in a gexp, it produces the resulting string.
<jbnote>ok, thanks. I also just got this from gexp.scm. I just don't understand why in what looks to me like identical places, but in slightly different contexts (function arguments VS more-or-less direct value) it seems to behave so very differently. And i'm at a loss how to write things in a way that I get the behaviour I want.
<jbnote>would the difference I observe be the switch in define-gexp-compiler ?
<ulfvonbelow>a file-like object is represented differently in the "build side" than on the "host side". For example, (string-append (file-append somepackage "/bin/blah") "-suffix") will fail because a <file-append> object isn't a string. However, #~(string-append #$(file-append somepackage "/bin/blah") "-suffix") will succeed if, for example, that gexp is used in a computed-file, or #:phases of a package, etc.
<jbnote>ulfvonbelow: Thanks for taking the time to educate me :) I think I understand the examples you gave. However here, at the same place -- where a string is required, a (file-append git "/bin/git") will yield the desired result (and the correct string) while a (string-append "CGI_SCRIPT=" (file-append git "/bin/git")) will not work. At the very same place. I'm at a complete loss to understand why.
<jbnote>ulfvonbelow: or to put it in another way, I don't understand why in one case, i'm on the build side, and in the other, on the host side. The expression is just transitioning from being the function called to being an argument of a function call.
<jbnote>ulfvonbelow: I would think they'd be in the same 'context'
<ulfvonbelow>file-append doesn't actually "do" the file append; it just creates a record (specifically, a <file-append> record) with the arguments it was called with, so that when that record is substituted into a gexp and that gexp is expanded, it expands to the desired result. Wherever you are putting that <file-append> object, it's ending up being expanded later on down the road. In other words, when it works, it goes like this: (file-append git
<ulfvonbelow>"/bin/git") --> evaluates to some <file-append> object --> that <file-append object> gets stored somewhere --> something expands it. But it doesn't work when it goes like this: (file-append git "/bin/git") --> evaluates to some <file-append> object --> (string-append "CGI_SCRIPT=" <that <file-append> object>) --> type error!
<ulfvonbelow>if you share more about where the <file-append> object is getting stored and used down the road we could more precisely trace what's happening