<bhartrihari>Hello, I tried to install the texlive package recently but it failed because of lack of free space (apparently 8.2GB wasn't enough). It downloaded a 2.6GB archive which I don't want to download again. Is there a way to make guix gc not delete that archive?
<bhartrihari>I mean, is there a way to run guix gc without deleting that archive?
<jackhill>bhartrihari: The basic idea is that you can create a gc root for it. I think you can do that with `guix build -r keep-texlive-root $(guix gc --derivers /path/to/texlive)`
<jackhill>I haven't tested that, but it will create a keep-texlive-root symlink that tells garbage collecter to treat the path as alive.
<jackhill>yes. You can undo it by remving the symlink.
<bhartrihari>Where is the symlink located? Or is there some dedicated command to delete that?
<jackhill>ordinary guix package operation create symlinks under /var/guix/gcroot. This one would be treated just like those. I beleive it can reside anywhere the guix-daemon process can see it.
<bhartrihari>So I would be able to delete it with a simple rm command, right?
<jackhill>deleting is just a regular rm. For the automatic ones that guix package, guix pull and company create those commands also manage the cleanup, for for manually created ones, the cleanup is manual as well
<jackhill>also, if you're tight on disk space, you may consider the texlive-packagename packages instead of the full thing to just install what you need. You may run into some remaining bugs with the "modular" texlive, but reports are welcome.
<riddochc>Hi, folks. New to guix, been using linux a rather long time (23 years, feeling old now saying that)
<riddochc>Still figuring things out here. Like what to do with the "profile contains conflicting entries for zlib", where both ruby and erlang want zlib 1.2.11 but there's apparently a different hash value in the path...
<riddochc>Been puzzling over this one for a while. Somehow I thought that ruby and erlang could each use a different version of zlib, if necessary, but it doesn't *seem* to be necessary, but there's apparently some sort of conflict anyway.
<jackhill>That almost sounds like a bug to me. I wonder if ruby and erlang really need to propogate zlib into the profle (I see that ruby does it directly, but for erlang it must be from one of its other propagated-inputs).
<jackhill>Without the propagation, the different versions would be fine because they wouldn't conflict. Would you mind opening a bug report?
<pkill9>yes they are conflicting because they are propagating inputs
<jackhill>as a workaround you could use ruby and erlang in separate profiles
<jackhill>at the very least, now you'll get to learn some more guix concepts :)
<riddochc>Yeah? I notice the erlang package is relatively old... And sure, I'm willing to file a bug report, Oh, I hadn't tried out using separate profiles yet, so yes, good excuse for that.
<riddochc>Reading a bit about propagated inputs now. If possible, I'd like to offer a patch with my bug report.
<riddochc>Oh, an easier question... the docs say KDE isn't currently in guix, but it looks like there are a fair number of kde-based packages present when I search?
<riddochc>There's plasma-framework, which looks like a pretty substantial portion of it.
<jackhill>riddochc: it is a work in progress. I'm not sure how close we are.
<bhartrihari>Hello, I installed texlive-base, texlive-latex-base, texlive-bin, and a few other packages but I need a format file pdflatex.fmt. Does anybody know which package can provide that?
<bhartrihari>While invoking latexmk to create a pdf from tex file, mktexfmt gives me the following error "I can't find the format file `pdflatex.fmt'!". Is it a configuration error or does any package provide such a file which I can install? I'm using the modular texlive install.
<zimoun>Naive question: I have a local definition and the local source. The package uses git-fetch. I tweak the source then I rebuild with "guix build -L . --with-git-url=file:///path/to/". But I need to commit my changes each time which is annoying. I remember discussion about that but I do not find it. Basically, I would like to do "guix build -L . --with-source=." for any source method. What is the trick?
<DivanSantana>I want to use guix time-machine but install the outputs to a profile/directory. How can I do that?
<zimoun>DivanSantana: guix time-machine -C -- package i foo -p /path/to/profile
<zimoun>I answer to my naive question: '--with-source=pkg=file:///' :-)
<kmicu>bhartrihari: it’s possible that’s an issue with latexmk. Do you have a minimal *.tex file that reproduces the issue and you could share?
<kmicu>(You could also try compiling without latexmk (you could find what that tools does by investigating latexmkrc file))
<bhartrihari>kmicu: actually the problem seems to be with mktexfmt which is run by kpathsea. I generated a few pdfs using latexmk recently so I don't think that is the problem. I should try and install the entire texlive package I guess.
<bhartrihari>How do I delete unused packages from /gnu/store? I have 2 copies of ghc in the store taking up 2.6GB while none of my users have it installed. guix gc doesn't delete it, it seems.
<efraim>it may be referenced from other generations of your profile
<bhartrihari>Hmm. Can I mark it dead somehow? Any commands to find out what generations refer to them?
<civodul>bhartrihari: you can try "guix gc --referrers /gnu/store/xyz" to find out what refers to this item
<bhartrihari>Thanks civodul. Any way to delete an item and all its referrers? --delete option to giix gc doesn't work.
<NieDzejkob>bhartrihari: If 'guix gc' doesn't delete it, then it means that there's a path from a GC root to the item. An operation like "remove with all referrers" is almost never the right idea, you want to delete the old generations of your profile that refer to GHC, instead.
<NieDzejkob>if you installed ghc previously with 'guix package -i' or 'guix install', you're looking for 'guix package --delete-generations=1month', or something similar
*NieDzejkob wonders if/when their messages will arrive, since Quassel doesn't really like the network conditions
<bhartrihari>NieDzejkob: I have deleted all the old generations with guix package -d
<civodul>bhartrihari: the spirit in general should be: let the GC do its job :-)
<civodul>when it determines that /gnu/store/xyz can be deleted, it'll delete it
<civodul>you can run "guix gc --list-roots" to make sure you're not retaining "GC roots" unwillingly
<nckx>No. ‘Bournish’ isn't a separate thing, just a different REPL syntax for Guile.
<nckx>It *is* the REPL. And Guile doesn't handle keyboard input, the kernel does. You won't be able to type anywhere.
<nckx>Hence my suggestion to try an older generation's --repl, if you've typed successfully in the past.
<nckx>It must be a regression either in the kernel/initrd or your system configuration.
<bonz060>In guix, how do you look up documentation? I'm trying to figure out how `substitute-keyword-arguments` works... I've always relied on the online manual but for this case, I can't seem to find anything
<nckx>bonz060: ‘info guix’ or ‘info guix [topic]’, but I doubt that s-k-a is documented. In such cases I grep guix for ‘define.*substitute-keyword-arguments’, see that it's in guix/utils.scm, and read the docstring.
<nckx>Users of advanced emacs magic will surely frown at this but it's good enough for me.
<rovanion>My Intel i7-8550U never seems to clock down from ~3.9GHz on any of its four cores, according to cpufreq-info. Its running quite hot while it seems to be doing not much according to htop. Its running with Intel pstate as its governor. Any ideas on how to get it to throttle down?
<nckx>rovanion: Which governor are you using? See cpufreq-info (cpufrequtils package).
<ArneBab>I don’t: it goes the same route as pulseaudio, just more extreme: redo everything, play over the periphery to get people to adopt it, add subtle breakages that incur a cost for everyone who does something slightly out of the expected.
<lfam>That's what I hear, but I started using GNU/Linux when Debian was still using sysvinit, and I couldn't successfully host custom services with it. When they switched to systemd it became super easy
<ArneBab>I used to like pulseaudio when it came out, but the errors I hit over the years that typically could only be fixed by black magic (as in "I don’t actually understand what this does, but it works") got me quite unhappy.
<lfam>Now I deploy services quite easily, and I find it reliable and just sophisticated enough.
<lfam>I guess that people will always dislike change, and there are social components of the situation too
<ArneBab>I’ve been using Gentoo, and there writing a service was already easy. OpenRC does what SystemD does, but without the NIH. Instead of writing a whole new managing daemon that does everything, they defined a declarative language via bash functions that allows you to go down to scripting if you need to, but you usually don’t.
<nckx>cannot [install strace]: 1 dependencies couldn't be built
<leoprikler>since we already have package/inherit, I think this would be a good fit for some syntactic sugar ;)
<ArneBab>lfam: it’s not like the features offered by systemd are bad. As with pulseaudio it gives powerful features that are great until a subtle error prevents you from using your recording equipment for years, because you’re not able to find a reliable solution. Basic functionality breaks, quality is degraded, and that’s too big a price for convenience.
<ArneBab>but now I ranted enough; I found a solution for audio (tell alsa not to use pulseaudio; luckily documented for Guix!) and just stick with Guix :-)