IRC channel logs
2025-08-30.log
back to list of logs
<untrusem>how do you folks test building pakages, I tried in my cloned guix repo, with `-L .` but it just gives me `wrong number of arguments error` after running for 5 min <untrusem>I did the `./bootstrap` `./configure` part, am using the ./pre-inst-env scrips <untrusem>I don't think I am doing anything extra here <Rutherther>untrusem: wrong number of arguments has to come from something it evaluates, like your package then. If you do not want to wait for 5 minutes for every evaluation, run "make", ie. "make -j12". The compilation takes a lot of time though. <untrusem>I will let it run then, why its normal btw? <untrusem>Rutherther: so make compiles all the files for speeding up the lookup? <Rutherther>untrusem: no, compilation speeds up evaluation. Only what you change will then be evaluated from source <untrusem>So I am trying to package, oniux, https://gitlab.torproject.org/tpo/core/oniux , a rust program which is not available in crates yet, I checked the cargo.toml it depends on onion-tunnel and smoltcp which points to git repos, so do I need to package those too, I don't see workspace dependencies, How I can integrate them? , here is the error and package defination https://bpa.st/DIFQ <Rutherther>untrusem: no, with the new packaging models, crate dependencies are not packaged. You just import their sources from the cargo.lock <Rutherther>even git repos should be handled as far as I know <untrusem>Rutherther: yes I ran, cargo genererate-lockfile is the source <untrusem>also this, guix import --insert=../rust-crates.scm crate --lockfile=Cargo.lock oniux <Rutherther>ah, onion-tunnel comes from a workspace, so then yes, you need to package it <untrusem>yeah thought so, though the cargo.lock doesn't mention it <untrusem>I would need to package smoltcp also then <untrusem>Rutherther: wait do i package onionmasq or rust-tunnel? <Rutherther>untrusem: you package the workspace and ensure at least onion-tunnel is packaged, you can package other packages there if you want or if they are necessary for onion-tunnel <nalaginrut>hi folks, I switched to codeberg, but here's the error: <nalaginrut>guix pull: error: Git error: cannot locate remote-tracking branch 'origin/super-hacks' <Rutherther>it is ready, but there is no branch called 'super-hacks' that you're trying to pull from <nalaginrut>Rutherther: I didn't specify it, I just "guix pull" <nalaginrut>oops, it's specified in channel.scm, I just copy-paste <untrusem>its the main one, it will automatically redirect to codeberg <Rutherther>oh wait you didn't mean the module you import crates to, sorry <Rutherther>oh no, you really did edit it, you added reference to rust-sources... don't do that... leave rust-crates generated as is <nalaginrut>Rutherther: can I use your snippet and modify it to codeberg? I guess it's redirected to codeberg <nalaginrut>untrusem: can I use your snippet and modify it to codeberg? I guess it's redirected to codeberg <untrusem>nalaginrut, yeah, you can though you can just use it as it <identity>nalaginrut: after the pull, the default channel configuration (‘%default-channels’) should point to <https://git.guix.gnu.org/guix.git>, which redirects to codeberg, so after updating you should not need to mess with channels.scm, apart from setting up any other channels you might be interested in <untrusem>(info "(guix-cookbook)Cargo Workspaces and Development Snapshots") <nalaginrut>untrusem: guix pull: error: Git error: cannot redirect from 'git.guix.gnu.org' to 'codeberg.org' <untrusem>strange, can your access codeberg.org in a browser? <identity>i think somebody reported the same error semi-recently, might help looking through channel logs <Rutherther>untrusem: okay. Strange. I cannot do anything with that error without a stacktrace though <nalaginrut>guix pull: error: fport_write: Connection reset by peer <Rutherther>untrusem: and you definitely don't want to use cargo-inputs without a module specified in the rust-sources as that will point to guix rust-crates, not the one in your channel <untrusem>yeah, I changed that to my own, still the same error <ColdSideOfPillow>For some reason, adding the snippet of code related to LibreOffice causes an error <untrusem>it was by attellia, they asked about the error you had <untrusem>nalaginrut, this error ` Git error: cannot redirect from` <Rutherther>untrusem: does guix repl applied to rust-crates module spit out any errors? <nalaginrut>untrusem: anyway, I modify it to codeberg directly, but it encounters reset error <identity>ColdSideOfPillow: ‘home-xdg-configuration-files-service-type’ accepts file-like objects, and ‘origin’ are not that; not sure why it trips over an #<unspecified> <untrusem>> untrusem: does guix repl applied to rust-crates module spit out any errors? <untrusem>I haven't used the repl, how will I check it? <Rutherther>untrusem: "guix repl -L . ./path/to/cargo-crates.scm"... <nalaginrut>guix pull: error: fport_write: Connection reset by peer <Rutherther>nalaginrut: savannah is not really stable, so better to pull from codeberg <nalaginrut>Rutherther: I pulled from codeberg, the same error <Rutherther>nalaginrut: then it seems your connection is somehow unstable <Rutherther>or does it happen right after you execute pull? I assumed it does something for a bit and then errors <nalaginrut>it's interesting, I cloned guix to local directory, and pull from it, still connection reset by peer <Rutherther>nalaginrut: how are you pulling from it? How do your substitute urls look like? <nalaginrut> "BBB0 2DDF 2CEA F6A8 0D1D E643 A2A0 6DF2 A33A 54FA"))))) <untrusem>nalaginrut, please use a pastebin for snippets <untrusem>your client it smart thought sends new lines after some time <Rutherther>untrusem: and rust-sources.scm also without errors? <untrusem>I should delete the cache ant try again? <untrusem>nalaginrut, are your specfying the channel file with `-C` flags or is it located in ~/.config/guix/channels.scm <Rutherther>untrusem: and if you evaluate "(@ (rain-and-roses packages rust-crates) lookup-cargo-inputs)" inside "guix repl -L .", does it show an error? <untrusem>error: lookup-cargo-inputs: unbound variable <untrusem>nalaginrut, sorry I think its related to your network then, I am not entirely sure <Rutherther>untrusem: and if you remove the use-module of rust-sources + revert the changes you did manually, then execute the same thing in repl? <Rutherther>untrusem: okay, so it seems to me the issue is cyclic module dependencies here and that the cookbook didn't take this into account <ColdSideOfPillow>Also, is there any reason `home-xdg-configuration-files-service-type' (and by extension, `home-files-service-type') doesn't use association lists? <Rutherther>untrusem: your rust-sources refers to rust-crates and rust-crates refers to rust-sources. Even though the inputs field is thunked, something is evaluating it too early it seems, possibly the toplevel reference in rust-crates, I don't know <untrusem>Rutherther, ok now I am getting some different error, btw I wanted to know to package rust-tunnel will I need to do that `cargo generate-lockfile` and `guix import ../crates.scm .....` procedure again? <untrusem>the reason I ask this because I am getting <untrusem>guix build: warning: no Cargo inputs available for 'rust-onion-tunnel-0.9.1.8f727d9' <Rutherther>untrusem: yes you need to do the same procedure when packaging the workspace <Rutherther>kratacoa_: I am still confused what paths you're trying to remove as first you mentioned you're deleting a profile, but then you mentioned empty .drv files and that you tried to remove them with --gc-keep-derivations=no (which would be the correct approach, yes) <Rutherther>kratacoa_: can you send the paths you're trying to remove and what guix gc --referrers on each of them returns on some paste site? <kratacoa_>Rutherther: I had those empty .drv files after a failed reconfigure, now deleted and I've done a reconfigure since which was succesful. I was providing additional context in case they were useful cues, sorry if I had confused you <kratacoa_>the contents of this profile are related to elogind and it does appear in `guix gc --list-busy`, hm. How can I force that to be rebuilt? <Rutherther>kratacoa_: okay, so that means one path in "guix gc --list-roots" should point to that profile, can you find it? <kratacoa_>Rutherther: this command gives me nothing: guix gc --list-roots | xargs -I {} find -L "{}" -type d -iname "5k5qk*" -print <kratacoa_>this is the output for what you really asked tho lol <Rutherther>kratacoa_: I don't think that command should print anything. You need to be looking at the realpath of the path, not at the path itself. It shows you where the gc roots are, not what they point to <kratacoa_>Rutherther: fair point. This is what I get now following your advice: <kratacoa_>guix gc --list-roots | xargs -I {} sh -c "printf '{} ->' && realpath {}"| grep -i 5k5qk <kratacoa_>/home/kratacoa/.cache/guix/profiles/bjy5dkuteqddpkvkkzbz3fvqiodcucwgcjq262yefvuetcqytu2q ->/gnu/store/5k5qk1z7frqvvziprlcwbj8p6j87qkj3-profile <Rutherther>kratacoa_: okay, so it's a profile cached by guix shell, you should be safe to just remove this path and then guix gc will remove the store path <kratacoa_>Rutherther: where can I find info about this in the docs? looking for .cache/guix/profile in the docs returns nothing <Rutherther>kratacoa_: I don't think this is documented much, apart from a few clauses that say guix shell caches <kratacoa_>Rutherther: uhm, I deleted the path from ~/.cache/guix/profiles, but it still is not letting me delete the profile from the store <kratacoa_>ok, running `guix gc --verify=contents,repair` seems to have fixed that. Another run of `guix gc --verify=contents` returns nothing <nmeum>anyone using Guix with LUKS2? I know its not supported by GRUB but in theory it should be possible to have an unencrypted /boot and use some kind of derivation which copies kernel+initramfs from /gnu to /boot and unlocks the encrypted / LUKS 2 volume from the initramfs. has anyone implemented that yet for Guix? <fnat>Is there any (semi-)official Guix Docker image anywhere that can be used e.g. for CI/CD pipelines? <PotentialUser-8>is it worth switching from nixos to guixsd? especially to use it inside of wsl? <luca>Personally I'd make a docker image myself using guix with the packages needed to do what needs to be done in CI/CD <luca>and that image probably needs to be made in CI on debian or something <identity>PotentialUser-8: depends entirely on what you would consider big differences. Guix is mostly written in Guile Scheme, including configuration, which sounds like a big difference to me <ColdSideOfPillow>PotentialUser-8: I used to use NixOS before switching to Guix system, I think I can answer your question! <ColdSideOfPillow>- Guix has much better documentation. It's somewhat lacking in quantity (compared to NixOS), but it makes up for that in quality. <ColdSideOfPillow>Unlike NixOS, Guix documentation isn't scattered among thirty-seven different sites and doesn't have two somewhat conflicting paridigms (flakes vs legacy) <les>s/subjective/objective/i <identity>stuff is not ‘legacy’ until flakes stop being an experimental feature (read: never) <ColdSideOfPillow>Officially, flakes are experimental. But in the real world, flakes are used almost everywhere and the development is frozen on them because the NixOS team doesn't want to break setups <identity>“a drop in the ocean” is an overblown way to describe 1/3 to 1/5 of the size of the repositories, and the size of the repositories does not matter if the software you use is packaged, and on average it is, even with smaller repositories than Guix's <ColdSideOfPillow>identity: I didn't know the actual size, just sometimes felt that the repos were lacking. <identity>almost every time i felt that way, a commit adding the package mysteriously appeared on master… <Rutherther>identity: careful, you seem to be watched by someone then :) <identity>if they keep submitting issues and patches instead of me, then thanks and keep up the good work! <ColdSideOfPillow>identity: hahaha it has happened twice so far that was I'm packaging something/planning to package it, and I see that a PR had been sumbitted for it <Deltafire>if you need it to pause at the end of each screen, you can't read fast enough ;) <Deltafire>and i haven't changed it, so must be default <identity>ColdSideOfPillow: the current discussion in #emacs might shed some light: <identity> “you probably want to set ‘comint-pager’ to "cat", as is the case on master” and “(info "(eshell) Variables") says: “‘$PAGER’ […] indicates the pager […] Its value is that of ‘comint-pager’ if non-‘nil’”” <ColdSideOfPillow>My problem occurs not only on Eshell, but on Bash, ZSH, and Nushell as well <Deltafire>i don't see anything in src/guix that would set PAGER to cat (apart from in a couple of package build scripts <identity>by default, outside of emacs, $PAGER should be ‘less’, not idea why it is ‘cat’ for you, assuming you did not configure it to be as such <ColdSideOfPillow>identity: It has been `cat' since the moment I first installed Guix System <csantosb>Do we have a way to `./pre-inst-env guix build -P1 pkg1 pkg2`, where P1 applies to both, not just to pkg1 ? <ekaitz>csantosb: can't you -P1 pkg1 -P1 pkg2?