IRC channel logs
2026-02-22.log
back to list of logs
<apteryx>is anyone else hosting their own IRC bouncer on Guix? <ArneBab>apteryx_: not quite: I’m running a quassel daemon and connecting with quassel client. <nemin>untrusem: Thanks for the heads up about Rust 1.93. I went ahead and updated my PR. <efraim>if anyone is curious about the next part of rust-team, locally I've updated mrustc to the latest commit and I've built rust-bootstrap-1.90 on x86_64 and rust-bootstrap-1.54 and rust-bootstrap-1.74 both failed to build <efraim>so those either need to be fixed or aarch64 and riscv64 need to use a different one <Rutherther>efraim: hmm I thought mrustc works only on x86_64 <efraim>nope, we use it for all the architectures <efraim>rust-bootstrap-1.74 only worked on x86_64, I never got around to writing patches to make it work on aarch64/riscv64 <Lukas>Hello, I am new to packaging, and new to Guix. <Lukas>I have been working on packaging a go project for Guix. I have successfully been able to create a guix.scm file, and was able to run the application. <Lukas>Now, there are some caveats to this, which I am looking for guidance on. <Lukas>1. The package uses git for its functionality. <Lukas> - I am not sure if this should be directly included within the package, or if the user should install it separately? As when running the application without git, it indicates that the git version must be at least 2.32.0, even when git is not installed. I tested this through the use of --container. <Rutherther>efraim: Oh, I see, that must bed the difference I am thinking about <efraim>Lukas: if you paste too many lines at once the bot will silence you for a few seconds <Lukas>okay, sorry about that, I will take note of that. thanks efraim <yelninei>great python-docutils has test failures on hurd because they hardcode a pyhon error expecting ENOENT == 2 <sneek>Welcome back yelninei, you have 1 message! <futurile>Lukas: did you try putting 'git' into your 'inputs'? <yelninei>janneke: I've seen it, SMP will help a low with speeding things up <efraim>often with go a program will shell out to another program, so i'll more likely need to have the binary wrap git (or git-minimal) and not patch '/bin/git' <Lukas>futurile yeah, I had wrote (inputs (append (list git))), into the package, but for some reason git is still not available when running guix shell -f guix.scm --container <nemin>Lukas: What are you using git for? Is it actual functionality of the software or are you just pulling in additional data? <Lukas>okay, i found out that (propogated-inputs (list git)) is required, as these are used for runtime dependencies. now git is available within the container <Lukas>nemin It is the actually functionality of the software, as it cannot run without it <nemin>Ah, alright then, just wanted to make sure. <tusharhero>do mails to help-guix@gnu.org need to be be approved? <Lukas>okay, so it seems that everything is working as intended now when running it, although there was some issues related to the terminal, but i just used --preserve=TERM within the container, and it works now. what is the next stage of me trying to have it within the official guix repo? <tusharhero>I have been trying to post a mail there from yesterday but it doesn't show up on the archive. <identity>tusharhero: first-time emails to anything @gnu.org need to be approved <tusharhero>identity: well I posted to emacs-devel@gnu.org day before yesterday. <tusharhero>I am not even sure if it's an issue with @gnu.org or my email config, I am able to email others fine (they receive it). <efraim>give me a few minutes and I'll release the emails from hold <Lukas>okay, thanks nemin, I will have a look at that <identity>tusharhero: can you see your mail in the emacs-devel archives? if so, it probably was not approved just yet <nemin>but tl;dr: make a fork of the repo, make a branch, commit your package following the right format, open a PR to Codeberg, answer reviewers, win <efraim>tusharhero: ok, I'll drop the duplicates :) <tusharhero>I was scratching my head thinking something was wrong with gnus <efraim>rust-bootstrap-1.90 failed on aarch64, got a TODO comment from mrustc <janneke>yelninei: yes, and especially with the feasibility of using the Hurd as a daily driver <janneke>it makes hardly any sense to try to install a 64bit hurd if you can use only one core :) <janneke>it's not reviewed of merged yet, but /me finds this very exciting! <cbaines>andreas-e, congrats on the Guix Data Service bisect <cbaines>I've just replied but I believe you've found the problem <andreas-e>Well, I did not - you found it! I am reading the email, but do not quite follow. <andreas-e>What is special about fontconfig? That it comes before git in the package graph? <andreas-e>cbaines: This leaves us with KDE now having the same problem... <cbaines>andreas-e, are you sure it's the same problem? The data service log looks very different to me <cbaines>this is the key bit from the kde-team revision processing log: <cbaines>builder for `/gnu/store/a8hp9fq3cq92i1rxlyadacdz00bviy7m-guix-packages-base.drv' failed due to signal 9 (Killed) <Rutherther>if it's about guix eating up all memory due to the cycle, couldn't it be OOMkilled? <andreas-e>cbaines: So why can fontconfig not use git-download, but other packages can? <andreas-e>In kde-team, this looks as if already the equivalent of "guix pull" failed. But I thought that I had tested this already on the branch. <cbaines>andreas-e, I'm unsure, but I would guess fontconfig-minimal is somehow involved in git-minimal <cbaines>guix graph --path claims it's not, assuming I'm giving the right arguments <cbaines>but if you run guix size on the git-minimal derivation, then fontconfig-minimal shows up, so it seems like it's involved <cbaines>regarding kde-team, the QA data service should provide a substitute for this derivation that failed to build, so trying to build it locally might provide some information <Rutherther>"guix graph --path git-minimal --expression="(@ (gnu packages fontutils) fontconfig)"" gives me a path <andreas-e>Rutherther: Every entry in this path is frightening... Are these really minimal dependencies of git? <Rutherther>but it's hard to believe for me that all dependencies of git-minimal currently do not use git <Rutherther>andreas-e: I expect curl is necessary to be able to fetch http(s), whether nghttp2 really needs python, I don't know <andreas-e>I find it easy to believe; git-download is relatively "new", and all these basic packages have been around for ages. Also the dogma of using git-fetch is even newer. <Rutherther>what should we do here, though, 'ban' using git-fetch for git-minimal dependencies? <cbaines>there's a decision about how long to maintain compatability with older guix-daemon's without the git-download builtin builder <cbaines>I'm not sure if that decision has been made <Rutherther>I see. I expect that previously it would've been unacceptable to switch with 1.4.0 not having it then. But now that there's 1.5.0, I think it can be decided otherwise <cbaines>we're definately not in a good place to check for compatability at least, given that issues seem to manifest in the QA data service running out of memory when testing branches <untrusem>is there a way to see the package definition of a package from its command, for example `less` or some command it my own channel <untrusem>I lost its file but the command is still installed in my system, so wanted to look up how it was made 😅 <Rutherther>that is not possible. However if you still have the 'guix' package that produced it, then you will also have the source in the store <Rutherther>and you can then find it by looking at the share/guile of that 'guix' package <andreas-e>cbaines: The guix-packages derivation builds locally for me. One explanation is that the problem manifested itself while I was git bysecting the gnome-team branch, so if this caused an OOM the kde-team branch may have suffered collaterally. Is there a way of restarting the evaluation? <cbaines>andreas-e, the data service can retry, but it's probably easier just to rebase the branch and push <yelninei>ACTION wonders what it would need to get mrustc for x86_64-gnu apart from llvm <efraim>does llvm-21 support x86_64-gnu? <jonsger>ACTION does not understand what pulls in qtdeclarative-6.9.2-debug into it's config.scm... <andreas-e>jonsger: That happens due to grafts. If you need the normal output and this is grafted, then also the other outputs are grafted and then thrown away. I have not understood why this is necessary, but it seems to be a difficult problem. <yelninei>efraim: it should, but building it fails because of conflicts with ED errno <andreas-e>So do not do a "guix gc" for now... Otherwise you will download and redownload qtdeclarative-6.9.2-debug. <jonsger>andreas-e: download was already successfull :) <lilyp>andreas-e: do you see any way we could get rid of python in the closure of git-minimal? <Lukas>Hi, I am packaging a TUI for git, the package is written in golang, i was wondering if it would be better to put the package in version-control.scm or golang-apps.scm? <identity>lang-apps.scm is a relic from the times when everything was written in C, i think. <identity>well, Jujutsu is in rust-apps.scm, so i supposed you should put whatever you are packaging in golang-apps.scm <kestrelwx>I've just seen on the Fediverse that KeepassXC and Bitwarden take LLM contributions, does that make the version that do unsuitable for Guix? <identity>kestrelwx: i think there is a discussion about LLM contributions on guix-devel, but i am not following <Lukas>identity, hmm, that's interesting. I have also see that wezterm is in terminals.scm and not in rust-apps.scm, I guess I can just choose whichever? <andreas-e>lilyp: Probably we should create a curl-minimal package, which does not require nghttp2; or an nghttp2-minimal package which does not require python. <andreas-e>Actually we maybe should do something about nghttp2 anyway. It has python in its native inputs for tests, and should not retain a reference to python. <Lukas>identity gonna stick with version-control.scm, its where I started anyway haha <apteryx>Lukas: historically we've tried to organize things per topo; but these -apps.scm modules seems to go against this, I suppose to make maintenance easier (think teams/file-based scopes). <nemin>Lukas: Honestly, I just figured terminals.scm makes more sense when I packaged Wezterm. I'd personally probably go with the more specific category for easier finding. <identity>apteryx: you could argue either way for teams; do we want teams scoped for what the software is written in, or for what the software does? <Lukas>nemin hahaha that's cool, because I was using your blog on packaging wezterm as a guide. thanks for the help :] <futurile>apteryx: intersting, I thought it was about keeping interdependency between modules down <Lukas>apteryx yeah, I will stick to version-control.scm, thanks <apteryx>identity: currently it's more of the former, and it's easier to be that way (some people are good at go, others at rust, etc.). <fhang>Hello all, what is the stance for downgrading packages? <apteryx>you'd need a pretty good reason explained in the source as a comment <Lukas>only thing about language based groupings, is if you have a package that is written in multiple languages, say kitty, which is written in C, Python, and Go, which makes more sense to group the package based on what the end product is, rather than what it's built by <fhang>apteryx: Ok, I'll make a PR soon to downgrade Qtile. <apteryx>fhang: also, others options like upgrading other packages should be considered first, I'd say. <apteryx>unless that's a ton of work for some reason <apteryx>futurile: topo as in topography, or just topic <fhang>apteryx: Guix has the latest version of Qtile, at 0.34.1. The problem is that version dropped support for Python 3.11, the current Python version in Guix. Qtile crashes at runtime because of this; I have opened an issue about it here: https://codeberg.org/guix/guix/issues/5974 <fhang>The solution is to either wait for Python 3.12 in Guix, or downgrade Qtile. <apteryx>that's a good reason to revert the version bump :-). Could leave a TODO: Update when Python is upgraded to X. <fhang>kestrelwx: I have not tested on python-team branch. <yelninei>janneke: For gnumach debian has a 1.8+git20260129 tag which is not on savannah (yet?) <Lukas>i was running the new package that i added, and there is an issues where there needs to be an environment variable: export TERM=term-256color <Lukas>this happens when i run it within the guix shell, is this an issue, or is it okay since the user would most likely have that already setup? <futurile>Lukas: normal guix shell retains TERM; and for `guix shell container` you can keep hold of env variables you want <janneke>yelninei: that seems so; please ping youpi about that <Lukas>hi, i was wondering what is a better practice for packaging. the package is on github, and it uses releases. <Lukas>so far i have been using url-fetch, but would it be better to use git-fetch? the main thing about git-fetch, is that i am not aware how can i can just specify the version, i have only seen that you can use the commit. should i just use the same commit for the release version in this case? or should i just stick to url-fetch, and use the github <bjc>anyone here used the hurd disk image and knows the qemu arguments to make it work? when i try to start it, it doesn't probe wd0 for some reason <bjc>i assume it needs some kind of kernel arguments, but i'm not sure what they'd be <bjc>actually let me verify <kestrelwx>Lukas: You should use `git-fetch`, you just need to specify the release tag in the `commit` field. I think Github tarballs are not reproducible too, but I can't remember where I've learned that. <kestrelwx>`guix edit keyd` for example if the releases are tagged with a 'v' followed by a version number. <fhang>Lukas: I think the preference is to use `git-fetch`. The reason given to me was that using `url-fetch` to get the source archive was not reliable; Github produces zip archives can change in the future, causing a hash mismatch in the build. <bjc>yelninei: it doesn't actually say. just that it's 'qcow2' format <Lukas>kestrelwx fhang you are right, github tarballs are not reproducible, as i has having errors when running guix lint <bjc>yelninei: i'm able to start grub, which boots the kernel, though, with kvm, so i'm gonna continue assuming it's x86-64 =) <bjc>problem is that the kernel isn't able to mount the ext2 fs because wd0 isn't found <bjc>istr needing to put something in there to start rumpkernel, but i can't remember what it is <bjc>ACTION . o O (rumpdisk?) <yelninei>bjc: Does it work with "noide", but i am a bit confused because that should be a 32bit image and should not need rump <bjc>i added 'noide' to the first multiboot option, right before the 'root=' parameter, and now it's complaining about hd0 not being available <yelninei>ACTION is actually not sure how the image is produced <bjc>ok. i'll keep banging on it <yelninei>janneke: For %hurd64-default-operating-system should it set noide? It only changes %hurd64-default-operating-system-kernel which is a noop <bjc>it needs 'noide' and you need to change 'hd0' to 'wd0' <yelninei>janneke: Do you remember what the 'patch-compat phase in gnumach-headers-boot0 is working around? <avigatori>Can I associate a profile with my user so that it become the default profile for it? <nmeum>Would someone with rust packaging experience be interested in reviewing https://codeberg.org/guix/guix/pulls/4551 ? I've been rebasing this constantly to resolve merge conflicts in rust-crates.scm but so far haven't received feedback from a rust person so far <nemin>Don't let me stop you, I just caught the newer Rust version thing :) <nemin>(Not to mention, I can't approve nor request changes.) <untrusem>I am not in the rust-team as well but can suggest changes <untrusem>and i guess that would be the only change i would request <yelninei>"Add 'patch-compat' phase to allow building hurd-minimal etc, withour out-of-date bootstsrap binaries" The binaries did not change but this seems to work now? <Guest98>I have the same Guix system/home configuration for multiple machines. VMs in aarch64,x86 as well as a physical machine. I configured the home dir as a nfs share, since I don't want to lose my data if my laptop get's stolen or breaks. My question would be, since I can't abstract hardware, would that simply work or can I get issues with it? <futurile>for the VM's that are on the same machine you could use p9 or virtiofs for the /home mount <Guest98>identity: For example, gpu drivers and therefore monitor settings. Maybe software does detect the monitor and write it down in the home directory, though if I now login with a different machine there is a mismatch <bjc>ah dang, 'guix pull' segfaulted in hurd <Wurt>I want to maintain certain packages. How can I subscribe (via RSS or email) to receive failed build notifications from Cuirass? <janneke>[arguments]: Add 'patch-compat' phase to allow building hurd-minimal etc, with <janneke>our out-of-date bootstsrap binaries. <janneke>so i guess there was either a type-mismatch or function declaration mis-match betweeen headers of the bootstrap-binaries and new sources <janneke>yelninei: most likely that can be dropped with new bootstrap binaries! <janneke>yelninei: ah, you already dropped it i see; good! <Guest98>How does pinning in Guix work? Currently I assume, I would run guix describe to create a "channels.scm" file and add it to the repository. Now I would always run guix pull ---channels.. and after guix system rec..., is that correct? How would I update the channels.scm, by just running guix describe again in the future? <yelninei>janneke: I am rebuilding with the new gnumach tag and compat phase removed, the i586 bootstrap did not change in between the commit and now but i dont seem to have any problems (yet) <futurile>Guest98: you can also use time-machine to make sure that a channels.scm file works <nmeum>untrusem: just resolved nemin's comments in the pimsync PR. if you have something to add let me know :) <untrusem>nmeum: I don't have anything other to add <untrusem>being in rust-team must have a requirement that you have a resourceful machine to compile stuff all the time 😛 <nmeum>guix-cuirass-bot will also build it at some point, though there will likely be merge conflicts in rust-crates.scm by the time it has built it succesfully <ieure>Ugh, did the glibc vuln mentioned in news mean a glibc was grafted? Tons and tons of grafts when pulling now. <identity>d659fe8666c4bc38fcbdbe7b7a35101f2d7cc41b: gnu: glibc: Graft with fix for unsafe env variable [security-fixes]. <avigatori>how do you people organize your guix config files? <Wurt>avigatori, I use an org file. <ieure>avigatori, I have a dotfiles repo with one system/hostname.scm file for each machine, and a single home.scm that applies different bits of config based on the hostname. <Wurt>avigatori, yep. I produce one large file per computer. <identity>everything goes into a single guix-config/configuration.scm, which has both a home and system configuration; configuration files for other programs go in the same directories as they would go into .config/, so e.g. .config/mako/config goes into guix-config/mako/config <identity>i have a configuration for only one machine <avigatori>identity: do you use guix home to symlink those configs or do you do this manually? <trev>avigatori: i have my own module with sub modules - files, home, manifests, packages, services, systems <identity>avigatori: i use ‘home-xdg-configuration-service-type’ <seres_>hello, i tried using easyeffects, and while it started properly, adding an effect would freeze it and it would complain about something related to dconf, which i fixed by installing dconf, and i would expect such a dependency to be installed automatically. i'm super new to guix, maybe i missed something, but is this expected? <futurile>seres_: yes, it's somewhat expected. It's a bit of a hazy line. So Guix packages that 'rely' on a library retain a reference to it. But if something uses a 'service' (overloaded term) or a 'command' then it often you'll have to install it. <futurile>seres_: so say you installed 'git' and were using 'gnupg' for signatures, you'd have to know that and install it yourself <futurile>seres_: I guess in this case easyeffects uses dconf means it depends on gnome - maybe it's possible to use it without the full gnome stack so the packager decided not to do it <futurile>seres_: yup, it's a hazy line. The main reason it happens is either (a) the packager didn't know (so it's an error) or (b) the packager was trying to keep the dependency graph low <futurile>seres_: if you think it's an error you could try and look at the package and/or open an issue. If you're new to Guix I'd write yourself a note and come back to it in 3 months to see if you think it's a mistake then <kat>man i feel bad for that guy who gets near constant highlights in here <seres_>futurile: i think i'm gonna write myself a note yeah. thank you! <futurile>seres_: no worries - hope you're having fun with Guix so far! <seres_>futurile: i'm really liking it so far, i come from nix and having an actual programming language i can write software with helps in learning how to express things in my config, and actually learning Guile is my main focus right now <untrusem>avigatori, I use a org-literate config for both home and system <untrusem>its little outdated but can give you an idea <avigatori>seres_: how do you like guile so far? what do you use to write it? <seres_>avigatori: i haven't writtten much guile except my config and 1-2 packages, and i'm not even sure what little project i could use it for. i'm mostly reading documentation right now, i started playing with the web server module a little. it's my first LISP language too, i have a lot to learn. i use neovim to write code in general <hunter>Hello, how can I cross-compile with GCC targeting RiscV? I don't see any riscv64 packages like on Debian but seeing as Guix can cross-compile packages it must be available. <ekaitz>hunter: with GCC manually or a guix package? <ekaitz>hunter: `guix show gcc-cross-riscv64-linux-gnu-toolchain` <hunter>ekaitz With GCC manually as you would on e.g. Debian. <ekaitz>oh i think i have an inferior or something <ekaitz>now you have to make them with a function <ekaitz>hunter: read the end of gnu/commencement/cross-base.scm <hunter>Ah so they're not explicitly provided. Okay, thank you.