IRC channel logs
2026-04-16.log
back to list of logs
<ieure>illybytes, Just pushed a fix for that issue, please let me know if you still have problems with it! <illybytes>> illybytes, Just pushed a fix for that issue, please let me know if you still have problems with it! <illybytes> i will try to pull it after im done with dinner :3 <illybytes>okay seems like it hasnt been picked up yet by whatver mechanism services are updated with so gonna just try tomorrow morning <ieure>illybytes, `guix pull' should get you the commit, `guix system reconfigure' ought to apply it. Same error? <illybytes>> illybytes, `guix pull' should get you the commit, `guix system reconfigure' ought to apply it. Same error? <ieure>illybytes, Sure, please include your configuration and the full error you're getting, if you can. I stuck your autofs-configuration into my config, and I am able to `guix build' it. There may be a different error somewhere. I don't have the (rosenthal) Guile module, so I can't build your config. <illybytes>so guix describe says guix channel is on an older commit <illybytes>> so guix describe says guix channel is on an older commit <ieure>illybytes, Try running `hash -r', then `guix describe' again. <ieure>illybytes, I pulled, and after removing the modules I don't have, I'm able to `guix build' your system configuration. So I think definitely something weird with the guix you're using. <ieure>I don't understand what you're asking. <ieure>illybytes, Log out/in would likely have solved it. When you enter an unqualified command into a shell (like `guix'), it resolves it against your $PATH, and caches `guix' -> real path to the binary. <ieure>illybytes, And when you `guix pull', you get a refreshed copy of Guix, so the shell's cache can be stale. <ieure>illybytes, bash works correctly in this situation, I've no idea about fish. <ieure>How are you running `guix pull'? <ieure>This is a fairly common thing for new Guix users to run into. <illybytes>yes i did convince a friend to try out guix in a vm lol <ieure>illybytes, Most Linux/Unix distros are top-down: `sudo apt update' to refresh the package list, `sudo apt install ...' to install them, etc. <ieure>illybytes, Guix is bottom-up. Every user has their own revision of guix, with their own `guix' binary. So when you pull as root, you update root's guix, not yours. <ieure>System reconfigures always happen *as* root, but *using* a user's Guix. <ieure>illybytes, You may need to fix permissions on ~/.cache/guix for things to work. <ieure>Sorry, should have said "ownership." Permissions are likely fine. `sudo chown -R $(whoami) ~/.cache/guix' <ieure>The files inside it may not be; the command I gave fixes ownership of everything. <illybytes>oh wait, thats another thing i tried thzt errord, let me disable that and then see the autofs fixes <illybytes>it was the udisk service that i tried enabling but it fails to grab a dbus system services derivation lol <ieure>illybytes, udisks is already in %desktop-services, you shouldn't have to configure anything. <illybytes>so i just my disk manually using gnome disks and it seems to be using the default mount path of most distros: /run/medi lol <ieure>illybytes, Yeah, udisks doesn't know anything about autofs and vice-versa. <ieure>illybytes, Any output in `sudo herd status autofs'? <ieure>You can also enable (logging #:debug) and (mount-verbose? #t) if you need more logs. <illybytes>open_fopen_r:211: failed to open file: No such file or directory <ieure>Yeah, it always prints that, because of Reasons. <ieure>illybytes, Anything in /var/log? <ieure>illybytes, Also, do you see output from `mount | grep autofs'? <ieure>I am wondering if there might be a mismatch in expectations about how autofs works. <illybytes>> illybytes, Also, do you see output from `mount | grep autofs'? <illybytes>this does return a gnu store path for autofs/media.map on /media type autofs (rw, realtime, pgrp, timeout minproto etc etc etc <ieure>And what were you looking at which made you conclude "it didnt auto mount?" <illybytes>only log related to autofs is it starting up <illybytes>> And what were you looking at which made you conclude "it didnt auto mount?" <illybytes>well, it doesnt appear as a device under gnome files <ieure>Yes. For your configuration, you'd have to access /mount/ro/uuid/[some disk UUID here] -- that would mount a disk with that UUID. <ieure>ex. on my system, I automount my NAS on `/star', with an indirect map having device `my.nas:/star/&' and mountpoint of `*'. So if I access /star/library, it automatically mounts my.nas:/star/library on /star/library. <ieure>It doesn't mount things when it starts, it mounts them on demand, when accessed. And unmounts after a timeout. <illybytes>> Yes. For your configuration, you'd have to access /mount/ro/uuid/[some disk UUID here] -- that would mount a disk with that UUID. <illybytes>verified it is the disk uuid by checking in gnome disks <ieure>illybytes, `sudo blkid' in a shell will enumerate all block devices and print their identifying info. <illybytes>only mount points are boot efi, gnu store and root <illybytes>okay seems there is apparently another program that automounts local disks <ieure>illybytes, What is the thing you actually want to do? <illybytes>when i plug my external hdd and usbs they mount <illybytes>or atleast show up in gnome files so i mount them there <ieure>They will show up in Gnome's file manager when plugged in by default. <ieure>You don't have to do anything at all to get that behavior. <illybytes>> They will show up in Gnome's file manager when plugged in by default. <ieure>Only thing I'm aware of which might cause that is if they're in some format that Linux doesn't recognize. Could that be the case? <ieure>Shouldn't be an issue. I'm out of ideas! Want to post to the help-guix mailing list? Someone there might have better advice for making Gnome behave. But I will say that I occasionally use Gnome on Guix, and it has recognized stuff reliably. I don't know why this would be an issue for you. <ieure>I assume you see the device in `sudo blkid' output when you plug it in? <illybytes>i think its because im not really depending on gnome <illybytes>it might be missing some disk management stuff tbh <ieure>Possibly. EXWM is my daily driver and I do absolutely nothing special for GNOME services or disk config... Just opened Nautilus (the actual name of GNOME Files), plugged in a USB disk, it popped right up. <ieure>It should only need udisks, which you have if you're using %desktop-services. Possible D-Bus isn't getting started when you log in? Does D-Spy show a system and session bus? `guix shell d-spy -- d-spy' <illybytes>im guessing it might be related to gvfs-udisk2-volume-monitor maybe <illybytes>cus i looked through base.scm n it mentioned that <ieure>Maybe? Is it running for you? It's running for me. <illybytes>and the wikipedia article (which i got when i searched that name) mentions in an image description that that util is used by gnome to know if to show the disk or not <illybytes>nothing that bears the name gvfs is running lmao <ieure>I don't know how gvfs works, I'd think that's more for pseudo-filesystem stuff like MTP or WebDAV. Notification stuff is built into D-Bus, I don't know why GNOME would have a different thing for it, too. <illybytes>i guess because of the disk attribute x-gvfs-show that is pictured in wikipedia lol <ieure>Where, specifically, are you seeing noauto? <ieure>(This is 99.99999999999% not related to any of your problems) <illybytes>removing it fixed nothing still doesnt automount lol <illybytes>yeah that system startup not plug in fvbdbddbbd <ieure>noauto is a thing you can put in fstab(5) to control mount(8) behavior. It is not a partition option, as in, a part of the partition table itself. <illybytes>i just guix installed udiskie, then ran it and it auto mounted the disk!! <illybytes>so i guess i have to run it in my user session i guess lol <illybytes>like straight up works exactly like before on other distros, i guess that wad rhe missing piece lol <ieure>Cool, glad you got it sorted. And glad you found that bug in autofs, even if you didn't end up using it. <illybytes>also, guix.gnu.org is now using a 2 year old expired certificate for some reason? <czan>That's not what I'm seeing. :/ guix.gnu.org is serving a certificate valid from 2026-03-29 to 2026-06-27 for me. <illybytes>i guess either bad cdn or isp tried to mitm (not the first time they tried to) <czan>Was the certificate for the right domain? If yes: weird MITM. If no: seems straightforwardly dodgy. <folaht>Is there a way to install android-tools on the guix OS? <ieure>folaht, Some Android dev stuff is packaged, but I believe it's both incomplete and very old. So, I think the short answer is "not directly." You might try using them in an FHS container, or in a VM running a different distro. <folaht>I tried a VM and that doesn't seem to work. I think I'll just try using a liveUSB. <trev>seems like a few people have run into this lately <ampinga>trev: does them find a solution even if it is a temporary one? <czan>ampinga: Can you go back to a previous generation? <ampinga>unfortunately no. I tried to switch to slim also but it doesn't work <czan>Hmm. Can you log into a tty and "guix pull" to a previous commit, and reconfigure with that? <ampinga>I can log into a tty but I never try to get a previous commit. I will try that. Thank you <nckx>illybytes: Uh, there is no CDN. Do you remember anything about the certificate? (As czan says, if it was for the right domain, that's… weird.) <illybytes>domain matches the error was specifically about the data mismatch <illybytes>domain i was trying to access was guix.gnu.org, it had it in a bookmark already <librecat>I got an intresting question today: i decided to make a clone of gentoo portage but using an embeddable scripting language for high performance. After looking for more intresting options than lua i realized gnu scheme is also a embeddable scripting language! So is a c based build system scriptable with lua just gnu guix? <identity>no, not really. Guix is written mostly in Guile (sans the daemon, for now) <identity>this is like writing the whole thing in Lua <identity>also, it is Guile Scheme. GNU has at least 2 Schemes, the other being GNU/MIT Scheme <librecat>It might make more sense to go to extremes for a package manager as string/array transfers between languages is very computationaly costly <mra>librecat: hm? not sure what you mean by array transfers being costly <identity>not necessarily, your strings might as well be the same type to avoid ser/de costs <librecat>if i want to execv a lua table i have to iterate over it <mra>from an FFI point of view, passing a string is cheap. I guess enrolling it in garbage collection might be expensive? <identity>the problem here is strings/arrays being represented very differently, not exactly an inherent FFI problem <librecat>if i like scheme itself i might see myself daily driving guix <librecat>One of the things driving me away from nixos was the wierd language it embedded <mra>librecat: current nixos user and I very badly want to switch to guix for this reason <mra>nixos also has simply atrocious documentation. the commitment to high quality documentation is one of the best things about guix imo <librecat>My hardware isnt libre but i can write my own nonfree packages and not share them <librecat>I know that nonfree packages exist in corners of internet dont worry <librecat>Counter intuitively that is what enourages me to try guix most lol <librecat>the fact that people love it enough to share their nonfree packages <librecat>Hopefully one day i get all my work done on gnuboot <librecat>yeah the better solution is to not hide from FSF and FSDG rules and just get a old thinkpad or a core 2 duo desktop <librecat>using nonfree packages on guix feels like hiding away :D <trev>it's the dirty deed no one talks about <efraim>we do have the #nonguix irc channel for discussing non-free stuff. I don't think I could in good consciousness recommend buying such and old machine, or old graphics cards like I currently have <identity>just be lucky enough to have your hardware work without the non-free stuff <identity>and disable hyper-threading in the firmware interface… <efraim>when I get around to working on guix.vim more I'm going to need to remember to look at the vim repo. There's a lot of good vim code there to borrow <mra>efraim: switched from a 2019 MacBook to a 2012 ThinkPad a while ago and it was honestly an upgrade imo <mra>Moore's law is dead, old machines rock <illybytes>like you'd be surprised how well a 3rd gen i5 can run some stuff and act as a build server-ish <illybytes>(still havent set up any real ci, just tmux and pray <illybytes>> when I get around to working on guix.vim more I'm going to need to remember to look at the vim repo. There's a lot of good vim code there to borrow <illybytes>oh yeah spezking of vim, anyone here heard of evi? <futurile>have to wait and see if it sticks I guess, it's easy to fork a project, less easy to keep maintaining it <futurile>ironically, that consistency is why I staid on Vim when Neovim was getting all the attention. Bram's consistency and record was worth a lot. <mra>illybytes: is evi that thing that drew devault is working on? <identity>i think ddv is working on «vim classic» or something like that <mra>yeah, it's a fork of an older version <mra>ddv seems to be constantly working on a nigh-unfathomable number of things simultaneously <illybytes>oh seems like they took two different approaches, vim classic is based on the pre 9.0 version while evi is pre-AI commits <illybytes>oh yeah something quite strange happened to my guix, all the app icons are purple black dev texture checker board patterns <identity>illybytes: do you have an icon theme installed? you probably do if you use a DE service, otherwise try installing e.g. hicolor-icon-theme <illybytes>i have the one that rosenthal's live iso preinstalls (copy paste moment lol) <illybytes>okay something strange is a foot, why is there 3 repeated guix profile and guix home paths in my xdg data dirs 😭 <illybytes>like they are all the current profile for both <identity>i have 2 guix-home paths in my XDG_DATA_DIRS and my icons work fine <identity>i would assume duplicates do nothing for XDG variables <trev>illybytes: bashrc files doing it multiple times? had that happen to me when i migrated from guix as a package manager to guix system <illybytes>okay thankfully i saved my gpg key in plain text <illybytes>any cyber security experts here? my password is potentially between 6 to 20 characters, it contains alphanum and maybe has underscores, how hard would that be to crack? <andreas-e>illibytes: Alphanum with capital and lower case letters plus underscore means 63 characters, or essentially 6 bits. <andreas-e>So there are about 2^120 different passwords with 20 characters. Way beyond what is feasible with brute force. <ente>if it's your own password you don't usually have to bruteforce <ente>which gives me an idea how I could crack my old password from my own backup <ente>probably not gonna do it anyway because it takes time <xyz93>hi, is there a guix node expert available by any chance? <xyz93>as far as I understand node doesn't support NODE_PATH resolution if esm modules are used <xyz93>e.g. "await import('acorn')" in a "guix shell node node-acorn" fails, while a "require('acorn')" succeeds <illybytes>untrusem: dont think i need that rn cus i found the password but will keep in mind :3 <xyz93>i hit this problem while trying to package maplibre-gl <untrusem>xyz93: you could raise an issue and tag team-javascript on codeberg <xyz93>untrusem: ok, i will do that <xyz93>a possible workaround would be perhaps to create a directory-union of all node inputs in the source directory during build, but directory-union is not available in build phases, right? if i try to include (guix gexp) as a build module, i get no code for module <futurile>xyz93: that's going to be due to the modules on the build side I guess. I always look for a package that's doing what I want and figure out how they did it heh <xyz93>futurile: thanks, i grepped guix source for directory-union usage but it seems to be only used in services and not in packages <fanquake>I'm doing a guix pull (no substitutes), which is failing due to a hash mismatch for guile-lzlib-0.3.0.tar.gz. <fanquake>expected hash: 1whgmwkr1v8m63p4aaqn8blwl9vcrswwhbfv4bm0aghl5a6rryd7 <fanquake>actual hash: 1v1pfqp6hwl0rivs7swhqnfgznxlfnws9ldmn6avnhd10filfa3a <illybytes>for some reason gnome keyring service and gnome keyring itself isnt present at all, added the service, which should pull keyring but it seems even after reconfiguring it has added it all? <nckx>futurile, cbaines: Thanks <3 <cbaines>fanquake, can you share the store item for the guile-lzlib tarball with the hash mismatch <fanquake>Not sure if it's worth opening a new issue there or not <cbaines>but the actual desired store path is /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash which is what you get with #:recursive? #t <cbaines>the nar-herder just copied the guix publish script behaviour, which hardcodes #:recursive? #f <nox>how can one add environment variables to `(default-environment-variables)` ? <illybytes>according to the guix manual, you'd need to use home-environment-variables-service-type <untrusem>illybyte: I know, gnome keyring doesn't seem to work for me either, I am using keepassxc as my keyring <nox>I mean at runtime. When I start my Home Shepherd, `WAYLAND_DISPLAY` doesn't exist, and I'd like to add it for future services to have in their environment. <nox>untrustem: for example, in your config, how does home-mako-service-type gets access to this env var? <untrusem> (info "(guix)Shepherd Home Service" " -- Variable: home-shepherd-service-type") <untrusem>so basically `simple-service` extends the given service with the provided value <untrusem>you can see in my 'extend-env-vars-service it extends the home-environment-variables-service-type , this sets the env vars <untrusem>so you can specify `WAYLAND_DISPLAY' there <untrusem>I think it gets assigned for me when I start my window manager <illybytes>okay so both gnome keyring AND kwallet dont work for me 😭 <trev>illybytes: did you add the service? <illybytes>both of them, not at the same time but independently, for gnome keyring it just straight up doesnt run and no apps that can talk to it can see it <illybytes>as for kwallet, it is seen by ssh but it refuses every request and kwalletmanager returns a systemd service relayed error <illybytes>kwalletd6 was not provided by any .service files <ieure>illybytes, Guix System doesn't use systemd. <illybytes>but it mentions .service files, i guess thats hardcoded into that app <f1refly>hey, I just set vm.dirty_background_bytes and vm.dirty_bytes after having my computer freeze for like 30 minutes after trying to write a large amount of data to a microsd like this: https://paste.rs/Yo7Nh.lisp . Is this a bad approach and I'm not seeing something important or will it be fine like that? <ieure>f1refly, Well, the code you pasted will not work at all, because the `number->string' forms are inside a quoted list and won't eval. <f1refly>yes, i just realized that when trying to build it :) <f1refly>Disregarding my incompetence regarding guile, what about the sysctl settings? <ieure>I have no idea about the values. MMC is just generally slow and crappy, sounds like you had that experience. Tweaking kernel values will only ever let you control a bit when the slow crappy stuff happens, it can't fix the underlying problem, which exists in hardware. <ieure>If the values work for you, that seems good enough. I assume you're making a performance vs. durability tradeoff here, by increasing the threshold at which the dirty pages are flushed to disk -- so increasing the risk of data loss if the machine loses power. <f1refly>The problem is that linux has a shared dirty page count between all devices and there's still not a good solution to having a very slow and a very fast disk at the same time because it's a hard problem to solve for the general case... <f1refly>My idea was the opposite: 64-bit system have an obscenely high dirty page count by default, like 3GiB+ by default or something(?), so I tried decreasing it to 256MiB and starting writeback at 128MiB. <f1refly>This is of course terrible for my internal nvme but will at least not make my system hang for half an hour the next time. <ieure>I see, well, sounds like you have a good handle on things. :) <f1refly>I'm very aware of my own incompetence and was hoping for someone to tell me I'm wrong and why that is ^^' <f1refly>Now I just have to figure out how to append that list. Can't be that hard, right? <ieure>f1refly, The service is extensible, so this is very easy. (simple-service 'sdmmc-tuning sysctl-service-type `(("vm.dirty_background_bytes" . ,(number->string (* 1024 1024 128))) ("vm.dirty_bytes" . ,(number->string (* 1024 1024 256))))) <ieure>You can cons that onto your services list instead of screwing around with modify-services, which I find generally irksome. <f1refly>I have a whole bunch of modify-service statements so I don't worry too much about it <ieure>Yeees, but this is so, so much easier. <f1refly>and splitting things into their respective functions is neat as well <ieure>Yes, all my configs work this way, I have procedures that bundle related functionality, even if they change things in different places. It's really nice. <ieure>Those are all either transformers or transformer constructors... so I can do (define %os (operating-system...)) (profiles/+intel %os), and it pops out an OS with Intel packages,kernel tuning, etc etc. Super clean, easy to compose. Big fan. <ieure>Next on my list to see about contributing. <f1refly>My only exposure to functional languages is some elixir and.. well, guile I suppose <f1refly>Editing my guix config is always scary enough even without worrying about the most optimal way to split and abstract it <ieure>That's kind of why I like the transformer approach. You don't have to edit the configuration, just stack up whatever transforms accomplish the end result you want. <sh>where to find the xorg config? <ieure>Those are the parts of the manual covering configuration generally, and xorg specifically. <sh>this differs to much from a regular linux system for me :/ <ieure>sh, It is very different, yes. <ieure>It's best to approach as learning an entirely new thing. <sh>I just wanted to write to use the amdgpu module in an xorg conf file <ieure>sh, It's included by default, you don't have to do anything. <sh>only 1024x768 on a 2K monitor <ieure>Then your problem is different than you think. <sh>why complicate really everything? <ieure>sh, It's more complicated in some ways, simpler in others. Everything is complicated when you don't know how a system works. <ieure>You don't have to like or use it, we won't be upset. There are lots of options if Guix doesn't work for you. <sh>and slackware in the past <ieure>That's pretty much exactly my path. Started with Slackware *ages* ago, switched to Debian (I still use it on some stuff), then to Guix.