IRC channel logs


back to list of logs

*civodul processed some of the patch backlog
<civodul>i'll be afk for a few days
<civodul>i hope fellow committers can take a look at the backlog in the meantime :-)
<the_tubular>Enjoy your break civodul :)
<civodul>the_tubular: thanks :-)
<civodul>will do!
***rekado_ is now known as rekado
<Aurora_v_kosmose> Is this actually true regarding the instructions though? Or does GCC (among others) simply test for instructions existing at load/runtime and use them opportunistically?
<cehteh>the runtime detection is used commonly, but its not opporunistic, it needs some machinery to gather cpu features and then branch into the approbiate paths
<Aurora_v_kosmose>cehteh: But can it be told to build with such detection/gathering machinery?
<cehteh>iirc the kernel does it even wilder, patching itself on instruction level, at least it did that, dunno if thats still state of the art
<cehteh>dunno how firefox does this, but a friend just did that for rust and AVX optimizations
<cehteh>in a rust program i mean
<cehteh> for example
<xelxebar>Hey Guix!
<xelxebar>Recently, I've had the need to run three separate Electron apps.
<xelxebar>In general, when I find something not in the repo, I like to package it up. However, as node apps with approximately 3↑↑↑3 dependencies, I'm at a loss for how to properly go about packaging.
<xelxebar>Trying to build with node-build-system, ends up failing with ENOCACHE.
<xelxebar>By throwing all the build and runtime dependencies in a guix shell, I'm able to get the apps running, using appropriate FONTCONFIG_PATH and LD_LIBRARY_PATH envars.
<xelxebar>That recudes the problem to dependency handling. Are there any ongoing discussions etc. about this?
<Aurora_v_kosmose>Well, there's a way to explicitly do it in GCC with multiversioning...
<xelxebar>Aurora_v_kosmose: Not sure I follow. We're talking about nodejs deps, right?
***bjc` is now known as bjc
<euandreh>Is there an function akin to (wrap-program ...), but that allows one to set flags instead of environment variables?
<apteryx>what do you have in mind more specifically?
<euandreh>right now, create a personal "wget-hsts" package that inherits fully from "wget"
<euandreh>but that puts --hsts-file=my-path-goes-herer right before "$@"
<euandreh>so the wrapped executable would be just 2 lines: a shebang and "exec "/gnu/store/.../.wget-real" --hsts-file=... "$@"
<Aurora_v_kosmose>xelxebar: I mean more things like vectorized instructions.
<Aurora_v_kosmose>So that a program can run on old x86 cpus and brand new one with appreciable performance improvements from those.
<xelxebar>Aurora_v_kosmose: Oh, I must be missing context. Thought you were responding to my question.
<Aurora_v_kosmose>Ah, sorry no. You joined some time after I asked my own.
<xelxebar>You have me interested in this multi-versioning capability though! :)
<Aurora_v_kosmose>xelxebar: +resposting+ Is this actually true regarding the instructions though? Or does GCC (among others) simply test for instructions existing at load/runtime and use them opportunistically?
<Aurora_v_kosmose>Basically, it goes on about Gentoo allowing for modern optimizations on CPUs that support it due to being built locally & all.
<Aurora_v_kosmose>But that would fall flat if GCC and other compilers were to have the ability to dynamically detecting such features and use them.
<Aurora_v_kosmose>Naturally Guix has the same ability as Gentoo on this aspect, though perhaps not the same build flag defaults (as it would hinder reproducibility on machines that lack such instructions).
<xelxebar>Aurora_v_kosmose: You might be interested in the Guix HPC blog:
<Aurora_v_kosmose>If dynamic detection is implemented in GCC, using it by default might be viable and reproduce the same benefits as Gentoo in Guix (minus some disk space).
<xelxebar>AFAIU, gcc doesn't automagically do any runtime instruction detection. That's typically something that the engineers stuff in and build "fat binaries" with microarch-specific execution paths.
<Aurora_v_kosmose>Yeah... I know gcc has explicit multiversion support, but implicit would be significantly more useful on a distribution level.
<Aurora_v_kosmose>As otherwise you effectively have to build all packages for your system locally to have the same benefits.
<Aurora_v_kosmose>Which I suppose might be as simple as modifying the global gcc build-system definition to include those flags
<Aurora_v_kosmose>But that comes at significant downsides in time spent building stuff.
<xelxebar>Yeah, it would be nice, but the tradeoffs are non-trivial, no? Detection itself is a non-zero (albeit small) and somewhat tricky overhead, while carrying around enfattened build products has the obvious size overhead.
<Aurora_v_kosmose>Indeed. How worth it it'd be for a distro depends on how much it minds such bloat. Some programs might see very little bloat, while some might more than double in size.
***CodeKiwi is now known as DigitalKiwi
<Aurora_v_kosmose>xelxebar: Oh, tunable packages are pretty neat.
<Aurora_v_kosmose> That "properties" option is not documented in the package reference.
<littlebobeep>Why does define-public gccgo-4.9 have a multline custom-gcc block, but define-public gccgo-10 and define-public gccgo-11 are basically empty?
<milia[m]>Hello! Is there a way to use non OSS and non GNU in guix, such as zoom and WhatsApp? I guess it's not suggested, but was wondering if it's at all possible.
<milia[m]>* non GNU software in guix,
<kitty1>milia[m]: There are *plenty* of non-GNU things in the default repository ; for non-free software you will have to find a channel that supports them or write your own channel definition.
<milia[m]>kitty1: Great, thanks!
<kitty1>some non-free protocols can also be bridged with free ones, but generally if possible I think most people (including myself) in this community would just try to convince anyone else to use free software if at all possible lmao
<kitty1>np uwu
<kitty1>er like
<kitty1>as in when communicating with them , because frankly its just so much nicer when the other party is able and willing lmao
<littlebobeep>Is this Electron app being built from source? ^
<bost>I wonder if there is no emacs 28.1 in the official guix channel and you all install it manually / from elsewhere...?
<bost>I mean, if there is *really* no emacs 28.1 in the official guix channel...?
<kitty1>bost: as far as I am aware the newest one on the default channel is emacs-next, which is at 28.0.50-02ea3466 .
<bost>kitty1: that's rather surprising.
<jpoiret>it shouldn't be too hard to adapt the current emacs-next to be 28.1
<munksgaard>Which package do I need to install for the`as` binary?
<jpoiret>munksgaard: gcc-toolchain
<munksgaard>jpoiret: Thanks
<FlaminWalrus>Anyone have an example of a package definition that uses an origin snippet to remove a file? I'm still trying to wrap my head around gexps...
<littlebobeep>How much RAM is necessary to compile ungoogled-chromium and icecat?
<jpoiret>FlaminWalrus: make-linux-libre-source in gnu/packages/linux.scm does that
<FlaminWalrus>jpoiret: thanks for the tip. Any idea why some places the gexp #~(begin...) is used some places and just the quote '(begin...) in others?
<jpoiret>historically, gexps came pretty late in Guix, and package build phases used simple S-Exps instead (eg '(begin ...))
<jpoiret>all of the packages are being moved to g-exps but it takes a lot of effort
<jpoiret>you should definitely use gexps for new code
<xelxebar>Aurora_v_kosmose: That might be intentional. I don't think properties is intended for generic use, really. If you dig around in the repo, it seems to be mostly a place where internal and "obscure" package info is stored.
<xelxebar>littlebobeep: It looks like that's building from source. Doing a little sleuthing, it looks like yarn2nix is doing most of the heavy lifting:
<xelxebar>It looks like yarn2nix is a wrapper that creates a package containing all the lock file deps. Then that package gets used to populate the node cache for the desired package.
<xelxebar>It's quite non-ideal from the package management standpoint, since you get zero dependency sharing between node packages.
<xelxebar>But it is nice to have *some* method for packaging up node apps.
<jpoiret>oof, match and delayed/thunked fields in records don't mesh well
<jpoiret>even match-record doesn't seem to work with it
<littlebobeep>xelxebar: I am worried about missing LICENSE info for all the modules that get download and yarn's ability to accurately report which of these files ends up in the binary
<xelxebar>Oof. Yeah. That's definitely a legitimate concern. The licensecheck tool might be helpful, after pulling deps into node_modules.
<bjc>does guix support building virtual machine images with lvm?
<jpoiret>bjc: that is, building a vm that uses lvm for its partitioning scheme?
<bjc>i don't think lvm applies to the partition level, but uses existing partitions
<bjc>so you'd partition the disk, assign partitions to lvm, then format the lvm volume
<jpoiret>it gives you additional partitions too
<jpoiret>well, block devices if you want but yes
<bjc>i'm interested in using it with a disk that contains an efi partition, as well, so i can't give it the whole device
<jpoiret>you want to create a whole disk for a vm?
<jpoiret>do you really need a specific partitioning scheme for that vm?
<bjc>yes, because i want to use it as a test bed for a bare metal install
<jpoiret>on bare metal that'd be different
<jpoiret>then i suggest running the install in a vm itself
<jpoiret>it'll be more akin to a usual installation so that you'll get a feel for it (if you haven't already) and it'll support lvm for sure
<jpoiret>as for guix system image support, i don't think there is right now
<bjc>i'd have to set up the disk by hand to use the installer, though, right?
<bjc>since it doesn't seem to support lvm natively
<jpoiret>i think guix system image overrides whatever file-systems are defined by the config, depending on the image type
<jpoiret>bjc: with a manual install, everything is possible
<jpoiret>i don't think the graphical installer would work with lvm
<bjc>right, but my end goal here is to be able to install it with lvm at some point
<jpoiret>but you can do so with the manual install. it's not that much more complicated than the graphical one
<bjc>and before then i have to make sure that the bootloader and things work correctly with lvm, since it changes how things work a bit
<jpoiret>you just have to type the relevant commands
<bjc>ie, guix system reconfigure can't blow anything up with lvm
<jpoiret>not more than guix system init :)
<jpoiret>not less either
<lamdacore>hi, I am attempting to setup a fresh guix in a logical volume (LVM on luks to be precise with a separate boot partition). Could anyone help me /give me hints on how to make dual work work in such a setup? I am using systemd-boot
<bjc>seemed like starting with a vm image that has the disk set up correctly and then running the reconfigure commands inside it would be the most straight-forward way to go
<jpoiret>bjc: rather, you should run the installer iso in a vm and do a manual installation i think
<jpoiret>in any case, you'll have to partition the disk, either through the graphical or manual install, and for lvm you'll need the manual one
<milia[m]>Sorry to ask... What are the most striking differences of guix comparing to NixOS?
<jpoiret>lamdacore: are you using luks2?
<jpoiret>milia[m]: nixos has its own configuration DSL, whereas Guix uses the full power of GNU Guile, a Scheme dialect!
<jpoiret>that means that we're able to add incredible features on top of guix all the time while tinkering
<jpoiret>ie. it's more hacker-friendly
<bjc>i was thinking if a step were added between the image partition and the image formatting, where volume management could be set up, that'd be pretty flexible
<jpoiret>and you can do much more
<bjc>long term i'd like to zfs-on-root, which would require something similar
<jpoiret>although first downside: nix's community is way bigger than guix's, although you could argue that guix's is very tightly-knit
***piyo` is now known as piyo
<jpoiret>bjc: most distro installers have volume management inside the image partition step
<jpoiret>the graphical install is here mostly for generic setups, the manual install covers all the other use-cases, as niche as they can get
<bjc>in the case of disks with an efi partition, you'll always need something between the gpt-level partitions and the volume management, though
<milia[m]>jpoiret: Thank you !
<lamdacore>jpoiret: yup luks2
<jpoiret>lamdacore: as for the systemd-boot thing, i suggest adding an entry in systemd-boot that loads up Guix's own GRUB, because that way it would be 100% compatible
<bjc>and, at least in the case of lvm, i think that's sufficiently end-user to warrant work in the area
<jpoiret>Guix likes to have its own bootloader, because it wants to support rollback, and we don't have systemd-boot i think
<bjc>there is no systemd-boot, no
<jpoiret>bjc: right, but that requires significant work
<lamdacore>I see. yeah. i saw the linked initrd and images and didnt know how to proceed.
<jpoiret>my (very personal) opinion on the matter is: if you know what LVM is, you most likely can manage a manual installation which will serve you well
<lamdacore>so which bootloader type should I chose here? "grub-efi-bootloader"?
<bjc>jpoiret: i figured it would, which why i'm trying to do as little at a time as possible while still being useful. which i think is getting support in vm image creation, to be able to have a test bed for future work
<jpoiret>lamdacore: yes
<lamdacore>and the target is "/boot" where I should found my vfat EFI partition to it?
<bjc>i've had distros install on lvm by default. and its a requirement for luks, which is becoming much more mainstream
<apteryx>I guess patching of shebangs does the right thing (use inputs in preference to native-inputs) ?
<jpoiret>lambdacore: you mentioned that you have an unencrypted /boot, right? that's needed right now for luks2
<jpoiret>lamdacore: sorry for the typo ^
<lamdacore>jpoiret: yeah it is an unencrypted seperate fat32 parition
<jpoiret>personally, I mount my efi partition at /esp and bind-mount /esp/EFI/Guix/ to /boot
<jpoiret>so that my efi partition is nice and clean
<jpoiret>that will definitely work, but you could also go with esp on bare /boot/efi
<jpoiret>you're using efi right?
<jpoiret>although it may look unclear, what i'm saying is that you can also totally use your EFI partition for your Guix's /boot needs, since it won't even install the kernel there (only GRUB)
<lamdacore>yes efi. I am always confused with esp/efi partitions and where EFI images go.
<jpoiret>bjc: i wouldn't say it's a requirement, i'm using bare BTRFS on LUKS, it works wonders
<lamdacore>and I am unfamiliar with how grub works.
<jpoiret>GRUB's just a bootloader
<jpoiret>it will load your kernel and initrd, and can unlock and read whataver partitions it needs to do that
<bjc>huh. i really thought you needed lvm for luks
<jpoiret>on guix, both your kernel and initrd will be in /gnu/store, so not on boot at all
<bjc>color me surprised
<lamdacore>I'll give your suggestion a shot with /esp and /esp/EFI/Guix/ to boot. how do I configure a bind mount in config.scm?
<jpoiret>let me give you the relevant part of my config.scm
<jpoiret>lamdacore: do you know a bit of scheme?
<bjc>ohhh.. do you have to bind mount the esp so that /boot/grub/grub.cfg exists?
<bjc>i was wondering what you did that for
<lamdacore>jpoiret: yes, I found the links to the profiles. which is untennable to create and maintain with just a vfat EFI
<jpoiret>let's say i don't necessarily have the most "bare" config
<jpoiret>bjc: basically, yes :)
<lamdacore>jpoiret: thanks. a little - I am more familiar with common lisp and elisp
<jpoiret>oh, if you're okay with lisps then it'll be a breeze
<jpoiret>lamdacore, bjc:
<jpoiret>you can ignore the btrfs shenanigans if you want
<apteryx>bjc: lvm for luks? nope. It'd be a bit ridiculous to have to setup LVM just to encrypt flash drives :-).
<bjc>apteryx: have you seen how apple does it? it's basically lvm in order to get luks
<bjc>so i guess i just assumed
<lamdacore>jpoiret: thanks will give a shot later today.
<lamdacore>BTW, do i need to include some module in my config for lvm?
<lamdacore>Here is what I have so far:
<jpoiret>no, you shouldn't need it
<lamdacore>would appreciate a quick sanity check.
<jpoiret>you're missing something in swap-devices
<bjc>does guix even install anything in /boot other than grub?
<jpoiret>oh, are you using the latest or 1.3 installer?
<apteryx>bjc: I don't know how Apple does it (and with LUKS being a Linux/GPL thing, I am surprised they are using it at all)
<jpoiret>if you're using latest installer, you should use the devel manual at
<bjc>i'm trying to figure out why you don't just mount the esp in /boot
<jpoiret>the swap-devices specification has changed
<jpoiret>bjc: I like having my ESP tidy, by separating the different oses
<lamdacore>1.3 non-guix installer from Jan. since I needed firmware for the amd apu on my laptop.
<bjc>apteryx: they're not using luks/lvm, just the apple nih-equivalents of volume management and encryption
<jpoiret>so grub/ ends up in /EFI/Guix/ rather than in / of the ESP
<jpoiret>lamdacore: oh, then it should look okay
<lamdacore>yes. I saw the warning for the swap devices. but I couldn't grok what changed in the documentation
<jpoiret>but then as soon as you update guix on your newly installed os, you'll need to adapt your config for the new style
<jpoiret>well, maybe it's because you were looking at the 1.3 manual, rather than the development one
<bjc>i found the deprecation notice lacking as well. i can't remember how i figured out what to put there, but i suspect it was reading source ;)
<lamdacore>ok tha explains it :)
<lamdacore>any hints on chroot and reconfiguring? otherwise I will rerun guix init via the usb-drive
<jpoiret>i remember chrooting being quite annoying
<jpoiret>you're better off just guix init'ing again
<lamdacore>roger. 👌
<apteryx>when would this occur? Throw to key `decoding-error' with args `("peek-char" "input decoding error" 84 #<input: user-commands/ 15>)'
<apteryx>or more like why
<apteryx>this is trying to run substitute* on user-commands/ in
<apteryx>hm, works outside of the build env, so perhaps locales?
<apteryx>seems to choke on this line: "normally, C<ä> is sorted like C<ae>, but in phone books or"
<jpoiret>oh no, locale problems
<apteryx>I'll try sed for the kinks
<apteryx>err, "for kicks"
<apteryx>works with sed
<apteryx>sadly there doesn't seem to be a 'ignore' port conversion strategy in Guile
<apteryx>only ‘error’, ‘substitute’, or ‘escape’ (the default being error)
<apteryx>actually sed had that ä character converted to C<<E4>> in the build environment lacking the needed locale
<jpoiret>is the file not UTF-8?
<apteryx>yes it is
<apteryx>oh, wait
<apteryx>emacs says multi-byte: iso-latin-1-unix
<jpoiret>erf, and i guess substitute* doesn't take an #:encoding key
<jpoiret>you could (with-fluid %default-port-encoding ... (substitute* ))
<jpoiret>where ... is the encoding
<apteryx>no but we can probably change the default port-encoding globally
*apteryx reads info '(guile) Encoding'
<jpoiret>i think the with-fluid approach above does exactly that, but locally
<apteryx>example spotted in marble-marcher
<apteryx>(with-fluids ((%default-port-encoding #f)) ... )
<apteryx>the Guile default port encoding is ISO-8859-1? Heresy.
<jpoiret>depends on whether the locale is initialized
<apteryx>where is this mentionned in the Guile Reference manual?
<jpoiret>in Encoding, right under %default-port-encoding
<apteryx>"The ‘%default-port-encoding’ itself defaults to the encoding appropriate for the current locale, if ‘setlocale’ has been called.", OK. And how does setting this to #f end up choosing ISO-8859-1 as the encoding?
<apteryx>ah, I need to slow down and actually read :-) "As a special case, the value ‘#f’ is equivalent to ‘"ISO-8859-1""
<apteryx>I'll go explicit then
<apteryx>solved, thank you :-)
<SrEstegosaurio[m>Hello, I was trying to install GUIX following the graphical install. But it fails every time due to a GRUB error. I tried searching or installing GRUB manually with the same result.
*SrEstegosaurio[m uploaded an image: (844KiB) < >
<SrEstegosaurio[m>Sorry about the quality. If it's unreadable let me know.
<jpoiret>SrEstegosaurio: can you switch to a tty and check that /mnt/boot/efi is mounted?
<jpoiret>possibly using lsblk
<jpoiret>what partitioning scheme are you using?
<SrEstegosaurio[m>jpoiret: Yeah, going.
<SrEstegosaurio[m>jpoiret: The `boot` drive is actually mountud on `/mnt/boot/efi`.
<SrEstegosaurio[m>jpoiret: I have a pretty normal one:... (full message at
<jpoiret>hmmmmm, looks like the grub-install command above is wrong, it should be /mnt/boot/efi not /boot/efi
<jpoiret>did you use the latest or the 1.3 installer?
<SrEstegosaurio[m>But it's true that I have both my root and home partition formatted as BTRFS.
<SrEstegosaurio[m>jpoiret: I downloaded the iso yesterday from the official website, so I guess it should be up to date.
<jpoiret>hmmm, i might know why
<jpoiret>btrfs shouldn't interfere
<jpoiret>did you let the installer format your partitions?
<SrEstegosaurio[m>jpoiret: Okey, I added it just in case.
<SrEstegosaurio[m>jpoiret: Yeah, as I don't have my Dvorak keyboard with me I wanted to avoid typing at all.
<jpoiret>we have two sets of installers, the 1.3 release at, but also the latest one at
<jpoiret>it's better to use the latest, as it contains some fixes
<SrEstegosaurio[m>So, should I try with the latest one?
<SrEstegosaurio[m>SrEstegosaurio[m: Also I told the installer to erase the contents on the boot partition while configuring the disks. But that shouldn't be an issue.
<SrEstegosaurio[m>Btw now the errors msg is different.
<jpoiret>ideally, you should try with the latest one yes
<jpoiret>what is it?
<SrEstegosaurio[m>jpoiret: This time it seams to be on `efibootmgr`:
*SrEstegosaurio[m uploaded an image: (867KiB) < >
<jpoiret>are you sure you're booted in EFI mode?
<jpoiret>is /sys/firmware/efi/ present?
<SrEstegosaurio[m>jpoiret: It should be, when I booted the computer the UEFI/EFI menu was there.
<SrEstegosaurio[m>jpoiret: I was going to check for those.
<SrEstegosaurio[m>It is.
*SrEstegosaurio[m uploaded an image: (678KiB) < >
<jpoiret>very weird
<jpoiret>can you use the newest installer in the meantime/
<jpoiret>it looks like the Block device required message is completely bogus
<jpoiret>it's the result of calling strerror on something that's not an errno from what i can tell
<SrEstegosaurio[m>jpoiret: Yeah, it's far from ideal but I think I can.
<SrEstegosaurio[m>I'm using mobile data to perfom the installation. xD
<jpoiret>ah, that doesn't seem very good
<jpoiret>additionally, i think it might be a bug with how GRUB interoperates with efibootmgr
<jpoiret>do you have anything along the lines of secureboot enabled?
<SrEstegosaurio[m>jpoiret: Iirc I have it disableda let me checka
<SrEstegosaurio[m><jpoiret> "additionally, i think it might..." <- Maybe.
<SrEstegosaurio[m>SrEstegosaurio[m: It's disabled.
<jpoiret>is your EFI partition full?
<SrEstegosaurio[m>jpoiret: The one mounted on `/mnt/boot/efi`?
<SrEstegosaurio[m>Okey, I'm going to check it.
*SrEstegosaurio[m uploaded an image: (1593KiB) < >
<SrEstegosaurio[m>It does not semas to be full. The partition has ~500mb of space.
<SrEstegosaurio[m>But those dirs weren't there before.
<SrEstegosaurio[m>And actually, `efi` was written on small caps.
<SrEstegosaurio[m>Why was the EFI folder inside a partirion that is mounted on /mnt/boot/efi?
<jpoiret>it's a convention iirc
<jpoiret>well, i don't even any ideas
<SrEstegosaurio[m>Anyways, I think that I'm going to try at least one my time and if not I'll just download the newest version.
<SrEstegosaurio[m>Thanks for the help. (:
<jpoiret>you could send a bug to
<SrEstegosaurio[m>jpoiret: Me too, I'm just trying random stuff at this point. xD
<SrEstegosaurio[m>jpoiret: I would report it correctly.
<lechner>Hi, my install with root-on-mdadm drops into "Early boot Guile'. Is there a way to recover?
<apteryx>SrEstegosaurio[m: good luck! Reports about the install process will be welcome as that's one thing we want to improve before the next release
<jpoiret>lechner: early boot guile is pretty advanced stuff, so no
<jpoiret>can you spot an error message?
<lechner>jpoiret: it's gone right now, but something about cannot construct array
<jpoiret>mhmm, looks like an mdadm error then
<lechner>do i have to include any modules manually in the initrd?
<lechner>i didn't just for lvm alone
<worstname>when does a package like emacs get updated? i dont know the process for how guix updates packages generally, like sources pulling in a newly released version
<worstname>emacs is now @ stable version 28.1
<vagrantc>the modules included in guix's initrd are pretty manual ... there is a small list included by default (though if done with the installer it might add those to your system config.scm)
<vagrantc>also no module dependency resolution
<vagrantc>so you have to list all the dependencies too
<jpoiret>worstname: someone needs to step up and write the corresponding package
<jpoiret>thankfully, emacs-next was already far into 28.05 so it shouldn't be too hard to adapt it for 28.1
<bjc>there's a patch in the issue tracker from lilyp that updates emacs to 28.1
<bjc>you can apply it by hand if you want -- it worked for me at least
<bjc>or use emacs-next, which is 28.0.50 rn, i believe
<worstname>i ran `guix build emacs --with-source='
<worstname>gotta say, its cool to find something useful like that and it works..
<jpoiret>well, that will just build emacs but not install it in any of your profiles
<jpoiret>you'd have to use guix install for that
<worstname>i rant it from the output dir to test it
<ggoes>it's nice, but i'm also currently running into the problem where installing it (with-branch=emacs-next=master) recompiles emacs for every emacs package i have in my guix profile
<ggoes>maybe that's unavoidable
<EMax`0Mancer[m]>does anyone have a minimal example of modifying the system configuration to enable the wayland feature of gdm?
<EMax`0Mancer[m]>I mean, it feels like this should work, but it doesn't seem to:
<tom[m]1234>Hello . Can you please tell me where on the FSF website you can see the recommended libre programs? Thanks
<vivien>tom[m]1234, there’s
<tom[m]1234>vivien: Hello. Thanks a lot
<jts>can a package be defined using local source files? for example, to define a package inside its source directory
<mbakke>jts: yes, many projects have a 'guix.scm' that you can build by 'guix build -f guix.scm'; see e.g.
<jts>thank you! I was in the planning stages of implementing a "local-fetch" procedure so you've saved some wheels being reinvented XD
<zacchae[m]>is the python venv system known to be broken in guix?
<zacchae[m]>I seem to be unable to use pip in a python venv environment.
<zacchae[m]>I get ModuleNotFoundError: No module named 'pip._internal.cli.main'
<EMax`0Mancer[m]>is there some way of manually adding a .desktop file in wayland-sessions?
<lilyp>you might want to check our pip package, but the leading underline suggests it shouldn't be used publicly
<bjc>EMax`0Mancer[m]: if you mean outside of guix, sure: stick it in .local/share/applications (or somewhere else in your XDG_DATA_DIRS path)
<EMax`0Mancer[m]>bjc: will gdm pick it up from there?
<bjc>in guix your desktop files should be stuffed into your profile's 'share/applications', so for the default profile you'd find them in .guix-profile/share/applications
<EMax`0Mancer[m]>for wayland-sessions rather than for applications though
<bjc>gdm? no. those are per-user
<bjc>i dunno how to get gdm to find them, or even why you'd want it to
<bjc>oh, you mean the options you see for logging in with a given session? like plasma x11, sway, gnome x11, gnome wayland etc?
<EMax`0Mancer[m]>wayfire, installed either through guix (an unofficial package) or nix, doesn't seem to create a .desktop somewhere gdm can see it (or perhaps at all)
<bjc>iirc, those aren't .desktop files you need for that
<bjc>gimme a sec. i used to remember where all this stuff went
<bjc>oh, they are desktop files, apparently
<bjc>in your system configuration you can manually create the .desktop files and then symlink them to the appropriate place (which is probably somewhere in /run/current-system/profile/share, but i haven't verified that yet)
<bjc>oh.. i don't have a session manager installed. no wonder i can't find it
<bjc>well, on manjaro it's /usr/share/wayland-sessions, so presumably on guix it'd be /run/current-system/profile/share/wayland-sessions
<roptat>hi guix!
<zacchae[m]>lilyp: A work around was to use a guix shell --pure, though this "shouldn't" be necessary
<bjc>EMax`0Mancer[m]: ah, there's documentation here:
<apteryx>zacchae[m]: can you share a minimal reproducer? I used pip in a venv minutes ago
<EMax`0Mancer[m]><bjc> "well, on manjaro it's /usr/share..." <- ok, not at my guix machine at the moment, but will I be able to symlink into /run/current-system/profile/share/wayland-sessions? I thought this was read-only.
***lh is now known as hupfer
***hupfer is now known as lh
***hpfr is now known as lph
***lph is now known as hpfr
***lh is now known as lhindir
***lhindir is now known as liamiam
***liamiam is now known as lmhpfr
***lmhpfr is now known as lhupfer
***lhupfer is now known as liamhupfer
***liamhupfer is now known as lh
<apteryx>EMax`0Mancer[m]: I believe they meant symlinking the other way around
<EMax`0Mancer[m]>apteryx: what would that look like? I thought gdm is looking in /run/current-system/profile/share/wayland-sessions