IRC channel logs
2025-08-29.log
back to list of logs
<jfred>Does anyone here run a luanti server? I just installed luanti-server, minetest-game, and luanti-voxelibre into the system profile of my server and tried running luantiserver, but it doesn't seem to find the installed games. `luantiserver --gameid list` returns nothing <jfred>Is there another step I'm missing? <mange>I do have a luanti server, but it turns out it's on my NixOS machine, so it's not much use to us. FWIW, running "guix shell luanti-server luanti-voxelibre -- luantiserver --gameid list" prints mineclone2 and voxelibre. <jfred>Huh, so it does... interesting, I wonder why it doesn't see the games when installed in the system profile then <jfred>oh wait a sec, now it does? maybe I just needed to log out and back in or something <mange>Yeah, you would need to do that for the environment variables to be set in your shell. LUANTI_GAME_PATH and LUANTI_MOD_PATH are set as search paths on the luanti and luanti-server packages. <jfred>this is making me wish there were a guix service to run a luanti server too. way back in the day I tried writing a minetest service for guix but I didn't get very far, I was a lot newer to guix back then though <jfred>maybe I'll give it another try <mange>I don't think it would be *too* hard, but there's some trickiness to getting a service running with the right environment for things like this. I'm not 100% sure of the details, but I'm sure it's possible. You might need your shepherd service to set the LUANTI_GAME_PATH and LUANTI_MOD_PATH manually. <jfred>The thing that I think would be especially nice, and I don't know how hard this is, would be to be able to define configs for multiple worlds as guix configuration. Especially if you could define the mods to use for each as guix packages, because per-world mod config is always kinda annoying in my experience with how many dependences some mods have <hugohugo>how do you all keep track of your branches? I'm trying to become a bit more active contributer to Guix, and now I get my branches all tangled up because I need changes from astro-updates and python-team and some of my own branches (and want to keep up to date with master). Do you all have your own local 'develop' branch or so into which you regularly merge all feature branches you are interested in? Or do you use inferiors for each branch? Is this a common <hugohugo>enough problem to have a canonical approach? <hugohugo>This is a point I love about Guix though, that it is possible to have this problem at all <mgd>Hello. If we find a build is broken either via https://ci.guix.gnu.org/ or just trying to install the package, should we open an issue on Codeberg or something else? <sneek>Welcome back mgd, you have 1 message! <apteryx>phew! /gnu/store/5w522sagfd721avmhixaanqqrli9mg8x-icecat-minimal-140.2.0-gnu1 built <mgd>identity: Thank you. Just to check, what does it mean if an issue is deprecated? That it's not going to be addressed? <apteryx>yeah, icecat 140 runs without my patch <identity>mgd: issues tagged as ‘deprecation’ are about deprecating/removing packages <mgd>identity: Thank you. QGIS and claws-mail seem to be broken. I hope they don't get removed :( <identity>mgd: if upstream is maintained and builds properly, then you could contribute an updated package definition <apoorv569>Can someone look PR #2277 and #2276? Both are PRs fixing a package that is ATM broken on GUIX. #2277 especially is broken for a long time now. <hugohugo>but apparently there is a discussion that claws-mail does not actually need sylpheed <hugohugo>and qgis seems to have a substitute, it installs without problems for me <adanska>anyone know how to use a snippet to append a line to a file? I need to tweak a rust crate's `build.rs` but i dont want to delete the whole thing, just add a cargo link directive to the bottom <kratacoa>Rutherther: a few days ago I asked about how to delete from the store an item that on `guix gc --referrers` refers to itself and is listed as being alive. You asked for a clarification, but I hadn't seen it. <kratacoa>the problem persists, and I have two broken items in the store (with modified hashes), and I failed a system reconfigure this morning with a bunch of empty writes. Unfortunately I can't rollback to a generations before these items were there, as I had deleted them to get space a few weeks ago. I couldn't delete any of that from the earliest one. I also attempted to delete afterwards all of them, and that <kratacoa>also failed to get rid of the "still alive" warning. <kratacoa>Before deleting that, I had tried running `sudo guix daemon --gc-keep-derivations=no` and deleting them that way, to no avail <kratacoa>I'll correct myself: I assume I had empty writes due to "expected [Derive` stuff that ime indicates that, I didn't check as I just ran `guix gc --verify=contents,repair`. I also had a bunch of other corruption, and the new generation didn't appear on reboot <kratacoa>I managed to clean that up, however those two errors from the past persist <hugohugo>adanska: if you figure it out, how to add a line to a file in a snippet without overwriting it, could you please share what you learned? I couldn't figure it out either (but since my file was only like 4 lines long, I simply added the full contents to the snippet) <mgd>hugohugo: cool! I'll need to have a look at how to get that. I <podiki>andreas-e: is world-rebuild in a state where i should rebase mesa-updates on it? i was going to do that gtk ungraft (as well as i think some x-related stuff that needs updates) <andreas-e>podiki: I think it is probably good to go. I have some doubts about i686; there many more packages are shown blocked (that is, by another failing package) than before. For instance by ghc@8.0.2; but the branch has a substitute on CI, so this looks like a problem only on QA. And rust is given as blocking on i686, but when I try to build it for i686 Guix states that it is not supported on i686. <podiki>what were the main updates on world rebuild anyway? <andreas-e>So I will probably merge without taking i686 into account and let things be sorted out after that, if it turns out there are real and not just spurious problems. <podiki>ah that's nice, i haven't looked into milestones yet but that's a good idea <andreas-e>Lots of things that fit nowhere else. Venerable old C projects with lots of dependents, so I do not really expect problems. <podiki>i expect a new mesa point release on the 3rd (based on their calendar) so maybe i'll wait until that day to the rebases and updates <podiki>but the current state is good to go on x86_64 at least from what i saw <andreas-e>Yes, we used milestones for the core-packages team merge, that was quite motivating: People could add an issue when things broke, and one somehow sees progress being made, which is motivating. <andreas-e>I think we still have a few days to go just for building things. <andreas-e>And the emacs-team branch normally comes next, but there is a mysterious problem with the data service not evaluating it. <podiki>yeah i saw a report of that, weird <andreas-e>I hope to be able to merge world-rebuild next week, since I will be on vacation the week after. <podiki>well that works then, ~5 days to the mesa release fits <andreas-e>And python-team also comes before mesa-updates, so no hurry. <andreas-e>I try to package a project which requires to run "autoconf -i"; without the "-i", it complains about a missing install-sh. Do we have a package that provides these? <andreas-e>Hm, autoconf itself; maybe I can run with "-i" without it downloading from the Internet. I will give it a try. <old>what is the easier way for me to get a kernel with different CONFIG_ options? <untrusem> I wanted to ask if connman is stable for you <AidenIsik>Hi, sorry if this is a stupid question, but I can't seem to find the answer. Which module do I need to import to use guix-home-service-type? <AidenIsik>My guess was (gnu home), but that doesn't work <AidenIsik>That is very interesting then, I get an unbound variable error <ieure>AidenIsik, Can you paste your config somewhere? (not in the channel, use a pastebin, see topic) <ieure>AidenIsik, I looked at the code, it's in (gnu services guix). Would you please file a bug for the manual being incorrect? <AidenIsik>Okay, let me try that, and yeah I'll file a bug report if that's wrong, thanks <ieure>Deltafire, Why do you think that's suspect? Where do you see that? <ieure>AidenIsik, Nice. Yeah, manual is definitely confusing. <lfam>Howdy Guix! I'm wondering if there is a way to do line-by-line code review on Codeberg? <lfam>Like, how we used to quote patches and review them in email? <ieure>lfam, Yes, it's built into the review interface. <Rutherther>lfam: yes, though I think it's always only for single lines. Just open the file changes, hover over a line and a plus appears. Then you can either leave a single comment or do a review (multiple commetns) <ieure>Other forges let you select a range, not sure if Codeberg has that yet. <Rutherther>yeah, I don't think it has, or I am just not understanding the UX <ieure>I seem to recall that it doesn't. Would be nice if they added that. <redacted>I'm packaging a Rust app in a custom channel, but the package depends on unexported dependencies in (gnu packages rust-crates). Is invoking them with @@ the best way for me to go about using those dependencies? <redacted>(short of just packaging the app for the Guix official channel) <Rutherther>redacted: no, you're not supposed to use crates from (gnu packages rust-crates) in the first place <Rutherther>why don't you do it properly - by making your own rust-crates in your channel? <redacted>I think I'm confused about something then. Which makes sense, since I'm unfamiliar with rust. <redacted>I've been assuming "rust crates" are libraries like I'm used to, but I don't usually have to repackage libraries that are already packaged somewhere. <redacted>The cookbook gives a workflow, but it assumes you're packaging for the Guix official channel, and it instructs you to update gnu/packages/rust-crates.scm <Rutherther>redacted: the only two differences are that you insert to file under your channel and that then you pass #:module parameter to lookup-cargo-inputs with your channel's module <Rutherther>redacted: there is nothing 'packaged' in rust-crates, it is just collection of sources <Rutherther>and you don't reuse them, or like... not on the level of actually referring to them, of course, if you use the same package version, the same source in store will be used as it will be the same derivation <identity>crates *are* libraries, bug they get built with, and statically linked into, the executable <andreas-e>identity: A Freudian typo :) It looks like a bug for me... <luca>Speaking of the new packaging model, I found it really interesting how the old model only packaged major versions of crates, which meant most rust apps were using as up-to-date crates as it was resonable. The new model seems to take exact dependencies. Are there any particular reasons this change was made? <ieure>luca, Mainly that it was a large maintenance burden to handcraft the N different versions of the same project into individual packages in order to satisfy the exact deps. It was a lesser, but still large burden to tweak dep boundaries to match what was also packaged, and upstream dislikes when distros do this, since it changes the dep profile they expect and can introduce bugs and unexpected behaviors. <luca>Were there ever any actual reported bugs due to this? <Rutherther>it's not just bugs, it is that you can't build it <luca>breaking changes between minor/patch updates that fail compilation? <look>luca: from my experience, if upstream manually chooses to freeze a specific minor version in cargo.toml its most likely because of something that leads to bugs/compilation errors <luca>That's the default though, no? `cargo add X` just points to a specific patch version <Rutherther>luca: well obviously it's not a minor update then, but upstream marked is as one. Nothing stops them from doing that. And there's a lot of crates, so some of them are bound to do it <luca>Sure, and I completely understand that this may be an issue or it's one that guix wants to prevent all toghether. Was just interested if this did actually show up and if so if it was a major hassle. (though it's hard to compare the old and new rust packaging models like that) <ieure>luca, The first point I made, the one I prefixed with "Mainly," the one where packaging anything written in Rust for Guix was a major hassle due to their sprawling dep trees and insistence on specific versions of everything, yes, that happened. Many, many times. <ieure>luca, There was a lot of discussion on guix-dev if you want to get the rationale from primary sources. <look>although I never used cargo myself, the default of 'cargo add X' should be to add the major version as a constraint, not the minor version, no? <luca>`cargo init cargo-test && cd cargo-test && cargo add tokio && cat Cargo.toml | grep tokio` outputs `tokio = "1.47.1"` <ieure>I don't know what cargo's behavior is. <luca>ieure: if you have any links or keywords I'd be interested in reading <ieure>luca, I don't have any sitting around, and search works the same for both of us. <look>luca: now try 'cargo add tokio@1.47.0 && cargo generate-lockfile' and look at Cargo.lock for tokio version <look>it should bump to the latest available semver, which is what we use for packaging the source right now <look>the dependency is not frozen by cargo at all, it needs to have '=' preceding the version for it to be frozen to a specific version <redacted>Rutherther: Ah, it all makes more sense now. Thanks!