IRC channel logs


back to list of logs

<cbaines>civodul, I've pushed a core-updates fix now. I think the cryptic error was due to a #f in allowed-references/disallowed-references in the gnome-photos package arguments
<civodul>cbaines: awesome, thanks!
<civodul>ACTION -> zZz
<wolfdog>managed to get the disk image for RPi 4 built, thanks juli for the qemu-binfmt pointer :-)
<trannus_aran>hey, so does anyone have any tips for running guix on fedora silverblue/atomic?
<trannus_aran>I can run it on regular fedora if I just remember to turn selinux off before I run guix commands (which is irritating, but so be it I guess)
<trannus_aran>but on silverblue, even running in a toolbox/container environment, I have to have a separate terminal tab set to run guix daemon as root before I can run any guix commands on a user account in said sandbox
<wolfdog>quick question, if I'm deploying to a machine and the OS configuration I'm using references an external channel, do I need to setup the Guix in the target machine to also use those channels?
<freakingpenguin>wolfdog: I don't think so, as long as the machine doing the deployment has those channels you should be good.
<wolfdog>cool, thanks
<wolfdog>tried to use `guix-for-channels` on my configuration to pin my channels and it ended up "computing Guix derivation" like 5 times across the system reconfiguration :S
<wolfdog>is this normal?
<adanska>Hi Guix!
<lykso>Since I asked for help earlier with getting a gexp into my kernel config, I figured I should report back with what I did. I ended up defining an origin using url-fetch and a "file://" URI to my base kernel config, then I used "sed" in the "snippet" gexp to append a line to the kernel config setting CONFIG_EXTRA_FIRMWARE_DIR to my custom firmware's store path. Then I just passed that origin in as the
<lykso>#:defconfig argument to customize-linux.
<attila_lendvai>is there any conclusion about the graphviz "Error: Could not set character size" when building a guix checkout locally? it's blocking me again.
<attila_lendvai>what's worse, is that it's in a part that is not relevant to me. all i care about is the scheme code, not the manual.
<roundduckkira>adanska: I tried to do what you said to do and it failed the first is the file and second is output
<sneek>roundduckkira, you have 1 message!
<sneek>roundduckkira, adanska says: you can use the `modify-services` procedure like this: `(modify-services %desktop-services (delete gdm-service-type))` in the `services` field of your `operating-system` record. then, youd add the session manager of your choosing to your list of services.
<roundduckkira>basically for some reason despite what I do it sees lightdm-service-type as an unknown variable
<roundduckkira>an unbound one
<roundduckkira>sneek: later tell adanska: I tried to do what you said to do and it failed the first is the file and second is output
<sneek>Got it.
<roundduckkira>I realized sneek is a thing, noice
<adanska>roundduckkira: you need to import the `lightdm` module
<sneek>Welcome back adanska, you have 1 message!
<sneek>adanska, roundduckkira says: I tried to do what you said to do and it failed the first is the file and second is output
<roundduckkira>that's a module?
<roundduckkira>didn't know heh, thanks
<efraim>try something like this:
<peanuts>"~efraim/guix-config (master): 3900XT.scm - sourcehut git"
<adanska>you can check what module a service is in by running `guix system search foo`, and you can then see its location
<roundduckkira>yeh now I get the xorg-server provided more than once, I'll look over that file
<roundduckkira>hmm confused about such
<roundduckkira>like I thought I already rid of gdm with the modify services thing
<roundduckkira>adanska: basically after fixing that issue, it goes "xorg-server provided more than once" but I got the modify-services line
<adanska>roundduckkira: try moving your `(set-xorg-configuration...)` to the lightdm config like this `(service lightdm-service-type (lightdm-configuration (xorg-configuration (keyboard-layout keyboard-layout))))`?
<roundduckkira>oh oki
<roundduckkira>adanska: Wrong type to apply: #<<keyboard-layout> name: "us" variant: #f model: #f options: ()>
<roundduckkira>at least a bit closer but it sees it as a wrong type?
<roundduckkira>this worked before tho independently
<FlaminWalrus>Is =guix-home-service-type= supposed to install user packages? That's what the documentation seems to suggest, but it's just run the services for me.
<adanska>roundduckkira: go back to how it was before with set-xorg-configuration, but add `lightdm-service-type` to the end of its arguments
<adanska>if you check the documentation for the `set-xorg-configuration` procedure it seems to accept an optional argument to specifiy what session manager to target?
<adanska>also im sorry i cant help anymore, i have to go :( let me know how it goes for you :)
<roundduckkira>adanska: oh I didn't notice that
<roundduckkira>and okay sorry
<roundduckkira>but what you recommended idn't work eithe and gave back the old no multiple x servers error
<PotentialUser-81>Hello. Is the a way to download the latest Guix Linux as the link for it is not working ?
<f1refly>is gradle packaged for guix?
<AwesomeAdam54321>f1refly: Not yet
<f1refly>alright I'll have someone else initialize it for me
<AwesomeAdam54321>Kotlin has been bootstrapped to version 1.0 though:
<peanuts>"Julien Lepiller / guix-android ? GitLab"
<AwesomeAdam54321>Kotlin and Gradle have very tight co-dependencies on each other, so it's a lot of effort to bootstrap it to the newest version
<AwesomeAdam54321>It's easier to change a project's build system to something else like Maven for now
<trev>is there a way to fully disable from my substitute servers? I tried to do it in my system config, but for some reason it still tries to sync from it
<trev>actually, let me try the exact code from the manual, where you modify the guix-service-type
<attila_lendvai>this is driving me mad... how do i turn a shepherd service, namely (repl-service), into a guix service that i can use in my operating-system definition?
<f1refly>I'll just run gradlew manually for now and just specify my dependencies in the manifest file
<wolfdog>using “guix deploy” to deploy to an ARM machine seems to build derivations using emulation, is there any way to force it to do cross-compilation? i’m building a kernel for my raspberry pi and it’s taken almost 10 hours and still going thanks to the build being emulated @_@
<civodul>wolfdog: hi! you can set (build-locally #f) in ‘machine-ssh-configuration’
<civodul>er, (build-locally? #f)
<wolfdog>that’d make it build on the target machine, right?
<wolfdog>if I build the derivation by hand (guix build --target=aarch64-linux-gnu …) I suppose deploy will simply copy it
<wolfdog>[…] to the target?
<wolfdog>(sorry, pressed Return by accident)
<attila_lendvai>to answer myserlf: there's no such thing. must write a guix shepherd service wrapper for it.
<cbaines>attila_lendvai, I'd look at examples in Guix for service definitions. You need to extend shepherd-root-service-type
<attila_lendvai>cbaines, thanks, i'll take a look. this nomenclature is confusing the shit out of me...
<attila_lendvai>cbaines, it still can't work as-is. i need to turn the closures in (repl-service) into gexp's. i don't think there's any oneliner to turn (repl-service) into a guix service.
<wolfdog>hm, even with (build-locally? #f) it builds it locally using QEMU
<cbaines>attila_lendvai, that makes sense, since Guix adds a layer of abstraction over the shepherd configuration
<cbaines>maybe some adapter could be written, but I don't think that would be useful in Guix
<attila_lendvai>ACTION still thinks that using 'service as a name for guix OS components wasn't a good idea
<attila_lendvai>cbaines, i think it's not even possible to write such an adaptor (how to turn the closures into gexp's?), because that code needs to be 'staged'. i.e. compile the gexps into a form that a different guile binary can load into shepherd.
<attila_lendvai>what is a command line alternative of emacs' geiser-connect-local ?
<attila_lendvai>i'm trying to connect to shepeherd's repl socket
<civodul>wolfdog: ‘--target’ is for cross-compilation; ‘guix deploy’ does native compilation
<wolfdog>native compilation is what i’m trying to avoid, since it’s awfully slow haha
<wolfdog>with build-locally? set it stil started building locally with native compilation though, so i don’t know what happened there
<wolfdog>maybe i should disable the qemu-binfmt service for good measure?
<attila_lendvai>...and the shepherd repl is running in a vm. i'd also be happy with a way to connect my emacs into a socket in a vm.
<civodul>wolfdog: hmm not sure why (build-locally? #f) is insufficient then
<attila_lendvai>yay! managed to mess around in shepherd with its repl (socat - UNIX-CONNECT:/var/run/shepherd/repl)
<gerogaga>Has someone had problems with direnv trying to continously load the .envrc? The package didn't update but it suddenly doesn't work and will keep going until my system crashes.
<jakef>is guix gc deleting stuff it shouldn't?
<andreas-e>It behaves a bit weird in the presence of grafts. If you install a grafted package, it may delete the ungrafted one. Then if someone else on the same machine installs the grafted package, guix needs to download the ungrafted one again to determine the hash.
<RoundDuckKira>sneek: later tell adanska: I got the dm changed successfully thanks!!!!
<sneek>Will do.
<wolfdog>on second look, seems like whatever `build-locally?` should be doing is not happening? looking at the code at gnu/machine/ssh.scm, seems like if the host and target architectures differ, and build-locally? is #t, the deployment should fail
<peanuts>"ssh.scm\machine\gnu - guix.git - GNU Guix and GNU Guix System"
<wolfdog>but if I set build-locally? to #t, disable qemu-binfmt and run the deployment, it fails, but after trying to build a derivation for the target architecture
<civodul>wolfdog: weird; do you have a minimal test case you could send to bug-guix?
<wolfdog>I will attempt to make one
<ngz>I'd like to change TeX Live versioning. Currently, those packages use the reference of the TeX Live SVN repository, i.e., currently "66594". While correct, it is not very useful. I'd rather report TeX Live version used, in this case "2023.0". Unfortunately, 2023.0 is a lesser version than 66594 (!), so I think future package updates may be missing out TeX Live packages. How could I work around that?
<wolfdog>hm, trying to install Guix on a foreign distro (Debian) after having uninstalled it a while ago gives me an error with guix pull
<wolfdog>guix pull: error: reading file `/gnu/store/1xh5b299d09nrpgjpwa0wxpz0fs83d7p-guile-gcrypt-0.3.0.drv': No such file or directory
<wolfdog>are all my computers cursed? XP
<ieure>wolfdog, Probably your $HOME/.guix-profile and/or $HOME/.cache/guix are stale.
<wolfdog>I don't have the former, and I deleted $HOME/.cache/{guix,guile} to be certain, but I have the same error
<mrh57>has anyone used R-lang packages installed via Guix? library(libname) doesn't seem to be able to find them
<mrh57>okay it does work with guix shell, so perhaps an issue with my env
<lilyp>don't forget to include r itself always
<mrh57>yep that was done
<ngz>Interesting. I call a memoized function. The first time, its evaluation takes 40s. It also takes 40s the second time.
<ngz>(with the same argument, of course)
<JetpackJackson>im trying to package python-dbglib and the build works, but python cant find it when i use it:
<peanuts>"debian Pastezone"
<Deltafire>is there a command to search for services? thought i saw one somewhere
<Deltafire>ah, guix home search