IRC channel logs
2023-08-28.log
back to list of logs
<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... <yewscion>bumble: Oh, this looks nice! I'm looking forward to hanzi not messing with the column spacing! <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? <sneek>martin2020, you have 1 message! <sneek>martin2020, podiki says: see ^ (or log) for using fhs container for appimages <vagrantc>martin2020: you might need to install udev rules <martin2020>podiki, vagrantc: thanks. I briefly looked at the udev service and was too intimidated to try it haha. But I just installed brightnessctl instead, and that seems to work fine <podiki>it should be as simple as adding a service to your config, (udev-rules-service 'light light), for example <podiki>at least that's the idea, depending on how you have your services, but that line is what you'll need <PotentialUser-82>Hello guys, I think I have some problem, I installed Ulauncher, but I got "ValueError: Namespace Gtk not available" error at runtime, does anyone know how to fix this error? <apteryx>uh, "help2man: can't get `--help' info from guix system" <apteryx>PotentialUser-82: you probably need to install 'egtk+' <jpoiret>apteryx: in what context does this happen? <aeroplane>Hey everyone, I have a question, about configuring guix. Since I know only basics of lisp (elisp), I am curious if I need to learn any new sytax or the syntax is almost similar to elisp. <jpoiret>ulfvonbe`: i agree with you that the sexp conversion wasn't implemented but I don't think it should have caused any errors <jpoiret>only that #o700 would have been used every time <jpoiret>aeroplane: syntax is similar to elisp but there are some differences. Also, Guix uses a lot of custom syntax and things on top of Scheme. <jpoiret>for system configuration it's not too different though <jpoiret>main differences with elisp is lexical scoping, more functional stuff and less mutation usually <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? <mrvdb>rekado: i'm on ppc64le-linux, not sure if that makes a difference (compiled clisp manually from aur and that one works ok) <mrvdb>guixp9 is the ppc64-le build machine, right? is that machine still building? seems a bit quiet on ci.guix.gnu.org <rekado>mrvdb: oh, that does indeed make a difference! :) <nckx>I've kicked them both (by restart cuirass-r-w and guix-daemon) and guixp9 is building a Guix. <nckx>It is building two Guix. <nckx>Currently building eight Guix. <nckx>What a time to be alive. <adanska>anyone have issues with the kde task mangager not showing your active apps? <apteryx>jpoiret: when using python-pygobject I think <andreas-e>hako: The web sites seem to be very fiddly... I have restarted qa. <andreas-e>But it is still not working. cbaines is the only one who masters them, I am afraid. <nckx>I also restarted QA 😊 Also with a clean cache directory, no dice. <nckx>I've moved the old one back. <nckx>Yes, this is totally different software from CI. <Guest19>Guys, anyone has a doc or link somethinng to install a plain xorg with no login mmanager , started by old startx ? <Guest19>guix hangs on system reconfigures almost all the time at the end suposedly <Guest19>after guix system:bootloader was sucesfully .... <Guest19>it usually displays a 0.0 Mb will be downloadded <Guest19>and thats where it dies and sleeps the sleep of the righteous <Guest19>Ctrl+C followed by a second reconfigure hangs too <rekado>the linux-libre mascot looks different now. I miss the squeaky clean little fella. <Guest19>it seems guix still have lots of bugs <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. <dthompson>lfam: same thing happened to me over a week ago <lfam>Did you find a resolution? <lfam>Maybe my dependencies need to be updated (i.e. `guix pull`) <podiki>when this happens I often have to reset the docs directory or clean out various files (never sure what), sometimes do the bootstrap again; but shouldn't happen on a clean check out <lfam>podiki: I'm trying and failing with a fresh checkout <lfam>I'll try clearing the cache <dthompson>I haven't done guix hacking in quite some time so my repo was very out of date <podiki>ACTION realizes a ~/.cache/guix-old exists from the last time I did this, free 3 gigs back yay <podiki>when I get the weird doc/cookbook failures i go on a random deleting spree <lfam>I run a headless Debian install where I installed X by hand. It's weird to have a Trash on a system like this <lfam>I always forget about it <podiki>lfam: that is a good one, considering i don't use a file manager usually, not sure how trash got stuff <lfam>Clearing the cache didn't help me <lfam>Maybe there's another cache somewhere??? <andreas-e>I have a script that moves things to trash from the command line, and I use it most of the time instead of "rm". <podiki>you are a safer/smarter person than me :) <lfam>I cleared the guix and guile caches in ~/.cache, made a fresh checkout, and it still fails to build the cookbook <lfam>Do you have a moment to try reproducing podiki? <podiki>lfam: sure, let me try a fresh checkout with a cleared cache <podiki>(so far so good; just did checkout, pure environment, bootstrap, configure, now about 39% through make) <podiki>some other cache/state somewhere....? <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. <lfam>Yeah I've used that kind of thing <lfam>But these days if I am out of space I just buy a bigger SSD <podiki>not ncdu, but baobab in the past <podiki>i think it is used as part of the QA system <vagrantc>it does not appear to be totally up to date <podiki>but yes, also keep meaning to use that in patch review workflow and haven't done it, good reminder! <vagrantc>at least the patches for 65233 do not include the updates submitted on almost a week ago <vagrantc>oh, maybe that is because i forget to v2 the series... <acrow>vagrantc: For git.guix-patches I just get a blank page. <acrow>I suspect it's just keeping the rif-raf out. <acrow>vagrantc: Any comments on 60976 <vagrantc>ah well ... it looks nice on the surface, and i am sure it will one day be terribly useful :) <acrow>vagrantc: Not sure on the fragment number but it's labelled PATCH v4 1/3 and the next two. <acrow>vagrantc: Yes, #18 is at the top. <vagrantc>acrow: still applies to master, at least <andreas-e>Could someone (next4th? lilyp?) explain to ngz and me how propagated inputs work in the presence of several outputs? The manual is rather unclear on the topic. <andreas-e>From looking at texlive, I get the following impression: <andreas-e>We have lots of texlive-xyz packages with outputs "out" and "doc". <andreas-e>And metapackages propagating a collection of texlive-... packages. <andreas-e>When installing the metapackage, my impression is that all outputs are downloaded, but only the "out"s are actually installed into the profile. Is this true? <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? <lilyp>yeah, you'd either have to hack up some union-build or separate the packages if you want to split them <ngz>andreas-e: This does not explain why "doc" outputs are pulled, doesn't it? <andreas-e>ngz: I think this is a separate shortcoming of the daemon or something. It looks as if ot does not download outputs separately. <andreas-e>Well, it needs to *build* them together; and then apparently it either builds the package locally or downloads all its outputs as substitutes. <ngz>If the package is built locally, then yes, you are bound to get both outputs. But when a given output is downloaded, this shouldn't happen. Odd. <andreas-e>Clearly it does not need to happen, substitutes could be downloaded separately by output. But our observations seem to indicate that this is not how things work. <andreas-e>This implies that there is no point to have several outputs for packages that are essentially only ever propagated. <ngz>"doc" can still be GC'ed <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). <ngz>andreas-e: I think I fixed the texdoc issue a few minutes ago <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. <acrow>vagrantc: xebian successfully installed your guix deb package. Sweet! <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. <acrow>They are pretty small files. <acrow>vagrantc: src(ditaa):/test-resources/text/art*.txt <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: gif should be ok too. <ngz>andreas-e: The whole point of modular TeX Live is to never download it completely, tho. <andreas-e>If it is supposed to replace the monolithic one and not just complement it, people may wish to do so, however. <vagrantc>acrow: i daresay, works for me... a few minor issues with the patch (trailing whitespace, commit) <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. <ngz>andreas-e: It makes sense. <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. <ngz>Could "out" contain a reference to "doc"? <andreas-e>No, but it is the same thing: Packages are always downloaded completely, no? <ngz>Also, some packages have "#:disallowed-references '("doc")" in their definition. <andreas-e>I tried texlive-biber. This downloaded the -doc. <andreas-e>But "guix gc --references /gnu/store/s4ig4pz1dbpjchfm15f0mdzd5fmyx305-texlive-biber-66594" shows only references to perl packages. <ngz>Let's try with a non-texlive package. <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 ? <andreas-e>ngz: And vice versa, I have just tried the two. <vagrantc>acrow: hrm. applying "guix style" made some things look much nicer, but added some too-long lines. <ngz>andreas-e: Was it the case, let's say, one year ago? (sorry, my guix time-machine-fu is weak). <andreas-e>Time to do something else now, sorry. Like dinner... <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. <unmatched-paren>i think it's (something something something cross-compilation [steady, yet just barely incomprehensible, muttering]) <mirai>I haven't confirmed this but from what I understood I think the following (contrived) example should illustrate <mirai>suppose you got a package with src/<whatever>.scm , doc/manual.xml doc/manual-extra-section.xsl and doc/general-style.xsl <mirai>the manual-extra-section.xsl is used to generate manual-extras.html but this (for some reason) depends on the target platform (lets say that it provides ARM64 section or a X86 one) <mirai>manual.xml and general-style.xsl are independent (and lets say it pulls docbook-xsl as a dependency), so the distinction of native or regular search-path doesn't matter <mitchell>is there an example of a package using search-paths instead of native-search-paths? <mirai>the extra-section.xsl (happens to pull some imaginary package opcode-highlighting-xsl whose files are platform specific) would actually make a difference vs #:native-search-path <mirai>mitchell: well, you can grep the source <mirai>admittedly there's one or two but not too informative <unmatched-paren>i understand the difference between 'native' and 'regular' in general but don't get how that applies to search paths <mirai>perhaps you could craft some dummy example packages? <mirai>make them output files with obviously target specific info and give them search path specs <unmatched-paren>mirai: i understand kind of what you mean, but i don't get why you need a different field for search paths that point to architecture-dependent files <unmatched-paren>if you compile X normally, getting O1, and compile Y cross-ly, getting O2, I don't see how a native-search-path couldn't work with both... <apteryx>unmatched-paren: I think as the name implies, and similar to native-inputs vs inputs, the native variant is to be used *also* at build time, while the later would only be used at run time <nckx>vagrantc: One of several ‘apache’ %mirrors? Substitute server? <nckx>Guix should print if Guix verbose. <vagrantc>i presume a mirror, as it is not yet in guix ... <vagrantc>was just surprised to see that lint warning after ... having successfully built it several times (and even after some "guix gc" fun)