IRC channel logs
2026-07-10.log
back to list of logs
<PotentialUser-22>hey everyone! i finally fixed my package so now its a cli command. but im running into some issues regarding udev. my tablet is not being detected when its supported. i also noticed that the config is devoid of the `tablet-data.txt` and `settings.json` files (seen here: https://opentabletdriver.net/Wiki/FAQ/General). did i do something wrong? here <bdunahu>udev sounds like it wants to be installed system wide instead of under your user? but I don't really know how that is supposed to work <bdunahu>so it's not installed in ~/.guix-profile/ anymore? <czan>Have you registered it at the OS level with a udev-rules-service? <PotentialUser-22>`(udev-rules-service 'opentabletdriver opentabletdriver (service kernel-module-loader-service-type '("uinput"))` <czan>That doesn't look like a correct application of udev-rules-service, but I assume you just accidentally included the kernel-module-loader-service-type in there during the copy+paste. <czan>I think you don't want opentabletdriver directly there, though, you probably want to (file-append opentabletdriver "/lib/udev/rules.d/70-opentabletdriver.rules"). I've tried to get that path from your package definition. <PotentialUser-22>czan most likely. i tried using udev-rules-serivce before and wasnt successful. with the file-append, do i use it like this <PotentialUser-22>`(udev-rules-service 'opentabletdriver (file-append opentabletdriver ...))` <czan>Yeah, that's what I would do. Then after reconfiguring I'd check that your rules file shows up in /etc/udev/rules.d/ as you expect. <nutcase>Hi guix. My Emacs config uses elpaca and its use-package macro to pull in packages. I can explicitly make Emacs use guix's Emacs packages instead by adding ":ensure nil" to each use-package declaration. Does anyone know, how I could make Emacs/elpaca automatically decide to use guix's packages if already installled and fetch via elpaca otherwise? <krisbalintona>nutcase: with use-package probably not cleanly. You'd probably have to define your own keyword that does the special handling <sham1>Fairly sure that :ensure is supposed to not install anything if a package can be found in the load-path. It'd be weird for elpaca to not also do this handling <sham1>Of course, this is now the perfect opportunity to migrate away from elpaca and towards using guix to install all the packages <krisbalintona>actually maybe that's right. nutcase maybe defer to sham1 since it's been a while since I had a setup like yours <krisbalintona>sham1: how does one deal with Emacs packages that they want to keep real up to date with (as one does with MELPA or package-vc)? <futurile>PotentialUser-85: you might want to ask on #nonguix and/or try the help email list <nutcase>sham1: that's why I am asking: Migrating to Guix packages is something I avoided since I am using guix. Now I am wondering how smooth this migration could be. <nutcase>krisbalintona: I have full control, I think. If I use ":ensure t" then elpaca pulls and builds a package. If I use ":ensure nil" then elpaca doesn't do that. That's how I loaded pdf-tools and mu from guix packages and avoided an elpaca update of these guix managed packages. Probably, I can live with that way, but I was asking if there is something that could make it easier. <krisbalintona>nutcase: I'm saying that if you wanted a single keyword that says: if this package is installed by Guix, do nothing, but if it isn't, then install it with elpaca, then you'd have to define your own keyword <nutcase>Now, after thinking further: probably it's a good choice to explicitly tell ":ensure nil" or ":ensure t" to avoid surprises, which Emacs packages comes from where, and to have a more declarative setup. <nutcase>krisbalintona: yes, thanks. That confirms that I didn't ignore some elpaca feature <krisbalintona>nutcase: but as sham1 said, I think :ensure t should be fine since installing an Emacs package via Guix adds it to load-path (IIRC), so elpaca/whatever should know it's already installed <krisbalintona>nutcase: so to answer your initial question: if Emacs packages installed through Guix behaves in the way described in my previous message, :ensure t should just do what you want <krisbalintona>nutcase: if it doesn't, and you want to stick with :ensure nil instead of defining your own keyword, then you can just leave a comment stating that :ensure is nil because the package is installed through Guix <Arsen>can I apply patches to a package? I want to work around a bug in 'perf' <nutcase>krisbalintona: I think, M-x elpaca-pull-all tries to update Emacs packages with :ensure t regardless of where they are installed from <nutcase>I'll probably stick with explicit decisions (nil vs t) per package <krisbalintona>nutcase: that's interesting. I don't use elpaca since a long time now but I'd first look into the part of its source code that interprets :ensure t that way and see if I can advise that function in a way that achieves what I want. Or you can continue doing :ensure nil <attila_lendvai>Arsen, yes, look at the gnu/package/patches dir, it has many examples. the package definition can refer to these files. <Arsen>hmm would I have to modify guix itself for that? <Arsen>gentoo has an /etc/portage/patches that applies so-called user patches <nutcase>krisbalintona ok, I didn't have an idea how to modify elpaca, but advices are a good idea. I will think about it, but probably just use nil vs t, after rethinking my use case. <PotentialUser-85>Arsen yes, in guix everything lives in your one config file (or if you spread it across a few) <PotentialUser-85>so you'll have to provide your own package definition (check how others `inherit` packages), add the patch, and then point your config to install that specific package definitions <PotentialUser-85>it's not /too/ different from gentoo, but the mindset is a bit different here <sham1>krisbalintona, nutcase: I just saw the messages. Basically to keep up with a package as with using MELPA or package-vc does take some work since one would have to follow the git commits, but that can thankfully be automated at least somewhat. Besides, the problem with just following packages like that is that you can get significant drift, if you have multiple machines <sham1>Now, how prevelant that is for your case, I don't know. But at least for me, the pinning is nice <sham1>At least with pinning you will know that you won't suddenly get an update that will just break everything. In our contemporary world of supply-chain attacks on software, that's important <nutcase>sham1: I already use elpaca which pulls directly from git repos, which gives a rolling release experience with the most recent patches, releases, features etc. and it's easy to try things before a release. It's true that this might introduce additional issues, but that's rarely the case (at least with emacs-next). I am not aware about the gaps / drift in guix's emacs-xyz packages, but will make this experience. <nutcase>sham1: and yes, supply chain attacks are more likely with pulling main branches <switchy>dcunit3d: the swapfile did just work for hibernation :) pointed the `resume` device to the cryptroot mapper and I guess the initrd decryption did the trick <Deltafire>just updated my laptop and now resolvconf doesn't generate /etc/resolve.conf any more (it's an empty file). Rolling back to the previous guix confirms that all works again <kestrelwx>I think you have to restart NetworkManager service. <Deltafire>that looks like the issue! will give that a try, thanks :) <Deltafire>i did read a couple of news items when updating, but didn't see the one mentioning openresolv <kestrelwx>I use connman so didn't even get to encounter the issue. <Deltafire>weird this only happened on my laptop, which is syncronised to the same guix commit as the desktop PC which didn't have this issue <csantosb>sneek, later tell ieure, I managed to reduce the closure size of Yosys in cb2b04d71af, by 2 GB, thanks for your help ! <ieure>csantosb, Hi. Glad to hear it. <sneek>Welcome back ieure, you have 1 message! <sneek>ieure, csantosb says: I managed to reduce the closure size of Yosys in cb2b04d71af, by 2 GB, thanks for your help ! <ieure>You can use it to leave messages for people when they're not around, which it will repost when they return. <ieure>I know why everything is Like This, but it is genuinely absurd that `guix shell vlc' downloads mariadb. <ryanprior>Does anybody have a recommendation for how to upgrade rootless Guix? I saw one technique which involved running the daemon as root temporarily, which I don't think is an option for me, as I'm running the daemon inside an unpriviled container in the first place so even if I run it as root it won't have those privileges. <ieure>ryanprior, Tell me more about "unprivileged container" here. Like a container run with rootless Podman? <ryanprior>ieure: exactly, it's a vanilla OS apx container which is backed by rootless Podman <ieure>ryanprior, Why wouldn't running it as root inside the container work? <ryanprior>I mean, it would work, it just would still have limited privileges <ieure>What would the point of rootless podman even be if you had to run it as root on the host to use root in the container? <ryanprior>it involves running a privileged daemon. I don't think I can do that inside an unprivileged container <ieure>While I'm not 100% certain, I believe you are incorrect. I think you should try it. <maplebaguette>I'm having trouble doing a guix pull --no-substitutes. It seems to not be able to build disarchive-0.6.0. I was doing a fresh install of guix on WSL2 Ubuntu. "ERROR: <maplebaguette> message: "build of `/gnu/store/j9x4x1wrcv78slvhh2psvhpl2gxh9vqc-disarchive-0.6.0.drv' failed" <maplebaguette>guix pull: error: You found a bug: the program '/gnu/store/p339flyqm6qcyl6g48576k8z62csq9n4-compute-guix-derivation'" <ryanprior>So, I had to improvise a bit but I was able to rescue my unprivileged guix-daemon :) <orahcio>Hi, may I send PR via AGit for a small fix to the documentation? <ieure>orahcio, Anyone is welcome to open PRs, you do not need to ask. <stephen0>anyone else getting a 503 when trying to guix pull? <stephen0>It's hard for me to debug because I get access denied when trying to browse codeberg through a browser pretty much all the time, but normally I can clone things just fine. <PotentialUser-22>hi again! does anyone know how to change a udev rule to use MODE instead of uaccess? <Deltafire>stephen0: yeah, looks like codeberg is borken <pdpnw>stephen0: I had to switch my channels to use ssh, somebody in another room said codeberg's been struggling with unauthenticated traffic <pdpnw>if you use ssh should work, I'm doing a pull at this moment <Deltafire>i noticed one of the repos used by a package in guix was geo-blocked in the uk <pdpnw>they must be taking some pretty heavy handed measures to block bots. qutebrowser gives me an access denied, perhaps they're blocking webkit based things <pdpnw>I'm able to log in with librewolf, otherwise I get 504/503 but that's on their end <sham1>I had some trouble on my phone earlier today <pdpnw>from what I recall there were some fun things in gnu/packages/web-browsers <ryanprior>So, no sooner than I thought I was out of the woods with my guix daemon, I am actually hitting errors again XX <ryanprior>I am up to date (guix pull and sudo -i guix pull both report "nothing to be done") and some commands work (eg guix shell bash), while others fail (eg guix shell openssh) <ryanprior>"guix shell openssh" fails with: guix substitute: error: corrupt input while restoring '/gnu/store/guix-directory-1639.lPZL3i/restored' from #<input:hash-input 7fe284c8b900> <ryanprior>That reminds me of what I was seeing before updating my guix daemon, which makes me suspect that it's not actually fixed? <ryanprior>guix describe reports that I'm on aa641a7175bc6eba1e1c6472884245d2f2557967 from Jul 10 2026 18:27:06 <stephen0>hmm, ssh sounds like something I'd need an account for and to upload a key...