IRC channel logs
2025-06-01.log
back to list of logs
<Yappaholic>podiki: I am not sure about every dependent package, but for me grafting xorg, window managers and wayland compositors with xkeyboard-config@2.44 gives no issues <podiki>I think it is mostly just data so I think it should be mostly okay, maybe people's configs will need updating though <podiki>There should be decent x86-64 substitute coverage by now too <Yappaholic>podiki: Yeah, it's mostly xkb configuration files, it will be fine <Yappaholic>I got into configuring sway with home-manager and I gotta ask, what branch is responsible for updating home services? <Yappaholic>Not that it's bad, I just miss a couple of features that nix's sway configuration system has. <podiki>branches are mainly used for packages that have lots of dependents or complicated updates (where you need to do a whole lot at the same time) <podiki>ACTION runs off for now, have fun! <Yappaholic>Oh well, that would be awesome if I have enough brain capacity to understand and implement those features in scheme, but maybe opening an issue first would be easier :) <Hamled>In the manual (section 8.2) there is an example of defining a package, and it has this line in the package record definition `(arguments '(#:configure-flags '("--enable-silent-rules")))` what is the reason for the nested quote on the list with "--enable-silent-rules" ? <Hamled>oh okay, i guess that form gets evaluated during the build process? <SquircleSpace>Other than "no one has updated the package yet" is there a reason guix doesn't have emacs 30.1? <apteryx>oh, I need a git with lfs support: Forgejo requires git with lfs support to run tests; isn't our git built with this? <SquircleSpace>git lfs is an extension to git that adds support for large files (Large File Storage) that are stored outside the git repo <meaty>what would be the best way to implement a shared, generalized "install-completions" phase? <meaty>a quick grep shows the phase is implemented 30 times in the codebase <meaty>naively, I think it could be a function in (guix build utils), but maybe it could instead be a whole "phase" kept somewhere? <meaty>like "(add-after 'install #$(install-completions arg1 arg2...))" <meaty>Also does anyone know a good way to grep for whole s-expressions <meaty>nvm, used indentation to match <meaty>ok linux, just after I sent my last message, my system locked up (no vterm, no ssh) and my motherboard's DRAM light came on. I tried restarting and the POST stopped at the dram phase again... then I tried again after a minute or to and it started right up and now I'm here. how can I troubleshoot this? <meaty>This happened yesterday, too, when I was afk, I came back to a dark screen and the DRAM light on <ruther>sneek: later tell SquircleSpace, yes, emacs is already updated on emacs-team branch. So the reason is that there are branches before it in queue that are waiting to be built by QA <ruther>meaty: best way to implement a shared phase is to make a build script that you import in the modules, that is what all build systems are doing, they have gnu/build/xyz-build-system.scm that have the phases defined. Those modules are then used at the daemon <ruther>meaty: it is not possible to do #$(install-completions ...). That will execute install completions at the 'evaluation' side, you cannot pass a whole procedure through, and even if you could, you would not have its dependencies, that is why modules are used. <meaty>ruther: so... perhaps implement it as a phase in the root gnu-build-system (if that is the "root") which does nothing unless you provide arguments to, e.g. a #:install-completions-args build argument? <meaty>ruther: or is it possible to have a "pre-made" phase with parameters that can be put into modify-phases <meaty>but isn't used automatically? <ruther>meaty: of course it is possible, phases are just functions, you reference a function from a different module. All standard phases are those functions from different modules. <ruther>meaty: submitting something to gnu-build-system is a world rebuild, so I doubt it would get accepted unless it was a phase that is used a lot <meaty>ruther: aha, right. So one could do `(add-after 'install 'install-completions (install-completions args))` where (install-completions args) is a function that returns the desired build phase function? <meaty>ruther: re: world rebuild, so it would be better to add this hypothetical function to (guix build utils) perhaps? <ruther>meaty: that is syntactically invalid. It would be (add-after 'install 'install-completions install-completions). If you wanted to modify the arguments you would have to make a new lambda here and call the function inside of it <ruther>meaty: guix build utils is even bigger world rebuild than gnu-build-system <meaty>ruther: dang. where could it go then? <ruther>meaty: I don't know, a new module perhaps <meaty>iirc, there is also a delete-all-but procedure that is copied around the codebase a few times <meaty>re: module, how does (guix build shortcuts) sound? <meaty>delete-all-but appears roughly 26 times <meaty>install-completion phases make up 471 lines (including data that would be arguments), delete-all-but re-definitions (near-identical) make up 168... but of course, it's hard to really quantify the benefit of de-duplicating this kind of thing. idk, maybe centralizing these would be a world rebuild (or a redundant phase name) for no reason <meaty>anyone know any other candidates for de-duplication? <xelxebar>What's going on when we see an endless stream of "substitute: looking for substitutes on ..."? <meaty>ruther: what about #~(modify-phases %standard-phases (add-after 'install 'install-completions #$(install-completions ...)))? Where (install-completions ...) is evaluated before build time and generates, returns the desired procedure to be run at build time? or am I getting my gexp parity mixed up <meaty>good to see that it isn't just me though <ruther>meaty: I am not sure. Maybe it could work if it is quoted right <xelxebar>meaty: Oh, nice. Thanks for reporting! This has been bugging me for a good while. <meaty>xelxebar: No problem! if you have a codeberg account, please chime in so we know other people experience this too <xelxebar>BTW, if this is a progress bar, it's seriously defunct comared to the other progress bars we see elsewhere, like during build steps. <xelxebar>Rather, when everything works well, it's a percentage indicator. <meaty>the ui is a bit rough in general imo. one of the first things I noticed is that the progress bar that appears for downloads doesn't resize itself when you resize the console, so if you narrow your console at any point it fills your scrollback buffer with junk <meaty>actually, if the name for the download is too long (which is common) it does it right at the start <xelxebar>Yeah, and there are other issues when your locale is some CJK language, as well. <xelxebar>BTW, we should probably be a bit careful posting about unspeakable-channel on the official channels. I suspect it's substitute server might be surfacing a bug on our side. <meaty>I wonder if guix uses such rudimentary TUI tech for legacy/low-resource support? I always thought the download bar thing was because polling the terminal width would might take up too much resources for such a base-level function <luca>I think guix's CLI is actually pretty neat. No confirm options and pretty good stdout output. I've only grown to appreciate it more with time <xelxebar>meaty: You can always pipe output to cat to see how progs behave when $(tty) is false: e.g. guix build hello | cat. <xelxebar>In this case, I don't think we're doing the right thing. <mra>ooh, i need to check out fj.el. how have people who have been using it found it? it looks quite neat <evilsetg>Hi guix, I am trying to package something, right now reformating from the old to the new input style but I am stuck at one question. How does the new input style handle multiple inputs that are outputs of the same package? In the package that I am building they get the same key in the `build-inputs` alist of the builder. Having duplicate keys in the `build-inputs` seems to be trouble. How do I solve that in the new input style? <csantosb>Ey, just discovered this, 6.4 Customizing the System-Wide Guix, for building a system image including guix-science channel; however, what about substitutes ? I'm thinking about guix.bordeaux.inria.fr. <ruther>csantosb: Getting Substitutes from Other Servers <csantosb>Ok, so this is it: I have a system image with guix-science channel and guix.bordeaux.inria.fr substitute <csantosb>Is there a way to put this into the system.scm file ? <luca>In particular `authorized-keys` and `substitute-urls` <csantosb>The key.pub is used solely during image build, I guess ? <luca>ACTION is not qualified to answer <intermet>Hi there! I want to share the host DISPLAY and xorg server with a guix system container? Any idea on how to do that? For a shell container we would just presever DISPLAY and XAUTHORITY but there is not such option for system containers. <csantosb>luca, ruther, works like a charm, thanks ! (including guix-science in sourcehut guix image) <ruther>intermet: preserve means to set the env var to same value as in the base system. Don't also forget to share the socket file, otherwise there is nowhere to connect to with the env var. <intermet>ruther: thank you! so it is enough to share the /tmp/.X11-unix/X0? <ruther>intermet: also $XAUTHORITY if it is set <potatoespotatoes>can i just install guixsd from any OS's live image if that image has guix? <andreas-e>Hello! I cannot push to the master branch at codeberg, but obtain the following error message: <andreas-e>remote: Forgejo: branch master is protected from unverified commit 3f695db271d8b99dfd0f65e4436a6fd1ed9ec7a0 <andreas-e> ! [remote rejected] master -> master (pre-receive hook declined) <andreas-e>Does it ring a bell? The commit is correctly signed with my gpg key. <hako>have you added your key to Codeberg? <andreas-e>Probably not... It is in the keyring branch, but that is not enough? <hako>Yes, currently it relies on Codeberg's account it seems. <hako>The repo is set to reject unsigned commits, and Codeberg only knows the key set in account settings <andreas-e>But not very convenient. The form does not seem to accept a file, but one needs to copy-paste the key, and I do not see how to export it without its signatures. <podiki>what has been up with berlin cuirass web front end, takes like 10 tries to not get a 504 gateway timeout error these days <podiki>but i noticed when serving files like a log it is fine usually <podiki>also, evaluations keep failing with missing files <ruther>ieure: guix describe -f channels has nothing to do with what guix pull pulls, how does your channels.scm file look like? <ruther>podiki: hm, how do the errors for evaluation with missing files look like? <ieure>ruther, Hmmm, it's wrong there as well. Alright <podiki>saw it on master last few days at least too <ieure>ruther, Okay, I see, I search & replaced "guix/" in some of my files and it hosed that URL. <xFFFC0000>oh, nvm, I just saw it is `HTTP download failed: 500` <podiki>and why using just one specific server from the build farm? <xFFFC0000>podiki: connection issue. that was one of the fast servers. although I am keep getting 500 from it <xFFFC0000>where can I get list of servers/urls I can use for substitute-urls ? any list available? <podiki>all the hyrda ones are in the same physical space <ruther>podiki: hmm, that's interesting, seems a bit like store corruption? <podiki>but anyway, generally if seeing a network issue just retry as it can be flaky. maybe if you are just specifying one it doesn't have what you are looking for too <podiki>ruther: yeah i don't know, maybe something got gc'ed somehow? <ruther>podiki: if gc did that, that would definitely be a bug though <podiki>i'm not sure how the various parts and servers of cuirass work either (or what the storage situation is, maybe some storage isn't mounted or something?) <meaty>how do I tell guix "this substitute server is down. stop searching it" <podiki>remove it from your config or specify --substitute-urls without it <ruther>podiki: hmm, right. Now that you mention it if the store is shared, I don't even know if it can keep track of the processes using the individual store items when doing builds <podiki>ruther: i don't know if i just wasn't looking before or if this actually started after moving to codeberg...maybe some caching issue? <ruther>like if someone does guix gc in the base system, but the build is running in a VM <ieure>Shouldn't guix rebuild the store item if it's missing? <podiki>this error seems to be something the current guix/cuirass process is already referring to <ruther>ieure: yeah, except if it started missing during the build... <ieure>Is it some kind of race, like it checked the store for the file, saw it was there & didn't need to build, then it got gc'd? <ieure>Like how often can that happen? <xFFFC0000>guix describe points to old commit. how can I fix this? I updated .config/guix/channels.scm but still when I use guix describe points to old commit. <xFFFC0000>no, even after guix pull I have same guix describe output <meaty>anyone here use gnucash? if so, how did you get it working? <ieure>xFFFC0000, Did you run `hash -r', log in/out, or re-source your profile? <ieure>xFFFC0000, bash will cache the path to the old `guix', any of those should invalidate it and pick up the new binary <xFFFC0000>for some reason it was not showing me to source my profile again. or `hint: After setting `PATH', run `hash guix' to make sure your shell refers to `/home/alef/.config/guix/current/bin/guix'.` <xFFFC0000>I don't know why, but it pull was successful without showing that message <ruther>xFFFC0000: so now it works? or is it still wrong? <xFFFC0000>one other question. I have manifest.scm for my project. Is it possible to set channel there? custom channel. The question boils down to setting channel setting inside manifest file instead of parameter <identity>xFFFC0000: see (info "(guix) Inferiors") <ieure>xFFFC0000, 1.4.0 is multiple years old. <ruther>xFFFC0000: release 1.4.0 is two years old. Releases are not updated in any way, it is just a tag <ruther>xFFFC0000: so it can't be updated <xFFFC0000>Fair enough. Understood. I have to go with master then. <ruther>xFFFC0000: yes, master is always better. Versions are mostly for installation <xFFFC0000>found the problem. it reverts to /usr/local/bin/guix that is why guix describe keeps going back to 2021 <ruther>xFFFC0000: are you sure you're souring the ~/.config/guix/current/etc/profile in your shell profile files? <xFFFC0000>yes, that was the problem. it is a old system. commented out on .bashrc, fixed it <ruther>xFFFC0000: bashrc shouldn't be the one sourcing it. Only profile should be <xFFFC0000>thanks. will take care of that. any way to do something like "gcc-toolchain@13.3.0:static" in manifest.scm? I want specific version, and I want static package. <noe>xFFFC0000, try “guix shell gcc-toolchain@13.3.0:static --export-manifest” :) <ruther>xFFFC0000: what you send is a valid specification, so yes specifications->manifest will try to find package with that name and version in the channel you're using. <mra>hey guix. how's everyone? <mra>i'm tinkering with guix to avoid studying for my exams :) <pastor>Hello, could any commiter check out this issue? I think it's ready and the detected issues have been addresed: <mra>pastor: you may want to open a pull request on codeberg? not sure if people are still looking at patches submitted to debbugs <csantosb>mra, in principle, until the end of the year, yes <mra>ah, apologies. i probably should have read the GCD <pastor>I hope people will still give attention to already submitted patches <vagrantc>so ... guix build linux-libre-arm64-mnt-reform tries to build and fails applying patches in one of it's phases ... but does download the source tarball successfully <vagrantc>guix build --source linux-libre-arm64-mnt-reform ... tries to rebuild the source tarball <vagrantc>shouldn't they, like, use the same source tarball ? <vagrantc>what does "guix build --source PACKAGE" use different sources than "guix build PACKAGE" ? <vagrantc>computed derivations or something confusing like that that? <ruther>vagrantc: it has to do with grafts, --source --no-grafts will produce the derivation. I suppose that grafts aren't applied when you guix build package, but are when you guix build --source. Not sure what is changed by grafts here though <ruther>s/will produce the derivation/will lead to the same derivation as if you don't use --source <vagrantc>e.g. guix build --no-grafts --source linux-libre-arm64-mnt-reform ... spit out a tarball!