IRC channel logs
2025-05-26.log
back to list of logs
<Hamled>meaty: I guess the directory name is the base32 encoding of sha256 of something derived from the remote's URL, so hopefully that path should be consistent across updates and system/userspace guix if you're pulling from channels with the same git URL <apteryx>are the Codeberg notifications supposed to already be focus to our teams? I seem to get notifications for everything that happpens, which is a bit overwhelming. <look>apteryx: you might want to unwatch the repository <ieure>Huh, got a weird one. Noticed the disk was nearly full on my Cuirass box, so I ran `guix gc'. But it deleted a bunch of stuff used by my current home generation, including my SSH key, so I couldn't SSH back in. <ieure>I logged in by ssh'ing in as the build user, then `su -' to get root, then `su - ieure' to get into my account. Then `guix pull' and `guix home reconfigure', but it's still broken. <ieure>I can SSH in now, but stuff is still pretty busted, like, I get "bash: /home/ieure/.guix-home/setup-environment: No such file or directory" <ieure>Which is because ~/.guix-home points to a store item that got gc'd. <ieure>I would have expected `guix home reconfigure' to fix that. <ieure>I guess it has issues if it needs to replace broken symlinks. <ieure>Fixed with `find . -xtype l -print0 | xargs -0 rm' and another `guix home reconfigure'. <apteryx>look: ah, watching the whole repository would do that, I see! Thank you! <apteryx>is our meson build system cross-build ready? <apteryx>it adds a --cross-file argument to 'meson setup' <apteryx>am I supposed to be able to create a PR with: git push origin HEAD:refs/for/master ? <apteryx>it says: ! [remote rejected] HEAD -> refs/for/master (The topic-branch option is not set) <apteryx>it was a tool designed by the inventor of the 'agit-flow', IIUC, to ease its use from the command line <SquircleSpace>Hey folks, I'm having trouble getting Guix to boot on my machine. I installed it onto an external SSD connected via USB. I'm able to successfully boot in a qemu VM when I make the SSD accessible to the VM (using -drive file=/dev/sda,format=raw), but when booting on real hardware it looks like something goes wrong with the connection to the SSD <SquircleSpace>shortly after the root fs is mounted and chroot'd into. The kernel boot logs have "device offline error, dev sda" and then a ton of errors about I/O failing. I'm planning on trying things like installing to an internal drive and trimming down my config.scm to a minimal reproducer, but I'm wondering if anyone here has seen this sort of failure <apteryx>OK, that worked to create a PR on Forgejo/Codeberg: git push origin HEAD:refs/for/master -o topic="add-muon" -o title="Add Muon, Samurai and adjust meson-build-system" <apteryx>what is server error 502 on codeberg? I'm trying to reply with a comment. <apteryx>oh, the whole codeberg is down: "This Codeberg service is currently unavailable due to technical difficulties, maintenance or a service update." <apteryx>I tried to join them on matrix: #codeberg.org:matrix.org, but I got: MatrixError: [403] You do not belong to any of the required rooms/spaces to join this room. <apteryx>I've used it successfully to build p11-kit and pkcs11-provider for example, after tweaking the meson-build-system lightly. <apteryx>how should I quote multiple substitute URLs when using 'GUIX_BUILD_OPTIONS' ? <apteryx>seems the options are broken on spaces, disregarding quoting <podiki>...is it a guile thing where you need more backslashes? <podiki>oh, maybe specify it additional times, one server per <meaty>How can I read the up-to-date documentation on the new rust importer? <meaty>I can't find it in guix/doc/guix.info on the rust-team branch <PotentialUser-88>I have an issue on Guix distro, when I connect using `mosh` I get the XDG_RUNTIME_DIR issue from guix home saying it doesnt exist <PotentialUser-88>while when I use `ssh` I dont get that issue and the directory is created <efraim>I have a suspicion that Guix might need something in ~/.ssh/rc to start various services when connecting over a non-login bash shell but I haven't done the work to see what should be added <efraim>perhaps there's a --ssh config flag you can add to have it count as a login shell? <apteryx>efraim: our bash is built with flags explicitly requesting that .bashrc be sourced for login shells connecting via bash: DEFAULT_PATH_VALUE -> sets a default PATH; STANDARD_UTILS_PATH is also used as a fallback for PATH; NON_INTERACTIVE_LOGIN_SHELLS causes all login shells (even the non-interactive ones) to read the startup files (e.g. ~/.bashrc); SSH_SOURCE_BASHRC ensures that ~/.bashrc is read for SSH logins. <guix-newbie>i'm running a long `guix pull` with long compiles. During this `guix package` does not run because `profile .../guix-profile is locked by another process`. Is it easiest to have another user to develop packages to avoid this? Or is there another way? (--dry-run still wants the lock) <apteryx>in shell.c it looks like it identifies SSH if the SSH_CLIENT or SSH2_CLIENT variables are set. <apteryx>it basically says do: git config push.default upstream && git config branch.local-branch.merge refs/for/main/topic-branch; where I've s/topic-branch/add-muon/ for my case <efraim>I think you should change upstream to whatever you have codeberg set as, for me it's origin <apteryx>'git push' fails with: fatal: The current branch add-muon has no upstream branch. <apteryx>I thought so, but actually the 'man git-config' defines 'upstream' as a value <efraim>i'm also not sure about s/main/master/ and if 'local-branch' is also a special value <apteryx>git config branch.hokus_pocus dummy -> invalid key <guix-newbie>I figured out how to evade the lock when running `guix package`. `guix shell` does not use that lock, so I'm using that now while the `guix pull` is running. <csantosb>Hi ! Anyone found a way to reply to codeberg messages without using the browser ? Fj.el or something ? <apteryx>efraim: it looks like I was wrong about 'local-branch' being a literal for git, it worked only because there was already some 'local-branch' entry in my .git/config file <apteryx>so hm, probably I should have used my local branch name in its place <apteryx>hm, testing this, I've created a 'add-muon' branch on the remote. Not what I wanted. <jlicht>hey guix! Happy day 1 CE (Codeberg Era)! <meaty>when packaging something for the first time, is there a way to tell guix "don't bother look for substitutes for all the new stuff, it's not there" without missing out on substitutes for the packages in the depenency tree that are already build on some server or another <meaty>seems unlikely but worth asking <civodul>but that’s okay: it’s just one extra HTTP request in its pipeline <meaty>civodul: not when the rust package adds 20 new dependencies and one of the substitute servers is spotty... <meaty>at least after the first build (attempt) I can use --no-substitutes <apteryx>weird, agit wants '-o force-push' instead of detecting I pushed with --force <apteryx>haven't been able to convince git to push to a refs/for/master/something yet by default (for a local branch) <apteryx>this works to refresh a PR: 'git push origin HEAD:refs/for/master/add-muon -o force-push' (add-muon is the topic branch name) <meaty>are any of the rust team on right now <meaty>I could use some advice updating my typst patchseries <ruther`>meaty: in case it was just one package you could guix shell -D package to fetch the build deps. But with more its not so easy anymore, yeah <meaty>ruther`: its okay, I got them downloaded eventually <meaty>but now I'm in a wierd spot in the packaging workflow and idk what to do... 'cargo generate-lockfile' errors out partway through cos it can't select a version for one package <meaty>I tried continuing despite that but I think that just leads to an incomplete set of deps being imported, cos now the typst package is missing typst-eval, a pretty important component <meaty>so i wonder what to do now? manually package typst-eval? if so put it where? or perhaps I need to "select" the right version of zip for cargo? if so how? manually package it? <meaty>at least this new workflow is easier to dissect cos the hunks are more disconnected <apteryx>what do we do with the QA 'request for merging' issues now? Continue business as usual, creating these on the guix-patches Debbugs tracker? <cbaines>apteryx, I believe so, the guidance hasn't changed and I think that's what the GCD says to do <civodul>yeah, we can always change it later if/when we have a clearer idea of how to do it <cbaines>so the builds for x86_64-linux should progress a bit <cbaines>this does again highlight the need for QA to do more rigerious testing and provide better feedback about builds <civodul>by “brute-forced”, you mean that you restarted it? <civodul>(there’s a pending patch for this xz-mesboot issue BTW) <cbaines>build coordinator builds can't be restarted, but I did submit 3 more builds for the same derivation after the first 3 attempts failed <ruther`>That is interesting. I was never able to build xz mesboot locally with parallel builds enabled. I tried multiple times <hako>meaty: what's the error? <civodul>ACTION clicks “Unwatch” on guix/guix <civodul>i’m getting way too many notifications currently so something has to be done :-) <efraim>i was wondering what others were doing. I'm getting hundreds of emails <old>I sawo on the ML that the master branch has to be force-pushed. Does this imply anything for end users? Should I avoid doing a pull until the transition is stabilized? <noe>old if you had pulled to a commit that was rewritten in the force push then the pull would block unless you use “--allow-downgrades”. Pretty sure everything else works fine, including guix git authenticate. <old>well I will avoid pulling until Guix become stable again <noe>Ludo activated signed commits only so I think we’re pretty safe now <morsicus>Hello there. I've a quick question, I just started to be interested by Guix and I spotted some tiny typo/issues in the documentation. It seems that the way to go to submit patches is by email but I also see Codeberg pull requests. Which one is the recommended one? Thanks in advance for your time. <noe>Hi morsicus, we just switched to codeberg yesterday! So doing a pull request is best :) <identity>morsicus: you can still send an email patch if you want to, but the email workflow will only be available until the end of the year <noe>If you know of places that still recommend sending mails, you can report that so that its changed to recommend pull requests. <apteryx>ah, we can't reply by email to codeberg comments? <old>hopefuly someone will make a codeberg-mode <tusharhero>morsicus: Please use Codeberg, we switched to Codeberg recently, so the documentation maybe lacking. <noe>apteryx: no, its disabled on codeberg <noe>It’s in forgejo, they need to setup the mail server <sham1>Hmm, apparently forgejo instances are only partially supported by Magit Forge <sham1>That would be very nice to see get mainlined <ekaitz>civodul: how do the teams work in codeberg? I'm getting the emails correctly but I don't know *why* <sham1>Yeah, but like tarsius says, it's not right now. And I fully understand, technical debt is good to pay back <sham1>Patience is the key, I suppose <ekaitz>also i'm sick of this anubis thingie... i cannot open stuff in icecat... thanks AI i guess? <Yappaholic>Hi everyone, I am trying to use nix service in system configuration, but it seems that nix service does not create /nix/var/nix/profiles/per-user/$USER folder, how can I solve it? <sham1>Yeah. Anubis is not really to blame, it's the LLMs scraping the Internet <sham1>And yet when I do it, it's called copyright infringement <ekaitz>sham1: sure! that's llms fault, but I cannot avoid the anubis easily ... <sham1>Yappaholic: you need to create the directory manually <sham1>As per the instructions provided in the info manual <identity>ekaitz: you could fiddle with your user-agent, it ignores you if you do not have "Mozilla" in your user-agent string <sham1>One of these days I'll finally get my act together, and package mdbook and then put up a change to update nix to the current version <Yappaholic>sham1: Manual just says to create a symlink to the ~/.nix-profile and then run nix.sh. Also when creating the folder and trying to use home-manager, it says that /nix/var/nix/profiles/per-user/$USER is not a symlink <andreas-e>Hello ieure, just a quick "thank you", since I think you are behind packaging librewolf. I have just tried it out and it works on a website where both icecat and ungoogled-chromium fail :) (thanks to a patented or whatever video codec, I suppose, but it is much better than my fallback of using an Android phone with Google services). <andreas-e>And it can also replace chromium for buying train tickets, for instance. <sham1>Where you create /nix/var/nix/profiles/per-user/$USER and then chown it to yourself <sham1>Although home-manager not working with that would be weird <Yappaholic>sham1: Oh, didn't know there was a dev manual, the 1.4.0 manual doesn't describe those steps <noe>sham1: packaging mdbook would be very nice, I used it through cargo but that breaks when I update guix <jaadu_>What is the guix equivalent of the package "python-devel"? <andreas-e>We do not separate headers and libraries into two projects. <andreas-e>Well, if I understood your question correctly. What do you need? <jaadu>andreas-e: I need python.h for a python venv. <noe>it’s in the python package, you can check by looking in the path given by guix build python or running guix locate Python.h <demindiro>Hello, I have Guix System installed on a Hetzner server, but it seems to occasionally lock up with the CPU pegged. I can't log in when this happens, so how do I go about debugging this? <identity>demindiro: do system logs have anything suspicious in them? <demindiro>Looking at some of the last entries before it locked up in /var/log/messages I see "linux: [1960390.713434] Out of memory: Killed process 13816 (guix-daemon)" <ruther>demindiro: what is the memory usage of the server? <demindiro>Right now just 119M out of 3.73G, though I suppose it's a lot higher before it locks up <g_bor>My question is would it be possible to do this in a less drastic way that would actually enable us to do this? <g_bor>Having the SOURCE_DATE_EPOCH to be around the time of the last commit would solve issues, not all of which are cosmetic (mainly stuff around checking the age of some things) <civodul>apteryx: did you intend to push the ‘add-muon’ branch? <ruther>demindiro: it is quite an important metric. To know what the memory usage is. Because currently it is not known if it is overloaded memory -> OOM that causes the CPU spike or if the spike has another cause from an external program <csantosb>Ups, dd5cb57, looks like something is going on here <ieure>csantosb, What do you think is going on? <csantosb>Nothing strange in "Merge branch 'csantosb/python-logfury'" ? <csantosb>Sounds weird to me: all "Merge ..." log messages relate to teams; hope not all contributions produce a merge from now on. <g_bor>csantosb: this can be configured on the repository settings, and also on the pull request level as far as I can see. On my personal projects I like to configure this in a way that I don't have merge commits for single commit contributions, but have one for MR with multiple commits. The rationale being is that usually a single MR is something you <g_bor>can revert together, but this you don't need for single commit contribution, there you can just revert the commit. I am not sure what will be the final process here, and this is just from my personal experience. <ngz>Hello. I read that I need to update .git/config file to adapt to new upstream. Is there some documentation about what part should be modified? I suspect it is the [origin] section, but I’d rather not make mistakes. <csantosb>ngz: You need to update the url under your [remote "watever"] <ngz>csantosb: Sure, but to what? <csantosb>I'm using url = git@codeberg.org:guix/guix.git <ngz>Isn’t that the read-only URL? <ngz>I assume that when you want to push something to the repository, you need to specify the username somehow. On previous repository, it was login@git.savannah.gnu.org:/srv/git/guix.git <ngz>I am a bit confused here. <luca>No, on codeberg it knows based on your ssh key. Like gitolite if you've used that <ruther>ngz: nope, that is not how most git forges work. They have just one user and users are resolved by their keys <ngz>I never used a git forge before. <ngz>OK, so I set url to this and I do not touch the "fetch" key? <ngz>It currently is set to "+refs/heads/*:refs/remotes/origin/*" <csantosb>That being said, better setup your .config using git commands <ngz>Oh. Isn’t it the same? <csantosb>Sure, but git commands avoid errors when manually modifying things by yourself <ruther>what could be specific to guix in regards to agit flow? <ngz>No idea. But I would certainly appreciate to know the proper way to submit patches, push some, close bugs, relying as little as possible with the web front-end. <ngz>As I wrote, I never used a git forge, so I wondered if there was some quickstart guide for people like me. <jonsger>cbaines: do you know why bordeaux doesn't have substitutes for zig? On a server I currently don't have IPv4 so I can't fetch from ci.guix.gnu.org... <ngz>ruther: I live in Emacs. <csantosb>ngz: Good news is tarsius, author of magit, uses guix too <ngz>Thanks for this documentation. I guess I need to figure out how to use all of this. I guess I will be more comfortable when Guix will update its "Contributing" part of the manual. <csantosb>I'm following the forgejo.org link using the command line; this is more than enough to start with. <csantosb>Email based workflow is still available until end of the year, by the way <ngz>The link above is about creating pull requests. It doesn’t tell about applying patches locally, or closing bugs (I assume this is only supported using the web interface). <ruther>ngz: no it is not, there is an API <ruther>ngz: as for applying patches locally, you can pull from refs/pull <ruther>you can add +refs/pull/*:refs/remotes/origin/pull/* to the remote.origin.fetch option <ngz>ruther: Ahem. Sorry for being bold, but I don’t get it. I need to use a git command to extend the "fetch" field from [remote "origin"] section. For example, if I want to test, e.g, <https://codeberg.org/guix/guix/pulls/26>, how would I proceed? <ngz>(the third sentence is actually a question) <ruther>well the easiest is to `git fetch origin refs/pull/26/head`, then you have it at FETCH_HEAD. If you wanted to fetch pulls by default, you could use the remote origin fetch, you don't need to do that to fetch from PRs <luca>Personally I like `git fetch origin pull/26/head:branch-name-thing && git checkout branch-name-thing`. Also rebasing helps in case it's a bit of an older PR (which I guess guix doesn't have yet ;) ) <ngz>So you don’t suggest to extend remote.origin.fetch? <ruther>why do you need suggestions? Why don't you just decide on your own? <ngz>ruther: These are odd questions. They probably mean I abused your patience already. Sorry about that. <meaty>if I'm packaging a rust workspace, how do I tell guix that the sources for its packages are inside the workspace repo? Do I need to define packages for each of its components in the repo's ./crates directory <ruther>meaty: this is currently well supported only on rust-team branch <meaty>ruther: I am on the rust-team branch <morsicus>Hey, I'm trying to build the documentation locally but I get the following error: <morsicus>guix.texi:17624: @include: could not find os-config-bare-bones.texi <morsicus>guix.texi:17806: @include: could not find os-config-desktop.texi <morsicus>guix.texi:17813: @include: could not find os-config-lightweight-desktop.texi <morsicus>make: *** [Makefile:5351: doc/guix.info] Error 1 <morsicus>Do you have any idea why? I'm not very familiar with texi files. Maybe I missed something in the setup process <morsicus>`./pre-inst-env make doc/guix.info` and I previously took care of `./configure` <identity>morsicus: next time, please paste the output to a pastebin <ekaitz>hmmm i don't think you need the ./pre-inst-env <ruther>meaty: then it should basically just work, if you want to choose what ones to install you can use cargo-install-paths parameter <morsicus>sorry identity, you are right. It's not very readable/friendly. <ruther>ngz: I don't know, maybe. I guess I am just sensitive to people asking for suggestions rather than looking at the options and deciding for themselves what fits best for their use case. <meaty>ruther: what about #:cargo-package-crates? What's the difference between it and the guix-import generated cargo-inputs <ruther>meaty: cargo-package-crates says which crates to package in the package phase, when you use install-source? <ruther>meaty: it doesn't have anything to do with cargo-inputs or any inputs <ruther>it has to do with what rust source will end up in the output of the package you are building <meaty>ruther: ahh, I see. So it shouldn't be used if you just want the binaries from the workspace <ruther>meaty: yeah, if it's just a binary package, you could set install-source? to #f and then the cargo-package* arguments are basically ignored <meaty>ruther: okay, so I tried both with and without #:cargo-install-paths specification (cos I want all the binaries) and the build of the workspace fails, saying "no matching package (package in repo's ./crates dir)". what's happening then? Why can't it tell that the crate it wants is in the ./crates dir? <ruther>meaty: please send the whole log <ekaitz>morsicus: (i'm trying to build it myself but guix decided to download things and some substitute server is down) <ruther>meaty: where is typst-eval supposed to come from? <ruther>according to unpack phase there is no typst-eval in the source you are using <ruther>but according to unpack you don't really have that in the source you're using <meaty>??? but it's right there... the crates.io listings for typst-eval and co. even point to this same repository <morsicus>ekaitz: arf ^^. It's weird, those files don't exist in the repository. Are they generated on the fly by something? <ruther>what are you actually fetching? the repository or cargo? <ruther>you cannot rely on cargo having the whole workspace, they package just parts, sometimes delete test files etc. <ruther>it's best to just use the git repo <meaty>ruther: ohh, I see. There is the "typst" package that is INSIDE the "typst" workspace repo on github. That must be what the importer retrieved <ruther>meaty: it is not about importer, it is about crates.io having `typst` as just that one package, not the whole workspace <meaty>ruther: yeah that's what I mean <morsicus>ekaitz: Already done but the result is the same. <ekaitz>you are simply running the wrong command <ekaitz>if you want it in pdf is `make pdf` <morsicus>ekaitz: it's weird. The make info is returning the same errors https://paste.debian.net/1376759/. I also followed the documentation and by what I was able to check in the Makefile, the make doc/guix.info looks like what I want. These files "os-config-*" seems to be templates but I don't understand how they are built :/ <ekaitz>let me clean the repo and do it again <ekaitz>morsicus: I cleaned and ./bootstrap && ./configure && make info <ekaitz>morsicus: oh oh I cleaned everything really and now I see the same error <morsicus>ekaitz: are you using a guix shell -C ? Because I'm starting to think that the problem comes from my guix shell. <meaty>is there a way to make guile git-aware? so that I don't have to recompile every time i visit a different branch of guix <meaty>I'm realizing guix can't really compile incrementally either <ekaitz>morsicus: we could bisect for the win <ekaitz>morsicus: could you find some past commit where the build process works? <ekaitz>morsicus: I found it!! you need to `make` first so you can `make info` <JodiJodington>"you need to `make` first so you can `make info`" if only Makefile had a system for specifying dependencies of a step /s <morsicus>ekaitz: Indeed! Sorry I didn't caught that :/ <ekaitz>JodiJodington: let me ask you what are you trying to achieve with that message? <ekaitz>morsicus: on the contrary, thank you for spotting this! this needs some review <JodiJodington>ekaitz: I was being sarcastic, I didn't mean anything by it. Just implying that project's makefile couldve probably had the `info: ` rule depend on whatever it needed so the user didn't need to know they had to run `make` on its own first. I didn't mean to derail anything. <ekaitz>JodiJodington: I understood very well your sarcasm here, i'm just trying to understand why would a person say something like that in a place where people is giving more than their best to make something useful for others <JodiJodington>I did not think much before I said that, I am sorry. I especially didn't mean any harm to the maintainers of the project, it was not supposed to be a jab at them <ekaitz>i have to admit that i thougth the same, but let's try to be a little bit careful here, please <ekaitz>(and thanks for thinking again <3) <ngz>JodiJodington: what about sending a patch to fix this? It not a huge thing, but it still is an improvement. <ekaitz>i was trying to fix it myself but autotools is getting in the way <Tadhgmister>I know I've asked this before but how do I go from <computed-file> -> derivation -> output path as 2 steps not using the magic ,build from the guile repl? <Tadhgmister>I'm trying different combinations of gexp->derivation and build-things (from `(guix store)` ) but I cannot figure out what the magic is <morsicus>ekaitz: are you taking care of opening an issue? <look>meaty: you can do it with git worktrees <ekaitz>morsicus: if you want to give it a go... it's late here and I need to work in other things... <ekaitz>morsicus: if you make a pull request, tag me and I'll review/commit <morsicus>Thanks ekaitz, I'll check-it out probably tomorrow. It's starting to be also late on my side. I really want to thank you for your help and kindness :). <ekaitz>morsicus: nah thank you for pointing this out. It's important that we have people reporting this kind of things 