<apteryx>rekado: I hear you. I'm also often confused about the types and the comments not matching what it's supposed to be, or abusing terms such as derivations (while they are in fact a monadic procedure) don't help :-) <apteryx>I think an easy action would be trying to correct all those comments so that they don't lie about the type the procedure actually returns. <bandali>but comments are unfortunately bound to get outdated <leoprikler>is there a way to tell guix gc, which "packages" to clean? <apteryx>leoprikler: if you know the paths, you could try guix gc -D <apteryx>perhaps, `guix gc -D /gnu/store/*emacs*' <mwette>Can channel urls be something other than http, say file:///path/to/dir ? <mwette>^ that is in ~/.config/guix/channels.scm <vagrantc>it's an exciting day! 2032d8473d11711b88fd3e48644c569dee32fa42 ci: Cross-build for riscv64-linux-gnu. <vagrantc>sneek: tell civodul Thanks for 2032d8473d11711b88fd3e48644c569dee32fa42 ci: Cross-build for riscv64-linux-gnu. Very exciting! <sneek>civodul, vagrantc says: Thanks for 2032d8473d11711b88fd3e48644c569dee32fa42 ci: Cross-build for riscv64-linux-gnu. Very exciting! <vagrantc>sneek: later tell civodul Thanks for 2032d8473d11711b88fd3e48644c569dee32fa42 ci: Cross-build for riscv64-linux-gnu. Very exciting! *vagrantc wonders what the use of "tell" is without "later" ***cualquiercosa is now known as Telior
<Telior>howdy! quick question: how do you add DEs and WMs in guix? It seems you can't just add .desktop files <pkill9>Telior: you add windows managers to the system config packages <leoprikler>Bigger ones through services, smaller ones to packages. <pkill9>and desktop environments as services <Telior>Thanks for your answer! Sorry, I'm still not familiar with how guix works. How do I add packages to system config? Is it with the config.scm file? <Telior>stumpwm, I installed it already c: <Telior>but it doesn't show up on my DM screen <pkill9>Telior: yes you add to the system config <pkill9>then run `guix system reconfigure config.scm` <pkill9>the manual has explanations and examples for configuration <jfred>Thanks to everyone who organized and helped with Guix Days this year, it was a lot of fun! <pkill9>how many people involved with guix are in university? <Telior>ok, think I got it, gonna reconfigure to check, thanks a lot :D <pkill9>apteryx: when are you gonna merge earlyoom? :) <Telior>ok, I don't got it. I get an error: "stumpwm: unbound variable" <pkill9>Telior: you need to import the module containing stumpwm <pkill9>either (use-modules (gnu packages wm)) or (use-packages-modules wm) <atw>*use-package-modules ;) <bandali>pkill9, i for one am (in grad school) but for not much longer for now <Telior>think it worked now, I'll report back in a bit if it does, thanks!! :) *vagrantc starts packaging u-boot-qemu-riscv* and opensbi <vagrantc>i didn't realize the cross-toolchains were working yet for riscv64 ... guess they have been for a while? <alextee[m]>ie, if a dependency is not found it has a fallback mechanism for pulling from a git repo or from somewhere else <alextee[m]>Drakonis_: which mailing list? i know there's a meson build system but i didnt know it supported wraps <alextee[m]>yeah i don't see anything there, and the manual doesn't mention it <Drakonis_>it doesnt seem to explicitly invoke meson, only configure the environment for its usage <Drakonis_>so it might be able to support wraps? have you tried? <alextee[m]>yeah it fails because it needs to connect to the internet <alextee[m]>supporting wraps would mean guix would pre-download the stuff <Drakonis_>so the meson build system would need a couple changes to allow for wraps to work <alextee[m]>yeah. i don't really see a problem with it since you can specify hashes or specific commits in wraps, but meson allows you to specify more ambiguous things like git tags, so i guess guix would have to check and decide <Drakonis_>but it would be best to package the required dependencies <alextee[m]>there's a use case where there's packages using different commit versions of a library so that would mean you'd have to make separate packages at each commit <vagrantc>yay! the beginnings of riscv64 on guix :) <vagrantc>can at least get to a bootloader prompt from qemu now <oriansj>the M2-Planet port to RISC-V however will take a good bit longer (it is a horriable to bootstrap target) <apteryx>vagrantc: nice! you have a development board at hand? <apteryx>I had to ask about grammar in #english to make sure about some detail for the doc, but it's ready now. <vagrantc>apteryx: i don't have a development board, but guix already has some qemu targets that work with riscv64 <vagrantc>apteryx: including a target that somewhat emulates the development board. <jackhill>oriansj: what makes riscv a horrable bootstrap target <vagrantc>wild guess would be it only has support in very recent toolchains <vagrantc>which tend to have more dependencies to bootstrap... <jackhill>I was thinking that the instruction set had a difficult property or something <vagrantc>it may have some surprises there, too :) <sneek>Welcome back lispmacs, you have 2 messages. <sneek>lispmacs, lispmacs says: you're a great programmer <sneek>lispmacs, lispmacs says: is this THE lispmacs!?! <Telior>hey there, I'm back with stumpwm-related problems <Telior>now when I try to reconfigure I get this message: guix system: error: build of `/gnu/store/biw32bphadrfbr6rsjfm6jbw6n8pqifq-cups-pk-helper-0.2.6.drv' failed <shtwzrd>I need webkitgtk on aarch64 but the build is failing. Really I'd rather just use a substitute, and it looks like berlin.guixsd.org has it. But guix always tries to build it instead. How can I find out why that is? <shtwzrd>alternatively, is there a way to query to figure out why guix wants to build a particular thing given a configuration? Like, when I --dry-run my system.scm, I can see it's trying to build gnome-shell which is probably why webkitgtk is pulled in as a dep but I don't understand why it wants gnome-shell (my config is using xfce). I know about `guix graph` but that only deals with packages, right? <shtwzrd>vagrantc: ahh, and I reference %desktop-services so that's probably it. Thanks :) <vagrantc>i switched to sddm before, but eventually just started using "sway" without any display manager :) *vagrantc found gdm to be the source of many bugs and frustrations and a large dependency graph <shtwzrd>yeah I seem to recall desktop-services using sddm, or maybe it was just the config I based my system on, back when I tried guix the first time <shtwzrd>gnome-shell is a huge dependency for a display manager. <vagrantc>before gdm worked, i think the default was slim <shtwzrd>I've removed %desktop-services and replaced it with an explicit list of services, starting with what is in the original %desktop-services. Seems like there's more gnome-shell deps in here than just gdm and accountsservice though. Is there something smart I can do to look up the dependencies of these services? <shtwzrd>tbh I know i don't need most of these services to begin with, but my goal right now is to just try to build a reasonable default config for the Pinebook Pro and I want to try to leave the default Guix System as 'in-tact' as I can without having a result that takes weeks to compile on that device :D <shtwzrd>vagrantc: and you're actually the guy that wrote the bootloader package for the rk3399 aren't you? So thanks for that :) <pkill9>apteryx: would it be worth adding to %desktop-services by default? <vagrantc>shtwzrd: pinebook pro needs a bit more work, most likely <vagrantc>shtwzrd: it's very similar, but... the details matter :) <vagrantc>also needs the device-tree to land in mainline linux eventually <shtwzrd>vagrantc: ahh, was not aware I'd need a patched u-boot: thanks for that. I'll include that in my system def. For kernel I've made a package def using the patched mainline manjaro offers <vagrantc>what version is it based on? ... would be nice to get it working soon ... several guix folk have them <shtwzrd>the manjaro pbp kernel? They're on 5.5 <vagrantc>hope those patches are moving upstream :) <vagrantc>ugh, it's a code-copy branch, rather than just making a branch off of upstream :( <shtwzrd>yeah they're trying to get them upstreamed afaik. Hope it happens soon :) <shtwzrd>even then though, it's going to need some nonfree firmware for the wifi so we'll still need mainline kernel. Is there even a build server that provides substitutes for mainline? If not the functional difference between it being mainlined or being custom compiled from this branch is basically nothing ***nly` is now known as nly
<vagrantc>shtwzrd: you can use USB wifi instead with free firmware <shtwzrd>vagrantc: true, that's an option. the wifi chip pbp is using is also its bluetooth chip. Is there a combination wifi bluetooth dongle out there with free firmware? <shtwzrd>'cause two dongles would be all my ports, lol. Not practical for me. Then again, I think there's an extra usb line on the soc that's unused, could maybe try to hook to that. Or cannibalize the webcam's connection. <oriansj>also wasn't there a wifi card which had the same chip as the Free software usb wifi? <oriansj>but then again not all laptops might support that card standard <shtwzrd>oriansj: ahh, pbp does have an extra nvme slot, so maybe it could use that card <raingloom>how come only a few packages have debug outputs? <raingloom>context: i'm trying to debug Evolution and realized i'm gonna need to add debug symbols myself <oriansj>raingloom: probably because their creators don't want people running their programs to see lots of noise in their terminals. <oriansj>raingloom: one must remember most developers don't know about things they can do better until they hear it repeatedly <raingloom>i guess, but it's right there in the packaging guide. it's pretty hard to miss. ***link2xt[nm] is now known as link2xt