*civodul processed some of the patch backlog <civodul>i hope fellow committers can take a look at the backlog in the meantime :-) ***rekado_ is now known as rekado
<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 <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? <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>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. <xelxebar>You have me interested in this multi-versioning capability though! :) <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). <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 <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
<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. <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. <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>as in when communicating with them , because frankly its just so much nicer when the other party is able and willing lmao <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? <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>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>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 <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>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 <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 <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 <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 <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 <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>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 <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 <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 <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>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? <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) <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>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 <apteryx>when would this occur? Throw to key `decoding-error' with args `("peek-char" "input decoding error" 84 #<input: user-commands/xindy.in 15>)' <apteryx>this is trying to run substitute* on user-commands/xindy.in in mirrors.ctan.org/indexing/xindy/base/xindy-2.5.1.tar.gz <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" <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 <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* )) <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>(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"" <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. <jpoiret>SrEstegosaurio: can you switch to a tty and check that /mnt/boot/efi is mounted? <jpoiret>what partitioning scheme are you using? <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>did you let the installer format your partitions? <SrEstegosaurio[m>jpoiret: Yeah, as I don't have my Dvorak keyboard with me I wanted to avoid typing at all. <jpoiret>it's better to use the latest, as it contains some fixes <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. <jpoiret>ideally, you should try with the latest one yes <jpoiret>are you sure you're booted in EFI mode? <SrEstegosaurio[m>jpoiret: It should be, when I booted the computer the UEFI/EFI menu was there. <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 <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>Why was the EFI folder inside a partirion that is mounted on /mnt/boot/efi? <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. <jpoiret>you could send a bug to bug-guix@gnu.org <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 <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? <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 <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>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>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 <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 <EMax`0Mancer[m]>does anyone have a minimal example of modifying the system configuration to enable the wayland feature of gdm? <tom[m]1234>Hello . Can you please tell me where on the FSF website you can see the recommended libre programs? Thanks <jts>can a package be defined using local source files? for example, to define a package inside its source directory <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) <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 <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 <zacchae[m]>lilyp: A work around was to use a guix shell --pure, though this "shouldn't" be necessary <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 
