IRC channel logs

<teddd>For reference the functions I was looking are the monadic procedures : `(build-derivation (lower-object my-package))`

<bdju>I haven't got the time to troubleshoot this right now, but seems multiple GTK applications are very broken and everything shows up blank. Specifically I noticed transmission-gtk and pavucontrol. Luckily had pavucontrol-qt which works fine, for transmission I worked around it with daemon + remote.

<bdju>I'm on guix 81bb918

<apteryx>didn't we have patches somewhere to decouple gtk4 from qt ?

<apteryx>already applied to gnome-team branch, but not sufficient anymore it seems

<apteryx>lilyp: if you have things that cause a (near) world rebuild, let me know, we could synchronize to include https://codeberg.org/guix/guix/issues/1674, otherwise it can wait another time

<apteryx>bdju: are you on kde?

<bdju>apteryx: I'm on Sway.

<Guest54>Hello! I did a first-time install of guix yesterday. I have some questions, if anyone is willing to entertain them.

<vhns>Guest54: not to be mean, but you're better off just asking the questions and waiting on someone to answer

<Guest54>Yes, I normally follow the "don't ask to ask a question" rule, but only in chats that look active. I didn't know if anyone was awake.

<Guest54>So question #1:

<Guest54>I guess when I was reading the guix docs, I came under some false impressions. I thought that installing the guix system would create one "cohesive" guix system. But I've been realizing that even in the guix system there's a split: the guix package manager seems to be a different thing from the guix system. Like how when I run "guix describe" vs

<Guest54>"guix system describe" I get different commit hashes. Is this correct?

<Guest54>And that I shouldn't expect to be able to rely on "guix system reconfigure" to just automatically use (say) the channels or settings or whatever else I'm accustom to the guix-package-side of things to use?

<PotentialUser-60>Hello, hope anyone can help me out. Since like a week ago my guix pull fails with this error:

<PotentialUser-60>Throw to key `bad-response' with args `("EOF while reading response body: ~a bytes of ~a" (3653452 12944720))'.

<PotentialUser-60>substitution of /gnu/store/rkfjvglmp7jnyvhn5ps0zxa39dwczzhg-guix-system failed

<PotentialUser-60>guix pull: error: corrupt input while restoring archive from #<closed: file 7fced8742000>

<PotentialUser-60>is this solvable or do i need to reinstall?

<vagrantc>Guest54: each user has their own independent profile, and the system profile is another profile ...

<vagrantc>Guest54: "guix pull" is used to update the list of available packages and services, and things like "guix system reconfigure ..." updates the system-installed packages and services

<vagrantc>"guix upgrade" would upgrade the user's installed packages

<vagrantc>users typically have both packages from the system profile and their own selection, with the user's packages (for the most part) taking priority.

<vagrantc>there's also "guix home" which might manage your user's packages in a slightly different way, but i think it is basically the same idea

<vagrantc>Guest54: so if you run "guix pull" in between "guix upgrade" and "guix system reconfigure" you might have somewhat different selections of available packages

<vagrantc>PotentialUser-60: that should be fixed ... you might have to revert to an earlier generation and then update to current? i do not recall off the top of my head.

<vagrantc>PotentialUser-60: maybe also guix gc --verify=contents,repair ...

<PotentialUser-60>since what it seems to fail at is the substitution im trying to pull without substitutes now but its taking a while, any chance of that fixing it or do i dont even bother?

<vagrantc>try reverting to an older generation?

<vagrantc>(e.g. from the boot menu?)

<PotentialUser-60>uhh my guix installed without a grub menu for some reason so i think i may just be cursed, will try a manual rollback and the gc thing after veryfying if pulling without substitutes fixes it

<vagrantc>ok

<PotentialUser-60>thanks for the tips tho

<vagrantc>it definitely sounds like something folks had been experiencing who got unlucky pulling the bad commit(s)

<lh>vagrantc: guix is a leaf package in debian, right? maintainers have absolutely no leeway to move to a newer, untagged version in a security-critical scenario?

<lh>if the debian policy is to force removing vulnerable leaf packages entirely over updating them to untagged versions, that seems rather limiting

<lh>that said, I do think there should have been 1.4.x tags when there were disclosures, carrying patches downstream gets unwieldy

<apteryx>how does .guix-authorizations work for repos outside of guix, more specifically, is creating a keyring branch of any importance on these repositories?

<apteryx>example being look at: the guix-maintenance repository

<untrusem>so this is a relevant bit from my home-config https://bpa.st/5XFA, when I run this, guix outputs `transformation "with-branch" had no effect on emacs-master`, where I am going wrong, I followed things according to manual

<untrusem> https://bpa.st/5XFA correct url

<Rutherther>untrusem: you need to transform a package, not a string

<untrusem>Rutherther, if I use `(transform emacs-reader)`, this is the error

<untrusem> https://0x0.st/8Rds.txt

<Rutherther>untrusem: because now you're passing a package to specification->package that expects a specification - a string...

<untrusem>ohh ok

<untrusem>btw if I want to install a package from guix rust-team branch, I will need to use transformation for that as well I think?

<Rutherther>untrusem: no. For declarative approach you can use inferiors. For something like guix install you can just 'guix time-machine --branch=rust-team -- install ...'

<untrusem>oh cool, I will define that in my config

<lilyp>apteryx: what exactly is the problem there?

<lilyp>we should probably not expose the "-real" thing, imho

<apteryx>it's not exposed, at least not via $0

<apteryx>$0 will resolve to the name of the wrapper, which is clean

<apteryx>lilyp: a bit more context in https://codeberg.org/guix/guix/issues/1674#issuecomment-6033910

<lilyp>ahh, it's basename vs full path

<lilyp>hmm

<apteryx>yeah

<lilyp>perhaps we should introduce this as a togglable flag #:wrap-basename?

<apteryx>I'm not sure. I thought it was more conventional to use base name, but I don't know where I had seen that

<lilyp>i think most hand-written scripts would only use the basename and not the full path

<apteryx>Maybe when we use low level exec? I seem to recall you have to provide an arg0 manually, which is typically given the name of the command about to be called rather than its full filename

<apteryx>(in C for example)

<lilyp>yep, there's two styles here

<lilyp>one with hard-coded basename

<lilyp>and one where the resolved bin is used twice

<lilyp>Depending on any particular behavior is probably a bug

<lilyp>OTOH when was this committed to master (and when to its feature branch before)?

<lilyp>10 months looks rather old

<apteryx>it came with the core-packages-team branch merge

<apteryx>so very recently

<apteryx>it only causes issues in rare, odd cases. Supposedly Emacs is one.

<apteryx>Cling was an example segfaulting with a file name rather than a command name as $0

<apteryx>arg0

<apteryx>But it now seems the tool is to blame

<lilyp>hum, emacs works for me just fine

<apteryx>it was brought to guix-devel recently, I think?

<apteryx>I forgot the details

<lilyp>probably depends on gnome vs. kde though, because emacs vs. emacsclient and all those varieties are a small mess

<apteryx>lilyp: indeed, can't find the mail, it's annoying

<apteryx>lilyp: found it: https://lists.gnu.org/archive/html/guix-patches/2025-07/msg00181.html

<lilyp>assuming this is indeed an issue still, we should fix it on the emacs-team branch imho

<lilyp>particularly by resolving the native-lisp directory eagerly

<Kabouik>bjdu I did observe too that pavucontrol does not open from my launcher anymore, and I had to run it in terminal to see the window.

<sneek>ekaitz: Greetings :)

<ekaitz>sneek: botsnack

<sneek>:)

<ekaitz>hi all

<gabber>hi there

<gabber>what could be a reason for my desktop (sway) not showing pavucontrol's icons? when i hover through the guix i see where there ought to be buttons, but nothing shows (it's issue#1700). am i missing some icon sets in my profile? this does not seem to be reproducible per se

<ekaitz>gabber: you might not have icons installed

<gabber>ekaitz: do i need specific icons? or all of them? is there more to it than install some icon package?

<ekaitz>gabber: i have both hicolor-icon-theme and adwaita-icon-theme installed

<ekaitz>the hicolor is often a fallback

<ekaitz>i don't know how any of this works, but I had the same issue you have

<gabber>ekaitz: thanks for your input!

<ekaitz>gabber: give it a try and let me know

<gabber>`guix shell adwaita-icon-theme hicolor-icon-theme pavucontrol -- pavucontrol` does not solve the issue, though

<gabber>maybe i need to actually *install* them in my profile?

<yelninei>is there a way I can "ungexp" an expression when I dont have gexps? I want to add a patch in a phase but the package does not use gexps and most people use #$(local-file (search-patch ...)) for this

<ekaitz>gabber: shelling probably won't do it

<gabber>ekaitz: i see. thanks!

<ekaitz>yelninei: put a gexp

<ekaitz>you cannot ungexp what isn't gexp-ed, but you can always gexp things

<yelninei>ekaitz: does this work for old-style packages as well? I guess it would be better if I also migrate the package to the gexp style

<andreas-e>yelninei: If it is not in a gexp, chances are it is in a quasi-quoted list `(...). Then you should be able to unquote with something like ,(local-file ...)

<andreas-e>Or if the list is quoted with ' you need to quasi-quote it with ` instead.

<yelninei>andreas-e: Then i get a reader error: ice-9/read.scm:126:4: In procedure read-expr*: libxcb-1.17.0-builder:1:4986: Unknown # object: "#<"

<yelninei>it inserts the printed local-file object instead of the full path to the patch

<yelninei>ACTION gives up and ports the package to gexps

<yelninei>i guess the way to do this is add the patch as an input and the look it up from there but this is not really convenient

<gilaro>Slt! J'essaye de compiler OpenWrt avec OpenWrt Buildroot. Je n'y arrives pas.

<gilaro>git clone https://github.com/openwrt/openwrt.git

<gilaro>cd openwrt

<gilaro>make

<gilaro>err..

<andreas-e>Mauvaise fenêtre? Quel est le rapport avec Guix?

<gilaro>@andreas-e: Cela ne fonctionne pas avec Guix System alors que tout fonctionne avec Manjaro.

<gilaro>guix shell -CNF -m manifest.scm -E TERM

<gilaro>(specifications->manifest

<gilaro> (list "git"

<gilaro> "ncurses"

<gilaro> "unzip"

<gilaro> "python"

<gilaro> "cdrtools"

<gilaro> "perl"

<gilaro> "emacs"

<gilaro> "less"

<gilaro> "coreutils"

<gilaro> "make"

<gilaro> "nss-certs"

<gilaro> "grep"

<gilaro> "bash"

<andreas-e>Ah je vois. Checking 'argp.h'... failed.

<gilaro> "sed"

<gilaro> "gawk"

<gilaro> "gcc-toolchain"

<gilaro> "rsync"

<Rutherther>please don't send so many messages here, use a paste service

<gilaro> "tar"

<gilaro> "findutils"

<gilaro> "patch"

<gilaro> "diffutils"

<gilaro> "util-linux"

<gilaro> "gzip"

<gilaro> "bzip2"

<gilaro> "wget"

<gilaro> "file"

<gilaro> "which"

<vhns>very nice spam

<gilaro> "glibc"

<gilaro> "glibc:static"

<gilaro> "pkg-config"

<gilaro> "autoconf"

<gilaro> "automake"

<gilaro> "binutils"))

<Kabouik>I find some odd comfort of seeing it coming one line per second.

<gilaro>@andreas-e: oui, ncurses.h également.

<andreas-e>On a vu un problème lié à argp.h dans un autre projet. Je pense que c'est un problème dans le code de OpenWRT, en lien avec notre passage à gcc-14.

<andreas-e>Peut-être qu'avec gcc-toolchain-13 à la place de gcc-toolchain cela fonctionnera.

<andreas-e>Sinon, il faudrait plutôt voir du côté d'openwrt, je le crains.

<gilaro>@andreas-e: ah, merci beaucoup !

<gilaro>@andreas-e: je vais tester, see and wait!

<gilaro>@andreas-e: Par contre, c'est étrange car le test semble fonctionner lorsqu'on invoque la commande manuellement.

<gilaro>gcc -include ncurses.h -o test_ncurses test_ncurses.c -lncurses

<gilaro>#include <ncurses.h>

<gilaro>int main(int argc, char **argv) {

<gilaro> initscr();

<gilaro> return 0;

<gilaro>}

<andreas-e>Je ne sais pas, désolé.

<gilaro>@andreas-e: J'ai modifié le manifest en substituant gcc-toolchain par gcc-toolchain@14.3 mais cela n'a pas fonctionné. :-(

<Kabouik>La suggestion d'andreas-e était de tenter avec gcc-toolchain-13.

<andreas-e>Je viens de tester, cela ne fonctionne pas non plus...

<gilaro>Je vais demander de l'aide du côté de OpenWrt. Mais cela m'étonnerait que j'obtienne une réponse. C'est un drôle de problème.

<gilaro>Le point positif est que d'autres personnes arrivent à reproduire ce bogue.

<human_equivalent>:o I think I'm about to submit my first guix patch

<andreas-e>Nice!

<human_equivalent>andreas-e: It's actually mainly just a copy of a patch you made last week but for another package. 0:)

<andreas-e>That sounds like a good start!

<human_equivalent> https://codeberg.org/heq/guix/commit/8f1d5e9b8d8ea843f60ca4e675a8771bf3306437 here it is, I'm just going to read the checklist and the contributing stuff before I create a PR... it's about gcc-14 and drbd-utils. I haven't set up my own repo yet but just putting that package definition in a file and running --install-from-file worked

<andreas-e>human_equivalent: That looks good, but I see there are also newer versions of this software at

<andreas-e> https://linbit.com/linbit-software-download-page-for-linstor-and-drbd-linux-driver/

<andreas-e>9.31.0 instead of 9.25.0. Would it make sense to try an update first?

<human_equivalent>Probably! I'll give it a try. :)

<andreas-e>In any case, it would probably be good if you created a pull request on codeberg, I will let you set up things as an exercise :)

<human_equivalent>Yeah, I'm just looking at pre-inst-env and linting before I click Create PR. But now I'll try the new version instead.

<human_equivalent>9.31.0 built fine without gcc-14 patches

<andreas-e>human_equivalent: Excellent, that makes the situation easier.

<human_equivalent> https://codeberg.org/heq/guix/commit/76cfe35eee58a1b44be432bb23a759fbe908276c but I'm going to try building the deps before creating the PR

<human_equivalent>Haha I just realized that I think my server wants to install drbd because I experimented with Ganeti some time ago, but decided not to use it. I think I just forgot to remove it from the package list. Oh well, time well spent anyway.

<andreas-e>Funny! But it is always good to get newer versions of maintained packages into Guix. I have just read a comment on Mastodon by someone who liked Guix, but found the packages too outdated compared to Nix.

<Kabouik>When using an .envrc file containing https://0x0.st/8Rh2.txt, I end up in a Bash shell where the text I type is not visible (but if I press RET, I can see that some text was typed). Is that just the Guix shell being trapped in some non-interactive shell started by direnv or something? What would be the solution?

<Rutherther>Kabouik: that is not how you use direnv, direnv doesn't support makng a new shell process like that

<Rutherther>in fact I don't think you can use direnv for shell container at all

<Kabouik>Turns out if I use `-- fish` instead, I can type in just fine and I'm indeed in a Guix shell environment, but I think it's hacky, and the same issue occurs when I exit it with C-d

<sham1>Yeah, that's now how direnv is meant to be used

<ieure>That's launching an interactive shell *while direnv is sourcing the envrc file*, right?

<Kabouik>Someone actually recommended using direnv to automatically spawn reproducible environment with Guix shells and have them work in Emacs too, as that was my use case

<Rutherther>this will definitely not work in emacs out of a shell

<Kabouik>Emacs' Dirvish does load that guix shell when I enter the directory, but I'm having trouble with ESS inheriting the Guix shell indeed.

<Kabouik>(using emacs-envrc)

<Rutherther>because you gave nothing to 'inherit', you just spawned a shell

<sham1>Kabouik: sure, but what you'd use guix shell for is to find out the relevant --search-paths. Also <https://github.com/direnv/direnv/blob/master/stdlib.sh#L1396-L1419> If you have `channels.scm` in the same directory as your .envrc file, it'll automatically use it. But in your case you could adapt this code instead

<sham1>So instead it'd look under the guix-directory for your channels

<Kabouik>I'm happy to use something else if this is not how direnv is meant to be used. I actually discovered this tool just for this when it was recommended to me, and I'm happy I did, but my main use would be this (I don't often need to just set different environment variables in a directory, if that's what it is for). If this is inappropriate, it'll be easy for me to jump to another solution, but I would want something that could work from Emacs ideally.

<Rutherther>yes, that is what it's for, to set environment variables per directory

<sham1>It will work with emacs just fine

<Kabouik>sham1: but I need time-machine too, I don't think `use guix` uses time-machine.

<sham1>Kabouik: check the code

<sham1>It absolutely does invoke time-machine

<Kabouik>You're right. So just move my channels.scm and manifest.scm to the root of the folder, and use only `use guix` in .envrc? What if I need extra parameters, like --container, --expose, etc.?

<Rutherther>how would container work with direnv if it just sets env vars?

<Kabouik>Oh, there's "$@" so I should be able to add arguments to `use guix`

<sham1>I think there might be an XY question going on here. Why do you want to be in a container?

<andreas-e>human_equivalent: Pushed! Thanks and congratulations!

<gilaro>andreas-e: Le problème vient vraisemblablement des variables d'environnement. J'ai fait un test rapidement en ajoutant -I/gnu/store/bssjcc1w3wrw0dk7da81fb54mf46b0j6-profile/include lors de l'invocation de gcc : https://pastebin.com/gfPRKKZu.

<human_equivalent>andreas-e: hah great - just added a comment about maybe wanting to double check with a guix ~make check~ that doesn't return errors :)

<human_equivalent>yay

<Kabouik>sham1, Rutherther: I assume just because I misunderstand how --container works and what are its benefits. I was trying to follow the advice on slides 21 and 22 here: https://10years.guix.gnu.org/static/slides/04-hinsen.pdf#page=22.00 (hopefully I didn't misunderstand the benefits).

<Kabouik>(The video with the speech insists more on why using --container for reproducible science)

<Kabouik>But then the video is not talking about direnv, so maybe there are details that don't translate when using direnv to deploy the reproducible environment.

<sham1>Yeah, you don't need --container with direnv. You'll still get a reproducible environment

<sham1>Your channels.scm and manifest.scm are the things that provide the reproducibility, since the channels.scm pins your channels and manifest.scm gives you all the packages you expect. Using guix shell --container is orthogonal to that

<sham1>`--container` is useful if, when running your program, you want to limit what your program can access

<Kabouik>But don't I risk to deviate from reproducibility if I'm in a shell environment using my channels.scm and manifest.scm AND some of my env variables loaded from my .rc files?

<Rutherther>env vars shouldn't be set in .rc files, only in .profile files. If your rc scripts export variables, you should change that definitely

<Kabouik>Though in that case --pure might be more relevant anyway.

<Rutherther>pure is definitely relevant, but works only if you don't export variables in rc, just in profile

<Rutherther>and yes, you get lower reproducibility than a container

<Kabouik>Yeah, I do have some variables exported in my .bashrc and even fish.config files since I moved to fish. Hum.

<Rutherther>but there is no translation of shell --containej to direnv, direnv just sources env vars, it cannot drop you into a container shell

<Rutherther>Kabouik: try "guix shell --pure --check"

<Kabouik>Not as bad as I expected I guess: https://0x0.st/8Rhw.txt

<Kabouik>But the .bashrc sourcing seems to have aborted before the end due to this tput error.

<Kabouik>Which made me realize by the way that chsh is not the way to change the default shell of a user in Guix. I thought it was fine because my terminal spawns with Fish, but that's just because my .bashrc ends with `fish`, a quite hacky trick that I probably set temporarily then forgot about years ago. I see I need to set it in my config.scm instead.

<Rutherther>it's better to have bash as user shell anyway as that is the only guix supports

<Rutherther>for other shells you need to do more work, bash just works out of the box

<Kabouik>When you say it's the only one guix supports, do you mean `guix shell`? I can see that my PS1 is not modified in Fish when I run guix shell, but if that's all I'd still prefer having Fish as my default because I'm used to it.

<Rutherther>I mean profiles in general, so yes, guix shell, guix package (install...)

<gilaro>bye!

<Rutherther>although sorry guix shell doesn't care as it doesn't rely on shell in any way

<Rutherther>so just the profiles, when you log in etc.

<Kabouik>I don't see what doesn't work when using guix shell except the PS1 not being altered, guix package seems to work fine from Fish

<Rutherther>then you must've already modified your fish config to source the appropriate files

<Kabouik>Indeed, I see `set -gx GUIX_PROFILE "$HOME/.guix-profile"` and `source "$HOME/.profile"` in my fish.config. But then that leads to the earlier issue: multiple env variables are exported from my fish.config which I think is just an .rc file, and you're saying this should all go in ~/.profile, right?

<sham1>Setting up fish appropriately is also supported by Guix Home

<Rutherther>yes, but by ~/.profile I meant also other shell equivalents, ~/.profile is for sh, bash etc.

<sham1>With the `home-fish-service-type`

<Kabouik>I'm not using Guix home yet sham1. I would like to try it at one point, but I'm already far too easy getting distracted by easier tasks and drawn into rabbit holes!

<identity>‘find-alternate-file’ is definitely one way to quit a channel…

<Rutherther>Kabouik: as for the fish equivalent of .profile, I think it's checking is-login, all done from just one config file you mentined

<Kabouik>I wonder, is it not acceptable to just source ~/.profile in my fish.config (https://0x0.st/8RFr.txt) and have all env variables I need set in ~/.profile in the form `export FOO=bar`? I just checked and they seem to be correctly evaluated if I do so.

<Rutherther>it is not correct to do that in every interactive fish, only in the login shell

<Kabouik>Actually Archwiki suggests the hacky trick I was using to keep Bash as default shell, but just enter Fish for interactive shells: https://wiki.archlinux.org/title/Fish#Modify_.bashrc_to_drop_into_fish

<Kabouik>This doesn't look very clean though.

<Kabouik>And Gentoo does a similar thing: https://wiki.gentoo.org/wiki/Fish#fish_as_a_default_shell_with_Bash_as_the_login_shell This significantly increases the time Fish needs to start in a new terminal window.

<nikolar>exec into bash :P

<nikolar>but yeah, fish is weird and i don't recommend using it

<nikolar>erm i meant "exec into fish from bash"

<Kabouik>Interestingly when I set (shell ...) to fish in my (user-account ...), then ran `status` in a Fish shell, it reported not being the login shell, so I wonder if all those hacks are even necessary.

<Rutherther>Kabouik: is-login is going to be set when you're executing a login shell. As in you execute fish with --login

<Rutherther>that happens when you log in

<Rutherther>it won't happen when you start a shell in your session

<csantosb>Ey Guix, I have an error when building with mpi ... https://codeberg.org/guix/guix/pulls/1547#issuecomment-6070528

<csantosb>Is this familiar to anyone ?

<attila_lendvai_>is there an manifest.scm equivalent of `guix shell --system=i686-linux clang-toolchain`?

<attila_lendvai_>or is that what Rutherther is working on?

<attila_lendvai>my ultimate goal is to be able to compile -m32 C stuff

<akord>Hello everyone

<akord>I'm trying to edit /etc/config.scm

<akord>but if I open it either without sudo its readonly and with sudo it gives me segfault

<akord>what should I do?

<ieure>Use a text editor that doesn't segfault?

<ieure>What editor are you using?

<akord>neovim

<ieure>You can use another editor, or copy the file somewhere, edit, `sudo mv /tmp/config.scm /etc/config.scm' and reconfigure.

<akord>okay

<sham1>And/or you can set the u+w flag on the /etc/config.scm with chmod

<akord>hmm

<sham1>That would be useful even if you do end up copying it instead

<akord>the last option seems most promising

<ieure>You probably don't want /etc/config.scm world-writable.

<akord>yea

<sham1>Thus u+w

<akord>alright thank you

<ieure>sham1, It already is u+w, just it's owned by root.

<ieure>Ah, they left before I could say "keep your config in a Git repo instead of /etc"

<ieure>But that is IMO the actual correct thing to do.

<sham1>Well why would sudoedit complain about it. But yeah, the real solution is to put the config out of /etc and into a repo

<ieure>sham1, That's not what they were saying, they were saying when edited as their user, they don't have write permission (expected), and when they use sudo to edit it as root, neovim segfaults (not expected).

<akord>I'm back

<sham1>Oh, I see. I guess my brain autocorrected it to being `EDITOR=nvim sudo -e /etc/config.scm` but I suppose that's not a good assumption

<akord>I tried u+w but it didn't solve anything

<ieure>akord, Yeah, because the file is owned as root.

<ieure>akord, You should put the file in a Git repo and delete /etc/config.scm IMO

<sham1>^

<akord>hmm

<namewillforget>Hey everyone! I'm trying to configure my btrfs system. I'd like to make my main btrfs volume `noatime`. For this, my current config looks like this: https://pastebin.com/ . This produces the following `fstab`: https://pastebin.com/wF0ws6KS . But if I boot with it, I get a message by btrfs that `noatime` is an unknown option. Why?

<namewillforget>I thought it was because I can't apply the option to a subvolume, but I don't know where else either.

<cage>Hi! my package fails the command 'guix challenge' https://codeberg.org/cage/tinmop/issues/54

<namewillforget>Because I can't specify the main volume at / because that's where the subvolume /@ has to be mounted.

<cage>does this fials happens because the building of tinmop is not deterministic?

<namewillforget>So I'm again out of ideas

<akord>I'm back again

<namewillforget>Oh, sorry, that's the right link to the config section: https://pastebin.com/nTTh9Jmf

<akord>so I tried it again but in a different terminal

<akord>and it worked

<akord>is there some issue with urxvt?

<Rutherther>attila_lendvai: yeah, I am afraid there is no canonical way to specify a system in manifest, and yes, the tool I am working on should allow that, though it's mostly meant for cross compilation rather than specifying the --system. It's possible to do this https://paste.debian.net/1388975/ with my tool and put it to packages list in a manifest

<attila_lendvai>thanks Rutherther! maybe i'll just jump the sharks and add x86_64 support to maru. 32 bit is becoming too much trouble these days...

<attila_lendvai>ACTION makes notes though

<Kabouik>After today's conversation regarding Fish/Bash and how to export env vars, I've tried to clean my environment and only export variables in ~/.profile, remove all env vars but PS1 from ~/.bashrc, and place `exec fish` at the bottom of my ~/.bashrc so that every time a terminal emulator is opened, Bash drops into Fish. According to Archwiki and Gento wiki, Fish should inherit the variables loaded by Bash (and therefore ~/.profile) that way, without

<Kabouik>getting in the way as a login shell, and therefore allow better compatibility.

<Rutherther>btw PS1 shouldn't really be an env var, it should just be a var

<Kabouik>But… It seems ~/.profile is not even sourced anywhere, and I don't think I should source it from ~/.bashrc` or it'd be evaluated every time I start a terminal emulator.

<Rutherther>what is your shell - the one in /etc/passwd? And do you have ~/.bash_profile?

<Kabouik>It's /gnu/guix-hash-blahblah/bin/bash for my user in /etc/passwd. I have a ~/.bashprofile but it just tests if ~/.bashrc exists and then source it.

<Kabouik>.bash_profile I meant.

<Rutherther>okay, then that is the issue - if ~/.bash_profile exists, it is sourced and ~/.profile is ignored, so you should either move stuff from ~/.profile to ~/.bash_profile, or source ~/.profile in ~/.bash_profile

<Kabouik>Oh, they're redundant? I did create ~/.profile after our discussion indeed. I should just have put everything in ~/.bash_profile then since Bash still is my login shell.

<Kabouik>And that one is loaded only once when I enter in my user session in Wayland, correct?

<Kabouik>Or even in tty maybe.

<Rutherther>bash will use ~/.profile if ~/.bash_profile doesn't exist - it falls back to sh behavior

<Kabouik>Understood, I'll do that change. Thanks.

<Rutherther>yes, the profile file is sourced only at beginning of session

<sham1>Kabouik: why don't you just set fish as your login shell instead of exec fish

<Kabouik>This was discussed above sham1: apparently there are all sorts of issues that may stem from using a non-POSIX-compliant shell as login shell.

<Kabouik>I did manage to get a working state when I set Fish as my login shell, and it was actually loading faster than it is now, but I was sourcing ~/.profile every time I started an interactive shell which I think is wrong.

<sham1>Well then you obviously shouldn't source it from the rc-file but the login file which is only sourced with a login shell

<Rutherther>fish doesn't have a login file

<Rutherther>it has is-login status variable

<sham1> https://codeberg.org/guix/guix/src/branch/master/gnu/home/services/shells.scm#L557-L574 So it would seem, and the home service uses it properly. If Kabouik you don't want to use the home service, you could at least nick this

<Kabouik>The Arch and Gento wikis both suggest this dirty approach sham1, surprisingly, as it has the fewest drawbacks. The Gento wiki also mentions using `bass` as a way to import variables but they have a comment stating that after long discussions, they decided the exec approach was better.

<Kabouik>I do want to use Guix home at some point sham1 but this will be a big rabbit hole for me and I just can't dive in it in the near future.

<sham1>WDYM you can't dive in, it's one file and one command

<Kabouik>I mean I haven't even fully read the Guix home manual yet, but it appeared that it was a completely different approach to managing home in a declarative way, which is appealing, but sounds like it'll need some work to configure.

<Kabouik>Moving ~/.profile to ~/.bash_profile worked indeed in that setup Rutherther, thanks a lot. Now sham1 that doesn't mean I am not considering what you're saying, I'm just afraid it wouldn't be so simple if I'm not using guix home at all at the moment.

<hesoyamian>hello

<hesoyamian>I hope this works. Trying this from erc in emacs

<sham1>hesoyamian: well we can see you at least

<hesoyamian>that's perfect, I was just looking for any ways I can better debug broken guix builds

<yelninei>hesoyamian: What kind of failure? Also have you seen https://guix.gnu.org/manual/devel/en/html_node/Debugging-Build-Failures.html

IRC channel logs

2025-07-31.log