<Guest69>Not sure myself but *** [Makefile:5394: doc/guix-cookbook.de.info] Error 1 sounds to me like that nonexistent nodes are maybe counted as error and it stops?
<ulfvonbe`>re: e9a5eebc785cb843034b38c5c5a6dd10904bdf2a, neither user-account->gexp in (gnu system shadow) nor sexp->user-account in (gnu system accounts) were updated to take into account home-directory-permissions it seems
<Guest69>Do you guys have sound in a VM from virt-manager?
<ulfvonbe`>not sure how that would end up with the error message in question, since positional arguments aren't used for either of those - it should have just caused the default to be used...
<martin2020>Hi, I have been using the "light" command to change the backlight brightness on guix system, but I have to use sudo every time, which is inconvenient. I have added my user to the video group, but to no avail. Does anyone know how I can control the backlight without sudo from the terminal?
<mrvdb>hi guix, after installing clisp I get this: "lisp.run: initialization file `lispinit.mem' was not created by this version of CLISP runtime" (trimmed the gnu/store paths). clisp is needed for sbcl which is what I actually want to install. Any ideas on how to deal with this error?
<adanska>hey guys! does anyone know how to get the default kde apps like okular and ark installed automatically alongside plasma-desktop? like how the gnome tools are automatically installed when using gnome-desktop?
<jonsger>meh, nheko doesn't start on wayland/sway anymore for me. It did worked in the past...
<rekado>mrvdb: if you want sbcl why don’t you “guix install sbcl”?
<next4th>jonsger: maybe try it in 'guix shell nheko qtbase@5 qtwayland@5' to see if it need the qt wayland plugin?
<mrvdb>rekado : i do, but that leads to the same error. clisp install fine, but can't do anything, be it while installing sbcl or standalone
<rekado>mrvdb: I cannot reproduce this with guix at commit 37cca1d87e18c257a9697110557a2bfaf9bc684b. “guix build sbcl” works fine.
<Kabouik_>jpoiret: Re (several days later): using .profile as recommended by Guix to inherit env in whatever WM GDM launches. Do you mena ~/.profile? That file was inexistent on my end, and I didn't find any Guix resources mentioning it. Is there something in the manual I might have missed?
<apteryx>lilyp: I've sent a revision for guix-emacs.el, incorporating your suggestion
<viaken>Guest19: That's behavior I've been chasing, but I've not had time to nail it down. I think Shepherd loses its socket somehow. I suspect my issues started when syncthing tried to start as a user before their homedir was mounted.
<viaken>That, or from subsequent attempts to restart it during system reconfigures?
<viaken>Anyway, I have an os config that should reproduce, but I've not had time to test it in a container/vm.
<qeqpep>Hi. I've stumbled upon edge case of a single-file origin as an input. It's handy to use old inputs format and assoc-ref %build-inputs to get its path. Wonder how to replicate that with a new format.
<viaken>lfam: podiki: Y'all ever try ncdu? I always pull it out when I need to clean up some space.
<andreas-e>What would make sense in the texlive context is that the metapackages also get "out" and "doc" outputs, and that the "out" and "doc" outputs of the propagated inputs get propagated into one or the other. So metapackage:out would be the full collection of the functional data, and metapackage:doc the full collection of the documentation.
<lilyp>andreas-e: propagated-inputs only propagate the chosen output, by default that's out
<andreas-e>lilyp: Thanks! So what I have in mind would be possible as follows: Duplicate each propagated input, once for its "out" and once for its "doc" output. And then declare two outputs of the package itself? Hm, I suppose that would not work, because the metapackage itself contains no actual files?
<andreas-e>One solution would be to only use one output for the texlive-xyz packages, since the doc output is downloaded anyway. And I think it makes sense that people get the documentation for their installed packages (assuming the texdoc issue with several directories in a path can be solved, but this is somehow orthogonal).
<andreas-e>Another solution would be to add packages such as texlive-scheme-medium-doc with a propagation of all the "doc" outputs of the subpackages into its "out" output. I think you already suggested this.
<acrow>vagrantc: There were some examples in the docs that I ran to verify that things were working.
<ngz>andreas-e: I'd rather have this "doc" issue sorted than bringing in all documentation in every TeX Live package. Also, note that "doc" outputs are _not_ downloaded when installing a collection.
<ngz>andreas-e: It seems to happen under some defined circumstances.
<andreas-e>ngz: Could this be an additional shortcoming that the doc outputs are gc-ed? Is there not a risk that they will be downloaded again next time?
<ngz>andreas-e: Do you see "doc" outputs when running, e.g., `guix install -n texlive-scheme-gust'?
<andreas-e>ngz: I just did the following from my monolithic texlive installation. "guix package -r texlive -i texlive-scheme-medium". And I think that each and every doc output has been downloaded. So far my impression is that you always download all outputs of a package, or none.
<andreas-e>ngz: I confirm for texlive-scheme-gust. texlive-antt-66594 texlive-comment-66594 texlive-cyklop-66594 texlive-iwona-66594 texlive-poltawski-66594 plus their -doc outputs, and finally texlive-scheme-gust-66594 are downloaded (I already have texlive-scheme-medium in the store).
<vagrantc>acrow: examples for ditaa in the upstream sources? do not see anything in the built package
<acrow>vagrantc: So far, so good. The only annoyance has been some screen blitting on the tty screens. I also need to manually update the app launcher for installed guix packages. I think that was automated under ubuntu.
<acrow>vagrantc: Hmmm.. It's been awhile but I think there were some tests/testlib in the sources that you could grab.
<andreas-e>ngz: Indeed something strange happens. From the profile n with texlive-scheme-gust, I have done a "guix profile --roll-back" to profile n-1. Then a "guix gc". This deletes all doc outputs (and keeps the normal outputs, since the profile n is still alive). Now I could of course do a "guix package -S n" to get back to my texlive-scheme-gust. But if I do "guix package -i texlive-scheme-gust" instead, then all doc outputs are downloaded again!
<andreas-e>Interestingly enough, here the daemon knows how to download only the "missing" doc outputs, and not the out outputs that already are in the store. But ironically, it is now downloading tons of package outputs that will just be put into the store, but not appear in the profile.
<andreas-e>ngz, lilyp: Something looks seriously wrong to me when combining propagated inputs and several package outputs.
<acrow>vagrantc: So, with pkg ditaa installed, cd src(ditaa):/test-resources/text/; then, eg. Run 'ditaa ./art10.txt ./art10.gif' and look at the gif it creates.
<andreas-e>(Notice that once we have the full modular texlive distribution, we have about 3GB of documentation split over, if I remember well, about 2000 packages.)
<acrow>vagrantc: It's tedious but I believe I went through them all some months back.
<ngz>andreas-e: 4200 packages actually; I'm almost done with the full modular TeX Live.
<andreas-e>I think downloading 8400 package outputs will be much slower than just downloading a monolithic package in one go.
<vagrantc>acrow: worked with art1.txt converting it into a .png
<acrow>vagrantc: Cool. Guix packages don't bitrot too quickly.
<vagrantc>acrow: also, while i see value in alphabetizing the use-modules entries ... i think it would make for a more readable diff to ... leave some "standard" things unsorted ... but opinions may vary wildly on that :)
<acrow>vagrantc: Yeah, I was told to do that by someone. Perhaps in a prior patch effort.
<andreas-e>ngz: Something even crazier: Start with profile generation n-1. Then "guix package -i texlive-scheme-gust" to reach generation n. Then do a "guix gc", but do not roll back. This keeps us in generation n, but removes the doc outputs from the store. Then do "guix package -u texlive-scheme-gust". This redownloads all the doc outputs! And after downloading about 1GB, guix notices that there is nothing to do and... does nothing.
<vagrantc>acrow: i read they suggested sorting the inputs ... but not sure about use-modules
<andreas-e>ngz: Now something else. I am in profile n with texlive-scheme-gust and do a "guix gc". What will "guix package -i hello" do? Download or not download the texlive doc outputs?
<andreas-e>We are lucky, it does *not* download the doc outputs.
<andreas-e>But if people do a "guix gc; guix pull; guix package -u", they will every time end up redownloading the doc outputs. So I think that the behaviour of "guix gc" makes things even worse. We would be better off not splitting the outputs to *prevent* the docs from being gc-ed and redownloaded even if the package does not change.
<andreas-e>ngz: Yes, it looks consistent with a certain logic.
<ngz>andreas-e: What happens if you install a non-meta-package?
<andreas-e>The same. It downloads the -doc, but does not install it.
<ngz>There's something fishy. No propagated inputs are involved here.
<andreas-e>The code would give the answer. But our experiments so far seem to indicate that packages are downloaded with all their outputs.
<ngz>Indeed, guix install mpd also installs mpd-doc
<lilyp>building a regular package does always pull all outputs as far as I remember
<ngz>Then, what is the point of the "doc" output? I am missing something.
<lilyp>maybe we should use union builds for texlive then?
<andreas-e>Hm. I just tried libxml2. "guix package -i libxml2:doc" downloaded only the doc output. Similarly with the static output.
<lilyp>I think it's the difference between `guix build' and `guix package'
<ngz>Yes, building a package provides all outputs since those are defined only at the end of the process.
<andreas-e>lilyp: The point was that "guix package -u texlive-scheme-gusto" always redownloaded all the doc outputs of the propagated inputs, although none of them was installed.
<ngz>Installing a package (with substitutes), however, should not pull non-default outputs.
<andreas-e>I also tried "guix package -i mpd", and it also downloaded the doc output.
<andreas-e>Strange. Indeed I do not see the point any more in having different outputs. (Admittedly, I have hardly seen the point before, but here it seems to imply lots of downloads, and together with "guix gc" even more downloads as with only one output.)
<ngz>Hmmm, would guix install mpd:out also download mpd:doc ?
<vagrantc>honestly, i feel like we should either improve guix style, or just go along with whatever quirks it throws at us ... rather than contradicting guix style too much
<vagrantc>and by we, of course, i mean ... someone who knows what they are doing :)
<cbaines>I've figured out why qa.guix.gnu.org wasn't working now, data.qa.guix.gnu.org wasn't returning some data and restarting it has got things going again. Something is up with the resource pooling.