IRC channel logs

2024-08-25.log

back to list of logs

<freedomforge> https://paste.debian.net/1327448 I keep getting a guix system: error: read errror while loading '/etc/config.scm' expected ")" however I can seem to find it.
<freedomforge>is there a way to edit this file in emacs?
<RavenJoad>freedomforge: I assume this is from the installer? If you switch to a TTY, you can just do a "guix shell emacs", open Emacs, and open the file like normal. (Bear in mind it will be an unconfigured Emacs).
<RavenJoad>Also, FYI, you mixed up the services and packages lists. You put %desktop-services into the packages list. That is likely where your issue is coming from.
<thanosapollo>The file browser for mullvadbrowser is broken, has anyone found somekind of fix for it?
<RavenJoad>I don't use mullvadbrowser as an Internet browser, but does it ship its own file browser? Or use the system one?
<freedomforge> https://paste.debian.net/1327450 line 14 error: use-service-modules: unbound variable. hint: Did you forget a `use-modules' form? however I included a use-modules and use-service-modules came with default install.
<freedomforge>basically, I'm just trying to add bspwm so that it's avaiable to login from gdm
<RavenJoad>freedomforge: use-service-modules comes from the (gnu) module. You need to add (gnu) to your (use-modules ...) list.
<freedomforge>RavenJoad: thanks, is --allow-downgrades a bad idea? when used with guix system reconfigure?
<bdju>I was trying to run a tool that interacted with a USB device and it was supposed to use ttyACM0 but I did not have this file in /dev. I ended up using another PC in the meantime with a different OS, but for future reference, is there a way to have that file created?
<efraim>podiki: llvm-for-mesa is smaller than llvm. Also iirc there were problems with llvm-15 on i686
<podiki>efraim: and is going up to newer llvm also bad then? seems we don't need to add amdgpu to targets now (tried with current mesa, 24.2.0); had to modify llvm-for-mesa
<podiki>but got it to build on x86, mesa jumped in size quite a bit, only a slight increase in my changes to llvm-for-mesa (went with 18, but 15 also worked)
<efraim>Newer llvm would be better. I think there was something weird with aarch64 and asahi drivers
<efraim>I think I committed some changes to core-updates to make that work
<freedomforge> https://paste.debian.net/1327458 guix system reconigure is complaining about $desktop-services as an invalid field specifier on line 23. Which doesn't make sense since I need to modifiy the default config. Or am I misunderstanding something?
<freedomforge>%desktop-services, rather
<RavenJoad>freedomforge: --allow-downgrades is not a bad idea, but you need to be sure what you are doing, because you are forcing your channels (Guix's and others' history) to back in time.
<RavenJoad>bdju: I believe items in /dev/ are created/populated by the kernel. So if /dev/ttyACM0 was not showing up, something else was different/wrong. Could the device have shown up as /dev/ttyUSB, somehow?
<RavenJoad>freedomforge: re: %desktop-services: Your services list is wrong. Parens are the problem. Also, I don't think using %my-services that way will not work.
<bdju>I dunno, dmesg labeled it ttyACM0 the file just wasn't there when I checked and the tool wasn't working
<bdju>while looking it up I found at least one case where someone said it was disappearing very fast so maybe I needed to do a one-liner to do everything I wanted in a row and hit enter as soon as I plugged it in
<koorosh>hello i'm trying to setup greetd to automatically login to a bash shell on tty1 but I still get the login prompt can someone help fix this
<koorosh> https://paste.debian.net/1327460/
<apteryx>is the icedove build currently broken?
<ieure>koorosh, I don't know an answer for sure, but I suspect you need a greeter which launches greetd-agetty-session which passes the --autologin option to agetty(8).
<koorosh>I'm trying to avoid the mingetty and agetty since passing configuring them with the autologin field set gives me the message "(error in service module)"
<koorosh>what is the easiest way to achieve autologin on a tty, I followed the manual for mingetty and wasn't successful
<thanosapollo>RavenJoad the gtk one that ships with the tor/firefox browser, it produces this error (Mullvad Browser:20107): Gdk-WARNING **: 22:56:41.816: Native Windows wider or taller than 32767 pixels are not supported
<koorosh>I either get the error in service module or /gnu/store/<hash>bash/bin/bash not found, but the path is a valid path pointing to bash
<podiki>efraim: thanks. i will do a local mesa-updates branch rebased on core-updates and then get that to the CI soon to see
<xFFFC0000>I have a multi channel setup in my configs. Are there anyway to force pull to update only single of them? when I use `pull`, it updates all of them.
<Rutherther>I don't know if there is a "native" way to do this, though one possibility is to use "guix describe -f channels > my-channels.scm" to get the channels used, with commits, remove the commits for channels you do want updated, and then "guix pull -C my-channels.scm"
<xFFFC0000>Thanks. will give it a try. a little bit complicated than I was hoping.
<h4>People say that `guix weather` is nice to figure out what takes space, but it says nothing relevant, it only says how much per substitutes we have downloaded (and in a garbled mean). How to I figure out precisely what takes space?
<adanska>question: when packaging common lisp packages, if their name doesnt include the `cl-` part at the front, do we add it when defining the source package?
<adanska>like, for example, there's a package with its name listed as `foo` in its .asd file. the sbcl version in guix would be called `sbcl-foo`, but would the source version be called `foo` or `cl-foo`?
<MisterEsse>Hi. Using the GNU Guix System: when installing a package that can be installed by compiling locally, and by "substitutes", which one will Guix install by default?
<adanska>h4: do you mean what takes space on your system? for that, you could do this little invokation: `guix size $(guix system build config. scm)` which should tell you which packages take up the most space in your system conf.
<adanska>otherwise just plain old `guix size foo` on a package foo will tell you its closure size.
<adanska>MisterEsse: substitutes.
<h4>adanska: Thing is that I make heavy use of `shell` so analysing my SCM won't do
<MisterEsse>adanska: thank you. How can I configure so that Guix does "compile locally" by default?
<adanska>MisterEsse: I'm not sure. i think you can remove the substitute servers by setting %default-substitute-urls to an empty list? or maybe theres an option somewhere else. otherwise, you can just pass --no-substitutes to all of your guix invokations
<adanska>`guix install --no-substitutes foo` and the like
<adanska>h4: so what exactly are you trying to measure?
<MisterEsse>adanska: `guix install --no-substitutes foo` seems the best approach for me.
<MisterEsse>Thanks!
<adanska>MisterEsse: no worries :)
<MisterEsse>if I am in a hurry and want to install some program, I want to be able to use substitutes.... ;-) .
<h4>adanska: Normally I use `filelight` or `baobab` but with all those symbolic links I can't figure out what is where so it's difficult to make sense of data. I want to know what packages takes most size
<adanska>oh, like in your store?
<MisterEsse>h4: by "store", adanska means "/gnu/store/".
<adanska>yes haha
<MisterEsse>:-) .
<h4>Yeah Guix seems to store many things over there
<MisterEsse>h4: ahahaha.
<adanska>uuh i wrote a little shell script a while back that went over every package in my Guix and sorted them by the closure size
<adanska>you could probably use a similar approach to just limit it to the packages installed on your machine...
<h4>adanska: Even such a script won't do it all, because there are many dependencies and what is important is to know the size of what you asked. Like what FireFox takes total, not `firefox` alone then `libweb` then `libgcc` and idk what. And there is a whole version paradigm too
<h4>Guix needs to figure out "ptincipal packages" that you've explicitely asked and inform about them taking account their dependencies
<adanska>well thats what the closure size is.. it includes all the dependencies right?
<h4>Like if I only installed Linux kernel it should tell me "Linux: 300 MB" and nothing else. Not "Linux: 0.01 MB; libWhatever: 2 MB; ..."
<MisterEsse>h4: I thing you might reach that with some sort of `du -sh` command... I am off, see ya!
<h4>I don't even know what it is supposed to mean but if it does that then yeah
<h4>MisterEsse: du list all files and don't take that dependencies and versioning dimension into account
<adanska>h4: see the output of `guix size icecat` and see if thats what youre looking for
<adanska>it sounds like it is
<h4>adanska: That commands list allll dependencies, exactly not what was asked. It should output "Linux: 300 MB" and nothing else. Not "Linux: 0.01 MB; libWhatever: 2 MB; ..."
<h4>But if it can produce exactly the same output but with explicit packages and sorted like that with percentages, that would be bliss. That's what I expected `guix weather` to do in the first place
<adanska>well it does show the total size at the bottom, and the `self` column shows the size of the program sans everything else
<adanska>`guix weather` just shows if theres substitutes avaliable for a certain package
<adanska>it doesnt do anything like that
<h4>Instead of `guix size icecat\n\nlibSomething 10% 1MB\n\n...` It should be `guix size\n\nFireFox 20% 100 MB\n\nLinux 30% 400 MB\n\n...`
<adanska>riiight..
<adanska>i feel like that would be kinda hard since many programs share dependencies, and those dependencies are deduplicated with hard links
<adanska>so they dont take up additional space
<h4>adanska: `weather` was advised here by I don't know who, but yeah, don't do what's needed... `’guix size` do exatcly right work but at wrong level. It should do it one level upper, at root level for all packages
<h4>adanska: Yeah the dependencies dimension and versioning one are really complicated to figure out
<h4>I guess I'll postpone garbage collecting even further in the future. The time to figure out a method
<adanska>hmm seems difficult im not sure how you would get the output youre wanting
<adanska>sorting the top level of the store by file size might work?
<adanska>just to see whats taking up the most space
<adanska>but that will include dependencies
<Rutherther>have you considered running guix size on your system / home derivations?
<h4>Just to see what is taking space yeah, but that won't makes sense in practice, because it'll be a wasteland of thousands of micro packages that takes no space. It only makes sense when regrouped by dependencies and version, to make big groups
<h4>Rutherther: Idk how to do that
<Rutherther>your current system resides at /run/current-system, so just get what it points to and run guix size on it. Or just build your system and run it on the result of that, but if you haven't changed anything that's going to be the same as /run/current-system
<h4>I rely heavily on `guix shell` so what is defined for my user isn't what the system really takes
<h4>Evaluating current-system only returns third of what takes /gnu/store
<Rutherther>of course, since gnu store has older system, and other stuff that is subject to gc collection, like what you obtained with guix shell
<h4>I want a total evaluation
<Rutherther>impossible, unless you have gc-keep-derivations, since it's not possible to tell what came from where in the store, and even with gc-keep-derivations you would have to somehow group it with other script. I don't understand why you would want this in the first place though, just keep stuff you need under gc roots and check those, as for the rest you can always gc it
<Rutherther>if you don't keep gc roots, you cannot even know if the paths there are still "relevant" for you, since if you did guix pull and do guix shell, it might use newer version than you already have in store, making the older version unnecessary
<h4>Rutherther: I don't know. I don't understand that system fully. All I know is that I have limited bandwidth so I avoid deleting old generations because when I upgrade I have to download everything a new time, and when I'm offline I rather switch to old versions to use local the re-fetch all the time
<h4>Like if you have 20 GB worth of packages, each upgrade you have to redownload those 20 GB
<h4>Is there a way to invoke old packages on the new system version?
<h4>For example I had a 2023 iteration of the system with FireFox 1
<h4>Did an upgrade and now iteration 2 is 2024 and have FireFox 2
<h4>But I don't have bandwidth right now to get FireFox 2 so I'd rather user FireFox 1 for now
<h4>What I've guessed is that I could use `guix shell firefox@1`, problem being that it tries to re-fetch everying even in that case and I don't understand at all why
<Rutherther>yes, one way is that you can just gc root the shell or any other built package, and use it out of the gc root directly. If you do not want to do that, another possibility is to keep multiple channels definitions with specific commits, you can use "guix describe -f channels" to get current definition, and save it for later, and use guix time-machine
<h4>I have locally everything needed to run FireFox 1, the proof being is that if I rollback I can use it, but no, on new system it re-fetch everything even for the same version
<Rutherther>that guess is not correct, firefox@1 means to get firefox package from current channels, of version 1. If you do guix pull and any of the dependencies that firefox@1 has are updated, the firefox@1 you had a week ago and the firefox@1 you have now are different
<nckx>Just because the name and version look the same does not mean that one firefox@1 is the other firefox@1.
<Rutherther>the easiest way to utilize gc roots is to just use guix profiles, ie. guix home, system, or guix install. Alternatively you make them yourself with --root upon build or shell
<h4>I freeze commits when I want to re push a new SCM without updating anything. But sometimes I do want new commits, new package, an upgrade. But I hadn't time to download everyhing I would ever need, so I go offline and need a package that I have only old version, and here `guix shell firefox@1` gives nothing
<h4>No, the firefox@1 I had a week ago is bit wise identical to the one I would want 50 years later. Same deps version need, same code, same thing. It's not an upgrade. firefox@2 is
<Rutherther>that's false, because you are not taking dependencies into consideration. The dependencies are what can make it non-bitwise identical. And since it's not known if they will do, it's built again
<h4>It's not that the version looks the same, they are the same. It's not a master commit pull, it's version release. One version is identiccal to another. Otherwise developers won't be able to debug anything
<Rutherther>it is not identical, that's wrong assumption
<Rutherther>if developers want to have the same version they have to stay on the same commits of guix and other channels to obtain the same version. Otherwise they are a different version since the dependencies are different
<h4>i don't understand at all that gc root thing. I guess that gc stands for garbage collection but I don't know else. I don't use `guix install` but rather defines in my SCM new packages. I don't like classical package manager way of managing things. I love guix shell temporary workflow and then the SCM for a definition of what your system permanently is
<h4>So I use `guix system reconfigure` and I want to use in the future Guix Home as it's like Nix Home I've heard. Very useful to define everyting in the system else that Guix base don't define in the SCM
<Rutherther>imagine that I stored output of addition program, like 1 and 1, being 2. Then I changed this addition program to produce 3 when I give it 1 and 1. I need to rebuild my result to know this change has occurred, I cannot just assume that because I still am trying to add 1 and 1, that I will get 2 even though the dependencies changed
<h4>One version needs one precise version of dependencies. And Guix is able to make cohabits multiple version at once, avoiding having to update all the system at once, à la Arch
<Rutherther>yes, it is able to do that, and one of the solutions I suggested does exactly that. But when you do guix pull it doesn't do that, it updates everything, even dependencies of other programs. Guix channel doesn't fix all dependencies of packages, until breakage occurs, where you then replace with working dependencies
<h4>I don't talk about Guix but developments in general. Developers fixate software and dependencies and makes a release out of it. Like firefox@1 use libSomething@1.3.6.3.24.6 and NOT libSomething@1.3.6.3.24.5 or libSomething@1.3.6.3.24.7. That's the point. To make sure there is no breaking compatibility and thats reproducible and debuggable
<nckx>That is not true.
<nckx>That's the assumption that's invalidating your reasoning above.
<h4>But for nightlies that use commits it's maybe something else but I don't use rolling release softwares, only stable ones
<h4>Yeah, you effectively totally have to rebuid everyting if you change anything, a version of software or dependencies or list of dependencies. But a version fixation of a stable software is all about shipping with deignated dependencies version, so firefox@1 needs specific deps
<nckx>(Plus, even that were the case, you'd have to assume that libSomething@1.3.6.3.24.6 is only ever built with bit-identical copies of its own requirements, which is also unlikely.)
<h4>Reproducibility is a whole chapter but without talking about bit wise, you still need to use same deps version, otherwise there would be regression because some funciton changed or added or deleted
<h4>You need the same version the dev made that version with
<h4>Maybe some new version gives non regressive changes but that's unlikely and dangerous, better use the version intended by developpers
<nckx>You're wholly entitled to that opinion, but I don't agree with it nor does the reality.
<Rutherther>that is not how Guix works. And if it worked like that it would be pratically unusable for whole systems, since you would always have to pull a lot of different dependencies of different software
<nckx>It's also not how software development or deployment works.
<nckx>I'm not saying that's good, but it's a fact whether we like it or not.
<nckx>(Also not saying it's bad; the model you're describing has a lot of flaws.)
<h4>Okay then if a software pulls latest version of its dependencies all the time, how you make work such software if the code it calls on dependencies don't exist anymore?
<nckx>I don't know, I've never used such a system.
<h4>And for my problem, how to call the software with old definiton which I have all dependencies locally without rolling back the whole OS?
<Rutherther>you don't make it work, that's impossible. You need to adapt the dependencies at that point
<Rutherther>have you actually read my suggestions? I've already provided multiple ways on how to achieve that
<Rutherther>if the suggestions are unclear, please ask about them specifically so that I don't have to provide detailed meaning of each of them
<h4>Or you need to adapt your software to dependencies, thus making a new version of the software. Orrrr, you pull the software with recommended deps version, so it works, like
<h4>Like I've said I didn't understood the GC part and I already use shell and system reconfigure, plan to use home later and won't use install
<Rutherther>gc roots is stuff that is considered alive by the garbage collector, so it won't touch it. For example your syste generations are gc rooted, or your home profile. If you want to gc root output of a shell or build yourself, use --root flag, and save the gc root somewhere. Then use the software out of that gc root itself, and not by executing guix shell/build until you want to update, and then update the gc root as well
<h4>Speaking of which, is it possible in the config.scm to define a file? It needs guix home? Or it can only with scheme? Or with a guix base function? For example if I want to create /home/user/.bashrc when the system reconfigure
<Rutherther>it is possible. Though you should prefer doing this with guix home that even has a service for user home files. In system you would have to make this service yourself
<h4>It's complicated for me to understand but if I get it right, the system avoids touching things that he defines as used, and he defines as such everything gave in the SCM at upgrading, but nothing else. To make it aware of something else you have to define manually, with the root flag, so it creates a standalone iteration that you can use, because guix shell will search to update without considering you
<h4>fixating version when you invoke it, which is utterly curious and fails the purpose
<h4>But I never cleaned my system and old softwares are tied to old generation anyway so it doens't go anywhere. So I have locally all what is needed. But it seems that I don't have the recipe anymore as which version use which deps version. Only the new recipe that needs version that I don't have
<Rutherther>guix shell uses what channels you give it, so you are using it with wrong purpose in mind. If you don't give it channels it just uses your current guix, being the one you obtained from guix pull. Give it the exact channels you want if you want it to give you the same result, which is also what I already suggested with guix time-machine
<h4>Yeah Guix home is made for that. But if I were to use it would absolutely need that it's written in config.scm aswell. I need my whole system deifntion to hold on one file
<Rutherther>exatly right, the recipe has changed / is missing, and that's why guix shell rebuilds it. By keeping older channels definitions along with commits you keep the recipes, and can use them with guix time-machine. Or alternatively the second solution - you don't keep recipes, but gc roots to the software so that you know what's what, and gc doesn't remove them
<h4>time machine seems to revert the whole system, isn't it? Where I only want the one time shell to be jetlagged, only the concerned software, not hte system. Ithought that fixating version would do the work, it seemed so logical
<Rutherther>no, time machine doesn't revert anything. It's just for a single command
<h4>So I have to maintain basically as much channel definitons than I have made generations, to switch the channel file to switch generation while in the guix shell
<Rutherther>if you want to keep all of them, yes. But I don't know why you would do that
<h4>In fact the recipe is not missing, it's held with older generations, but it seems to be hard bound with it so it wont use it in new generations
<Rutherther>you can of course use guix home out of your system config. Though I don't really understand the need for "single file", since your system is already scattered across many fies in guix channel
<h4>If time machine works temporarly like guix shell I think that's the solution I need. Because it's not realist to maintain an arbitrary database of channels file, and the gc root things seems to too manual, easy to mess up, not streamlined. YOu create manually version of things when you think about and have to delete them and so, its too heavy
<Rutherther>guix time machine and guix shell are two different things. You use guix shell, or any other guix command with time machine, it's not a replacement for shell
<h4>About guix channel I don't really care about loosing channel definition, though I would have liked that it'll be on the same file. But the config SCM should contain configuration and needed software
<h4>okay so something like guix time-machine generation 123 shell firefox (and that would pick naturally firefox@1 because thats what was available back then)
<nckx>Almost, substitute ‘generation 123’ with the Guix commit, but you can get that from ‘guix system list-generations’.
<h4>I would love to centralize in one file home and channels and system, so that would be mySystemConf.scm and I would pick it with me everywhere to reproduce my system easily. Even better than a container that is heavy. Would be kind of DockerFile but for Guix
<Rutherther>have you read documentation of guix time machine? no, you don't give it generations, you give it guix commit or channel file with multiple channels. If you want to use it with system generations, give it channels.scm out of the according generation, ie. /var/guix/profiles/system-xyz-link/channels.scm
<h4>nckx: There is for sure something to do like `guix time machine $(guix system list-generation | grep commit) shell firefox`
<Rutherther>just get it out of the channels.scm I suggested to have as little work as possible. Parsing it out of list-generations it will mean more work
<nckx>(But hey, if you wanna go through the effort of parsing it, the approach you describe *would* work.)
<h4>Or even better think better guix and define generation wise instead of commit wise, or two diffrent flags to choose how we designate
<Rutherther>it's quite funny though, parsing it back out of the thing that already obtained it from the channels.scm :D
<nckx>I've committed worse sins as a wee newcomer, some of which still survive in scripts to this day because why change what works, however poorly… 😛
<h4>Guix works really in a particular way, if you don't find out its philosophy and try to survivre in it, you tinker things that probably does what he already do lol
<h4>But really config.scm should be `(operating-system) [...] (channels) [...] (home)`. That would be ultimate DockerFile/GuixFile
<graywolf>Sigh, bit sad that Libera chat bans connections from VPNs... Is Guix fine with that?
<nckx>Libera doesn't ban connections from VPNs though.
<nckx>It bans IPs with observed abuse, mostly through dronebl (which has a mostly self-service removal, although new abuse will re-set the ban), and requires SASL for known VPN endpoints.
<graywolf>? I had to cycle my VPN few times before being able to connect
<nckx>That seems to bear out what I said, since you wouldn't be able to connect at all if it were a blanket ban.
<graywolf>I see. So in these cases I am expected to spray and pray that my VPN provides has at least one non-block server
<graywolf>I fail to see the point in that, attacker (abuser) can just do the same...
<nckx>Most of this kind of abuse is from automated botnets, and no, they don't. If there were no point, there would be no point, that's true.
<nckx>I'm not really super-qualified to give specific support here but there is definitely no deliberate ‘VPN ban’. Only a proportional response similar to how sites are forced to deal with Tor.
<graywolf>Thanks for explanation :)
<nckx>(TL;DR it sucks and it sucks that it sucks.)
<nckx>graywolf: Are you using SASL?
<graywolf>Yes, afaict
<PuercoPop>When inheriting a package, attributes that depend on a value, like a version don't appear to be recomputed, right?
<PuercoPop>Is there a way to refer to the parent/inheritor package attribute? ej. getting the package-name from the inheritor
<Rutherther>I don't think so. But you could just wrap the whole thing inside of a let, and have a variable like "base" to reference to the parent, and then you can use (package-name base)
<PuercoPop>Rutherther: using package-name seems good enough. Another issue is that I can't override only one attribute of source, is there a way to modify only a single source attribute with transforms? Or are they the wrong tool for the job?
<Rutherther>also if you just inherit the name, you can use this-package
<Rutherther>you can also just inherit the source of the parent package. But keep in mind you also need to change the hash
<PuercoPop>This is what I have right now. https://paste.sr.ht/~puercopop/9a3274b74c6ea088c5f643c9fa844b4a30e0aaa6 iiuc I could replace (package-name rust-rowan-0.15) with (package-name this-package), right?
<nckx>All Guix records support inherit, so you should be able to (inherit (package-source parent)) inside (source ...).
<nckx>So what Rutherther said in the meantime.
<PuercoPop>nckx: so I can do (package (inherit foo) (source (inherit (package-source foo)) (file-name ....)))?
<nckx>That should work.
<PuercoPop>Thanks!
<PuercoPop>Another question, what is the stance of guix for dual licensed packages, when one of those licenses is propiertary? Is it ok to upstream it?
<PuercoPop>Concretly I'm talking about slint, which is Qt's 'successor' in Rust. Which similar to qt, is double-licensed. GPL-3.0 and propietary
<nckx>I'd say that depends on the exact nature of the duality. We simply wouldn't mention the non-free licence. If that's impossible then the package might not truly be free. If the package promotes its non-free licence/version a bit too hard that might also be a problem.
<nckx>If we're allowed to distribute it under the gpl-3, then that's what we do, and we don't need the alternative.
<PuercoPop>nckx: Thanks. I'll see if I can upstream it them.
<nckx>Thank you!
<MisterEsse>Hi. Does Guix System have a global configuration option that avoids installing certain dependencies for all packages? If not, can I configure certain package to not install certain dependency?
<mirai>MisterEsse: dependencies in guix are a bit different compared to Ye Olde distributions
<MisterEsse>mirai: please continue...
<mirai>there's two kinds of "dependencies", propagated-inputs and inputs (there's also the native-inputs but it's not important here)
<mirai>the propagated-inputs are like the regular dependencies you're used to in other distributions (e.g. installing package FOO that has BAR as propagated-input = FOO and BAR will show up in your environment)
<Rutherther>MisterEsse what exactly do you want to get rid of?
<mirai>the simple "inputs" are *only visible* to the package that depends on it, e.g. package BAZ has libxml as an input = BAZ may internally call /gnu/very-long-path/bin/xmlcatalog but xmlcatalog itself doesn't appear under your path (fyi, libxml provides bin/xmlcatalog)
<MisterEsse>Rutherther: for example, I do not want, for example, dbus, in my system. How can I disable installing dbus, even as a dependency of some package, in my Guix?
<mirai>there's no environment polution
<duncan>woah, adding sbcl to global config seems to break GDM login :o
<PuercoPop>Any idea why after succesfully finishing the build phase the package phase (of cargo-build-system) says that store does not specify a version? For context it is a crate internal to the repo and it doesn specify a version using the version.workspace = true invocation.
<PuercoPop>What is weird is that packaging another internal crate, that uses the same idiom succeds.
<PuercoPop>which leads to be believe that it is not a short-comming of the cargo-build-system
<Rutherther>MisterEsse did you put %desktop-services to your services? that includes dbus-root-service-type, if you don't want it, use modify-services on %desktop-services, and remove this service type, also make sure to remove what depends on it like polkit service type, bluetooth service type, etc.
<Rutherther>I do not understand what you mean by disabling installing it as a dependency of some package. If a package depends on it, it's very well possible it won't even compile without it, or may need further adjustments to compile successfully. So you would have to modify those packages one by one to make sure they compile even without dbus. You of course can do that, just define your own package, and (inherit) stuff from the parent one. Then just modify the...
<Rutherther>... inputs
<MisterEsse>okay. My goal was to compare Guix to Gentoo. In Gentoo, you can disable having some dependency on your system with the "-" flag somewhere in the portage config files.
<MisterEsse>Gentoo seems more flexible.
<Rutherther>having a predefined set of changes is more flexible than doing any change?
<MisterEsse>(I still haven't installed Guix) .
<PuercoPop>MisterEsse: If you are wondering, does Guix have a similar concept to use flag, the answer is no. Use flags are not more flexible, they are more convenient
<MisterEsse>Rutherther: is, at least, more easy.
<MisterEsse>That is what I meant.
<PuercoPop>for example guix has multiple emacs packages. ej. emacs and emacs-nox which is emacs compiled w/o X
<MisterEsse>PuercoPop: yes, convenient. Wrong word :-P .
<PuercoPop>MisterEsse: but the rde projects, which builds on top of guix does have a similar concept to use flags
<PuercoPop>I think they are called features
<Rutherther>it's more convenient only as far as you do not want to do something that's not supported. The reason Guix doesn't have those exact features is that no one bothered to implement packages versions without dbus, but it would be possible to just override the whole operating-system, change all packages, and produce operating-system without dbus. It just means work for someone, and no one bothered to do it, like they did in Gentoo (though I am unsure of...
<Rutherther>... the exact implementation)
<MisterEsse>PuercoPop: show me some references to this use flags in Guix's project...
<MisterEsse>My goal, is to only have software installed, that I actually need (for example, ffmpeg installs a bunch of dependencies that I do not use).
<Rutherther>and what do you mean by "installed"?
<MisterEsse>Rutherther: I mean, that with ffmpeg, to only way to set only the dependencies that I want, is to compile ffmpeg manually.
<MisterEsse>And it is hard to make ffmpeg compilation work...
<mirai>MisterEsse: you want to define your own "minimalist" packages?
<mirai>you can
<Rutherther>with Guix if you want to change the dependencies you can inherit the package and change deps, build flags etc. if that's what you mean. But still the dependencies are not "installed", in the sense they would propagate to your environment, only ffmpeg sees them
<mirai>You'll have to _inherit_ a package like Rutherther is saying, I've got some myself https://paste.debian.net/1327522/
<mirai>it's not the simplest example but should give you some tips
<Rutherther>for modifying inputs you can use procedure modify-inputs, and for modifying arguments you can use subtitute-keyword-arguments, see ffmpeg definition here https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/video.scm#n1670, you can remove inputs you want, and #:configure-flags you want
<MisterEsse>thank you for the links. I am find it hard to learn new things. Seems that I have to learn even more stuff...
<MisterEsse>If only every software was in a LISP...
<PuercoPop>MisterEsse: Here you can see tropin explaining features. You'll see they match use flags. https://www.youtube.com/watch?v=7t301joOHlE&t=290s
<MisterEsse>(I know Guix uses Guile Scheme, but Scheme is yet another thing for me to learn. And some Common LISP people says that Scheme lacks some language capabilities that other LISP have, such as been treating every data as code).
<MisterEsse>PuercoPop: I cannot see videos in my non-graphical environment. Can you give me some reference containing only text?
<MisterEsse>I mean, treating every code as data.
<MisterEsse>Homoiconicity.
<pranav>MisterEsse: Scheme does not lack homoiconicity.
<MisterEsse>pranav: was probably desinformation, then.
<pranav>Could be, but could be miscommunication too.
<MisterEsse>pranav: at the time, the content of the speech sounded more like, divide and hate. That is why I think it was desinformation.
<MisterEsse>The question remain in my mind during this time... I did not accept it blindly, of course.
<MisterEsse>Seemed odd.
<MisterEsse>It could me a lack of understanding on my part. But it looked like hate-speech towards Scheme.
<MisterEsse>I think it was ams@gnu.org . He seems like very knowleadegle, but he hates Schemers and teases them a lot.
<MisterEsse>I mean, he hates Scheme.
<MisterEsse>Teases Schemers a lot.
<duncan>I think it is probably better not to speculate about this, on a public IRC channel
<MisterEsse>duncan: you are right. Sorry.
<MisterEsse>Does Guix packages use systemd dependencies (such as libsystemd, or elogind)?
<MisterEsse>I would like to have Guix without running into anything about systemd...
<Rutherther>elogind is used
<mirai>some of them use elogind
<MisterEsse>Damn...
<MisterEsse>Is there a way to disable elogind dependency? (For example, using the "features" that PuercoPop talked earlier).
<MisterEsse>Using this "features" would be the best scenario for me.
<mirai>usually elogind is used to make the software work
<mirai>otherwise it won't build since it's a hard dependency
<mirai>I guess if you only use software that doesn't depend on elogind at all ?
<mirai>it's generally not added as an input unless necessary
<MisterEsse>mirai: that is a myth. I have removed elogind from my working system.
<Rutherther>I have not seen any of those features in rde modifying already existng packages. Though I might have just missed something. I don't think they do that. They seem to just provide a way to configure your operating system and home services
<MisterEsse>some packages did depend on elogind. I have to compile and install them manually, without elogind.
<MisterEsse>Rutherther: thanks.
<mirai>you can define your elogindless packages with the inherit+modify-inputs technique discussed above
<MisterEsse>mirai: thanks.
<MisterEsse>Is all the Guix software 100% free?
<MisterEsse>I mean, Guix packages.
<mirai>yes
<Rutherther>Guix channel has strict policy on free software, you cannot add non-free software to Guix channel
<MisterEsse>that is great.
<MisterEsse>So, no Linux?
<mirai>linux-libre
<MisterEsse>yes! :-) .
<MisterEsse>I did know that (about linux-libre). I was asking if there was no linux. (A "yes" means to this question means that there is no linux in Guix).
<Rutherther>exacty, no Linux
<Rutherther>only linux-libre or hurd, though from what I understand hurd is not ready at all
<MisterEsse>Rutherther: thanks for your answer. Indeed, 100% free software. That is the way :-) .
<MisterEsse>Hurd seems to be taking so much time... It is disappointing.
<MisterEsse>Thank you for the chat. Have a good one, to everyone.
<mekeor>running "mktexfmt pdftex.fmt" results in an error stating "Can't locate TeXLive/TLUtils.pm in @INC" for me with texlive and texlive-bin installed. i also tried installing texlive-scripts.
<nckx>nikolar, ieure: AIUI, gnu.org is under something of a DoS attack lately.
<nckx>I think it makes sense to host the CSS ourselves.
<nikolar>nckx: what did i say so you tagged me
<nikolar>ah right
<mekeor>"guix shell --pure sed coreutils texlive texlive-bin texlive-scripts -- mktexmf pdftex.fmt" succeeds though.
<mekeor>hm, my user profile seems to be missing the GUIX_TEXMF=/gnu/store/...-profile/share/texmf-dist environment variable.
<nckx>Is Artyom Poptsov in this here chat?