IRC channel logs
2026-05-11.log
back to list of logs
<Sven792>Rutherther: I build the iso from master, booted that and copied the font-related installer output over. Didn't test the installation but the fonts seem to be correctly installed now, nice <bjc>there are so many reasons why not, but this isn't the place for it <bjc>ah, the issue is that console-run needs write access to dev nodes <janneke>bjc: weird, i mean, debian uses: ext2fs.static ext2fs --readonly ... <bjc>yeah, i think there's a boot order thing happening <bjc>runsystem isn't run until after console-run, but runsystem is what does the fsck and remount <bjc>but console-run needs /dev to be mounted rw <bjc>devfs someday maybe, but for now, that means root has to be rw for that <bjc>hrm. seems like runsystem is run from within console-run <Sven792>that's sad I got a different image than Cuirass. I need to call the bit busters <lfam>I recently updated by Guix-on-Debian system to the latest from a generation created in February. And now my terminal rxvt-unicode is broken. Many terminal applications fail to start with "Error opening terminal: rxvt-unicode-256color" <lfam>Does anyone have any idea what's going wrong and how I can fix it? <lfam>I see a new package 'rxvt-unicode-terminfo' was created. When I install that, then things work again. Tada <ekaitz>lfam: sad, shouldn't the rxvt-unicode depend on the terminfo? <lfam>It really is mysterious. The rxvt-unicode package already installs the terminfo and sets up the TERMINFO_DIRS variable <lfam>Indeed I do not want to investigate either <apteryx>nice to see people in non-europe time zones :-) <ieure>I'm in the US, seems like it's fairly busy around here in my time zone. <folaht>apteryx, I'm not in a non-european time zone. I'm just unemployed. <folaht>If there are people awake. Does anyone know how to patch a package and then use it? In particular the package 'xkeyboard-config' Because I'm still don't know what exactly I need to do. <folaht>I'm able to create a xkeyboard-config package with the patch included, but I'm not able to rename the package. <apteryx>folaht: ah; sorry to hear it. About xkeyboard-config, is this a package you run manually as a user? <apteryx>if so, you could try 'guix build xkeyboard-config --with-patch=xkeyboard-config=/file/name.patch' <apteryx>otherwise what I'd do is probably patch it in-tree (guix checkout), build the checkout, then ./pre-inst-env guix build xkeyboard-config, or './pre-inst-env guix shell xkeyboard-config -- xkeyboard-config' for example to try it <apteryx>ieure: yes, evenings is a great time to hack, so long you do not have kids that don't feel like sleeping :-) <folaht>apteryx, what do you mean 'run manually as a user'? <apteryx>was wondering if it's used in a service perhaps but I guess not <folaht>I think it's built-in with guix, part of xorg-configuration. I've been given advice by someone on how to set xorg-configuration to change the layout. <folaht>How to choose a different package. <folaht>But if do 'guix build xkeyboard-config --with-patch=xkeyboard-config=/file/name.patch' I will end up with the package xkeyboard-config. <folaht>I need to build it under a different name if possible. <folaht>From xkeyboard-config to my-xboard-config <folaht>And I don't know how to do that. <folaht>Or I need to know how I can choose the correct xkeyboard-config package by the system manifest when there's multiple packages with the same name and version. <apteryx>folaht: if you define a variant in your operating-system definition file, you'll be able to refer to that exact variable in your xorg-configuration, I think <apteryx>hm, nevermind, it's not exposed directly at the level of xorg-configuration <apteryx>in this case maybe you could use something like this, where 'my-xkeyboard-config' is a package defined in the guix tree below the original one, inheriting from it but applying the patch you want; then you should be able to use something like './pre-inst-env guix system build --with-graft=xkeyboard-config=my-xkeyboard-config' <apteryx>using a graft instead of just changing the original package to avoid rebuilding a ton of stuff <apteryx>hm, --with-graft would inherits the grafts limitations, so the name of your replacement will have to be the same length as the original, including the version <apteryx>I guess that means you have to set the version to something arbitrary e.g. 2.99 and use '--with-graft=xkeyboard-config=xkeyboard-config@2.99' <neonio>hi guix, is there a way to just 'stop using' guix home? i have had my home config integrated into my system config for a while now but 'guix home describe' says i'm technically still using a profile from 2025 <apteryx>folaht: you could test all this in a ./pre-inst-env guix system vm /path/to/your/config.scm <ieure>neonio, I delete $HOME/.guix-profile and any files linked to it, like .bashrc, .profile, .bash_profile, etc. When you say "integrated into my system config," do you mean you're using guix-home-service-type in your operating-system to deploy your Guix Home configuration? <neonio>ieure, are you sure that's okay? .guix-profile is owned by root/root <apteryx>folaht: that's a script that appears it the guix git checkout tree after you run './configure'; it allows you to run the uninstalled guix from the checkout directly <ieure>neonio, Sorry, .guix-home is what you want to delete. But .guix-profile shouldn't be owned by root, I don't think. It's just a symlink to the store, in any case, it doesn't matter. <folaht>apteryx, oh right, I forgot to even run guix build in the git environment. <apteryx>see (info "(guix) Running Guix Before It Is Installed") <apteryx>and before that, (info "(guix) Building from Git") to build it <neonio>ieure, .guix-home is a symlink to the home profile described in my system config, not the one guix home describe gives <folaht>Oh, that sounds like building Guix itself. Do I have to dive in that deeply just to make a single change in the keyboard layouts? <apteryx>if you need to patch xkeyboard-config to do so, I'm afraid yes. But perhaps you don't need to patch it? <folaht>No, I just want to add my custom layout. I thought 'patch' was the way to go for that. <neonio>ieure, that file links to the 'guix home' profile described in my system config, not the one i'm trying to get rid of <apteryx>folaht: perhaps (info "(guix) Keyboard Layout") can provide some hints to achieve what you want? <ieure>neonio, They should be the same thing. <ieure>neonio, What profile is `guix home describe' showing? Where is that coming from? <neonio>guix home describe: ...`canonical file name: /gnu/store/ixxrj9wjz11y3cp3xafr8vkfnysh9ya1-home` <neonio>readlink .guix-home: /gnu/store/8xkj58rg1yzy1nck4fxk9nrzbifw4b8l-home <ieure>neonio, You might want to look in /var/guix/profiles/per-user/$USER to see what's going on with this. <neonio>i see the old profile sitting in there <ieure>neonio, Does the system home stuff use a different profile than user guix home? I'd find that surprising, but I suppose that seems to be what's happening. <attila_lendvai>i wonder if source level debugging of ld-linux-x86-64.so.2 is possible on guix... if i load the loader into Cutter and pass my binary as an argument, then i do see symbol names of the loader, but i'm afraid it's not coming from the debug info, but the loader binary itself. <ieure>neonio, My Home stuff is in /var/guix/profiles/per-user/$USER/guix-home, is that not where the system-created home profile gets placed? <neonio>ieure: that directory seems to contain a home profile <neonio>but the configuration.scm within is the old one from 2025 <ieure>neonio, Which directory? /var/guix/profiles/per-user/$USER/guix-home should be a symlink o the store. The link target is the old profile? <neonio>yes, readlink of .../guix-home is .../guix-home-46-link, which is the old profile <ieure>neonio, What other profiles are in there? Any symlink without a -link suffix is the current generation of profile. Is there a link in there for the home profile created by the system? <folaht>apteryx, no, I want to go a bit further than that, but I get the feeling now that in order to create a 'my-xkeyboard-config' package locally that includes the patch is to write a package variant in the style of '(define my-xkeyboard-config...', correct? <apteryx>folaht: I see; I think that may be correct but that doesn't seem to be a common use case that is made easy, since there's no easy way to provide the xkeyboard-package used by the xorg config, IIUC <apteryx>perhaps that'd need to be made possible first to make that use case more practical <apteryx>alternatives could be perhaps some user service that remaps keys to what you need? <folaht>Well, I've asked before here and this person told me to provide the xkeyboard-package through setting a variant xorg-server in xorg-configuration and then define that with modifying unpits and then replace the xkeyboard-config with the variant one. <folaht>I think I'm beginning to understand what I need to do. <folaht>I'll go to sleep first, try it out tomorrow and come back later if I need help. Thank you for your help apteryx. <apteryx>good idea :-) fresh mornings solve the most problems, I find. <attila_lendvai>an ld-linux compiled with debug info crashes Cutter. oh well, i also follow that good idea... o/ <loquatdev>If I wanted to use the (gcrypt hash) module inside of a gexp, could I do that by just including '((gcrypt hash)) in with-imported-modules since gcrypt is already used by Guix? <efraim>does anyone know if it's possible to use the tree-sitter-build-system and not have the "js" output? <csantosb>Wow. Codeberg is "403 Forbidden" only for me ? <efraim>I managed to unbundle the rust-tree-sitter grammars, but now I'm running into what I'm guessing is module cycles between tree-sitter.scm and rust-crates.scm <apteryx>weird: GnuTLS: Error in the pull function.\n Unable to establish SSL connection. attempting to run guix-install.sh <efraim>oh, the Totally Not A Scam Email™ was actually not a scam, it was from my domain registrar <janneke>booting with --readonly, but second boot fails even with a clean root file-system <loquatdev>Is there a good example of iterating over a list of records inside of a gexp? <loquatdev>I'm trying to generate files for a service based off of a list of records. Would I be better off using computed-file instead of trying to wrangle call-with-output-port inside the gexp? <loquatdev>I've been writing a huge service from scratch and although my current solution works I'm curious about the more commonly accepted approaches. <adanska>loquatdev, absolutely. You might also be interested in `define-configuration` and the associated system of serializers which are meant to help with this. <adanska>look up the section in the Guix manual, it might prove helpful for you :) <Rutherther>apteryx: hm, the script already uses ftpmirror.gnu.org, so it should be resilient to gnu ftp being down. Are you seeing issues with it? <apteryx>maybe they blocked my IP for repeatedly downloading the binary installer? ^^' <apteryx>that'd be the IP of the hetzner box though... but I can't download from my home machine <Kabouik>I saw this morning that we no longer need to type the LUKS passphrase twice at boot, nice QOL change! <apteryx>it was quite fast when it worked though, which is nice <Rutherther>maybe we should change the script to a known list of mirrors, or I don't know... <Rutherther>yeah, ftpmirror is even supposed to choose the mirror closest to you <apteryx>maybe it could fallback to a copy on our own server? <apteryx>your suggestion for the bind mount worked by the way <switchy>Kabouik: have you only recently updated? I have only had to type it once since my install a few weeks ago... (although it doesn't respect keyboard-layout, minor issue) <apteryx>I think I'll merge the Hetzner side already since it's better than what we currently have <apteryx>and send the doc addition for review <Rutherther>I mean, I am used to it from nix, where you have /nix/store and /nix/var which go together, so there is no other choice. I was more surprised by people mounting /gnu/store directly <Kabouik>switchy: I typically upgrade once a week but I don't reboot often <apteryx>yeah, it just was the most natural thing to do for me, I was surprised systemd didn't work with layers of mounts the way linux does <apteryx>the passwords are still requested multiple times on a Btrfs array... I guess that's not compatible with the new GRUB script. <Rutherther>apteryx: are there passwords requested after you boot from grub? or only before grub? <jlicht>silly question, but what (guixy) ways do folks use to run a postgresql server as a non-root user when doing some local development for a project? <identity>Kabouik: if b90597b98d is to be believed, Danny Milosavljevic is to be thanked for that. the manual mentioned a way to do that manually before, but now it is done automatically, from what i understand <charlesroelli>jlicht: not too guixy, but it works: install postgresql to a guix profile, from a shell in that profile run initdb, createdb, and then launch with pg_ctl start <bjc>you know, i think the right way to solve the issue with console-run and --readonly is to mount /dev as memfs and create a bare set of required nodes at boot time <bjc>i assume you can set a translator on a readonly fs <bjc>in fact, i think you must be able to or it wouldn't be booting now <janneke>that's an interesting idea...but aren't you wondering how debian pulls this off? <janneke>otoh, if we can do it the right way (TM), that would be nice <janneke>no idea if we have devfs for the Hurd? <bjc>there isn't, but i'm thinking more bare bones than that <bjc>basically just a startup script that does the mount and touches a small set of required files so they're available for the rest of startup <bjc>null, zero, console, et <bjc>as long as *those* are rw, it should work, i think <janneke>ACTION would be happy with anything that works, atm <janneke>i'm almost out of ideas for today, i think <bjc>we already do this at activation, so it'd be a matter of moving things around <bjc>not sure how plausible that is. there's a big context difference between this early in boot and when activation happens <janneke>i'm pretty happy that i found that if we touch /dev/console in the initial image, we can run ext2fs.static using --readonly <bjc>isn't it already in the image? <janneke>as i believe that's a requirement for getting to runsystem when the root file-system is dirty <bjc>it's there on my childhurd and custom image <janneke> ;; Don't create /dev/null etc just yet; the store <janneke> ;; Don't create /dev/console, /dev/vcs, etc.: they are created by <janneke>well, we know that won't happen if we boot with --readonly <janneke>if you have an unbooted image that has /dev/console, i'd be curious how it got there! <bjc>i think then we might be able to do the memfs thing fairly easily <bjc>change the mkdir-p to set up a translator on an extant /dev path <bjc>so we'd still need that to be pre-created, but the rest should Just Work™ <bjc>hrm. maybe not if it needs to mess with /servers, too <apteryx>Rutherther: I think nothing changed, so both before grub and when linux boots <apteryx>I have a Btrfs RAID 1 with 2 devices, so I get prompted 4 times. <apteryx>If I mistype once, I need to reboot. <Rutherther>apteryx: I was mostly wondering that maybe there would be one less password on the Linux boot <apteryx>I think there wasn't but I'll try to pay attention during my next reboot <Rutherther>btw do you know if the actual keys unlocked by the passphrase are the same for both disks? <apteryx>the fix for hetzner bind mount per your suggestion is 54e92a3c055 <aldum>apteryx: take the ZFS pill :P <apteryx>would that resolve anything w.r.t. to LUKS encryption passphrases being prompted by grub/linux? <apteryx>also, I think I have options, e.g. a key in the initrd, but I think that's still a bit messy and I'd prefer not having a bare initrd laying around <aldum>you could move from GRUB+LUKS+BTRFS to ZFSbootmenu and encrypted ZFS <apteryx>If I could teach GRUB to retry the same passwords, and to retry on a mistyped password rather than fail irrecoverably, that'd be a good start. <apteryx>oh, also teach it to decrypt luks without taking half an hour or something <gabber>friendly reminder for all who have not yet voiced their opinion for the deliberation of GCD007—please feel cordially invited to do so! the deliberation period ends on thursday <jA_cOp>I noticed one less password for grub + LUKS, nice :) but honestly I'd use direct EFIStub boot if it was supported <jA_cOp>maybe not that popular on Guix because you can pick past Guix revisions in Grub? <attila_lendvai>anyone with experience debugging ld-linux.so? i compiled a debug build of it from a git checkout. if i set it as PT_INTERP, then it crashes in the ld-linux.so code. in gdb i see no debug info, probably because the kernel loads ld-linux.so in this case. if i debug /path/to/my-ld-linux.so my-binary, then i see all the debug info, but *it does not crash*... <sham1>I don't know if being able to pick past revisions would be that big of an obstacle, since NixOS also lets you do that, and they certainly do support booting with EFISTUB. I think the bigger "problem" is that the kernel by default doesn't get copied over to /boot or whatever one's EFI partition would be -- this also means that you couldn't do proper FDE, since grub needs access to the /gnu/store to find the kernel <sham1>It also means that whatever partition the store is on needs to be encrypted with LUKS1 instead of LUKS2, or at least you couldn't use Argon2i as the KDF, which makes me a sad bunny <jA_cOp>yeah, I'm assuming a solution that copies the kernel to /boot, ideally used together with Secure Boot <jlicht>ACTION finally has a hacky workaround to run "guix system container" sans sudo \o/ <jlicht>hi zimoun; welcome back from your travels <zimoun>yeah on the (another) road again ;-) <graywolf>Hello Guix! I have interesting problem; `guix time-machine -C ... -- describe' gives expected outcome. However `guix time-machine -C ... -- shell -- guix describe' does not. <graywolf>Is it possible to tell guix time-machine to modify the environment in order for the nested `guix' invocations to work as expected? <jlicht>graywolf: does it work when passing -W to shell? <graywolf>jlicht: "error: --nesting cannot be used without --container" <jlicht>ah of course. apologies for the noise :-) <graywolf>nah, I appreciate the attempt :) my only idea currently is to construct the PATH manually which is bit.. ugly <bjc>well, i can't use xattr on guix for some reason <bjc>getting “operation not supported” when trying to set the translator for /dev inside the tmproot <bjc>and, indeed (getxattr "/" "whatever") also fails the same way <bjc>seems like this code isn't used elsewhere, though there is a test for it <graywolf>bjc: on what filesystem? our kernel does not compile xattrs support for everything (if I am grepping right) <graywolf>right, so CONFIG_EXT2_FS_XATTR is not y in our kernel, but I have now idea if that is the cause <bjc>you got a quick run down on how i can change that? <bjc>i'll happily test it <graywolf>you running on linux (nonguix) or linux-libre (guix)? <graywolf>in that case it is simple, you can just add CONFIG_EXT2_FS_XATTR into nonguix-extra-linux-options in nongnu/packages/linux.scm and deploy from that <graywolf>(I recommend to verify by zcat /proc/config.gz after reboot) <bjc>ok, i'll try it. this is pretty confusing, though <bjc>nm, i was misreading it <bjc>i take it back. it's still bad <graywolf>I admit "simple" idea was to just clone nonguix tree and change it there in place .. :) <bjc>yeah, that is not very simple for me, since i'd have to change a bunch of other infra around to do it <bjc>this is just a very opaque and confusing part of the build <bjc>like, i have no idea if the option is set properly until the entire kernel is built. i don't know where to get a list of options i can set. etc <bjc>and search engines being garbage now… it's like the 90s again <bjc>/proc/config.gz has answers <bjc>using menuconfig means setting up a parallel build environment just to investigate what options are available <bjc>there's no option for btrfs xattr that i can see, either. so no idea why that's not working <bjc>there's a namespace i didn't know about. i thought that was a bsd thing <graywolf>ddg suggested the "Operation not supported" is very accurat error message to "bad name of the attribute" <bjc>i'm trying to use the ‘gnu’ namespace, since that's what the hurd expects, and that's why it fails <graywolf>no worries, glad to help; this message goes into my notes on "how not to report errors" <bjc>hurd's looking for translators on the gnu.translator xattr <sham1>Hm. It would appear that I found an oversight in `gnu/services.scm`. Apparently everywhere else when a `&missing-target-service-error` is raised, it's raised with an appropriately named procedure `missing-target-service-error`, except in `fold-services` where it's instead wrapped into a compound condition first, making the exposed predicate `missing-target-service-error?` not work for that. Interesting <sham1>I need an opinion. Do you reckon that I should make another PR for that or incorporate it to a PR I'm already working on, which is the context in which I found the oversight <graywolf>sham1: Huh, that *is* interesting. I would expect the predicate to accept compound conditions; can probably be part of same PR, just separate commit? <sham1>Yeah, that's what I was thinking <sham1>I'm not surprised that the predicate doesn't accept compound conditions, since the predicate comes from the SRFI 35 `define-condition-type`, which probably doesn't know anything about compound conditions <sham1>Which is kind of weird thinking about it, since the same SRFI also defines compound conditions, but whatever… <sham1>Oh wait, I think I just figured it out. Nvm. Apparently my reproducer had something wrong with it. The predicate *does* work. Would have been odd if it was actually broken instead of just being a skill issue on my part <bjc>god i feel thwarted at every turn <bjc>‘guix system image’ doesn't take a --with-source transformation <bjc>so nfc how i'm going to build a custom hurd image <bjc>guess i can do the transform in the system config <stephen0>I see base-packages is composed of base-packages-interactive and some others. Is there a way to use base-packages but to replace some of the packages under base-packages-interactive? For example, to append things like ripgrep and ncurses and to remove things like nano and mg? <graywolf>stephen0: (delete nano (delete mg %base-packages)) ? <bjc>also ‘modify-services’ <bjc>misread. maybe i should take a break =) <stephen0>graywolf: would that replace the %base-packages reference in my packages list? <stephen0>I wonder if something else might still be pulling them in. <bjc>yes, the full expression would replace it <bjc>%base-packages is just a list <bjc>the expression given creates a new list by deleting elements from it <ieure>Yes, more precisely, it makes a copy and applies changes to the copy -- it doesn't modify %base-services in-place. <graywolf>Well, the message does mention `use the `generic-git' updater instead', so I would presume the default approach does use GitHub API instead of git. <identity>tusharhero-xmpp: (properties '((updater . generic-git))) or something <stephen0>is this channel bridged with xmpp somewhere? <identity>not that i know of, discounting personal bridges <bjc>janneke: i don't want to jump the gun too much, but i think you're completely right about /dev/console <bjc>still going through the rounds, but i have a patch that has been working so far <janneke>bjc: that's great; i've been testing dozens of images and am kind out of inspiration for now ;) <janneke>bjc: the only thing i'm wondering: a fresh boot works, a second boot doesn't <janneke>i wrote a patch for startup.c to remove /dev and /hurd and create /servers <janneke>but that's too late, if we can remove everything the previous boot created before running console-run, and only re-create /dev/console, we would be OK <janneke>...but then, we would need to have a writable file-system, and we want to start with --readonly <janneke>ACTION goes to ponder on this a bit more <bjc>janneke: yeah, i've seen the ticket. my fix for that is currently just to use e2fsprogs <bjc>i'm still using --snapshot, so haven't tried a second boot yet <bjc>let me push this somewhere <stephen>does guix clean /tmp on boot? I'm porting elements from my nix config to guix and I'm not seeing anything in the info pages on this one. <bjc>it's got a bunch of debug spam, but that has patches which set --readonly on ext2fs.static, and the creation of /dev/console at image creation time <bjc>as well as using e2fsprogs to do the fsck <janneke>bjc: yeah, that's quite similar to what i had; a first boot should work beautifully <janneke>addinf e2fsprogs is probably the right thing to do <janneke>ACTION crosses fingers for bjc to figure-out (or avoid :) the second-boot problem <bjc>oh, right, --volatile <loquatdev>Is there some procedure for getting the sha256 of a file-like object for a gexp? <bjc>i set the base32 of the sha to 52 0s, let it fail, and copy and paste from the failure <loquatdev>I'm writing a service that has to contain hashes for files. I'd like to use mixed-text-file and do something like (mixed-text-file "file.ini" "path=" store-item "\n" "hash=" (some-proc store-item) "\n") <ieure>loquatdev, `guix hash' might work for that. <ieure>loquatdev, Why does it have to contain hashes? <loquatdev>It's an arbitrary requirement of a proprietary binary I'm packaging into a service. <loquatdev>I could just use source-module-closure with (gcrypt hash) and use sha256-file inside of a computed-file but I feel like there's a cleaner option. Maybe not. <loquatdev>I'm packaging this binary as an exercise. I'm trying to get a better grip on Guix so I'm making everything I can think of into services and packages :) <bjc>bah. same 2nd boot problem <loquatdev>I'm generated a config file with mixed-text-file and another config file needs the hash of that config file inside it. <janneke>bjc: yeah, we could do with some insight into this... <bjc>i'll keep banging on it <cluelessguixer>Haven't tested the memory yet, but I assume it's some kind of hardware issue. Seems to happen if I do system reconfigure (the case for this stacktrace), or after syncing the Monero blockchain for a while. Thought it was the old SSD at first, but can still happen on the new one. Thoughts? https://bpa.st/WEBQ <ieure>cluelessguixer, Run that memory test. <ieure>cluelessguixer, What CPU is this? <ieure>cluelessguixer, Okay. I was wondering if you got hit by a defective Intel CPU, but sounds like that's not the case. They shipped a bunch of 13th/14th gen with defects that makes them overvolt and destroy themselves. <cluelessguixer>I've had the CPU running for years more or less 24/7. It's running 3 Guix containers, 2 docker containers, and 1 VM at the moment, but it seems stable most of the time. Hopefully second hand DDR4 memory isn't too expensive these days, lol. <cluelessguixer>I'll have to find the will to prepare a flash drive for that memory test, and run it, though. <ieure>cluelessguixer, Stick Ventoy on a USB stick, then drop a memtest image onto it. <ieure>cluelessguixer, memtest needs to run on bare metal, so a full-blown OS is unnecessary and overkills. <ieure>cluelessguixer, Ventoy lets you put bootable images on a filesystem and choose them from a menu, so you don't have to dedicate a thumb drive to a single bootable thing. Good stuff. <ieure>You can put a Guix live image on it, too, if you want. <egnuun>I've installed firejail with Guix (on GNU+Linux Min) but when I try to run a program all it says is: <egnuun>> Error: ../../src/firejail/util.c:1047: create_empty_dir_as_root: mkdir: Permission denied <egnuun>Do you have any idea, what I am missing? <ieure>egnuun, I don't know if you can have a working firejail on a foreign distro. Firejail needs the suid bit to work, as a user, you cannot set it on binaries for obvious reasons. Guix System has a process for managing suid bits, but since you aren't using it, it can't work. <cluelessguixer>ieure: How have I not discovered Ventoy yet? Windows, random distros, memtest... on the same flash drive. Brilliant, honestly. <egnuun>ieure: But can I not set it as root? <ieure>egnuun, You cannot, it has to be set on the file, the file is in the store, the store is immutable. <egnuun>> chmod: Beim Setzen der Zugriffsrechte für '.guix-profile/bin/firejail': Das Dateisystem ist nur lesbar <egnuun>It says, that the file system .guix-profile/bin/firejail is read-only. <ieure>cluelessguixer, It's a truly excellent tool. <graywolf>weeeeell, technically, you could mount the store RW and set the flag, but I am 111% sure that is not a route you want to take <ieure>I would install firejail using the foreign distro's package manager. <egnuun>That doesn't work. Well, the installation works. <egnuun>When I do something like "firejail firefox" it won't find my existing Firefox profile. <egnuun>So another reason to (finally) embrace the Guix "virus". ;-) <ieure>egnuun, I haven't used firejail, but it can't find firefox because it's either not propagating (or is explicitly sanitizing) the environment for the jailed program. Why not use `guix shell -C'? <ieure>I suppose firejail probably enables more granular control or something. <egnuun>I mean on foreign distributions, that is the "standard". <Kabouik>I am running a guix shell --container --network with `--preserve='^SSL_CERT_FILE$' --expose=$SSL_CERT_FILE` as extra arguments but still getting SSL/TLS issues: https://paste.debian.net/hidden/9038b52a Anything obvious I might be forgetting? <graywolf>Kabouik: you probably need to also --expose the certificate path <graywolf>I personally just prefer `guix shell -CN curl nss-certs [my packages here ...]' <graywolf>sorry I cannot read, I see the --expose now <egnuun>ieure: But I am open to new/better alternatives. <Kabouik>Thanks graywolf. Adding curl and nss-certs to the shell helped, somehow the expose doesn't do what I wanted. <graywolf>Kabouik: there is also SSL_CERT_DIR , so for the "manual" way maybe you need both SSL_CERT_DIR and SSL_CERT_FILE (for both preserve and expose) <ieure>Kabouik, You may need $SSL_CERT_DIR as well. Also, $SSL_CERT_FILE is a symlink, it may be that the symlink is mounted in the container, but the store item it points to is not. <egnuun>I've read, that "privilege separation", still seems to be a problem with firejail (see here <graywolf>ieure: interesting, for me it is a regular file, not symlink <egnuun>I mean, maybe it's already a sufficient safety mechanism. <graywolf>waaaaait it is symlink on the host, but not inside the container <graywolf>I hade *zero* idea that --expose dereferences symbolic links <ieure>egnuun, I'm also not sure how that works, but Guix already uses the architecture proposed for firejail. The guix daemon is suid, `guix' is a user program which communicates with it over a socket. <ieure>graywolf, No idea, it does make a certain amount of sense, though. <Kabouik>Preserving and exposing SSL_CERT_DIR didn't seem to work. would adding curl and nss-certs to the shell be bad practice? <graywolf>Well I even put `curl' and `nss-cert' into manifest.scm files in my projects if they need working internet, so I would say it is fine. But, dunno, subjective. :) <graywolf>Technically you could make nss-cert-with-search-paths, that would set the path same way curl does. Hm... that is actually not completely dumb idea. <GalaxyNova>what is the recommended workflow for hacking on a channel? <GalaxyNova>I've been maintaining my own channel with my dotfiles but the way I've been doing it is by making a commit each time and pulling from it and rebuilding my home environment ot test <GalaxyNova>it is kind of slow that way to iterate if I make a mistake or something <ieure>GalaxyNova, Hack locally, `guix home reconfigure -L/path/to/working/repo home.scm' <egnuun>Currently Guix is downloading a lot of packages for the container. Bash, llvm, clang. and now adding them to the store. <egnuun>That is my only real issue with Guix. The advantage of more "traditional" package managers is, they share resources (i.e. dependencies that are already installed) between packages, so they don't need to get installed again and again. <egnuun>But that's why I like Guix, because I know, that the devs are aware of the problem. And they are actually improving things over time. <ieure>GalaxyNova, The downside is that your home generation's metadata about what commit it came from will be a lie. But that usually doesn't matter. <ieure>egnuun, Dependencies are shared between Guix packages, it's a tighter association than on a traditional distro. <ieure>egnuun, Guix packages explicitly reference libraries by absolute path, if two packages need the same derivation of the same library, it's the same store path, only one store item is downloaded, both packages point to it. <egnuun>Also not in the container, it seems. <ieure>egnuun, Guix packages cannot share your foreign distro dependencies, those do get duplicated. <ieure>egnuun, And because of the way Guix triggers rebuilds when a package's input graph changes, you can sometimes have multiple different derivations of the "same" library. <ieure>egnuun, If it's getting downloaded, it's something that was needed which wasn't already in your store. <egnuun>Also it's just bash-*-doc and not bash itself. So that must already have been downloaded before. <decipaliz>hey, can someone help me with a peculiar error i'm getting while trying to define a package? `validate-runpath' fails when i try to build a zig application, says it can't find 'ld-linux-x86-64.so.2', and i'm at a loss here. here's the package definition (nevermind the giant patch, will think of how to get rid of it later) - https://paste.debian.net/hidden/9ce54d31, and here's the error message - https://paste.debian <ieure>decipaliz, The error means something is wrong with the linker phase, the binary's ELF header has an RPATH with one or more entires not satisfiable by the package's inputs. This is usually a thing handled automagically by the build-system. <decipaliz>hmm, maybe it's related to the fact that i'm deleting build.zig.zon? i think i saw that zig-build-system somehow utilises it, let me try to patch it too (i'm not a fan of how much patching needs to be done atp) <ieure>decipaliz, If you want more detail, you can build with the -K flag and go poke around the binary that gets built. The readelf tool will inspect the RPATH stuff.