IRC channel logs


back to list of logs

<jgart>I think it doesn't
<drakonis>none of those with it
<jgart>bwrap is pretty cool,
<jgart>This project uses it:
<KE0VVT>jgart: I thought Flatpak used Bubblewrap.
<lilyp>Epiphany does too.
<drakonis>flatpak does that, yeah.
<jgart>p2pkgs uses redo also. I've been looking into it a bit
<jgart>pretty interesting
<jgart>there's a couple of implementations of redo out there
<jgart>there's one in POSIX shell also iirc
<jgart>Let's package this!
<jgart>Unix manual pages for R6RS and R7RS
<singpolyma>jgart: not info pages? ;)
<jgart>I prefer man pages
<jgart>although using info pages in emacs with evil-collection turn on is not too bad
<jgart>s/turn/turn on
<the_tubular>jgart Nice, when is it merge ?
<acrow>tex_milan1: Thanks for the feedback on BT. In the absence of a dbus fix would could this be a simple entry in .bash_profile or what have you? Or, I'm also considering trying to make it part of the guix-home configurations. Doesn't the initialization of blueman.mechanism need to be initiated on a per user basis? It seems to me that the bluetooth device needs to be owned by an individual. Not sure.
<raghavgururajan>Am I doing something wrong with this bash script?
<raghavgururajan>Only first if block is run.
<raghavgururajan>Not the consecutive if blocks.
<kwjc>anyone knowledgable about tor on guix? I have installed the tor-client package but not sure what it even does. I would assume that you would "run" it by simply typing tor-client in the terminal, but it says the package isn't installed.
<raghavgururajan>kwjc: You'd need tor-service-type to your services list and 'tor' group to your groups list, in config.scm. Then set clients to use SOCKS5 proxy at localhost:9050
<GNUtoo>hi, with GuixSD, is guix pull sufficient to update the package list?
<GNUtoo>*sudo su and then guix pull
<singpolyma>GNUtoo: yes
<singpolyma>No sudo
<GNUtoo>ohhh maybe that's why
<singpolyma>If you sudo if will only update the list for root
*GNUtoo tries sudo guix pull
<singpolyma>I assume you don't usually Brun as root :)
<GNUtoo>Here I want to run guix reconfigure /path/to/file
<GNUtoo>And for some reason sudo su and then guix pull doesn't find the package added by the latest commit
<GNUtoo>And as user it does
<GNUtoo>(Though I assume that I can't reconfigure as user)
<singpolyma>Try sudo $(which guix) reconfigure
<singpolyma>That's a hack, but maybe will work for you
<GNUtoo>The sudo guix pull seem to do more stuff than sudo su and then guix pull
<singpolyma>I'm not sure if sudo guix pull is fully safe. Probably depends how your sudo is set up
<GNUtoo>it's the stock guixSD config and sudo points to /run/setuid-programs/sudo
<singpolyma>Yeah, unfortunately you're running past the edge of where I know :)
<GNUtoo>And my user is in the wheel group
<singpolyma>sudo $(which guix) reconfigure should be safe to try
<GNUtoo>ok, your tricks may still work though
<GNUtoo>ok thanks
<GNUtoo>The manual also has a section on that but It didn't really made sense for me
<acrow>raghavgururajan: Yes, you are doubling the basename.
<acrow>profile="./guix-extra-profiles/$(basename $i)" might be closer.
<apteryx>GNUtoo: are you on a Guix System or something else?
<GNUtoo>guix system
<apteryx>on Guix System, it's safe to use just sudo: 'sudo guix system reconfigure ...', but other distributions such as Debian have configs that will reduce your PATH and other envs to some minimal set
<GNUtoo>The sudo trick seems to work
<GNUtoo>Maybe the issue I had was that I share the /gnu with another distribution
<apteryx>just sudo should be OK; unless you reconfigure from sources with pre-inst-env in which case what you need is 'sudo -E ./pre-inst-env guix system reconfigure ...'
<GNUtoo>ok, before I was doing sudo su, and in the new root shell I ran the commands
<vagrantc>sharing /gnu would also require saving the database in /var/guix
<vagrantc>i think
<raghavgururajan>acrow: I am confused. You mean profile="~/.guix-extra-profiles/$(basename $i)"?
<raghavgururajan>acrow: I modified it from
<raghavgururajan>Mine looks like this.
<raghavgururajan>The first if block runs, but not others.
<raghavgururajan>Should I change `~/.guix-extra-profiles/*` to `"$HOME"/.guix-extra-profiles/*`?
<excalamus>Good evening, Guix
<kwjc>good evening to you excalamus!
***lukedashjr is now known as luke-jr
<pyrotek45[m]>im getting more into emacs
<pyrotek45[m]>how would one write a config for emacs using guix?
<pyrotek45[m]>like how would one convert a normal config to an emacs config on guix?
<acrow>raghavgururajan: Sorry, I got distracted.
<acrow>I thought I recently saw that code somewhere in our documentation too or something similar. I can't find it right now though. Still, there are a couple odd things in that code. First, if you want to get all the subdirectories of a directory I'd use a directory test and not just filter out file names with extensions. This is what I think you are trying to do with the basename rewrite. I'd also double quote all the strings and use
<acrow>brackets around all variables. Just because shell quoting can quickly get out of hand.
<acrow>As you suggested using ${HOME} instead of ~ is another good idea.
<acrow>Unfortunately I don't have things set up to test your code.
<raghavgururajan>acrow: jgart corrected me with using `-d` instead of `-f`, as I was looking for directories.
<raghavgururajan>acrow: Similar code is in cook book.
<the_tubular>pyrotek45[m] that's exactly what I'm doing
<the_tubular>I'm at the very beginning though
<the_tubular>Well in fact, I'm still merging my bashrc to my guix-home
<pyrotek45[m]>well i wrote a config for emacs, but not in guix
<pyrotek45[m]>and when i tried to import my emacs config to my vm (that uses guix) it messed up
<acrow>raghavgururajan: Sounds good. This might also help: but I haven't tested it.
<pyrotek45[m]>i was able to get most of it working by doing a guix install of the emacs packages
<raghavgururajan>acrow: Thanks! That snippet sets profile to ~/.guix-extra-profiles/profile-name right? But there the actual path should be ~/.guix-extra-profiles/profile-name/profile-name
<raghavgururajan>There is a sub-dir with same name as profile
<raghavgururajan>*But the
<acrow>I'm not sure. I didn't change all the -f to -d which, I think, is what you really want.
<raghavgururajan>Ah Cool!
<podiki[m]>pyrotek45: I haven't moved my emacs config to guix yet, but had no changes to have it work on my guix system. it uses use-package (can bootstrap), worked fine. I have moved a few packages to the guix ones, mostly that depend on external programs
<acrow>Hmmm. What would be nice is to be able to say that all GUIX_PROFILE directories have these qualities (contain all these subdirectories and other things) and create a shell predicate to simplify this as well as make it more durable.
<podiki[m]>acrow: I would love better multiple profile support, there was some discussion on guix-devel about doing that with guix home which would make sense to me
<acrow>It's not easy. We also need to accomodate the variety of shells or force a shell to keep things manageable. Is this part of guix-home?
<pyrotek45[m]><podiki[m]> "pyrotek45: I haven't moved my..." <- sorry im new to guix and emacs, what do you mean "it" uses "use-package"?
<pyrotek45[m]>is that a guix or emacs thing and how would one use it?
<podiki[m]>acrow: was your last message about multiple profiles?
<acrow>Maybe this could also be pushed over to scheme. Return the shell from scheme with the environment appropriately extended??
<podiki[m]>pyrotek45: sorry, meant that my emacs config uses the "use-package" way of managing packages: but there are many other options in emacs land
<acrow>Yes, but now I see it isn't necessarily so. Sorry.
<pyrotek45[m]>so use-package is itself a package?
<pyrotek45[m]>is it part of emacs or an addon?
<podiki[m]>yes, it is a separate package but believe it will be part of emacs in a future version
<pyrotek45[m]>right now im using this... (full message at
<pyrotek45[m]>woops pasted it twice
<pyrotek45[m]>to install my packages
<pyrotek45[m]> * right now im using this... (full message at
<pyrotek45[m]>is this not a good way to do it on guix?
<podiki[m]>you could do that in a Guix manifest if you want to do it more in a Guix way
<podiki[m]>so that the packages are installed and updated by Guix instead of emacs; up to you what you want to do
<podiki[m]>downside (or upside?) with doing it in emacs with use-package or similar is that you have to update/do your package management with that separate tool (rather than guix)
<pyrotek45[m]>i would prefure to have a file that works on any distro
<podiki[m]>that's possible for both, since you can use Guix as a package manager on top of another distro too
<pyrotek45[m]>not fedora
<pyrotek45[m]>since the selinux kinda doesnt work
<podiki[m]>then probably want it from within emacs, of which you have lots of good options
<pyrotek45[m]>does the way im doing it now work in guix?
<pyrotek45[m]>it seemed like when i imported this is gave me some errors
<pyrotek45[m]>to my guix vm
<podiki[m]>it won't work until you've installed the packages, either from within emacs or with guix (you are trying to "require" packages that emacs doesn't know about)
<kwjc>i just gotta say this new version of openjdk+guix updates has made RuneLite run better than it ever has. even better than it ever did on windows
<zoglesby>pyrotek45[m]: you could try something like using a if statement on (system-name) inside of (use-package) and if it is in a list of guix systems skip an :ensure t or vise versa. I am not 100% sure that would work, but I don't see why it wouldn't off the top of my head.
<pyrotek45[m]><podiki[m]> "it won't work until you've..." <- i see, im not sure what the require does but i tried installing package undo-tree in emacs on guix and its not there
<pyrotek45[m]>which is interesting
<pyrotek45[m]>but its in guix
<podiki[m]>did you restart emacs?
<pyrotek45[m]>and maybe i could do something with an if
<pyrotek45[m]>and yes i resarted it a few times
<podiki[m]>what does echo $EMACSLOADPATH give you?
<podiki[m]>should output the path of the profile that has emacs packages
<podiki[m]>e.g. for me it has something like ~/.config/guix/profiles/emacs/emacs/share/emacs/site-lisp:/run/current-system/profile/share/emacs/site-lisp
<acrow>raghavgururajan: It isn't obvious to me (I'm new) that it is easy to canonicalize the GUIX_PROFILE file structure. I've only got one example that doesn't really match the few criteria you identify. Better is the enemy of good enough. I see why you're doing what you are.
<pyrotek45[m]>podiki[m]: ```/home/pyro/.guix-profile/share/emacs/site-lisp```
<podiki[m]>pyrotek45: looks right. maybe in emacs, in the *scratch* buffer, type in (getenv "EMACSLOADPATH") and press ctrl-j at the end of the line and check it has that path too
<podiki[m]>also, I don't know what you have exactly, but doing (require 'somepackage) is how you would load the package
<podiki[m]>but maybe best to try out use-package or read about emacs package management to see what system you want to use
<pyrotek45[m]>this is what the emacs one had
<podiki[m]>yup, that looks good
<pyrotek45[m]>i just started making an emacs config and learning emacs yesterday
*pyrotek45[m] posted a file: (4KiB) < >
<pyrotek45[m]>this is my config, it works fine on my fedora workstation
<pyrotek45[m]>but in the vm it complains undo-tree is missing
<pyrotek45[m]>hmm so i think the emacs in guix is an older version
<pyrotek45[m]>since once i removed the undo-tree it worked
<pyrotek45[m]>i take that back it looks like my fedora and guix version are the same
<pyrotek45[m]>idk why undo tree works on my fedora but not in guix
<podiki[m]>I haven't used undo-tree, maybe it is something about that package
<pyrotek45[m]>hmm weird
<pyrotek45[m]>i removed everything on my fedora emacs from .emacs.d except the init.el and restarted it and in fedora it worked fine no issues
<pyrotek45[m]>but on guix it doesnt work
<podiki[m]>works if I try "guix shell emacs emacs-undo-tree -- emacs -Q"
<podiki[m]>then in there I can do "(require 'undo-tree)" and it loads fine; so must be something in your init.el
<pyrotek45[m]>im assuming it is
<podiki[m]>you can remove things and see what makes it work/break
<podiki[m]>but anyway, I'd encourage you using something (like use-package, but there are others) to manage your packages in emacs, much better than without
<pyrotek45[m]>ill look into it
<the_tubular>Sorry, I was on the phone.
<the_tubular>But yeah, I read through your conversation, although I would try to do it trough guix and not emacs...
<the_tubular>I don't see why I'd need a second package manager while guix is perfectly fine as a package manager
<the_tubular>podiki[m] you have an example of a config.scm file that has emacs configure by it ?
<podiki[m]>the_tubular: I don't, but I'm sure people here do; mine is a literate org-mode file that I haven't yet guix-ified (not sure what I'll do exactly)
<podiki[m]>pyrotek45has problems with guix on fedora's selinux policy, so can't install emacs stuff via guix it sounded like
<the_tubular>Yes, that's exactly what I have at this moment, while it's not mine. I planned to start from scratch and do it the guix way
<podiki[m]>I haven't yet dived into guix home and see how I want to use that. currently all my configs tend to be literate org-mode files + gnu stow
<the_tubular>Yeah, I read the conversation briefly, and personally I don't really care about fedora
<the_tubular>Nor do I have a good understanding about SELinux
<pyrotek45[m]>looks like it and old issue
<podiki[m]>my basic guess is to just include packages in a manifest (I have my emacs in a separate profile) and then still have a regular .emacs setup. next step would be to manage that with guix home (if it can yet?)
<pyrotek45[m]>but Setting package-check-signature to nil fixed it for now
<podiki[m]>the_tubular: ditto :-) I'm all in on Guix, but have some machine with Arch still
<podiki[m]>glad you figured it out pyrotek45!
<the_tubular>Yeah, guix home is the way, I'm pretty sure
<pyrotek45[m]>thanks, but its prolly unsafe for long term
<pyrotek45[m]>but itll do for now
<pyrotek45[m]>also, my flatpaks havnet shown up in gnome on guix either
<pyrotek45[m]>any way to fix that?
<the_tubular>Package signature shouldn't really matter if you download stuff with HTTPS no ?
<pyrotek45[m]>not sure, but undo-tree was just not being installed on guix until i set the check to nil
<the_tubular>GuixSD or Guix on fedora ?
<pyrotek45[m]>im using a vm
<pyrotek45[m]>to test out and learn guix
<the_tubular>Umm, weird ...
<pyrotek45[m]>before i put it on metal
<apteryx>the_tubular: it's now called Guix System, not GuixSD, by the way :-)
<pyrotek45[m]>ive installed element on there but the icon doesnt show up
<pyrotek45[m]>i have to run it with flatpak run im.riot.riot
<the_tubular>Ohh good to know!
<the_tubular>podiki[m] as I was saying earlier, I'm still ocnfiguring bash on my guix-home. I'm pretty sure Emacs will be about the same
<pyrotek45[m]>i just learned about bash vim support
<pyrotek45[m]>by adding ```set -o vi```
<pyrotek45[m]>in bashrc
<pyrotek45[m]>you can edit and scroll through your command with vim keybindings
<podiki[m]>pyrotek45: you need to add a flatpak directory to XDG_DATA_DIRS
<pyrotek45[m]>its amazing
<podiki[m]>or you can source the profile script flatpak gives you, I do that in my .zprofile:
<the_tubular>Yeah, well that's very easy to do with eamcs too pyrotek45[m] :)
<podiki[m]>wherever you have flatpak installed (~/.guix-profile probably?) there is a profile script in etc/profile.d from flatpak you can use
<pyrotek45[m]>i also add these to my bashrc ``` bind "set completion-ignore-case on"
<pyrotek45[m]> bind "set show-all-if-ambiguous on" ```
<pyrotek45[m]>podiki[m]: lemme check that out
<the_tubular>What do does to ?
<the_tubular>The second one, the first one is pretty self-explanatory
<pyrotek45[m]> show-all-if-ambiguous
<pyrotek45[m]> This alters the default behavior of the completion functions. If set to ‘on’, words which have more than one possible completion cause the matches to be listed immediately instead of ringing the bell. The default value is ‘off’.
<the_tubular>Ohh, well guess I had it on without knowing cause I've never had the "off' behavior happen
<pyrotek45[m]>well the coolest part was learning bash had vi mode lol
<pyrotek45[m]>but the ignorecase is ah so good
<pyrotek45[m]>typing download and pressing tab to get Downloads is
<pyrotek45[m]>just amazing lol
<apteryx>nobody else has issues logging in on core-updates-frozen? some login1 timing out (dbus/elogind issue).
<the_tubular>How do you log in there ?
<apteryx>via gdm or slim (doesn't seem to matter)
<apteryx>I reproduce the issue only one of 2 machines so far
<podiki[m]>i haven't done guix pull in a while
<podiki[m]>(but am on sddm now)
<apteryx>core-updates-frozen, right?
<the_tubular>Also, did NS needs patching in guix ?
<the_tubular>NSS *
<the_tubular>Reference :
<podiki[m]>apteryx: yeah c-u-f
<podiki[m]>but commit: f22dfba53032c59fb260173143abf0e4e9a4f1e1
<nckx>the_tubular: Yes.
<raghavgururajan>Hmm. When youtube-dl and/or yt-dlp are install to a profile, the profile's /etc/profile file doesn't contain lines to export PYTHONPATH.
<lilyp>raghavgururajan: it doesn't, those are command line tools, not python libs
<lilyp>even then you need python for PYTHONPATH
<jpoiret>Hello guix!
<unmatched-paren>hi guix!
<unmatched-paren>is a plymouth boot splash screen planned for the future?
<GNUHacker>unmatched-parent ?
<unmatched-paren>even though i'm used to them by now, the firmware errors (about my now-useless wifi card) still freak me out a little
<unmatched-paren>GNUHacker: it's supposed to be unmatched-parenthesis but irc has a character limit :P
<GNUHacker>srry i try do a joke
<unmatched-paren>actually it *was* unmatched-parent for a second at first because irc cut it off, but i changed it to unmatched-paren very quickly :)
<jpoiret>unmatched-paren: i don't think so, but it shouldn't be too hard
<jpoiret>you could also patch GDM to have it handle the handoff
<unmatched-paren>someone who is a better artist than me will have to make a splash animation :P
<unmatched-paren>" Because it starts so early, it needs to be packed into the distribution's initial ram disk, and the distribution needs to poke plymouth to tell it how boot is progressing." [] <- sounds like it'd be quite a bit of effort...
<unmatched-paren>i don't really like messing with boot stuff, so changing the initrd sounds terrifying to me :P
<jpl01>Can anyone tell me why my pc-speaker dosen't get blacklisted, I have the following line in my config (kernel-arguments (append (list "modprobe.blacklist=pcspkr")
<jpl01>%default-kernel-arguments)) yet my pc-speaker still makes noise.
<raghavgururajan>lilyp: Ah. They complain about not finding site-packages. I guess they have libs somewhere?
<raghavgururajan>Nvm. It works now. *shrugs*
<mothacehe>hey guix!
<raghavgururajan>hey mothacehe o/
<mothacehe>hello raghavgururajan!
<efraim>hello guix!
<NicholasvonKlitz>Is there anywhere I can track the progress of merging core-updates-frozen?
<mothacehe>NicholasvonKlitz: The only blocker I'm aware of is discussed here:
<mothacehe>See also efraim recap here:
<awb99>I am buring images to a sdcard, and I would like to start the sdcard with uboot. I would like to have the filesystem to extend the full sd card size. Is this possible? I tried with --image-size=16G and this works, but when the images get larger the time for image preparation goes up, and also it never works with the full size of the sd card.
<mothacehe>you can generate a somehow small image and use resize2fs afterwards
<vdv>here if somebody is interested:
<vdv>a script to install guix in wsl2
<awb99>thanks mothacehe!
<awb99>do you know if resize2fs works with sd cards?
<vdv>but maybe interesting for other use cases too, it is a simple bootstrapping binary installation script to install guix system with running shepard services via a simple busybox barebone system
<mothacehe>awb99: sure, see:
<jpoiret>vdv: useful, i've been running guix on debian on wsl2
<vdv>miniwsl should be a lot smaller @ jpoiret :)
<vdv>@rekado, thx for suggesting contributing parts of it to the script
<vdv>i will try if i got the sparetime january next year :)
<zimoun>civodul, do you have an estimation about the number of “tunable” packages?
<civodul>zimoun: my idea is that we'd mark them on a case-by-case basis, starting probably with dependents of Eigen, xtensor, and similar header-only SIMD libs
<civodul>then we can look at packages for which we currently strip -march=native
<civodul>my take is that only a minority of packages meaningfully benefit from tuning
<zimoun>civodul, thanks. I have overlooked the “issue” since these days I am not doing too much the same kind of ’P’ from HPC. :-) And I re-read all LWN, the blog post, Nix. All is real cool!
<civodul>so i've looked at gnome-shell, gjs, and mozjs, checking whether we could downgrade one of these to avoid Rust
<civodul>and i don't think that's feasible
<civodul>so we'll have to give on on gnome-shell and gdm on non-x86_64
<civodul>*give up
<jlicht>going to be a special kind of fun once we need Rust to build the linux-libre kernel ...
<attila_lendvai>shepherd is printing useless backtraces, and i can't debug my issue. it's possible to tell guile to e.g. (debug-set! width 160), but where shall i add this? can i change something in the initrd to run guile with some extra args?
<lilyp>civodul do gnome-shell and gjs themselves contain rust code?
<lilyp>I'm not up-to-date if you couldn't guess
<mothacehe>lilyp: There's the following dependency chain: gnome-shell -> gjs -> mozjs -> rust
<lilyp>I see
<lilyp>And no patch to swap out mozjs for duktape, I assume
*mothacehe is investigating gui installation test failures
<jbv1[m]>zimoun I was looking at FYI julia supports specifying multiple architectures for the sysimg as explained here It will select at runtime one.
<zimoun>jbv1[m], yeah I know. But you have to generate for all microarchitectures. I have not done yet, the question is about the size.
<efraim>can we use an older version of mozjs?
<winning-luser>is tor browser working on guix yet or is there still work that needs to be done/figured out?
<efraim>I have a tensorflow-native package that I use with package-input-rewriting/spec
<mbakke>efraim: the newest polkit requires the newest mozjs (though there is a polkit-duktape variant that does not pull in mozjs)
<efraim>well that rules that out then
<jbv1[m]>zimoun: ok understood.
<zimoun>jbv1[m]: for instance, the official x86_64 uses «generic;sandybridge,-xsaveopt,clone_all;haswell,-rdrnd,base(1)» when GCC supports more that sandybridge and haswell. For instance, if you skylake as civodul, maybe some code will not be optimized for it.
<zimoun>and my naive questions were about if ’tune’ is an option or not for improving the performance of Julia. I do not know. :-)
<zimoun>jbv1[m]: if you have Julia code against we could benchmark, playing with options, feel free to keep me in touch (offlist). :-)
<efraim>you might want a custom julia with 'MARCH=native JULIA_CPU_TARGET=native' anyway, if you can spare the compiling time :)
<zimoun>I think, currently the distributed .ji are probably compiled with ’native’ so for Berlin. :-)
<zimoun>Well, I have not investigated more yet.
<efraim>I hadn't thought too much about those, but I assumed they would do The Right Thing™
<mothacehe>jpoiret: the gui-installed-desktop-os-encrypted and gui-installed-os-encrypted are broken on c-u-f. I installed a basic encrypted system using the installer and QEMU. On the installed image GRUB complains of an "unknown filesystem". I believe this is related to the LUKS2 patchset. Could you please have a look?
<florhizome[m]><unmatched-paren> "someone who is a better artist..." <- I came across this
<florhizome[m]>ig, there is plenty cool artwork... unfortunately not in an easy packagageable form...
<jbv1[m]>@zimoun not yet, but next year I'll have something published
<zimoun>jbv1[m]: cool!
<jpoiret>mothacehe: i'll take a look
<zimoun>efraim, yeah. I guess too. But 1) I am not sure that distrubte precompilated is a common practise and 2) the solution for “time of first plot” is System Image, and again I am not convinced that it is a common practise to distribute these images.
<winning-luser>has anyone used guix as a shared system, or heard of such a thing yet? think,, sdf etc
<efraim>it might just be me but I can't really think of a good use case where I'd want such a thing. Haven't heard of one though
<winning-luser>efraim: doubt there is practical use but it sounds entertaining regardless
<attila_lendvai>i have a binary file that runs fine on guix. inside a `guix system vm ...`, as a shepherd service, i get "cannot execute binary file". when i log in, and copy-paste the binary into the root shell, then it runs fine. any hints what could be missing from the shepherd environment?
<attila_lendvai>s/binary/full path/
<jpoiret>mothacehe: it's my first time running tests. Do they not use substitutes?
<jpoiret>ehrm, are you on guix system or foreign attila_lendvai?
<mothacehe>jpoiret: yes they do
<mothacehe>the command for the failing test would be: make check-system TESTS="gui-installed-os-encrypted"
<attila_lendvai>the binary is a dynamic one, but ldd only shows glibc stuff
<jpoiret>i thought i had just built glibc-2.33 but i might be having the wrong impression
<jpoiret>yes, that's what i'm trying right now
<attila_lendvai>jpoiret, yes, on guix system, and testing the swarm service in a vm
<jpoiret>do you mind posting a snippet of the service definition?
<mothacehe>but to ease debug, you can produce an installation image: ./pre-inst-env guix system image -t uncompressed-iso9660 gnu/system/install.scm and use it this way: qemu-system-x86_64 -enable-kvm -m 4096 -cdrom /gnu/store/the-installation.iso -hda img -boot d
<attila_lendvai>actually, what makes this binary work in the shell? it's compiled on a foreign linux, i.e. it doesn't have /gnu/store direct references
*attila_lendvai records his state and pushes it
<jpoiret>yes, don't worry, that's how I've been testing the installer/LUKS2 patches.
<jpoiret>but they were working fine that way, so i'm trying the marionnette test
<attila_lendvai>jpoiret, the relevant code is in services/swarm.scm:
<civodul>lilyp: no; mozjs contains Rust code, and gnome-shell -> gjs -> mozjs@78
<jpoiret>i think you have your answer figured out: the binary you want to use is not properly patched
<attila_lendvai>jpoiret, but it works from the shell. why?
<kwjc>how do I figure out the actual version of fastboot? GrapheneOS wants me to have version 29+, but when I do "fastboot --version" it just says "fastboot version -android".
<rekado_>kwjc: guix show fastboot
<attila_lendvai>jpoiret, i don't know what "properly patched" means. can you please point me to an example if you know any?
<jpoiret>attila_lendvai: i see you're using patchelf, that's what you need
<jpoiret>there should be examples in the channel you were referring to, but you have to know that it's not really the supported way of running software on guix
<attila_lendvai>jpoiret, i know, but i'd really like to run the official binaries in this context.
<kwjc>thanks a lot rekado_!
<attila_lendvai>daaaamn, it was an ordering issue in the bash arguments, nothing to do with ldd &co. it was a confusing error from bash...
<rekado_>fixed a lot of bioinfo packages on c-u-f.
<rekado_>the remaining ones are tricky.
<rekado_>the following all depend on Python 2 things, which are pretty broken: gess pepr ribodiff poretools grit miso python2-warpedlmm
<rekado_>metabat needs to be upgraded; later versions no longer use the scons build system (which cannot be used with gexps, it seems)
<rekado_>pplacer apparently needs an old version of gsl. I'll probably move it to guix-past --- if I can ever get it to build again
<rekado_>sambamba and variant-tools need upstream fixes.
<rekado_>(I reported the problems.)
<nckx>sneek: later tell jpl01: You did blacklist pcspkr, but that's not enough: modprobe.blacklist=pcspkr,snd_pcsp
<sneek>Will do.
<roptat>hi guix!
<roptat>kwjc "guix showw fastboot" will tell you it's 7.1, which is API level 25 (your 29+ is the API level, whereas our 7.1 is android's version)
<civodul>i'm preparing a patch so %desktop-services uses sddm instead of gdm on non-x86_64 platforms, as discussed earlier
<roptat>kwjc, if you need something more recent, I have this channel: that I use until I can finalize the soong-build-system, then I'll send patches to guix proper
<kwjc>thanks for clearing that up roptat!
<nckx>kwjc: Thanks, fixed.
<civodul>mothacehe: seems to be giving me results for older evaluations; for instance, if i check "guix" on aarch64-linux, the derivation and outputs are different from what's on c8060055de425764f58bb9d0a7756964d7eea58d
<civodul>does that ring a bell?
<civodul>rekado_: OTOH, if need be, older GSL versions should be quite easy to reinstate
<civodul>mothacehe: ah nevermind; i forgot to click "Go" after choosing the system
<mothacehe>i was running "guix time-machine --commit=0f2a77e14f8080a9f158f75d2634664565e81173 -- build --no-grafts -d guix -s aarch64-linux" to check it :)
<mothacehe>i'm running a vacuum on the berlin database copy i have
<mothacehe>it's been running for 20 minutes already
<civodul>yeah, twas just a proof that PEBKAC :-)
<civodul>ah good!
<civodul>though i guess you shouldn't swap the copy and the original or bad things will happen!
<civodul>that's to estimate the time it takes right?
<mothacehe>no that's just to estimate the downtime caused by a vacuum
<civodul>the other day i ran VACUUM live on the store db of berlin
<civodul>it took ~2h and it went from 19G to 12G IIRC
<mothacehe>oh! on the real db?
<civodul>(and no downtime)
<civodul>on the real one, yes
<mothacehe>then no need to explore that track further
<mothacehe>because it didn't seem to help
<civodul>yeah cbaines told me it could be done live
<civodul>dunno, maybe it did help a little bit
<civodul>did you stop GC in the morning recently?
<mothacehe>no today but the two previous days
<mothacehe>*not today
<civodul>ah ok
<mothacehe>we are down to 0.6T
<civodul>ah yes
<civodul>i guess we'll have to let it run once to completion since you've raise the threshold from 10T to 15T
<civodul>it's gonna take time the first time
<civodul>but subsequent GCs should be a bit faster
<mothacehe>yup now that c-u-f is built and merged soon, we can let a gc instance do its job to completion
<civodul>"merged soon" :-)
<mothacehe>hehe, maybe today :)
<mothacehe>but we need to coordinate not to kill the GC as i suspect at least rekado_ and myself are doing it frequently.
<rekado_>I haven't killed GC in weeks.
<rekado_>I promise to always ask for approval.
<efraim>rekado_: I can take a look at moving fixing pplacer or moving it to guix-past, probably tomorrow or the day after
<efraim>does imp still need the custom cmake? the comment says 3.17+, we have 3.21 on c-u-f
<rekado_>oh, we can just use the default then
<rekado_>I had to disable the test suite because different tests would fail on every run.
<efraim>I'm testing libtorrent-rasterbar, the other package using full cmake
*rekado_ tries to build all bioinfo packages once more and hopes there are no new regressions
<gnucode>morning guix!
<jpoiret>mothacehe: looks like the generated grub config doesn't have the right uuid
<mothacehe>mmmh right
<jpoiret>civodul: if you're taking the time to add sddm as default on non x86_64, why shouldn't we just have it for x86_64 as well?
<jpoiret>not relying on the gnome stack would be lighter
<jpoiret>i'm testing on efi right now because i remember it working when i tested it
<jpoiret>mothacehe: ^ also do you know if it still works on master?
<mothacehe>jpoiret: yes it does, see:
<mothacehe>but i'm not sure anymore LUKS2 support is to blame here :p
<jpoiret>yeah, i'm not sure either. To me, it's more about the grub.cfg generation
<jpoiret>with the efi test i'll be able to see the configuration file with my own eyes and see what happens
<civodul>jpoiret: yeah well, we chose GDM a while back so this would need further discussion
<civodul>more generally, GNOME is kind of the default for graphical desktop environments
<jpoiret>sure! changing literally the first thing you see on guix by default would need some thought :)
<mothacehe>jpoiret: the test broke between e4e5022 and 7a17123 according to the CI
<civodul>mothacehe: what are your thoughts on aarch64 failures like ?
<civodul>namely: In procedure stat: No such file or directory: "/tmp/guix-build-perl-extutils-helpers-0.026.drv-0/guile"
<civodul>i guess this has to do with qemu-binfmt, but i don't get what would be looking for this file
<mothacehe>ENOENT on executables are often cause by architecture mismatch
<civodul>but here it looks different: it's Guile trying to stat a surprising /tmp/guix-build*/guile file
<mothacehe>(looks like the build was successfully restarted)
<civodul>here's one i haven't restarted:
<civodul>can we tell which machine executed it?
<mothacehe>i definitely need to add this to te details page
<mothacehe>but lemme see
<mothacehe>it was built on hydra-guix-101
<civodul>ok, i'll take a look at the qemu setup there
<mothacehe>the "Stat of ... failed" comes from (ice-9 boot-9)
<civodul>ah so it's trying to auto-compile that?
<qzdlns[m]>hey folks, I'm having some trouble transforming a build-system to get wayland 1.6.1 up and running - I need meson >0.56, which is conveniently packaged in main as meson-next -- is there some obvious '#:build-system-package' option I'm missing from the docs/source[guix/build-system.scm] ?
<jpoiret>#:meson ,meson-next is what you want
<mothacehe>jpoiret: the uuid in /boot/grub/grub.cfg is the correct one
<jpoiret>but meson>0.56 is going to be the default when c-u-f is merged in the upcoming days
<mothacehe>but the one displayed at boot time by grub is wrong
<jpoiret>ehm, but there's no grub foldere inside of the EFI partition
<jpoiret>how does grub find its configuration then?
<mothacehe>must be embedded in the post MBR gap by grub-install I guess
<jpoiret>i'm testing on uefi right now, so it's GPT
<qzdlns[m]>jpoiret: yeah I've been missing c-u-f in main, that's good to know
<jpoiret>mothacehe: just checked, there's no difference between LUKS1 and LUKS2 uuids
<mothacehe> is talking about a geli module
<mothacehe>i'm trying to insmod it
<jpoiret>no, hang on, I think I know what the problem is
<jpoiret>grub tries to open the mapped device before having unlocked the other
<jpoiret>i think it's related with the fact that on UEFI the /boot/grub/grub.cfg is unavailable with the default installer config
<jpoiret>which makes me wonder how it even worked in the first place before
<qzdlns[m]>jpoiret: forgive my ignorance, but where would this keyword ~#:meson~ go?
<jpoiret>in the arguments field of the package definition
<bdju>I was emailed a PDF that I have to sign and send back. Is anyone familiar with that process? What program(s) on Guix could I use for this? I use zathura to view PDFs, but I don't think it can edit them.
<jpoiret>you can see an example in
<jpoiret>bdju: if you have a tablet, xournalpp is great
<qzdlns[m]>I can only see the 'toolchain' as a mechanism to modify implicit inputs to the build-system object (
<bdju>jpoiret: I was just planning to do a sloppy sig with my mouse anyway, so if that works, I'll try it out. thanks.
<jpoiret>qzdlns[m]: lets say that most build-systems have their own way of specifying the main building package
<jpoiret>and you often have to look at the .scm file of the build-system to find it (but they're very readable)
<jpoiret>mothacehe: on my efi test, the grubx64.efi file contains the label of the mapped device, which is not great
<qzdlns[m]>jpoiret: my hero
***stikonas_ is now known as stikonas
<jpoiret>mothacehe: on my own system, I have /esp as my EFI partition, and /esp/EFI/Guix bind mounted to /boot
<jpoiret>which means that the default /boot/grub/ directory for grub files is accessible from the EFI partition
<jpoiret>I think this is the main problem
<jpoiret>i don't know how this would work for non-EFI, it would still need a separate /boot partition
<mothacehe>mmh the system tests are not using EFI so there's something more here
<mothacehe>like a module not built/loaded by grub
<jpoiret>yes but that's true for the non-EFIs as well
<jpoiret>grub first tries to reach its grub.cfg, which is on the mapped device
<jpoiret>but it cannot unlock the mapped device yet, because the instructions for it are in the ... grub.cfg file
<mothacehe>it also appended to the grubx64.efi image i think
<bdju>jpoiret: worked great. thank you again for the recommendation
<jpoiret>no problem! I use it for note-taking myself with a 2-in-1 laptop
<mothacehe>jpoiret: have to go sorry, bye!
<rekado_>civodul: there were a lot of these failures, so I manually built the same derivations on pankow and then restarted the build in cuirass to make it switch to "successful".
<civodul>rekado_: yeah i've clicked on "restart" quite a few times, but this isn't satisfactory
<rekado_>certainly not! I just wanted to explain why some of these succeeded later.
<apteryx>hello! has nobody else experienced login problems (dbus/elogind related) on core-updates-frozen?
<apteryx>basically, as I experience in #52051
<jackhill>I found another problem on core-updates-frozen that doesn't exixt on master:
<apteryx>I've debugged this a lot yesterday, but still haven't found the exact cause; seems to be an unlikely race perhaps caused by slow/saturated IO (on boot, my spinning drives are drowned with IO, introduces latency not seen on other machines equipped with SSDs)
<apteryx>jackhill: could you run it in GDB to get a backtrace?
<jackhill>apteryx: I dont' think I've experienced the problem. I've tested core-updates-frozen on two machines. One if a simple latptop, and GDM starts in wayland more, and alows me to login to a sway or GNOME session. This is a laptop with a single screen. On my other computer, GDM doesn't ever draw anything on the screen, but I can swithch virtual terminals, and get a text login and from there start sway. I don't
<jackhill>feel like I have enough information yet to report a meaningful bug, but I suspect it's a machine specific problem. This one has three monitors two of which are via a usb-c to dual hdmi dongle.
<jackhill>apteryx: I'd be happy to try, but I haven't use GDB before! Is there a guide that you recommend?
*jackhill → afk
<jackhill>I'll catch up on backlog later
<apteryx>'info gdb' has it all, but some guix specifics: you need to find the real binary, not the wrapper script, so I usually spawn a new bash, then cat the wrapper script, copy the environment variables it sets, then `gdb /path/to/.program-real`, or something like this
<apteryx>you can also invoke the binary with args, using `gdb --args /path/to/real-binary any args`
<apteryx>then 'run', and upon crash 'bt' to print a backtrace, on 'taas bt' to get backtraces from all threads
<apteryx>for the login problems, I'll try using synchronization tricks used in (gnu services telephony) (in the jami service definition). I believe I had hit similar races there, when stressing service restarts (which involved restarting a dbus session).
<tschilptschilp23>Hi guix! Can anyone give a hint how to build a kernel module on guix? I'm just trying my luck compiling for a wifi usb dongle, but it throws me off with `/lib/modules/5.15.6-gnu/build` 'no such file or directory'-error so far. But I cannot find a 'build' directory in neither the 'linux-libre' nor 'linux-libre-headers' directories in /gnu/store, neither a /lib/modules/[...] directory at all. Is this a
<tschilptschilp23>naming problem, or am I totally on the wrong way?
<roptat>I think you need to create a package for it
<roptat>there's a linux-module-build-system that sounds like it'll be useful :)
<tschilptschilp23>roptat: wow, thank you!
<jpoiret>sneek, later tell mothacehe: looks like grub-probe -t abstraction /mnt doesn't return the needed grub modules for LUKS2, on my LUKS1 setup it detects everything properly. Worse, grub-probe -t cryptodisk_uuid /mnt doesn't say anything
<sneek>Got it.
<apteryx>do we have a log file corresponding to only the last boot?
<apteryx>OK, that's what I thought. Thanks.
<nckx>apteryx: You can find the boot boundaries with something like grep ' localhost vmunix: Linux ' /var/log/messages, not elegant but does the job.
<apteryx>lol: tail -n+$(grep -n 'Linux version' /var/log/messages | tail -n1 | cut -d':' -f1) /var/log/messages | less
<nckx>(But better than wasteful double logging with wasteful double disc writes, to be fair.)
<nckx>Er… actually we already do that with the ‘secure’ stuff, but that's not really an excuse to do more of it 😛
<nckx>shepherd-journald when.
<apteryx>also: all the fanciness of systemd, with compressed append-only logs is less efficient than a simple uncompressed text log, IIRC, due to storing lots of fields in a database for each message.
<apteryx>what is the point of the 'secure' log? I've not grokked its usefulness yet.
<apteryx>oh wait, it contains different things from /var/log/messages; I thought it was more like a copy or subset of it
<apteryx>seems useful after all, to review the sudo/login activity
<nckx>I was looking at it in the meantime & you're right.
<nckx>I swear I used a distro where it was a partial subset?
<nckx>I'm glad that does not seem to be the case {anymore,on Guix}.
<nckx>It's quite possible that distro was misconfigured.
<jpoiret>wow GRUB source is a mess
<nckx>Possibly by me, if not, for once, likely.
<apteryx>jpoiret: are you sure it's not the world it has to deal with that is a mess (BIOS)
<jpoiret>ehrm, I agree that's part of it, but still, you should see
<jpoiret>that's just an example (I'm looking at it right now)
<jpoiret>edge-case after edge-case
<jpoiret>but, it might be just unix's fault here too
<nckx>Clean-looking code that didn't handle them would be worse (although I agree that GRUB's code isn't… fun to deal with, at least).
<nckx>GNU(?) coding standards make it look worse than it is.
<jpoiret>nckx: clean-looking code or not, i'm going to blindly improve LUKS2 support! onward we go (to our demise)!
<nckx>Thank you jpoiret.
<GNUHacker>i want connect using "ssh -X " to my guix server
<GNUHacker>need i have installed a Xorg server?
<GNUHacker>can i do this with wayland?
<GNUHacker>have guix wayland by default?
<nazarn65>Hello,  could someone please help me with guix config ? I have added the httpd service but the config is not applying after the "reconfigure" command here is my .scm config
<nckx>nazarn65: What does ‘not applying’ mean? Which exact command are you running?
<roptat>nazarn65, what error do you get?
<nazarn65>After the guix system reconfigure config.scm , the httod.conf does not including changes specified in the config.scm
<nckx>Which exact command are you running?
<nckx>What is ‘the httpd.conf’ here? How are you checking?
<nckx>GNUHacker: I haven't used X forwarding on Guix System but you need an X server on the client, not the server.
<nazarn65>In the .guix-profile folder etc/httpd
<nckx>That file isn't used by the service.
<nckx>Its contents don't matter.
<nckx>You can restart httpd with ‘sudo herd restart httpd’ (I use nginx so not 100% sure about the name), then see if connecting to the server actually works as expected.
<nazarn65>Okay, when i trying to start httpd the error syays that user not valid user daemon but i have set another one
<GNUHacker>nckx: thanks
<roptat>nazarn65, you can find the actual one being used with something like "guix gc -R /run/current-system | grep httpd.conf"
<nckx>It helps if you include the real error message nazarn65.
<nckx>I'm afraid I can't parse ‘user not valid user daemon but i have set another one’.
<nckx>You certainly haven't set another user name in at least.
<nazarn65>Yes, sorry i have added it now to recheck the config
<nckx>I don't see it here, maybe it's cached…
<nckx>‘Latest commit 0f64c4d 10 hours ago’
<nckx>ps auxwww | grep httpd[.]conf # is another handy type of command.
<nckx>I wonder what they typed.
<nckx>sneek: later tell nazarn65: I have to go for now, good luck.
<sneek>Will do.
<GNUHacker>"ssh -X " work with my trisquel server but dont work with my guix server in same client
<GNUHacker>i think that something is wrong in the server
<GNUHacker>when I try ssh -X to guix server say: "X11 forwarding request failed on channel 0"
<roptat>GNUHacker, did you allow x forwarding in the config?
<roptat>on the guix server?
<GNUHacker>idk, ill check
<roptat>I think it's disabled by default
<GNUHacker>but where is ssh config file in guix?
<roptat>somewhere in the store, but it's generated from your system config file
<roptat>you can find it with guix gc -R /run/current-system | grep sshd_config
<roptat>and you'll see X11Forwarding is set to no by default
<roptat>the example here enables x11-forwarding for instance:
<roptat>(and other stuff too)
<GNUHacker>roptat: nice thanks
<GNUHacker>thats work now
<apteryx>sneek: later tell GNUHacker -X should be fixed on the core-updates-frozen branch
<sneek>Will do.
<roptat>new opam release \o/
<roptat>that means 3 more packages I can finally update without breaking opam :)
***jave_ is now known as jave
<vivien>Hi, it seems that gdm installs /lib/udev/61-gdm.rules in the system profile, shouldn’t it be /lib/udev/rules.d/61-gdm.rules ?
<roptat>that would make sense
<vivien>That file has stuff regarding Wayland, I’m not using it so I don’t know if it’s needed
<nckx>Oh my:
<nckx>That will take some getting used to.
<lilyp>so... what still handles ftp?
<lilyp>other than your file manager
<civodul>(guix ftp-client) FTW!
<civodul>what else? :-)
<nckx>In my lucky case, ‘changing ftp:// to http:// in the address bar’ :o)
<lfam>What's a protocol that can transfer files?
<nckx>I wonder if this will have the desired nudging effect.
<nckx>lfam: DCC over IRC.
<nckx>Just /join #project and request your desired release.
<lfam>Hold on, let me send you this binary for testing
*vagrantc wonders if we'll start seeing software released via gemini://
<nckx>The chiptune midi soundtrack in the, er, ‘installer’ is great.
<lilyp>I really like how warm my PC is getting; was feeling cold.
<gbrlwck>i try to copy a whole repository (it's a python/django app) to a specific location. guix doesn't seem to like my "." for the directory name. what am i missing?
<KE0VVT>civodul: I do not know how to build the PDF for Emacsy.
<roptat>mh, I thought hicolor-icon-theme was supposed to contain some icons? it's completely empty
<podiki[m]>question: guix install llvm would be newest available (llvm 12), and I can reference particular versions in inputs like llvm-11, but seems just "llvm" gives version 9?
<roptat>find `guix build hicolor-icon-theme` -type f returns exactly 2 files
<podiki[m]>is there some default set for LLVM somewhere?
<roptat>well, maybe not, the sources are empty, so I guess it's expected
<roptat>podiki[m], yes I think we do something like (define-public llvm llvm-9)
<civodul>KE0VVT: me neither (do i look like someone who should know? :-))
<podiki[m]>wow, that bit me hard, took so long to see that all the libLLVM* ends in a so.9....and hey look, the store path says that it is indeed llvm-9.0.1
*podiki[m] face palms
<opalvaults>gnome 40 yet?
<podiki[m]>roptat: thanks, now I see it, line 880 in llvm.scm, after all the llvm and clan defs...
<apteryx>podiki[m]: perhaps look at llvm-next on the wip-cross-built-rust branch
<apteryx>it builds the correct
<podiki[m]>apteryx: oh, is that a change to dylib? I know there was discussion of moving to a lib output of LLVM before, but seems stalled
<apteryx>opalvaults: guix pull --branch=core-updates-frozen
<apteryx>podiki[m]: it's the only supported shared library configuration as per upstream
<opalvaults>apteryx: i was hesitatnt to do that but if it's gonna be a long time before guix pushes gnome 40 to the main repo then i might as well
<podiki[m]>apteryx: yes I see it now, good to know!
<apteryx>it'd be helpful to gather more feedback
<opalvaults>apteryx: good point. i'll do that tonight
<apteryx>nothing terrible should happen (many of us are already runnig our systems on that branch)
<podiki[m]>I built LLVM with those options recently, so at least I know it builds and worked with Mesa
<opalvaults>need to be testing if i'm not contributing packages or code
<opalvaults>thanks apteryx !
<podiki[m]>opalvaults: I've been on core-updates-frozen too, works for me! and seems we are Real Close Now (TM) to the big merge
<opalvaults>podiki[m]: cool, i will start getting my machines switched over to guix
<opalvaults>i'm a basic boi and love me some material shell tiling and it wasn't working with 34. :P
<opalvaults>i'm itchin' to get starting switching over
<podiki[m]>x86-64 at least has great substitute coverage now, so no compilation needed
<opalvaults>so thanks all for the info
<podiki[m]>and it is guix, you can switch back and forth between branches and configurations easily :)
<podiki[m]>do report anything you run into of course! and welcome
<opalvaults>another good point! I will make sure to keep reporting bugs as I see them. :)
<apteryx>awesome, thank you!
<tricon>vagrantc: I would very much enjoy that.
<opalvaults>I met someone else on here who ran into the issue. I reported the bug but mattheiu was a bit confused that i ran into this issue. has anyone ever run the graphical installer and had troubles because the installer doesn't reformat the ESP partition? coming from Fedora->Guix it kept booting into Grub with Error: Unknown Filesystem
<opalvaults>I want to see if anyone else has so maybe I can get a better picture. Debian also has weird ESP unmounting bugs in its installer. seems like they are hard to get behaving correctly
<apteryx>my experience is that EFI implementations are often buggy (at the firmware level); I've had the experience that sometimes the EFI partition would stop being writable for no reason until I rebooted the machine.
<nckx>Installer reformatting ESP is definitely a bug.
<nckx>Oh, I read wrong…
<apteryx>*not reformating* ?
<nckx>Installer not reformatting ESP is definitely good?
<opalvaults>Don't you want it to overwrite the grub.cfg in EFI with the correct UUID of the filesystem tho?
<opalvaults>because it wasn't reformatting the EFI partition and correctly writing the .cfg
<opalvaults>so Grub was trying to access a root filesystem that belonged to another operating system
<opalvaults>that's how I understand it anyways
<nckx>Why would you ever want to automatically delete all other operating systems?
<opalvaults>what if I only have one?
<opalvaults>in fact, I only ever have one
<nckx>Then still.
<opalvaults>so it should overwrite the grub.cfg in boot/efi so that grub knows about the newly installed filesystem
<nckx>I don't understand why ‘reformatting’ is mentioned here.
<opalvaults>otherwise you can't access it
<opalvaults>but it doesn't do that
<opalvaults>in my experience
<nckx>Reformatting would still be horrible and wrong, but it's good that's not actually what you're suggesting, it seems.
<opalvaults>maybe if you decoupled reformatting and updating grub for instance that would be fine
<opalvaults>as it stands I had to manually reformat the ESP partition
<nckx>Let's put reformatting away, it's wrong :-/
<nckx>Not even Windows does that.
<opalvaults>no, I mean I had to reformat, in the true sense of the word. I had to have the installer reformat the ESP partition.
<opalvaults>I agree.
<opalvaults>If it was decoupled that'd be fine.
<opalvaults>But it appears that if you don't reformat, for some reason the GUIX installer doesn't update boot/efi/grub.cfg
<nckx>If the installer finds an ESP, it mustn't touch it.
<nckx>Well, extant files.
<nckx>The installer isn't responsible for doing so. Guix (not GUIX) calls grub-install to do so, and fails if it fails. So if grub.cfg is untouched, I wonder what's going on.
<jpoiret>opalvaults: this is definitely weird, the installer calls `guix system init /mnt` iirc
<nckx>opalvaults: What's ‘boot/’ here?
<nckx>The ESP is mounted at boot/efi in that sentence (because as jpoiret implies, it's mounted at /mnt/boot/efi during installation).
<opalvaults>/mnt/boot/efi being the equiv to /target/boot/efi for a deb system?
<nckx>No idea.
<nckx>From the sound of the words, probably.
<opalvaults>unsure if this is non-standard, but fedora uses /boot/efi/EFI/fedora
<opalvaults>which I figured makes sense
<opalvaults>but if it's supposed to fail if it can't grub-install then access/updating/installing grub isn't the issue?
<nckx>In Guix (and apparently Debian) the root of the ESP is mounted at /boot/efi. The ESP has itself a top-level \EFI directory, so yes, the final path is /boot/efi/EFI/$distro.
<opalvaults>and grub-install is done at the end right?
<opalvaults>when I get home I'll try and replicate the issue
<opalvaults>it was a Error: Filesystem Unknown, but actually I don't even think it was unknown, it was the UUID of a filesystem that didn't exist on my computer as I had wiped Fedora off of it
<nckx>What you describe is definitely odd. I've installed Guix over unclean ESPs before without issue.
<nckx>But did you still have Fedora selected in the firmware menu?
<opalvaults>if i'm the only one who is experiencing it it's likely user error i suppose. although I'm not sure why it only worked when I actually reformatted the ESP partition
<opalvaults>well... okay I don't know that for sure?
<nckx>OK. If you do, and \EFI\fedora\whatever.efi still exists, your UEFI will boot that, not Guix's \EFI\Guix\something.efi (bit fuzzy on the names).
<opalvaults>but it was first in the boot selection menu
<opalvaults>not boot selection menu, the UEFI boot order menu*
<nckx>If \EFI\fedora\whatever.efi still exists you didn't quite ‘wipe Fedora’ ☺
<opalvaults>i actually could not boot directly into it from the UEFI menu
<nckx>It being Guix?
<opalvaults>ahh, i'll check it when i get home and hopefully get back to you guys or that bug. i should have taken a picture or something lmao
<opalvaults>it == Guix, yeah
<opalvaults>it would still give me that unknown filesystem error
<nckx>Pictures could very much help! As well as a full view of your actual ESP.
<opalvaults>yeah i'll do that. thanks for helping me get a better picture
<nckx>opalvaults: But are you sure *Guix* is giving you that *error*. That's the link I'm not sure of.
<opalvaults>No, Grub was giving me that error.
<opalvaults>Sorry for being unclear
<nckx>But whose GRUB?
<nckx>Guix's or Fedora's?
<opalvaults>oh, good question
<opalvaults>It didn't specify iirc
<opalvaults>it was "maybe" fedoras?
<nckx>That's where I think (actually hope, because otherwise things get truly weird) the rub is. You (=your UEFI) is booting the old left-over Fedora GRUB .efi file. Guix cannot and should not remove it because it doesn't have a robust method of knowing it's ’obsolete’. It won't destroy data.
<nckx>ESP is user data.
<opalvaults>ahhh, okay. that makes sense as to why it wasn't booting past grub then.
<opalvaults>okay well then that's likely some user error but like i said i'll try and recreate it
<nckx>I'm just educatedly guessing at this point, some data would be much appreciated!
<opalvaults>if i can't i'll assume its user error and try and get the bug closed
<opalvaults>thanks again!
<nckx>I didn't mean to imply it was ‘user’ error in that you should know all this. It's all woefully complex and indeed often buggy.
<nckx>At the firmware level that is.
<opalvaults>well nckx it wouldn't really be GUIX fault for that
<opalvaults>it's so proprietary at that level
<podiki[m]>would be helpful if the guix installer reports seeing something it won't overwrite or otherwise an unexpected thing at that stage
<nckx>Maybe we could think of a way for Guix to help in that situation, but it's tricky: we can't (for example) assume that Fedora is gone just because the drive isn't currently attached. And grub-install should ask the firmware to make Guix the default but the firmware can decline that request (and maybe it should! I wouldn't want distro's changing my default…) or just straight out bug it up.
<nckx>podiki[m]: The Guix installer or Guix or GRUB don't ‘not overwrite’ anything. They write.
<nckx>But if the firmware is looking elsewhere, nothing will happen.
<opalvaults>i'm going to assume bug it up because in most use-cases it doesn't behave in an un-sane way in that regard.
<podiki[m]>sure, so maybe some basic reporting on what it sees when it is not an empty situation? i don't know, efi/grub/etc always cause me so much anxiety
<nckx>We'll need a bit more data before we can blame anyone, including evil firmware manufacturers 😉
<nckx>podiki[m]: But non-empty ESP is the norm, not exception, *especially* with newer users, so any warning would add more stress whilst being very likely gibberish to the user.
<nckx>But yeah, maybe we could handle this somehow. Even though it's normal.
<podiki[m]>good point
<podiki[m]>I'm also still bitter(?) at Grub for not supporting ext4's large_dir option that caused me grief in an early guix install
<podiki[m]>and logging from the installer to somewhere that is of use if boot fails may not be the easiest for (especially new) users to get
<nckx>So'm I, I told someone here about that innocent option without knowing GRUB would choke on it, felt wonderful when they returned all ‘now I can't boot’ >:(
<podiki[m]>don't worry, you didn't tell me, I learned to do that all on my own!
<podiki[m]>and then later saw that email thread too
<podiki[m]>(though with the recent changes in GC and such I see much much less links; I'm at just 255k right now on a very non-gc-ed machine)
<opalvaults>nckx: if you're familiar, what part of the installer codebase is related to network configuration? I've noticed that I'm stuck in a loop if I put the wrong wifi password in and I can't change the password or go to a previous step. Maybe I can look around and see if I'm equipped to change anything
<jpoiret>opalvaults: are you using the latest installer, with LUKS?
<opalvaults>i really think installers are super important to new users but they are a hellscape in their own right for sure. debian still has bugs in their installer dating back many versions. i wouldn't touch that codebase even if I wanted to tbh.
<jpoiret>alright, that's your issue
<jpoiret>i'm currently trying to fix this, but we should revert a82e9f45fd9f7c67123b7064c60065281035c744
<nckx>jpoiret: Which bug is this about exactly?
<nckx>I can revert that if you want, and it won't break anything else, and you provide a brief explanation :)
<jpoiret>installer-generated configs don't mix well with luks2, because grub-probe doesn't handle luks2 modules currently
<opalvaults>wait would that explain the filesystem stuff as well?
<nckx>And opalvaults is using LUKS?
<opalvaults>yes I'm using Luks
<opalvaults>i seeeee
<nckx>That would have been pertinent but then I should've asked, my bad.
<opalvaults>okay big derp
<opalvaults>yeah sorry that's a big detail but I didn't think about it
<jpoiret>i had mistakenly thought that having the installer format luks2 partitions properly would be enough, but I don't think I did try to boot the installer-generated config (I had my own to test with, and only adapted the installer to format LUKS2 properly)
<jpoiret>the issue doesn't arise if you have a grub.cfg that's accessible outside of LUKS
<jpoiret>which is why i didn't encounter it
<nckx>OK, let's revert that change then :)
<opalvaults>oh wow
<opalvaults>that's a keen observation jpoiret, good job
<jpoiret>that's why I'm currently working on GRUB to have grub-probe support that properly
<jpoiret>opalvaults: that's because mothacehe reported that bug earlier, see
<opalvaults>I feel I remember Grub not supporting Luks2 until fairly recently when you use cryptsetup
<opalvaults>you have to specify an older version of luks or something
<opalvaults>way over my head
<jpoiret>it does support LUKS2 unlocking, but support was apparently only half-baked and didn't make its way into grub-probe for example
<nckx>jpoiret, opalvaults: Reverted for now.
<jpoiret>so while GRUB will happily unlock your LUKS2 partitions (with PBKDF2 as its pbkdf, not the default argon2i), it will not detect that it needs that luks2 module while installing
*nckx …oh boy … memories of hacking on (then BIOS) GRUB come flooding back…
<jpoiret>i don't think it should be hard to fix, I have a patch coming that will hopefully be upstreamed
<opalvaults>well i'm glad it's an easier fix. thanks for your hard work on this guys
<opalvaults>much appreciated! :)
<jpoiret>no problem! if you can manage installing without the installer, LUKS2 is supported if you have your grub.cfg on the ESP partition (like I do)
<opalvaults>nckx: re: the link you sent earlier thank you for pointing me in that direction. Nothing looks out of the ordinary.. but then again it may not be catching a failure, and/or not executing previous functions when encountering the error.
<opalvaults>jpoiret: thankfully I run only one OS at a time and I'm working on getting GUIX on all of my systems so it shouldn't be a problem, however I will keep that in mind in the future.
<jpoiret>again, only with PBKDF2 key derivation function, see
<opalvaults>thanks for working on what is arguably one of the most esoteric parts of operating systems
<nckx>opalvaults: I think mothacehe would be interested in hearing about that wi-fi UI bug as well.
<jackhill>hmmm, `guix shell --with-debug-info=swaylock swaylock` doesn't seem to install debugging provide debugging symbols, is that expected?
<opalvaults>okay, i will try and recreate it and take screenshots though next time
<opalvaults>no thank you!
<nckx>I just kept you busy until jpoiret could saunter up and casually ask ‘LUKS?’
<nckx>But glad to.
<jpoiret>if only i had not been deep into grub source, that issue would have been resolved faster :)
<jpoiret>testing a patched grub as we speak
<podiki[m]>this is why I also don't relish the idea of redoing ever my full encrypted disk (laptop) setup, where I did get it to just need one password in the unlock grub step that also unlocks it after (keyfile)
<jpoiret>podiki[m]: are you on guix system?
<jpoiret>i believe i've mentioned it before but even from a security standpoint, that's pretty bad, since the initrd is world-readable
<podiki[m]>not on that laptop, it is Arch. my desktop (unencrypted and wild!) is guix
<jpoiret>alright, it's almost too good: i got grub-probe to actually output the needed luks2 module!
<podiki[m]>jpoiret: what is bad, encrypted boot?
<podiki[m]>but with a keyfile?
<jpoiret>having a keyfile in the initrd on guix system
<podiki[m]>since boot is unencrypted?
<jpoiret>you can't just blindly customize the initrd, you'd have to move it outside of the store, chmod it to r-------- and then add the keyfile to it
<nckx>You can just create a separate initrd with only the keyfile.
<podiki[m]>right, since the store doesn't let you do those permissions
<nckx>No need to customise Guix's once you've patched it too look for /some/file.
<opalvaults>ahh, so that's why guix asks for two passwords
<opalvaults>I think Fedora and debian must keep their initramfs's world readable then
<opalvaults>cuz arch is the only other system i've come across that has doublepass's
<nckx>‘Having a single passphrase prompt’ is separate from ‘being world-readable’. That's currently only an implementation limitation of Guix, not in general.
<nckx>If Fedora/Debian have a world-readable initrd with a key file in it, that's a choice, not a necessity.
<opalvaults>hmm, I wonder if Arch chooses it as well? podiki[m] seems to have gotten around the double password though
<opalvaults>it also makes it nearly impossible to customize the luks pass prompt lmao
<opalvaults>at least I couldn't do it on arch, i imagine it'd be the same problem on guix. it's superficial but i like to make things pretty if I can :P
<podiki[m]> I think that is it, but the size of that wiki page tells you a lot
*apteryx plugs a (wait-for-dbus-readiness) in dbus-shepherd-service's start slot
<podiki[m]>I also can't ever remember if i'm luks on lvm, lvm on luks, or what...I got it all to work following the directions and even did a live resize of a encrypted fs
<nckx>podiki[m]: It's also one of those ‘get all steps right, you might be OK, get one step wrong, you're screwed’ things. Which isn't to say we shouldn't do it! Just that's it's risky by nature.
<nckx>Referring to the page.
<opalvaults>wait but if the initrmfs isn't encrypted, it may not be world readable but it's certainly insecure in that case right?
<opalvaults>I'm not sure how Fedora's dracut handles things to be fair
<nckx>Oh, I was referring only to initramfses stored in the encrypted volume.
<jpoiret>opalvaults: the idea is to have the initramfs on an encrypted partition, with GRUB unlocking it once. Then the keyfile inside the initramfs is used to re-unlock the same partition
<nckx>Outside of it, I don't think there's a sane way to make that work.
<nckx>It sure will work.
<nckx>For everyone.
<opalvaults>so GUIX just hasn't implemented the re-unlocking part
<opalvaults>otherwise it's business as usual
<nckx>Guix hasn't implemented quite a few parts and the initramfs code is currently very static (basically a single script without much extensibility).
<opalvaults>i mean that's how I pictured it my head anyhow, "caching the key" for lack of better terms, and then unlocking the initramfs with it
<opalvaults>interestingly enough, i remember this guy related to KISS linux who wrote the entire initramfs in posix shell. it's wild what you can implement so early on lmao.
<nckx>Not even that. GRUB is what unlocks the initramfs (and kernel), boots one with the other, then the initramfs runs and uses the key it finds within itself (from its perspective: always ‘unlocked’) to mount / and boot it.
<nckx>opalvaults: That's neat but not that rare.
<opalvaults>nckx: all you've convinced me is that I know squat about these early processes. time to rtfm
<opalvaults>i think i still have my RHCSA book around here somewhere..
<podiki[m]>nckx: yes, that wiki page and instructions are a beast. takes a while to understand it but at least it did work for me carefully following it. it is all rather complicated and fraught with peril, which is why I don't look forward to doing that again anytime soon
<nckx>I mean, I'm sure it's a great initramfs & all, but it's still just a shell script that calls external C binaries to do the actual work. That's how the vast majority of initramfses worked before systemd and many still do. I'm sure his is smaller than average & probably cooler but the concept itself isn't mind-blowing.
<nckx>Guix is rather an outlier in that regard, we shell out much less and NIH much more :o)
<opalvaults>it's mindblowing to someone who doesn't understand initramfs apparently ;)
<opalvaults>oh here's another trip
<opalvaults>systemd replacement written in emacs lisp like what?
<nckx>My brain broke.
<podiki[m]>emacs all the way down
<nckx>And up, and around you.