IRC channel logs
2024-07-18.log
back to list of logs
<efraim>I think for grub we need a gcc for ppc64le that can compile to big-endian and little-endian <Chwoka2>hi, this an okay spot for newbie questions? <Chwoka2>how can i set the /gnu/store directory that guix uses off of read-only? even chmod on root doesn't do the trick <Chwoka2>(as for why i want to do that, the obvious question: sawfish wm expects me to be able to load and edit its themes by changing files in its directories and editing its files) <Chwoka2>(same goes for hexchat, the program i am using right now actually. which is annoying because for some reason my current configuration renders my own sent text as dark-grey on slightly-darker-grey) <jaft``>Chwoka2: /gnu/store is intended to never be modifiable (except by Guix); it's part of how Guix can guarantee reproducibility and all the other guarantees/benefits of an immutable distro. <Chwoka2>and it looks like i can also use ~/.config/hexchat for hexchat <lfam>Chwoka2: To echo the earlier messages, editing /gnu/store is never the right way to do stuff with Guix, and that's why it's so hard to do <Chwoka2>i suspected that might be the answer <lfam>Most programs support putting configuration and similar files somewhere besides the same folder as the program itself. And if they don't, we try to add that functionality <Chwoka2>prolly safer than editing source files, especially for a newbie <lfam>Yes, and even the most seasoned Guix hackers don't edit /gnu/store. It's not like "for experts only". It's simply not done <Chwoka2>and i've screwed up configuration bad enough i'm gonna try to restart (there's surely a better way but i know this'll work and this isn't the place to ask) so farewell <jaft``>It's funny; no shade, of course (everyone has different preferences, etc.), but I wound up on Guix (other than it being Guile all the way down: main OS in my favorite programming language? Sign me up) because I kept having my OSs become more and more unstable from (what I think) was editing config. files. <jaft``>I might run into issues just from the fact that Guix is smaller than other distros but, once something works, I no longer have the creeping worry of things not working; things just feel so much more solid. <jungy>I've been trying to get slynk to work in stumpwm, and it seems to fail because stumpwm doesn't have access to sbcl' <jungy>s dependencies. Even compiling with stumpwm+slynk just reports a require failure. <jungy>Is the guix way to handle these things to make your own package with what you need, or is there an alternative way to ensure the package can access what it wants? <jaft``>jungy: I've never used either so I can't say I'll be of help but how're you trying to use slynk? Like, how are you getting Slynk to run? <jungy>Just using stumpwm's eval to call (slynk:create-server) <jungy>That way I can connect to it with emacs' sly client <jaft``>Sorry; what I meant was how did you get Slynk installed. Via a package (or does StumpWM come with it installed)? <RavenJoad>jungy: I am using stumpwm+slynk and Emacs' sly, and everything works fine. What require are you missing? <jungy>well initially I just had stumpwm, when that was the case it couldn't require sb-cltl2. I switched to stumpwm+slynk, and now I can call the create-slynk, but when I attempt to connect via sly, it informs me that it couldn't find the #:quicklisp component. <RavenJoad>Huh... Strange... Slynk's function to start a server is slynk:create-server, not create-slynk. <jungy>Sorry, that's just my bad memory right now <jungy>I'm still setting up the computer so all this is relayed between here and there. I typed the correct function previously this evening. <RavenJoad>Ok. Are you sure you are booted into the right stumpwm session? That is the last thing I can think of that may explain this. <jungy>Should only be the one---I just selected it from the GDM <RavenJoad>Ok, weird. Mine is set up similarly and I have no issues. <jungy>Do you use just the standard emacs package from GUIX or are there any additional options you maybe inherit? <z572>hello! kde-team has merged. if you use sddm with qt5 theme, please set sddm-configuration's sddm to sddm-qt5. <faust64>but failed with err - libbpf: failed to find '.BTF' ELF section in vmlinux <faust64>but failed with err - libbpf: failed to find '.BTF' ELF section in vmlinux <civodul>faust64: hi! FWIW linux-libre 6.9.9 builds fine <civodul>maybe check with the people over at #nonguix if you’re looking at the vanilla kernel? <f1refly>I'm trying to lauch a ren'py application in a guix shell, currently it fails with MESA-LOADER: failed to open i915. And indeed, when I check the GUIX_ENVIRONMENT, i915_dri.so isn't in lib/dri/. <f1refly>guix locate i915_dri.so tells me that i915_dri.so is provided by mesa@21, but I cannot tell guix shell to include mesa@21 because apparantly it isn't defined <sepeth>Hi there, I am trying to write a package def, however I couldn't find out what should I specify for the build-system. The package I am trying to build only has a Makefile, so it just need to run "make". I couldn't find any example in the guix repo :( <sepeth>Hmm, think I can use gnu-build-system with (#:phases (modify-phases %standard-phases (delete 'configure) ... <Leopold> (source (local-file "my-package-1.0.tar.gz" "sha256-hash")) <Kabouik>I am trying to make a package for mpv with sixel support, but adding libsixel in inputs does not seem to work. I still get "Run-time dependency libsixel found: NO (tried pkgconfig and cmake)" during compilation. Any ideas? <ieure>Kabouik, You might need a flag to the configure script to enable it and/or point it at the libsixel .h files. <ieure>No. Also libsixel needs to be in inputs, not native-inputs. <dariqq>Kabouik: the pkg-config file for libsixel list gdk-pixbuf as depency which probably should be propagated by libsixel <ieure>Kabouik, I have no idea what that second paste is or how it's related. <dariqq>as a workaround you should be able to just add gdk-pixbuf yoruself <Kabouik>It's from the mpv package, thought you meant I needed to add and entry in there to point to the libsixel .h file. I thought this was the configure part. <ieure>Kabouik, Oh, *weird*. You added a quote to the end of the URL, which gives a completely different paste, some kind of program crash backtrace. <Kabouik>Ok dariqq I added gdk-pixbuf (how do you find the pkg-config name?) and this time the compilation did find libsixel! However the resulting mpv binary still seems to fail with --vo=sixel. <Kabouik>Heh, interesting ieure. Yeah I mistyped the url, saw it after posting on IRC but I didn't check the resulting url. <dariqq>Kabouik: i just ran guix build libsixel and then looked at the pkgconfig file in lib/pkgconfig/libsixel.pc. <RavenJoad>jungy: Sorry to get back to this only now. The only Emacs configuration I do from within Guix is choose emacs-pgtk. In Emacs the only thing I do is install paredit and sly with use-package. <Kabouik>So what would be the best way to test if my package modification works and can be submitted as a patch, when this package implied updating dependencies too? For single applications I usually do a package.scm, add `packagename` on the last line, and run `guix build -L . package`, but this won't work when there are changes in dependencies too. Do I need to push them to a private channel first and guix pull && guix install package? There must be <ieure>Kabouik, I keep a clone of Guix and cut a branch off that, and make my changes there. Then follow the manual's instructions for building from git, then build my package with `./pre-inst-env guix build packagename'. <Kabouik>Thanks. I need to check the manual instructions that describe that indeed. I head about ./pre-inst-env here but never understood how it worked. So far when testing packages that needed dep changes, I was always pushing them to my private channel, then pulling, which is not only long, but also clutters the commit history. <ieure>Kabouik, I have a specific branch of my channel for that kind of thrashing. <ieure>And will rebase stuff from there into the main branch so the commit history is nicer. <Kabouik>I find it surprising that guix build -L . doesn't have an option for looking for dependencies in the current directory if they exist (or are given as argument), but maybe that would be hard to implement. <Kabouik>I think it's significantly restraining package updates for mere mortals like me. <ieure>Not sure what you mean, honestly. But I have also never been able to get `guix build -L.' in the clone of Guix to work at all. I haven't looked into why. <Kabouik>I think your workflow is far better than mine, and also facilitates generating the patches, but that requires being fluent with git. I am comfortable with the base git commands only. <Kabouik>So for example here I tried to update mpv to 0.38.0, saw that it required libplacebo to be updated too, so I made a libplacebo.scm on top of the mpv.scm. When I `guix build -L . mpv`, if I could add `--local-deps libplacebo`, this would skip the need to upload both to my private channel and guix pulling before guix installing mpv. But again, I understand my workflow is not good, and error prone. Also this makes writing the use-module list a real <Kabouik>nightmare. I definitely need to get more familiar with git and learn how to guix build from git and pre-inst-env. <ieure>Kabouik, I think your problem is that you're writing standalone package definitions, not putting them in Scheme modules. `guix -L/some/path' will work fine as long as /some/path contains Scheme modules. <Kabouik>Though that means guix build -L should work in your Guix clone, right? <ieure>It doesn't, I don't know why. You don't need -L if you use the pre-inst-env. <weary-traveler>in my limited experience, when working on patches, working on the git checkout is the most straightforward way <weary-traveler>you shouldn't /need/ anything other than the most basic of git commands. it also provides a straightforward way of generating patches from your changes <ieure>weary-traveler, I think they were referring to my strategy of having a WIP branch in my channel which I rebase into main after it's working. Agreed that hacking on guix only needs basic pull/branch/commit stuff. <ieure>I agree that's a bit more advanced. <Kabouik>At least I got mpv 0.38.0 working in my branch now (with sixel), I'll need to make a patch for it, but I agree making a patch from there is a real hassle. <Kabouik>This has actually hindered me quite a lot, I have a bunch of packages working in my branch that I just didn't submit as patches yet because of that. <weary-traveler>ieure: i see. your channel is a fork of guix? how do you handle authentication? <ieure>weary-traveler, Not a fork of Guix, just a channel. <ieure>weary-traveler, I have Cuirass set up to build from the `next' branch, I'll just slop whatever commits in there until stuff works, then clean up + rebase into `main'. <ieure>I haven't messed with this setup super extensively. <Kabouik>Interestingly, pulling the Guix git now, I see someone has submitted a patch to include qimgv, which is "funny" because I had a package for it in my private channel since months, but didn't submit it as a patch (yet) because of what I said above. Tell me about wasted efforts. Sorry, Guix community. <ieure>Kabouik, It's endemic, I think a large part is that most folks don't look for existing patches before hacking up one of their own. <ieure>It'd be really nice if `guix search' also searched patches somehow. <ieure>Not sure what it'd take to make that happen, probably A Lot. <Kabouik>There was no patch for it when I built the package. My original intent was to draft it in my channel, then submit it. But you know how it ends, you procrastinate the patch submission because you're not comfortable with git-send-email, and months later someone did it from scratch. <Kabouik>It's funny that we didn't came up with the same patch definition. I'm sure the one that has been merged is better than mine, so at least there's this relief. <ieure>Kabouik, Can go the other way, too. I sent in a patch to update emacspeak months ago and forgot about it until the other day, when I got an email closing it, because someone else did the work. <ieure>I really do not think much of the email-based dev flow. <Kabouik>Or wait. Maybe I'm just an idiot. Turns out the qimgv package definition I see in Guix git is just an outdated draft from me, hence why it's not written the same way as the one in my channel (it probaably didn't work), and `git pull` in my Guix clone just kept it there before I stash those changes. <Kabouik>Do I need to add my name as copyright for updates, or just for new packages? <ieure>Kabouik, You should add it for new packages or if you did significant work on one. A straightforward update doesn't need a copyright line. <Kabouik>Interestingly, after propagating my changes from standalone packages to Guix git /gnu/packages/video.scm, and trying to use ./pre-inst-env guix build mpv, I'm getting " error while loading shared libraries: libguile-3.0.so.1: cannot open shared object file: No such file or directory" <vagrantc>presuming guix-daemon 1.2.x can support zstd, it appears guile-zstd is available in the relevent oldstable/bullseye release, and for 1.4.x on stable/bookworm ... it *might* be possible to backport support if it is not crazy ... though my understanding is this is only currently an issue with custom channels? <vagrantc>by not crazy, i mean, not a huge pile of changes. <vagrantc>if someone could relay the above into the bug report, that would be appreciated! :) <vagrantc>ah, looks like guix 1.4.x packaged in Debian should have working support for zstd ... so it is only an issue for the 1.2.x based guix ... <pjals>Hello. Why is wlroots built without Vulkan renderer support?? <pjals>I understand I can use a package transformation option to build it with Vulkan but browsing the web with a text-based browser to find the build flag for Vulkan is pain nowadays. <pjals>If only Guix had browsh, or some sort of Wi-Fi hotspot software <dthompson>ACTION dusts off guile 3.0.10 upgrade patch... <jaft``>I'm using the bluetooth-service-type and am adding Blueman to dbus-root-service-type as a simple-service but still have to manually run "dbus-update-activation-environment --all" in order to get blueman-applet to work. I expect there's just something, in my Guix config.s, that I'm just missing to take care of this for me? <dthompson>hmmm I thought updating the guile-3.0-latest variable was supposed to be safe... but guix refresh is telling me it's gonna cause ~3k rebuilds <dthompson>causes about 3k package rebuilds. could use a hand getting it to where it needs to go. the patch itself is trivial. <efraim>perhaps some of the pacakges using guile-latest should be using guile-3.0? <efraim>I think I have grub building for powerpc64le-linux. Just need something to test it on <dthompson>I guess shepherd could be changed to point at guile-3.0 since that's what guile-3.0-latest was an alias for. <efraim>oh no, I still need to find a source for my both-endian comment <ieure>efraim, Do we support middle-endian yet? <efraim>I'm not sure if middle-endian is a thing or if you're making a joke, but apparently for ppc64le it needs some files in big-endian mode, some in little-endian mode and some readable in both to ease compiling <dthompson>efraim: switching the shepherd-0.9 package to guile-3.0 does the trick 👍 <dthompson>only 47 rebuilds for a guile-3.0-latest upgrade now <efraim>one of these days we're going to need to actually make clang capable of cross-compiling <anadon>Looking to switch my distro over due to `guix pack` functionality and I need to check in about if I need to be careful to support and configure correctly support from the verboten repository that shall not be named. Because, ya know, I need my computer to not be an inert rock. <anadon>How carefully do I need to read in for the binary blob support? <ieure>I *think* Radeon GPUs work with free software and don't require non-free blobs. <anadon>So I'm going to get full ROCm HSA stack support out of the gate? <ieure>Sorry, I don't really do any GPU stuff, so I don't know what that means. <ieure>Radeon drivers are in the kernel, they're not an add-on like nVidia GPUs. What I don't know is if they also require firmware blobs -- if so, those won't be present in the linux-librew package and you'll need to get them elsewhere. <anadon>That's what I'm worried about. This is my primary system. It drives the backbone of everything else I have. I have to __know__ before I take the plunge. However, the `guix pack` feature is so powerful that I would really like the stability of having Guix as the only Package Manager and have it replace `apt` and Nix. <ieure>If you have a spare SSD, I'd install into that so you can poke around with things. Or, you can boot the installer and use Guix, it has the ability to install anything an installed system can. <ieure>Alternately, you can use Guix as a package manager on top of whatever distro you're already runnig. <jackhill>tips on where to start troubleshooting why avahi-daemon doesn't want to start? <RavenJoad>jackhill: I would start by looking at avahi's log file & config file to look for obvious problems. <ieure>jackhill, `grep -r avahi /var/log' <jackhill>RavenJoad: thanks! how do I get shepert to tell me what config and log file it's using? <jackhill>/var/log/avahi-daemon.log for the log. That's an easy one :) <efraim>ok, rebasing the rust-team branch again <jackhill>ah: "2024-07-16 22:19:16 Daemon already running on PID 788", but there's not PID 788 current running. I wonder where the lock/PID file is. <jackhill>oh, but that's an old message. Nothing in the log file from today, but I just did `herd restart avahai-daemon` <jackhill>some combination of `rm /run/avahi-daemon` and rebooting helped