<graywolf>Hi :) How exactly is one supposed to call vgcreate on the installation media? It does not seem to be in the path. My current "solution" is "/gnu/store/*-lvm2-s*/sbin/vgcreate", which let's be honest, does not seem like the optimal way.
<graywolf>Can I somehow call it using the guix tool? Or just add it to the path?
<KarlJoad>graywolf: You can just guix install the package to the installation media. Anything you install there is only kept in RAM, and is cleared out upon rebooting and will not be present on the installed system.
<KarlJoad>That should add the relevant directories into a location $PATH will find them easily.
<graywolf>I've tried the guix install, (it seems to actually download something, not sure why since that package is already present locally in /gnu/store), but it was still not in path. So I assume I'm missing something.
<oat>Why Guix decided to not included wpa_supplicant and iwd on the %base-package variable?
<KarlJoad>graywolf: If it is already present, then I cannot say why it is not already found through $PATH.
<apteryx>systemctl disable tmp.mount prevented that for the future, on that systemd machine
<Humanoid>When building a custom kernel, manually, where can I get a list of options needed for guix to run well?
<Humanoid>I found out from a bug report that CONFIG_DEVPTS_MULTIPLE_INSTANCES is needed. I wonder what else I am missing.
<KarlJoad>I am trying to run a "guix pull" and I keep running into the same issue on MY channel. "(exception keyword-argument-error (value #f) (value "Invalid keyword") (value ()) (value ("6.0.12")))". This happens with commits that previously used to work.
<KarlJoad>I am also trying with commits that I made several months ago, and the problem is still happening.
<KarlJoad>Humanoid: I use the kernel-config that Guix uses by default and add my own options. It is hidden away in (gnu packages linux).
<guixer>Humanoid did you check how the guix kernel is built with this command: guix edit linux-libre
<Humanoid>Ok, I see a lot of options in linux.scm. This is very helpful!
<Humanoid>Is there a way to print out that resulting config file that is built in linux.scm?
<Humanoid>KarlJoad, How do you get the .config out of it to then add your own options?
<KarlJoad>Humanoid: If you need to see some code about how to get the default configs in there and add your own, I can DM you. The config I use for that is not very FSF-friendly.
<apteryx>Humanoid: also, you can get the .config of the kernel in the guix repo
<oriansj>graywolf: the most fault tolerant method is as follows: make a 1GB partition; mount it on /mnt, herd start cow-store /mnt/ ; then guix install your desired package; You can clean up the partitions after
<florhizome[m]><kaelyn> "Friendly reminder of a core-..." <- Oh i noticed some problems
<jas>hi. i just tried 1.4rc2 on my laptop and everything installed fine (kudos!), however guix system reconfigure complains about a commit is not a descendant of a hash, should I use --allow-downgrades, or what's the recommended solution?
<rekado>jas: before 1.4.0 is merged into the “master” branch none of the commits on “master” will appear to be descendants of 1.4.0.
<rekado>this is the downgrade protection kicking in.
<jas>ok. i tried 'guix pull --branch=version-1.4.0' but still get the same error
<cbaines>the WAL file is temporary, but only if it's empty. Otherwise it contains data that hasn't yet been written to the main database file
<rekado>civodul: the wal file should be removed automatically when all handles are closed
<rekado>the shm file contains only an index; it would be recreated when lost
<M0rc0[m]><AwesomeAdam54321> "0rc0: Of course" <- Ok. Here goes, pls excuse my poor english.
<M0rc0[m]>After some research I am near to conclude that the only way to be totally sure of that your system is not being "monitored" is to use OS's like GUIX with no non-free software, is this assumption false or correct?
<AwesomeAdam54321>The assumption you stated is correct, although using the current Internet stack may make it easier to monitor you
<rekado>Guix (as a project) does not use Google or Amazon services or infrastructure, nor does Guix System on your machine call out to any of their services.
<rekado>there is no way around the firmware problem; there is a lot of hardware out there, some with the ability to have the kernel upload firmware, some with read-only firmware. In most cases there does not exist any free firmware.
<M0rc0[m]>Glad to hear that! rekado AwesomeAdam54321 Thx 🪖✊
<rekado>with regards to packages it should not matter where they have been built; “guix challenge” lets you compare the results of building a package on different servers to see if there are differences you should worry about.
<rekado>you can use this tool to spot check the servers that provide package binaries
<M0rc0[m]>* interesting! thx! Any other "hidden gems" you want to inform me about? ;)
<M0rc0[m]>* interesting! thx! Any other "hidden gems" you want to inform me about? ;) - and if you don't mind: *with regards to packages it should not matter where they have been built* : : You mind elaborating on why it should not matter?
<AwesomeAdam54321>M0rc0[m]: It shouldn't matter because the packages should be reproducible. The recipes specify the exact inputs, instructions and build environment so the output should be the same and if not `guix challenge` will expose the differences
<M0rc0[m]>* makes sense. @rekado Where would using GPL2 over GPL3 fit into all of this, if et al?/assuming it doesn't since: GNU is licensed under the GNU Project's own General Public License
<M0rc0[m]>* makes sense. @rekado Where would using GPL2 over GPL3 fit into all of this, if et al?/assuming it doesn't since: GNU is licensed under the GNU Project's own General Public License - Does this make GNU/(GUIX licensed under GPL "1" ?
<mirai>sepi: as a program-file or within a activation-service definition it will create it "in the outside fs"
<M0rc0[m]>* makes sense. rekado Where would using GPL2 over GPL3 fit into all of this, if et al?/assuming it doesn't since: GNU is licensed under the GNU Project's own General Public License - Does this make GNU/(GUIX licensed under GPL "1" ?
<rekado>the source code of Guix is licensed under GPL version 3 or later.
<rekado>individual software packages provided by Guix have their own licenses
<M0rc0[m]>Ok thanks. Do you have any opinion as to why Linus Torvald "slightly disliked" moving to GPL3? If I understood him correctly he meant that GPL2 was already OK and did what it was meant to do. But I can't help but hearing a slight hint in his argument to actually allowing more non-free elements into distros.
<M0rc0[m]>* into distros. Goin OT coz im guessing there is plenty of debates re.: gpl2 vs gpl3. (?)
<M0rc0[m]>* into distros. Going OT coz im guessing there is plenty of debates re.: gpl2 vs gpl3. So i just pose this as my final Q. (?)
<rekado>I can’t speak for Linus, but the GPL is a legal hack. In order to accomplish its goals of protecting the user’s four freedoms from abuse it needs to use a lot of complicated language.
<rekado>some people dislike this complexity; some disagree on what the license considers worthy of protection; some disagree on how the license goes about defining the tools to provide this protection.
<mirai>M0rc0[m]: the reason why LT "disagreed" with GPLv3 is no mystery
<mirai>GPLv3 adds the "tivoization clause" but LT didn't think TiVo was doing anything wrong in restricting (or designing) what their hardware can load
<mirai>***/didn't think/was of the opinion that TiVo wasn't doing anything wrong
<M0rc0[m]>mirai: I know. And I sense this some sort of political quagmire. I consider Stallman and Torvald to be principled men. And it is no mystery more than I make it, sort of. Consider me "paranoid" approaching these subjects.
<M0rc0[m]>***/blocks users from running modified software on its hardware by design
<oriansj>well practical vs absolutist perspectives honestly.
<oriansj>which you see even on topics such as bootstrapping; where even the 256byte bootstrap seeds which were hand made are forbidden from savannah
<oriansj>and ended up being hosted on github for a few years because of it
<M0rc0[m]>oriansj: True. So it all ends in a philosophical choice imo, and this is where Stallman is steadfast I suppose.
<oriansj>so both can be right on their own basis but there is no absolute always correct answer
<M0rc0[m]>* I suppose. As for Torvald I can say the same, but i will say contradictory that valid arguments are coming from both "sides".
<oriansj>nckx: well yes, one of the root copies are still on github (the main I update is on sourcehut) but ideally everyone would be free to choose their own root binaries.
<oriansj>and the short version is no binaries would be accepted
<oriansj>also my proposal to make the bootstrap-seeds a gnu project was also ignored, so eh
<sepi>Sorry to bother you again but I still can't figure out how to configure my wordpress service. I'm using the activation-service extension to write a config file into the store using plain-file. The file would later be referenced from the wordpress package from an environment variable. Is this a valid approach? I'd prefer to not have the config outside the store since I would like to run many wordpress service
<sepi>instances. When I try to reconfigure my system using my current approach I get an error telling me that my wp-config.php is an unbound variable. I only refer to this as a string in the call to plain-file.
<sepi>rekado: you were talking earlier about setting environment variables to pass a config file path to a service at runtime. How would I go about doing this? Also is there a way to verify if I was successful with setting that variable? Unfortunately I can't seem to find anything on this topic in the docs
<sepi>I also just noticed that passing stuff via environment to a PHP application is probably not so simple. The vars would need to be defined in php-fpm's environment
<rekado>sepi: what I had in mind was patching the PHP application’s source code to refer to a config file via environment variable.
<reza[m]><rekado> "depends on the contents of..." <- but is `gnu-build-system` not a variable from the `guix` module?
<rekado>reza[m]: it’s defined in (guix build-system gnu)
<sepi>rekado: I see what you mean. But how would you make sure that the php interpreter gets the variable set in its environment?
<reza[m]>rekado: It was a missing module, sorry for the noise
<mekeor[m]>has it ever been discussed to write a guile/scheme function which can be used in a manifest.scm in order to import all emacs-* packages used in a init.el file, given by path? like (append (get-packages-from-emacs-init "~/.emacs.d/init.el") (specification->manifest (list "foo")))
<rekado>sepi: good question. I don’t know. That’s probably because I don’t know anything about PHP.
<rekado>I forgot that you have php-fpm running independently of the application itself.
<nij->Hello :) I understand that guix can handle multiple different versions of libraries in the file system, and let the user easily create the environment they like.
<sepi>rekado: hehe, don't worry. I'm now trying to pass env vars to php-fpm by modifying the php-fpm shepherd service to have #:environment-variables set in make-forkexec-constructor. Somehow the environemnt doesnt seem to be applied. I checked reading /proc/$PID/environ
<nij->However, when dealing with a specific runtime (e.g. python), there's still a problem that multiple versions of the 'same' module cannot be loaded coherently.
<nij->My question is, how do guix people deal with diamond conflicts?
<nckx>Interesting. So the same Python process/environment might get a different version of package P loaded into it at run time, computed based on whether that environment also has packages A (works with P1, P2) & B (works with P1, P3) or A & C (works with P2, P3) in it? Or is it not that bad?
<nij->Not python, but tools around it (e.g. conda or virtualenv).
<nij->But what I really hope to achieve, is a lang whose runtime can afford coherently loading mixed versions of package.
<nckx>There's no way to emulate that functionally (with Guix) since there's no concept of computed requirements. You'd need explicit A-with-P1 and A-with-P2, and use each where needed.
<nckx>Yeah, that's the real fix, but it's beyond the scope of a package manager, even a broadly-scoped one like Guix.
<nij->Could you tell me a more concrete example of "passing incompatible data structures around"?
<nckx>I didn't have a real example in mind. Just libraries A & B (re)using some struct from C in their own structs, but being linked (packaged) against different versions of C with incompatible struct layouts.
<nij->Hmm.. I don't see why that would lead to conflict.
<nij->If A expects the data struct C:v1 uses, and if B expects the data struct B:v2, then just let them do what they are supposed to do.. what would happen?
<nij->The point, I think, is to be able to load C:v1 and C:v2 orthogonally into the scheme image, and to be referred independently.
<nckx>As long as you don't pass C:v2 to A or C:v1 to B.
<nckx>And I think that becomes likely in any sufficiently complex practice.
<lechner>It is easy to be misunderstood sometimes. Someone shy could read a mocking tone into it. Maybe it's time to make some fun of ourselves again
<lechner>Hi, is there an embedded OS like OpenWRT that is purely declarative? I tend to keep spare devices on hand, but shudder at the thought to program my firewall rules again. OpenWRT does offer a way to save settings but I do not use it often enough. I'd love to have 'guix deploy' for that use case
<yarl>It is a problem with the checks. They use the cross-compiled info and another program (pseudotty). Well then the tests can't run on the host machine, during the build. An idea would be that texinfo have texinfo (not exactly the same) as native-input.
<yarl>Of course this texinfo-input is not cross build. And it have to install pseudotty (that is not a bin_PROGRAM, in automake) in its store directory.
<VesselWave>Hello, I am trying to package hyprland. Hyprland modifies wlroot's files. I trying to make it safely with inherited "wlroots-hyprland". Can guix package definition download two repositories?
<pkill9>yeh VesselWave , you can add the extra repositpry as an origin directly from inaide the build procedure using a gexp, or you can add it as an input and call that
<VesselWave>There are XML files in wlroot source directory protocol/, and I convert it to H file in include/wlr/types/. But some XMLs are in hyprland directory protocols/. To make it clear
<jpoiret>yarl: usually when you ungexp something, it is built for the gexp's target, but with this it is built for the host's
<lechner>yarl / sorry we had a little bit of fun at your expense earlier. you are doing some very advanced work
<yarl>jpoiret: I don't get it. lechner: I don't feel advanced :/, and I did not mind.
<kori>am I right in my understanding that `guix system reconfigure` expects a file that returns a single operating system declaration?
<kori>because I want to declare all my configs in one file, so that I can use that for guix deploy, but I want to know if I could have a file that just pulls the file with all the operating systems declared and just contains %my-os
<yarl>jpoiret: What do you mean by "for the gexp's target/host"?
<yarl>Also, (probably a dumb question but) I don't get the difference between using assoc-ref and search-input-file. Is search-input-file just when you don't know what input it is (this statement seems odd)?
<nckx>It's so you don't _have_ to know. (assoc-ref inputs "emacs") breaks when your replace "emacs" with "emacs-next". (search-input-file inputs "bin/emacs") won't.
<nckx>yarl: ungexp-native is to ungexp as native-inputs is to inputs. No difference when you're not cross-compiling. When you are, say building aarch64 software on x86_64, #$foo will be aarch64 and #+foo will be x86_64.
<nckx>In that example, aarch64 is the target. x86_64 is the host.
<nckx>Other tools may use different terminology, but this is Guix's.
<kori>lechner: thanks, i want to do something similar
<kori>I don't want to just naïvely (load), but i'll do something similar
<yarl>nckx: Hmm. This is not crystal clear but that's probably my amateurism with gexp. I think I kind of get it. Thank you.
<yarl>What I am trying to achieve is probably stupid after all. Crossbuilding a package fails at make check because the host can't run it, indeed. Adding the package to itself as native input only tests it natively, not "targetly", the tests have lost some of their value. That is certainly a problem for most cross-compiled packages. Moreover, I am trying to substitute* the program in the tests while it has already been te
<yarl>sted as input. What is the best choice here? 1/Completely disable the tests. 2/add the package as native input, the tests are run there and disable the "target" tests. You still get "some" of the tests value. What do you think?
<lechner>kori / please let me know what you come up with
<oriansj>does anyone here have a *working* thermald config
<yarl>Well. I should pull more frequently. Ludo disabled the tests when cross building texinfo 1 week ago :'D
<KarlJoad>When pulling my personal channel from a local checkout (and using --allow-downgrades), I am getting an error. "(exception keyword-argument-error (value #f) (value "Invalid keyword") (value ()) (value ("6.0.12")))" Has anyone seen this one before?
<KarlJoad>The same error happens regardless of which commit I use. Even if it is the same one as is currently being used.
<rekado>6.0.12 looks like a linux kernel version number
<rekado>KarlJoad: do you get this even without your extra channels?