IRC channel logs
2025-05-30.log
back to list of logs
<cdegroot>(I'm running Guix on my laptop, with Nix for compatibility for some things that I still have in .envrc's (`use nix ...`), and Nix on my main workstation/homeserver monster of a box with Guix for all the new user-level stuff. Slowly moving towards Guix, because Nix.... well, you can get shit done but I really don't like the language and I'll rather gnaw off an arm than contribute to a C++ code base :P). So now I have /gnu and /nix everywhere, glad that hard <cdegroot>I'm prepping a series of blog posts about my Lispy Laptop - Guix/Herd, Emacs, Nyxt,StumpWM, writing webapps in CLOG, I just wish that someone would create something like Pluto (Julia) for Lisp. <cdegroot>It's good to have options, but it also makes it hard to contribute to Guix. Just noticed that Julia in Guix is waaaay behind. Do I upgrade or switch to Nix for that project?... <bavier>cdegroot: would be great if you could spend some time on Guix's Julia package ;) <cdegroot>I'm looking at it and "some time" is optimistic. On the upside, the Nix package source is much simpler so I'm toying with just porting that instead of trying to adapt the 1.8.x code that's currently in there. I just don't understand how the Nix build works, it really seems like Julia is intent on downloading stuff at build time... <cdegroot>Well, I'm thinking that because Nix downloads -full.tar.gz that's a tarball that has the bits that the build would otherwise download in it. The Nix package is really just very straightforward (and I'm find reading Nix, just not my favorite - but it's up-to-date with 1.11) <cdegroot>Well... C++ code is compiling (I can't help but marvel at the sheer complexity of languages that are implemented in C++ using LLVM where Lisp and C do just as fine a job ;-)). <cdegroot>Interesting. Looks like Nix has /bin/sh in the build container. Is there a way to have that in Guix as well? It's making things much harder... <cdegroot>(looks like I hacked my way past that hurdle. But I think that /bin/sh and /usr/bin/env are... ok :-)) <apteryx>how to build a go package that consists of various modules? <apteryx>do I need to make one package per module? <untrusem>Codeberg again having spam issue problem <untrusem>someone should access to main repo should close the ai generated issues <apteryx>packaging go is not fun with our current go-build-system, when we encounter Go modules <apteryx>I need to make one subpackage for each module, then propagate these from a metapackage <apteryx>untrusem: Thanks for the heads-up. I cleared those on the guix-packages-website repo; are there more? <apteryx>do we have a package module where to place a Go REPL package (gore) ? <m4xxed>Hey, anyone else running still running into the issue `guix home: error: unshare: 268566528: Invalid argument` when using `guix home container`? I wasn't able to update my `guix home` for 2 weeks now... I even found the issue in https://issues.guix.gnu.org/78356 , but never found a fix for it .. <m4xxed>(but for context, this only fails with the container, `guix home reconfigure` succeeds...) <ruther>yes, as you can see the issue is still open. It hasn't been fixed <untrusem>what's the easiest stuff to package to guix? emacs packages? <ruther>untrusem: anything that has an importer as long as the package follows the way expected by default <Yappaholic>Hello, I want to contribute to the guix packages and I wonder, should I send patches to the guix-patches@gnu.org or should I send pull requests to the codeberg mirror? <ruther>Yappaholic: neither, send pull requests to the codeberg main repository :) <ruther>Yappaholic: if you prefer the e-mail approach you can still send patches there, though. But I would expect PRs are going to be faster to get merged <Yappaholic>ruther: Thanks. I am kinda new to the codeberg (coming from GitHub), and the only info about contributing I saw was about guix-patches@gnu.org. Do I need to create another branch or I can send PR to the master branch (I am trying to update xkeyboard-config to 2.44, which many packages depend on)? <ruther>Yappaholic: yes, codeberg migration has happened very recently, no one has updated the docs yet, it is unfortunate <ruther>Yappaholic: send your PRs against branch you would send it against normally, that is usually master unless you want to target new functionality on team branches, ie. rust team recently implemented a new way of handling packaging rust packages, so if you use that, you would target rust-team <ruther>Yappaholic: if you make a new branch on your checkout/fork is completely up to you. It can be beneficial especially if you want to make multiple contributions. <ruther>Yappaholic: how many packages do depend on xkeyboard-config, do you know? <Yappaholic>ruther: I'll have a look at the AGit flow, but maybe keeping a fork would be more useful for me (once I will understand how to automatically fetch from the main repo). I've looked at the package references some time ago, I think it was more than 3000 packages, simply because xorg and wayland related packages rely on xkeyboard-config and xkbcomp <ruther>Yappaholic: yeah, that is a lot. I don't know what the best branch to put it to is going to be then... Guix doesn't merge through the webui anyway, so targeting the branch against master shouldn't really matter and hopefully someone will pick it up <ruther>there isn't a team handling xorg.scm as far as I can tell <Yappaholic>ruther: I see. My main concern was that based on the documentation, this amount of dependent packages would mark patch as core-updates, which are merged every 6 months or so, is it still true? <ruther>Yappaholic: it seems to me you're reading the outdated docs 1.4.0 <ruther>Yappaholic: I don't think those exact numbers are used anymore, now it's more about teams having their own branches with packages. Core updates is still one of them, that is true. And it could be one that could be used for this definitely <ruther>Yappaholic: but I might be mistaken here. Note that currently core packages team branch is top of the line, rebuilding the packages, so I doubt they will accept a new update like this right now :( <ruther>Yappaholic: don't most of the packages using xkeyboard config also use mesa? <Yappaholic>ruther: Well, that's unfortunare. Then I will try to make a PR to the master and hope that someone will pick it up. However, this might take a long time, since hydrating binary substituters will take a while after a patch like this. <cbaines>unfortunately, I think world rebuild commits are still being pushed to core-packages-team <ruther>cbaines: don't thousands of packages depend on mesa though? And that is going to mesa-updates <Yappaholic>ruther: I'm not sure about mesa, but maybe down the line xorg-server and wayland will eventually depend on mesa <ruther>Yappaholic: xorg-server does depend on mesa - `guix graph --path xorg-server mesa` <cbaines>ruther, I'm not sure what update you're refering to <ruther>cbaines: I am referring to mesa-updates branch <ruther>I really think there is going to be a huge overlap of packages using xkeyboard config & mesa, so imo it's better to put it to mesa-updates rather than core updates <cbaines>I am concerned by having the core-packages-team and c++team branches in play at the same time, as even with it's reduced scope, c++ team affects 80% of packages <Yappaholic>cbaines: Really? I thought that unless c or c++ related patches would affect compiler versions there might be some problems <cbaines>Yappaholic, I don't follow, what are you asking? <yelninei>i am officially out of commencement.scm for x86_64-gnu on both master and core-packages-team, even more painful than the i586-gnu bootstrap <Yappaholic>cbaines: I mean, what problems can occur because of core-packages-team and c++team updating at the same time? I'm curious about this, but if the explanation is too complex, then nevermind <ruther>Yappaholic: the most obvious problem is that once one of them is merged, the other will have to be rebuilt again, almost fully <yelninei>cbaines: i guess that is because of cmake-minimal? <cbaines>I'm not concerned by potential problems, more concerned that this isn't very efficient way to make changes <ruther>cbaines: do you know why the old way of having staging and core updates branches has been abandonded? <cbaines>I think there were multiple reasons/motivations <ruther>Yappaholic: if you are going to base your change against mesa-updates, you can ping podiki on the PR afterwards <cbaines>with core-updates and staging, the situation seemed to be that they were long running branches with lots of changes pushed over a long period of time, and all of those factors made it harder to work with <cbaines>it was also generally unclear which branch should be merged next, when that might happen, and what remaining work there is <cbaines>the situation has somewhat improved, but the scoping issue of branches still needs addressing, and currently at least, teams isn't an effective approach for decidiing scope <Yappaholic>ruther: Thank you. Since I haven't got any responses after sending patch to guix-patches@gnu.org, I will try to send a PR to the mesa-updates in a couple of days <ruther>cbaines: yeah, definitely. I think that on the other hand the team approach is quite easy, since the teams can work without affecting each other. Not sure if being easy outweights not being very efficient on resource usage <Yappaholic>Also, regarding xkeyboard-config. Is there a way to graft or replace dependency for keyboard-layout option in the operating-system/xorg-configuration? <ruther>my concern would be that the harder it is, less people would try to get the branches pushed => having issues resembling the old staging/core-updates issues <ruther>Yappaholic: in the operating system... so you mean like for building the console keymap? <ruther>oh sorry you meant xorg-configuration <ruther> Yappaholic: I think that for operating-system it is not possible, it is used during build <ruther>Yappaholic: for xorg I would think just grafting the package should work as it is referenced when starting xorg with -xkbdir option <ruther>Yappaholic: to be more concrete, I think if you used something like sddm, you could just replace the sddm in the sddm-configuration for one that has grafted xkeyboard config in the dependencies <ruther>but easiest to ensure it is going to be picked up everywhere would be to just use guix with the (replacement ...) option of the package definitely <meaty>Is there a way to tell guix "build this package (even if it's already built) and keep the build log even if it succeeds" <meaty>optionally, also ask it to keep the build dir even if it succeeds <Yappaholic>I guess another question I have about configuration is the gdm service, since I am not able to remove it comletely from the system, either with modify-services or using remove function with the lambda. I really don't want to use desktop managers since I prefer startx or launching wayland compositors from the terminal <ruther>meaty: yes, that is what --check option is for. The build log is kept always as far as I can tell. No, it is not possible to keep the build dir, you hav eto make the build intentionally fail. <ruther>Yappaholic: are you using set-xorg-configuration? <Yappaholic>ruther: I did write a transform function to apply graft for the neccesary packages, the only thing that's left is updating the keyboard in the operating-system <ruther>Yappaholic: if by that you mean the console keyboard that is built, I don't think that is possible without changing guix source <Yappaholic>ruther: I am using set-xorg-configuration, does it also pull gdm? <Yappaholic>ruther: That's unfortunate, but maybe it will be updated in the future <ruther>Yappaholic: yes, it does, use the configuration option of the startx service instead <Yappaholic>ruther: That's a little weird since there is gdm-service-type, which is included in %desktop-services. Seems like it should only configure the xorg server in my opinion <ruther>Yappaholic: that is not possible though <ruther>Yappaholic: 'configure xorg server' means to extend the service that provides xorg server, and that changes based on the login manager <ruther>I agree the naming is just wrong, but I don't think there can be much done with the current concept of it, other than just deleting it <mra>sneek: later ask apteryx hey, i meant to ping you on pull #127, but i'm pretty sure that when a message is edited to @ someone it doesn't notify them. the pull is related to an issue that you opened, so i thought you should see it <ruther>mra: hm, why don't you ping them in comment? <mra>ruther: that would be because I'm an idiot who doesn't consider such things lol <Yappaholic>ruther: I do agree, that since guix doesn't play well with xinit or startx unless you use home-startx-service, set-xorg-configuration should enable some kind of desktop manager, but the naming is really misleading :) <Yappaholic>I am trying to build vterm for emacs, which requires libvterm, but the cmake configure step can't find the library, even when it's installed system-wide. Is there any way to update clang/gcc include and pkg-config paths manually? <Yappaholic>Before that it did compile once, but ldd shown that the binary can't find libvterm.so <Yappaholic>csantosb: No, I'm using doom for package management, so vterm needs to compile a dynamic module, which relies on libvterm in gnu/packages/terminals <look>meaty: I have tinymist on a buildable state, from a couple months ago, there's some dependency unbundling to do but it currently builds and works fine <look>I can open a separate PR for tinymist once #79 gets merged <look>I hope you haven't spent too much time on it, since the importer does not currently support git registry patches (tinymist has them), so some small additional manual work is needed before importing <apteryx>anyone else using pounce-service-type as their bouncer? I've been running it for a couple weeks, and it has been very stable and using minimal resources, so I can recommend it! <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, mra says: hey, i meant to ping you on pull #127, but i'm pretty sure that when a message is edited to @ someone it doesn't notify them. the pull is related to an issue that you opened, so i thought you should see it <mra>apteryx: I saw, cheers. working on tests now :) <ghodawalaaman>hello, can anyone suggest me a laptop that works with Guix? my current laptop DELL Inspiron 15 3000 doesn't work with it <ieure>ghodawalaaman, Can you please define "works with it?" <ghodawalaaman>I mean in which I can install guix without having any problem <ieure>How does your current laptop not work with it? <ieure>Since Guix doesn't ship firmware blobs, and all modern computers require them, there isn't a straightforward answer to that question. <ieure>I don't believe there's one specifically made for Guix. <ieure>ThinkPads are a popular choice, T480 is a good model. <ieure>You can get an ath9k WiFi card for it. That's the newest one which has fully free drivers, <JodiJodington>make sure you look at the security issues with old hardware though before just getting one, it's not always an easy choice between fully free hardware and more secure hardware <ieure>Yeah... Older Intel CPUs have hardware vulnerabilities, and you have to choose between running unsafely at full speed, or mitigating them and taking a performance hit. <ieure>They've had a bad time of it lately, between the vulns and self-destructing 13th/14th gen CPUs. <noe>Does this subscribe you to every issue? <hako>noe: not sure, but my avatar don't show up in the list. <dthompson>can a shepherd service graph contain cycles or is it a DAG? <podiki>re: mesa-updates branch, yes taking patches, i hope can get up in line soon as it has been ready since i submitted it (just needs builds for non-x86 usually) <mra>oof, i am struggling to write a test case. if i build some derivation built from a gexp like (gexp->derivation "foo" ...), how do i get the uri at which it will be published? <mra>kind of losing my mind with this one lol <ampinga>hi there! does anyone have the same issue as me when using gnome video (totem): most of the videos couldn't switch to the next video automatically and totem didn't respond anymore after the end of the last video. Need help, where to ask help. <Tadhgmister>not sure this is the right place for a gnome app specific question <Tadhgmister>have you tried launching the app from a terminal so you can see the app logs to see if it is throwing an obvious error? <Tadhgmister>I use mpv and have been quite happy with it, not necessarily a fix but felt worth mentioning <Tadhgmister>dthompson shepherd services is a DAG, I feel like you would have to go out of your way to even get the guile to compile without throwing an error that one of the services hasn't been defined at the point it gets extended <Tadhgmister>mra what do you mean by published? like the path it will have in the guix store? <ampinga>Tadhgmister: I will check later for the app logs on terminal. But if I remember correctly it was related to a dependency. <Tadhgmister>I would guess it is some service it expects to be running on dbus but isn't, I know I've had a number of issues like that in the past when I was using gnome <mra>Tadhgmister: i mean published via `guix publish`. i'm trying to test that a derivation is not being published <Tadhgmister>publish just exposes the `/gnu/store` via http right? so the hash of the derivation would be the path it is published by right? <Tadhgmister> "builds the given derivation and then returns the path to its output" <Tadhgmister> (build-things store (list (derivation-file-name drv)))) <Tadhgmister> (derivation-output-path (cdar (derivation-outputs drv)))) <podiki>please use a paste service Tadhgmister for anything more than a line or 2 <podiki>(you get a temporary silence and then can get kicked via the bot) <Tadhgmister>mra `(derivation-output-path (cdar (derivation-outputs drv))))` gives you the path to the first output of the given derivation, although that path may not exist if you haven't explicitly built it hence the function to do that too. the derivation outputs is an alist so `assoc-ref` can be used to specify the output instead of `cdar` <podiki>Tadhgmister: it is just a simple rate limiter i believe, tries to stop someone as they are making a big paste is my guess. anyway, the headsup stands <noe>hako, probably because I don’t have enough permissions. It’s a shame non comitters lost to the ability to manage issues and prs <Tadhgmister>for me it initially gave me an error but then loaded <hako>morsicus: guix shell info-reader gnu-standards -- info "(standards) Change Logs" <ampinga>Tadhgmister: on my terminal it shows me: (totem:1901): Grilo-WARNING **: 18:55:42.102: [registry] ../grilo-0.3.16/src/grl-registry.c:1523: Plugin 'grl-lua-factory' nota available <ampinga>(totem:1901) Totem-WARNING **: 18:55:42.102: Failed to load grl-lua-factory plugin: Plugin "grl-lua-factory" not available <podiki>sneek: later tell civodul: I ended up changing the git url in cuirass via the web interface for mesa-updates, so it can start building i hope <Tadhgmister>ampinga so according to the internet grl-lua-factory is part of grilo-plugins which is a guix package, my best guess is you need that package installed? <Tadhgmister>no idea how to go any further than that hypothesis though <Tadhgmister>and not even confident that is strictly related to your issue, may be unrelated warning that doesn't cause any issues\ <mra>well, good news is that i got the test to work, bad news is that the test fails lol <podiki>sneek: later tell Yappaholic: i did a local update to xkeyboard-config which builds fine without changes, but haven't tested any dependents <podiki>sneek: later tell Yappaholic: I went ahead and pushed the xkeyboard-config update to mesa-updates, hopefully substitutes will build soon with that and newer mesa i pushed before <ampinga>Tadhgmister: okay I will try thank you. <meaty>look: dw, I looked into it and was scared away by the vendoring and workspace shenanigans :p good to know it's not as bad as it could be tho <podiki>hmm berlin hasn't picked up mesa-updates changes, i did change the git url in the spec <cow_2001>i am trying to load file-attributes, but nothing works <cow_2001>i am thoroughly confused. trying to run (asdf:load-system :file-attributes) fails consistently <potatoespotatoes>Hi all, I want to wrap an os derivation to check if a service is in the os-service list and modify the service if it is present, otherwise add a new service <ruther>potatoespotatoes: you cannot do that with os derivation. Os derivation doesn't have concept of system services anymore. Those are a higher abstraction used in the operating system record <ieure>potatoespotatoes, What service? For your usecase, you generally want to use a service extension, which does what you want. <ieure>But not all services support extension. <potatoespotatoes>Hmmm... that would be a good thing to check! I'm trying to create a kernel-module-loader-service-type or append to the list of kernel modules that it takes as an argument <ruther>the kernel module loader service type is meant to be extended. There is even an example in the docs showing that <ieure>potatoespotatoes, But to answer your general question, if you want to manipulate your operating-system, you generally want to manipulate the record, not the sexp whose evaluation constructs the record. So just (define %os (operating-system ...)) and screw around with %os. As long as the last form in your configuration evals to an operating-system, you're good. <potatoespotatoes>so if I define kernel-module-loader-service-type twice, then both lists will be unioned? <ruther>potatoespotatoes: what do you mean 'define' it? <ruther>potatoespotatoes: and what 'both' lists, where are there two lists exactly? <ruther>potatoespotatoes: this will add the service kernel module loader service type to the services list of the operating-system, so if the list already contained it, it is going to be there twice. That is not allowed. <ruther>potatoespotatoes: 'both lists will be unioned' doesn't make sense here, the cons* is just appending. It doesn't union anything. And the other procedures working on the operating-system do not know there were ever two lists. <potatoespotatoes>Yeah, so kernel-module-loader-service-type would be cons'd twice if I apply two wrappers (is that okay?). Is it okay to have two of these services or do I have to somehow modify the list in this service? <ruther>potatoespotatoes: neither. As was said, easiest is to use extensions. First option wouldn't work, second option is unnecesarily complicated <ruther>potatoespotatoes: yes. Since you are making a simple fixed extension, simple-service is used for that typically <potatoespotatoes>Hmmm... could you point to the example in the docs with the kernel module loader service? I'm a little confused w.r.t. how to define the procedure that fold-services calls and the fold-services documentation is not particularly helpful <potatoespotatoes>or... services-extension says it needs a one-argument procedure, but fold-services just seems to take a list of services -- is the procedure something like (const (my-new-kernel-module-loader-service)) <ieure>potatoespotatoes, `(guix) Linux Services'. <ieure>You're really overthinking this. <ieure>potatoespotatoes, Assuming you want to *add* modules, the example in there does everything you need in two lines of code. <ruther>potatoespotatoes: you don't make a procedure that fold-service takes. You make list of services. A *flat*, single list of services, nothing else. <ruther>the example is in guix cookbook under wireguard vpn <jakef>hi ieure, i fixed that acronym in the emacs-dicom pkg so it might be ready now <ieure>jakef, Cool, I'll take a look when I'm off work. <meaty>python packages, how do I address "module 'setuptools' has no attribute 'build_wheel'"? I feel like it has to be a common thing <ruther>meaty: you add python-wheel to native inputs <meaty>ruther: I tried that, no luck <ruther>then it is going to be something specific to that package <luca>Hi, do people with long-running desktop programs run them with shepherd, or just `exec <x>` in some window manager config script? Asking because it seems like there's a lot of env config involved to run more complex apps with shepherd <meaty>anyone know where tcsh completions are supposed to go?