IRC channel logs


back to list of logs

<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?
<leoprikler>e.g. remove all old versions of emacs?
<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>OK, added, but "guix pull --list-generations" does not show anything. What am I missing?
<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!
<sneek>Got it.
<vagrantc>sneek: botsnack
*vagrantc wonders what the use of "tell" is without "later"
<vagrantc>i guess if you're remote-controlling it
***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?
<Blackbeard[m]>Telior: what WM do you want?
<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
<Drakonis_>cool beans.
<Drakonis_>fosdem soon
<vagrantc>i didn't realize the cross-toolchains were working yet for riscv64 ... guess they have been for a while?
<alextee[m]>can guix handle meson wraps?
<alextee[m]>ie, if a dependency is not found it has a fallback mechanism for pulling from a git repo or from somewhere else
<Drakonis_>check the mailing list
<Drakonis_>there's a meson build system
<alextee[m]>Drakonis_: which mailing list? i know there's a meson build system but i didnt know it supported wraps
<Drakonis_>guix's mailing list
<Drakonis_>lelt me check the build system
<Drakonis_>that also works
<Drakonis_>doesnt look like it supports wrapping?
<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]>how to try? lol
<alextee[m]>oh you mean build a project that uses them
<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_>ah i see
<Drakonis_>the builds are sandboxed
<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
<alextee[m]>maybe too much trouble to be worth it
<Drakonis_>never too much trouble.
<Drakonis_>but it would be best to package the required dependencies
<brettgilio>Hello Guix! Sorry I've been away.
<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
<brettgilio>Its been hell at work
<Drakonis_>hell eh?
<apteryx> /join #english
<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>pkill9: about earlyoom: now
<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.
<vagrantc>now guix has the parts that get you as far as a bootloader prompt:
<apteryx>vagrantc: pretty interesting!
<apteryx>pkill9: earlyoom is now in master
<apteryx>(the service as well)
<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>oh, that makes sense, thanks vagrantc
<jackhill>I was thinking that the instruction set had a difficult property or something
<vagrantc>it may have some surprises there, too :)
<vagrantc>but at least they're documented
<jackhill>time for a mesc++ :)
<lispmacs>sneek: help
<lispmacs>hi sneek
<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 has it. But guix always tries to build it instead. How can I find out why that is?
<shtwzrd>For reference, I'm expecting it to pick up the substitute from this build
<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?
<vagrantc>gdm uses gnome-shell
<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>also used slim for a bit ...
*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: thanks
<pkill9>apteryx: would it be worth adding to %desktop-services by default?
<pkill9>seems like it fits
<vagrantc>shtwzrd: which board?
<vagrantc>shtwzrd: pinebook pro needs a bit more work, most likely
<shtwzrd>vagrantc: it's using the RockPro64, which is just a rockchip rk3399 afaik
<vagrantc>shtwzrd: it's very similar, but... the details matter :)
<vagrantc>shtwzrd: there is a patch for pinebook support for u-boot:
<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 :(
<vagrantc>oh, i misread it
<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
<vagrantc>which i do on the "regular" pinebook
<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.
<raingloom>oriansj: why would that add noise?
<raingloom>no, i'm talking about package outputs
<raingloom>not console output
<raingloom>such as gmp:debug
<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