IRC channel logs

2024-08-12.log

back to list of logs

<Rutherther>I am trying to use luks and lvm. I cannot boot though, and it seems the reason is that "insmod lvm" is not executed in grub. When I execute it manually, it sees the partitions on the crypt0 device
<Rutherther>Any idea why that could be?
<tadhg>@Rutherther might be https://issues.guix.gnu.org/70826
<tadhg>if you are trying to unlock with keyfile... wait that might be a different thing
<Rutherther>I am using passphrase
<Rutherther>here is my config https://termbin.com/8vd1
<Rutherther>I think the most important in getting luks and lvm working is putting them to mapped devices, and then making the root fs dependent on them with (dependencies mapped-devices). Or am I missing something?
<tadhg>if the grub.cfg doesn't have the right `insmod` line you expect it is definitely affected by code I've looked at recently but I know that is not at all helpful
<tadhg>the code touched by the edits in the issue I linked wasn't in the same place so that doesn't help much either
<Rutherther>it has insmod luks, insmod luks2, but no insmod lvm
<tadhg>hmmm.... doing a `grep -lr "insmod lvm" doesn't turn up any hits, nothing in gnu/bootloader/grub.scm looks relevant
<tadhg>presumably lvm stuff is supported in guix I just don't actually know how the mechanism works so I definitely can't be of service here
<Rutherther>it's interesting that I found a few users complaining about this, reporting in issues. But then they disappeared and the solution is nowhere to be found. Also someone made a patch, but they stated tests were passing before and after that patch, meaning the patch had no effect on it... it's strange
<tadhg>I mean, if they fixed something but didn't add a test for the case it fixed I can't imagine the maintainers would be quick to accept it in that form
<Rutherther>no, the patch was not accepted, it was closed after all https://issues.guix.gnu.org/60442
<Rutherther> https://lists.gnu.org/archive/html/help-guix/2023-02/msg00088.html this guy has basically the same issue as I do, but also no answer sadly
<new-guixer>Hello. I tried to hook up sass-dart/flutter to work with bash, and it would tell me "$PATH:dir" does not exist. So I used strace, and found that dart on execution is trying to find my US English locale file in gnu/store.., and never does. Any ideas what the issue is?
<Rutherther>found a similar config on github https://github.com/kennyballou/dotfiles/blob/22349ab3889f202dcfde4ca07dec14a0bf069a07/systems/axo.scm#L81 the only difference I see is that they have needed-for-boot true, I could add that ,but I don't really understand how that could change the behavior
<tadhg>@new-guixer does it show the full path in gnu/store? is it refering to a path that has been garbage collected or does the file it is trying to access exist?
<tadhg>I don't know enough about dart/flutter to help but I imagine the locale is either specified in the package definition in which case it should not fail or it is somehow determining it at runtime in which case I'm not sure anyone at guix can help
<tadhg>@Rutherther since the partitioning of drives is inherently out of guix's control it is clear that exotic scenarios are not super well supported. The current issue I'm tackling seems a good indication of that.
<Rutherther>tadhg I get that, but I didnt think lvm is exotic. And from repos of other people. It seems they use it, so it seems to be supported. But I am probably missing something... Anyway I am going to get rod of lvm since I dont really need it.
<xFFFC0000>I want to build with guix. What I mean is implementating my build logic inside GUILE too. A very prototype would be: https://paste.debian.net/1326139/
<xFFFC0000>If such a tool was available, that would be the Cargo for C/C++. solving C/C++ build problem.
<xFFFC0000>s/very prototype/very naive prototype/
<bdju>is there anything written anywhere about how to get thinkfan working on Guix System? my temps are quite bad and I'm getting frequent thermal throttling. I'd like to see if I can make the fan run faster to combat this.
<bdju>it seems to need a config file in /etc and a service. I tried some command from the arch wiki but can't seem to use it in its current state
<bdju>I'm using a T440p
<janneke>xFFFC0000: not enitirely sure what you want, have you seen potato-make and/or bespoke?
<janneke> https://github.com/spk121/potato-make, https://codeberg.org/lechner/bespoke
<xFFFC0000>potato-make was what I was looking for. Thanks.
<Ironsmith37>hello! i'm using guix 1.4.0 on Ubuntu 23 (for now) on a riscv64 system and getting an error when trying to run `guix pull`:
<Ironsmith37>| 'check' phasebuilder for `/gnu/store/bd5qfbhkyg9zw3nvz4pipr8xq324c01j-findutils-boot0-4.8.0.drv' failed with exit code 1
<Ironsmith37>build of /gnu/store/bd5qfbhkyg9zw3nvz4pipr8xq324c01j-findutils-boot0-4.8.0.drv failed
<Ironsmith37>digging deeper i can see that it's failing on a test: `FAIL: test-lock`
<Ironsmith37>checking the test log i can see that it hangs on the second test within this file:
<Ironsmith37>Starting test_lock ... OK
<Ironsmith37>Starting test_rwlock ...FAIL test-lock (exit status: 142)
<Rutherther>install without lvm was successful. raghavgururajan btw I did not go for a crazy setup like you wanted to have same root partition for both nixos and guix, but I have shared /boot, and here is updated tree https://termbin.com/rtsh. I can boot both. I use systemd-boot for nixos, grub for guix. Though I am not sure if this ports to non-UEFI systems as well. (my /boot is esp)
<raghavgururajan>Rutherther: Nice!!!!!
<raghavgururajan>Rutherther: Hey! I remembered why encrypting /boot is provided by coreboot/libreboot.
<raghavgururajan>Conventional distros use to have file like vmlinuz initramd etc under /boot
<raghavgururajan>Now I think they are either under / or under /boot.
<raghavgururajan>But we both won't see any files other than grub.cfg in /boot because, you use NixOS and I use Guix System.
<raghavgururajan>Both have those files in /[gnu|nix]/store instead
<raghavgururajan>That means it's encrypting the store and not /boot, for both our distros.
<Rutherther>they are under /boot. Someone even asked here yesterday if this behavior is possible on GuixSD as well. And I would also like to know. From skimming the code for grub it seems to me it's quite intertwined to providing it out of the store now. Which is a pity, since when store is under luks grub has to unlock it, and it takes a significant amount of time
<Rutherther>(for conventional distros I meant that they are under /boot)
<Rutherther>NixOS actually has them inside of /boot, it's visible in the tree I sent, I have them under /boot/EFI/nixos. I am not even sure if there is other way with systemd-boot, since it's much more minimal, and I don't think it supports unlocking encrypted devices
<raghavgururajan>Rutherther: So, as per CIA triad. Singing boot files,
<raghavgururajan> scratch that
<raghavgururajan>ignore above message, let me type fully
<raghavgururajan>Rutherther: So, as per CIA triad, signing boot files provide Integrity and encrypting them provide Confidentiality.
<raghavgururajan>Current UEFI only supports signing I think.
<raghavgururajan>Suporting encryption of boot files, will require bootloader to be present outside of HDD/SDD, like ROM in Motherboard.
<Rutherther>raghavgururajan: that makes sense, yeah, thanks. I personally didn't consider confidentiality in /boot
<raghavgururajan>And coreboot/libreboot provide that via payload.
<raghavgururajan>Cool!
<raghavgururajan>Just wanted to let you know, since we discussed yesterday. :-)
<Rutherther>yes, thanks for that, I appreciate it
<nikolar>hello guix, a bunch of packages that depends on rust are failing to build for aarch64
<nikolar>it seems like llvm (which is a dependency of rust) fails to build only due to a set timeout
<nikolar>so if someone could bump the timeout and rerun the build, that would be nice
<tschilp>Hi guix! I'm struggling a bit with how to handle rust (packages) on guix. I'm trying to use a package that requires rust-1.79 for compiling. We currently have 1.77.1. As I do not have a clue how I would use rustup on guix, I naively (could have know better) tried to compile rust itself. I did so cloning the repo, checking out 1.80.0, setting up the shell with ~guix shell git python curl pkg-config libiconv gcc-toolchain~ to get
<tschilp>close what the installation instructions tell me, and the running ~./configure --set install.prefix=$SOMEDIR~ and the recommended ~./x.py build~. Well, for bootstrapping it again pulls some binaries (cargo, rustc, rustdoc, rust-gdb, rust-gdbgui, rust-lldb) that guix will not execute ('no such file or directory', the classic error trying to run binaries for 'normal linux OSs'). Does anyone have hints for this situation? Funny enough,
<tschilp>some precompiled go-binaries seem to just run fine on guix, I never was lucky with rust so far...
<nikolar>as far as i know, go doesn't depend on glibc, so their binaries are self contained
<nikolar>rust does need the system's libc, and presumably it can't find it
<nikolar>you could try setting LD_PRELOAD to the location of the libc.so
<spanko>> some precompiled go-binaries seem to just run fine on guix, I never was lucky with rust so far...
<spanko>Rust is highly api-dependent, and I think Go is statically linked
<spanko>(abi*)
<spanko>Try to `ldd` your problematic binary
<Rutherther>tschilp: there is already rust 1.79 in guix, just use rust-1.79 out of gnu packages rust
<Rutherther>I do not know why the specifications match rust 1.77 though. The name is just "rust" as all other packages, so I would expect it to be matched
<nikolar>spanko: both rust and go are statically linked, the difference is that rust is only mostly statically linked
<nikolar>they depend on the system's libc
<tschilp>nikolar, spanko, Rutherther: thanks for your input, this makes things clearer to me and with the hint at 1.79 most likely solves my problem!
<nikolar>no problem
<Rutherther>ah, I see the reason. The versions used in the bootstrap chain are hidden. That's why specifications do not match them. There is property hidden #t on them
<Rutherther>and the comment says that these rust versions should not be relied upon :( so I am not sure if this will solve your problems. The rust version in guix is overriden from one of the rust versions in the bootstrap chain. There are quite a lot of changes from it. So maybe the one from bootstrap chain will not work properly.
<nikolar>are you not supposed to specifiy rust-1.79 or whatever?
<Rutherther>the package is exposed from gnu packages rust module as rust-1.79, yes. But hidden, so you cannot get it directly with specifications, ie. guix build command, you need to make .scm file where you include the module
<nikolar>ah so you can use it if you need to
<Rutherther>yes, but because it's mainly for the bootstrap chain it might not work properly for compiling some apps. You can try and see. If not, not sure what the best course of action is then
<nikolar>rust is such a mess
<spanko>its a shame
<nikolar>what is
<Rutherther>btw have you seen these?
<Rutherther>there is a section on rustup, using fhs, https://guix.gnu.org/de/blog/2023/the-filesystem-hierarchy-standard-comes-to-guix-containers/
<Rutherther>also someone made https://github.com/declantsien/guix-rustup, seems that will obtain you a rust toolchain, using guix. nixpkgs has something similar, but it's not guix
<AwesomeAdam54321>nikolar: I was working on the antioxidant build system because rust is such a mess
<nikolar>That sounds familiar
<AwesomeAdam54321>Unless there's a clear plan on how it's going to be merged in guix, things will stay the way they are with regards to rust
<nikolar>It's such an over hyped language it's not even funny
<spanko>> what is
<spanko>that rust is a shame
<nikolar>Rust is a shame indeed
<spanko>lmao
<spanko>that rust is a mess*
<nikolar>Rust is a shame and rust is a mess you're right :P
<Franciman>i really like it as a language. But as a packager? My gosh if I hate it
<tschilp>Rutherther: thanks for the fhs-link, I did not know about it at all. Seems I had to modify it a bit to ~guix shell --network --container --emulate-fhs bash coreutils curl grep nss-certs gcc-toolchain pkg-config glib cairo at-spi2-core pango gdk-pixbuf gtk+ git --share=$HOME/temphome=$HOME~
<tschilp>(removing gcc:lib, pango versioning and using at-spi2-core instead of atk). Now I'm slightly lost, because I'm sitting inside ~temphome~ and cannot reach anything from there, but run rustc 1.80.1 via rustup ;)
<tschilp>I guess I'll curl the program from there :)
<Rutherther>that share flag should give you ability to access your filesystem
<Rutherther>the way you specified it you should have your $HOME/temphome mounted do $HOME in it. If you want whole home, just remove that /temphome
<tschilp>OK, that's cool. I was monkey-copy-typing. Now I set the source code dir as home and give it a try.
<tschilp>Thanks again. Inside this fhs-emulated shell I still had to set LD_LIBRARY_PATH to /lib, but the binary works nicely outside the shell as well now!
<Ironsmith>hello guix! i'm using guix 1.4.0 on a riscv64 system running Ubuntu 23 and getting an error when trying to run `guix pull` : `| 'check' phasebuilder for '/gnu/store/bd5qfbhkyg9zw3nvz4pipr8xq324c01j-findutils-boot0-4.8.0.drv' failed with exit code 1` `build of /gnu/store/bd5qfbhkyg9zw3nvz4pipr8xq324c01j-findutils-boot0-4.8.0.drv failed` digging
<Ironsmith>deeper i can see that it's failing on a test: `FAIL: test-lock` which is hanging on the second test: `Starting test_lock ... OK` `Starting test_rwlock ...FAIL test-lock (exit status: 142)` looking into that, it looks like this used to fail for aarch64 on 8 cores and x86_64 on 32 cores. there was a patch a few years ago but it was removed, looks
<Ironsmith>like upstream findutils/gnulib fixed the issue?
<Ironsmith>trying to apply the old patch but not sure how to setup a dev environment for this. i tried the cookbook my-hello.scm package example but when i try to install that it via `guix package --install-from-file=my-hello.scm` it fails the with same error i'm getting when trying to `guix pull`
<Ironsmith>can anyone give me pointers on how to create a dev environment to test out different patches for `findutils` so that i can debug why i can't `guix pull` ?
<Deltafire>oh, the massive one with a rest area in the middle?
<Deltafire>^ ignore
<AwesomeAdam54321>Ironsmith: Can you install packages using guix 1.4.0? If the guix 1.4.0 environment has the same error as well, then it'll probably be a bit tricky to fix
<Ironsmith>good question, i think i was able to but let me double check that now
<Ironsmith>no everything i try to install tries to build findutils-boot0-4.8.0 (strange though, is it because this is a depedency? i see 4.9.0 is the latest). i'm going to try to reinstall guix completely
<OnASnoopPhone>Hello! I was thinking about switching to guix as my first fully free distro to replace gentoo when I get a wifi usb dongle or a computer that works with a fully free distro. However, as a gentoo user (a source based distro), I seek the power to freely compile packages using the package manager, set compile flags for them permanently, and even set specific compile flags globally. Is that possible with guix?
<tadhg>It is abaolutely possible but may require more overhead code compared to gentoo
<tadhg>"permenant" is the main issue, you'll likely need to do a lot of transformations to ensure all the dependents are using your modified version of a package as nothing gets installed globally everything references specific builds of packages in the gnu store
<Franciman>i think there is makeopts somewhere, wait
<Franciman> https://www.reddit.com/r/GUIX/comments/adm40o/gentoolike_use_flags/
<Franciman>this is an example
<OnASnoopPhone>tadhg, you mean that I need to make sure I select the version of the package I configured for its deoendencies know about it?
<Rutherther>OnASnoopPhone: you have to explicitly override the packages to have the flags you want. Like what's on the link. You cannot just do "guix build xyz" and expect xyz to have the flags, you would need to make .scm file that will expose xyz, overriden with the flags. You could of course make your own functions for that to make it easier to do.
<Rutherther>Or alternatively you would have to fork guix, and make sure to include the flags in the builds. Then you could do guix build xyz. But that's probably more work, and still won't work anywhere you use different version of guix, such as with time-machine or inferiors to get older revision of a channel
<tadhg>OnASnoopPhone: Basically, like a specific example is if you use syncthing service you never explciitly install or include the *package* for syncthing you just list the service, if you want to patch something that syncthing depends on you have to setup the transformation that replaces the dependency and explcitly give the transformed syncthing package to the service for it to use your patch, and you may need to
<tadhg> do this for every service
<tadhg>I'm also unsure what you even mean by globally set compile flags, like not all packages are built with gcc so idk what you even expect to accomplish there
<OnASnoopPhone>Right Rutherther, I'm looking at the link and they talk about some sort of code, so I would need to put that in a package install file or whatever it's called here (on gentoo its name is "ebuild")? Or what does that expose and override mean here?
<OnASnoopPhone>tadhg, global flags on gentoo work like this: On example, I can set wayland support globally, which means packages, when they have a wayland option, will compile with its support without requiring setting specific flags in another file. I can do this by editing a config in the package manager.
<Rutherther>OnASnoopPhone: whole Guix is configured with guile. You would need to put it to your operating system config, and also to other stuff like your user profile files, basically everywhere where you want overriden packages come from. There is no "global" config
<OnASnoopPhone>Oh ok, so there is no global flag setting possible, but it is possible to override default flags for specific packages by making some sort of guile scheme file override? Also, according to tadhg, it would also require configuring/transforming it and packages that depend on it?
<tadhg>Ok but the way wayland support is enabled isn't consistent, there are a lot of packages in guix that enable support for wayland by default but sometimes there are compiler flags, sometimes environment variables, usually added dependencies but which are needed are not totally consistent...
<tadhg>If you have a working copy of guix you can pass `--export-manifest` (might be called something else, check `--help` if that is wrong wording) to basically any command to show how you would specify the same command line modifications as a guile transformation
<tadhg>See `Scheme Procedure: options->transformation` at https://guix.gnu.org/manual/en/html_node/Defining-Package-Variants.html
<OnASnoopPhone>So e.g. lets say package "gnubg" pulls in package "X" because it has X window system support compiled by default. If I would override it so it will not compile with X support, it will still pull in that package if I don't also override its dependencies and similarly when enabling support for something?
<tadhg>You'd write a guile definition for the variant of X, you'd specify a transformation that replaces the original X package with your nrw one and then apply that transformation to the things that need it
<tadhg>Orfor sake of argument, you define all the variations of all packages you want, plug them all in the same transformation and then apply it to the list of all the packsges you want installed
<OnASnoopPhone>So I basically need to specify the dependencies myself while setting the compile flags?
<Rutherther>OnASnoopPhone: no, you can override all deps with one procedure that will map them. The thing is where your package X that you want overriden goes. You need to make sure that the overriden package X is passed there, and not the one without overrides.
<OnASnoopPhone>So I can map specific packages to specific flags? E.g. map the package X to X support?
<Rutherther>yes, of course. You can transform package X with flags A, and package Y with flags B
<Rutherther>and this can traverse the whole tree if you wanted, where for each dependency you could specify specific flags. Or you can just apply the same ones to all dependencies. Up to you
<OnASnoopPhone>So you mean that e.g. when I have package X installed and I install another package, that one gets installed with X support contrary to the packages installed before installing X because I overrode X to set specific flags?
<Rutherther>sorry, I don't understand what you mean
<Rutherther>it gets built with transformation you will apply now to that package. It doesn't matter what you did with other packages before. Because there is no "global config" for that
<OnASnoopPhone>I'm also trying to understand your messages... So anyways it seems like in Guix, it is possible only to compile specific packages with specific flags by overriding them somehow with a guile scheme file, which will also need to override the dependencies and such. So it's harder to do as in Gentoo, but is it still possible to get a speed boost by not getting a substitute because it will compile for the specific system, right?
<AwesomeAdam54321>OnASnoopPhone: Yes
<Rutherther>OnASnoopPhone but guile is a powerful language, you can of course apply it to many packages at once, as can also be seen on the reddit link someone sent earlier.
<OnASnoopPhone>It can get applied to many packages at once? So are global flags possible?
<Rutherther>Yes. No.
<OnASnoopPhone>So yes, but with some caveats?
<Rutherther>The transformation you specify in your system config file does not go into packages you install from completely different file or method. Such as if you used "guix build xyz"
<OnASnoopPhone>So it will only work in a specific way? E.g. "guix install xyz" will work? (if that is the normal install command)
<Rutherther>No, that wont work. You have to provide the transformation method. If you wanted to use guix build or install, you cannot just put the name of the package. Instead, you need to make scm file that will apply the transformation
<OnASnoopPhone>So I basically need to specify the transformation method correctly with some guix (runtime) flag? e.g. "--transform=file.scm"
<Rutherther>Something like that
<OnASnoopPhone>Alright, so in summary, it is possible to get the power of gentoo in guix, but with some additional caveats and obstacles, requiring specifying transform files etc.. Thank you so much for your help! I'll probably try out guix anyway, since it actually cares about freedom contrary to gentoo and I may still be able to tinker with packages to get my favourite compile flags working for them.
<tadhg>The way I see it is that the packages "installed" (available for your use) on your system come from 3 places: your OS config, your profile, and your home config.
<tadhg>the OS config file and optionally the guix home config file will explicitly list out packages and services to enable where you can specify variants or transformations
<tadhg>When you do `guix install X` it gets added to your profile but you can manage the entire set of installed packages in the profile with a manifest in order to specify the same transformations there
<tadhg>If the transformations are straight forward like using a specific git url and commit for a package and it only matters for packages you specify manually then it is pretty trivial. If the modification is used by some particular desktop service you just specify as `%desktop-services` (like say D-Bus) then getting your transformation to the right place may be more annoying but still doable
<tadhg>If the transformations are more complicated you will need to get familair with guile and guix packaging which is a skill but will probably have nore freedom than you could with gentoo
<Rutherther>tadhg isnt it somehow possible to get operating system package and call package-mapping on it?
<elevenkb>Hello there, I'm having trouble running `ipfs-service-type'
<ieure>What's the magic needed to have my Cuirass/substitute server return CI information when I run `guix weather' like the official ones? Guessing that I need a reverse proxy which maps certain paths to cuirass and others to the substitute server, but the docs don't seem to mention how to do this.
<ieure>Bonus if I can point a browser at the same URI and get the Cuirass interface.
<elevenkb>/var/lib/ipfs/.ipfs/config has the wrong permissions apparantely.
<tadhg>Rutherther if there is I am unaware of it, because some stuff like the grub install package is only built and used during the `system reconfigure` step it would certainly be nice but I could see how it wouldn't be trivial for a maintainer to implement
<Rutherther>Any tips on making boot with grub faster? It takes a lot of time for grub to decrypt
<tadhg>I don't but wish I did
<Rutherther>I think it should be possible to change the bootloader to copy the stuff to boot, but it will be a lot of work probably.
<tadhg>I don't think it would be too much work, like if you look at the grub.cfg you can see all the files referenced in the store, you would just leave the gnu.load and other linux arguments that are read by the kernel after loading
<tadhg>The bigger issue which is why it isnt a supported feature already is that if you update the kernel and it has a critical issue and you want to boot a previous generation where would that image be?
<Rutherther>Nixos solves this by having the files with hash in name
<tadhg>yeah and guix does the exact same, and if you want to put your entore guix store on an unencrypted drive that grub can read then you'll be golden
<tadhg>You are talking about copying stuff out of the store into the boot partition, how many generations of kernels do you want to maintain theref
<Rutherther>The problem is I dont want that. What I meant is that nixos copies them from store (that may be on encrypted partition) to /boot, and keeps hash in name to allow booting to arbitrary generation you keep
<Rutherther>Nixos has an option for how many generations to keep. Not sure about guix. It then deleted the previous ones
<tadhg>Hmm, to my knowledge guix copies one image for grub and stores all linux kernels in the normal store, none get copied to the boot partition
<Rutherther>Yes, exactly
<tadhg>I do know I've hacked together a setup where I manually set the linux image but used the same gnu.load parameter from a generation to load the same system config stuff and that worked, like I'm sure getting it to be done in guile wouldn't be terribly complicated but setting how many revisions back to copy into the boot partition wouldn't play well I imagine
<tadhg>As far as guix cares deleting old generations is a gc operation and only changes which things in the store are considered essential
<tadhg>Oh wait, it would also regenerate the grub config of which generations can be loaded, actually it might play decently well
<Rutherther>You dont really have to do that, you can just set number of actual system generations to keep, making it much easier. Yes, its a tradeoff, but I would be willing to go for that since I really dont like waiting 30 seconds for decryption
<Rutherther>The deletion in NixOS is done upon bootloader installation, based on which generations are still gc rooted
<Rutherther>I think it could be made the same on guix
<Rutherther>I will try to get around to it, sounds like a nice project
<somethingidk>hi, what exactly is guix? is it a package manager or an OS ?
<ieure>somethingidk, It's both. "Guix" is a package manager, "Guix System" is an OS based on that package manager.
<galois`>When was the guix website improved?
<nikolar>it's been like this for a while
<galois`>Hmm okay. I havn't visited it lately. But it looks decent now.
<somethingidk>can you achieve a reproducible machine with just the guix package manager?
<jaft_r>Anyone here have any experience switching from the pulseaudio service to pipewire, specifically so screensharing can work on Wayland? Got an interview coming up on Wednesday…
<somethingidk>why do you want to switch to pipewire
<jackhill>jaft_r: I haven't gotten around to setting up the home service, but starting pipewire and wireplumber manually seems to work for me. What compositor?
<jaft_r>jackhill: Wayfire
<jaft_r>somethingidk: Need to screen share. As I understand, – under Wayland – that's not possible unless with Pipewire.
<jaft_r>Or maybe not Wayland in general but true for wlroots.
<jackhill>jaft_r: oh, the other thing is to have XDG_CURRENT_DESKTOP set correctly so the right portal gets selected
<jaft_r>jackhill: Anything with step-by-step instructions? I'd been considering trying it out, at some point, but I'd been focusing mostly on preparing for the interview for today and tomorrow so I don't want to get too lost in the weeds and burn up that time with otherwise, you know.
<jackhill>jaft_r: I don't have any at hand currently, sorry. I assume this will be via a browser?
<jackhill>I might look here for hints: https://wiki.archlinux.org/title/Screen_capture#Via_the_WebRTC_protocol
<jaft_r>jackhill: understandable. Teams (🤮) meeting so yeah; via the browser.
<jackhill>I wonder what would happen if you ran the browser and whatever you wanted to share both via xwayland
<Franciman>hi, is guix compatible with https://github.com/apple-oss-distributions/xnu kernel?
<Franciman>darwin kernel, i mean
<jaft_r>Franciman: It isn't. Guix uses some Linux-specific features so, outside of Linux and the Hurd, it isn't able to run on any other kernels/OSes. I forget where I read that but I'll share it, if I find it.
<Franciman>thanks