IRC channel logs
2024-01-29.log
back to list of logs
<ieure>Gooberpatrol66-p, It's been broken for hours, I mentioned earlier. <apteryx>ieure: I just 'herd restart mumi' it <ieure>Seems like a lot of the Guix project infrastructure could use some attention. <Groumf>Hi I just saw that there is a guix package in the repo. Should I install guix on my guix system? I thought it would be included. <Groumf>I describe my use case, I deploy a pretty bare system on a distant server and use various environment for various tasks using guix shell. <Groumf>In that case I would want guix on my host system right? (even if it is already guix) <ieure>I don't think you need to install the guix package on a computer running GuixSD. <Gooberpatrol66>after a reconfigure, grub was erroring "unknown filesystem" but recreating the boot entry with efibootmgr fixed it <krascovict>Client: HexChat 2.16.1 • OS: Guix System ? • CPU: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz (1,20GHz) • Memory: Physical: 7,4 GiB Total (5,3 GiB Free) Swap: 3,6 GiB Total (3,6 GiB Free) • Storage: 8,9 GB / 230,5 GB (221,6 GB Free) • Uptime: 1h 5m 59s <Groumf>Is it possible to guix depoly a home-environment? <Groumf>I mean, ideally I would want a qcow image that has everything I need, including dotfiles but I am starting to think I should not be using guix for that. <Groumf>It is not the point of the software maybe. I am a little bit lost. <podiki>there is no guix deploy for home, though it does come up so there is interest for someone to make it <Groumf>I am starting to wonder wether there should be something (a concept) that binds together operating systems and home environment <Groumf>They are really segregated as of now and it does not really make sense to me. <Groumf>Not that I am in a position to make such suggestion... Still, it scratches an itch. <mange>Sorry, it's just called rde. I don't know why I put "Guix" before it there. :/ <Groumf>Hmmm maybe I should dive into rde a bit. I don't know if it is very rational but I sort of wanted to strictly stay in guix. <freakingpenguin>I brought up upstreaming guix-home-service-type on the rde-discuss ML a couple days ago, I'm hoping that'll spark some movement. <freakingpenguin>The code is self contained so you can just copy-paste it into your own config. Works with guix-deploy too. <apteryx>freakingpenguin: thanks for doing that <sektor>Do I run pre-inst-env in the context of the container I made when compiling Guix? Or is that container just for compilation? <efraim>Initial impressions on using the RPI5 as a build machine: It's really fast. Apparently armbian on it uses 16k pages, so it triggers the jemalloc bug. '--tune' incorrectly detects it as armv8 and not armv8.2. and its really fast <sektor>ACTION is returning to his talking ISO project now. <civodul>i wouldn’t have bet on Raspberries as build machines <civodul>good to know they’re now strong enough <efraim>On the other hand it only has 4 cores, and I'm running off an SD card. IIRC ~$110 with the power supply and the heat sink fan <efraim>I still want to test out my wife's macbook air to get a feel for a mac mini as a build machine, but for at-home use it seems plenty fast <efraim>It built libreoffice in 186 minutes <civodul>uh, yeah 4 cores is going to be a problem for GCC, LLVM, LibreOffice, etc. <efraim>{bash,fish,zsh....}-completions-dir looks like a good macro to add to (guix build utils) or somewhere, it's declared everywhere <janneke>jpoiret: lol, its '"" not that hard '"' to make a [gnu/]linux distribution -- great talk btw <janneke>rekado: simultaneously both humble and brilliant as ever, very much enjoyed watching your talk; this recommendation is totally subjective, of course ;) <klm`>How do I install the avr-toolchain from avr.scm? It doesn't define a public package. I tried guix build -e '(begin (load "gnu/packages/gcc.scm") (load "gnu/packages/avr.scm") (import (gnu packages avr)(gnu packages gcc)) (make-avr-toolchain #:xgcc gcc-13))'; but it doesn't produce a working avr-gcc. <efraim>there's a gcc-cross-avr-toolchain, does that work? <klm`>Oh, I didn't see that one. It says "gcc-cross-avr-toolchain: unknown package", but I think it's because my Guix SD is too old. I'll update and give it a try, thanks a lot! <rs404>I have a raspberry pi that I use as a home server. The SD card has died, and I want to install a declarative os on it. I tried GUIX a few years ago, and I do think it's the future, but it was a little beyond me at the time. NixOS seems to have come some ways as well in recent years, becoming more accessibl. I would prefer to use GUIX instead of NixOS on the pi. Can someone tell me the current status of GUIX on PI's and possibly point me to some <rs404>snape: thanks for that. some of it is above my head. I don't have enough knowledge to be able to appropriately gauge the completeness. I'm in a position where I have sme knowldge of NixOS, enough to get the pi servr going, but I do not have enough knowledge to know whether I'll be able to get GUIX running on the pi. is it worth my time as a mid-tier geek to learn the ins and out of GUIX for my pi server (i'm keen, it's just a time issue), or s <snape>plus knowing makes you go from mid-tier geek to high-tier <snape>sneek: later tell mange: I'll do it <rs404>snape: got any suggestions for maps to get there? I need to mainline the knowledge as I don't have time at the moment to sift the internet to find the gems as i need to get my server up and running again <snape>so to basically "guix system init --target=aarch64-linux-gnu gnu/system/examples/raspberry-pi-64.tmpl /mnt" <snape>(note to myself: the channel is so peaceful without peanuts bot repeating my links) <snape>so rs404: you can search for "guix system init" in the docs I pasted <snape>to have some examples of how it's used <snape>for this to work you need to have a "bootstrap os" installed on the raspberry I believe (ubuntu, whatever" <snape>also don't hesitate to ask questions if you don't understand stuff <snape>there's an installer too, but I don't know if it works on the raspberry. I'd use the manual way if I were you <apteryx>autom4te produced scripts contain /bin/sh; is this a bug? <apteryx>or maybe it's the same autotools dilemna, where they should be portable <rs404>thanks snape, I appreciate it <rs404>In NixOS, containers can be mapped to their own IP address, much like Docker's vlan (which is apparently a bad idea to use because of too many MAC addresses floating around? dunno). Are GUIX containers able to do the same (own external IP address per container) without causing too many issues? <snape>rs404: I don't know. The default is that I share the same IP as my container <snape>rs404: btw you can use containers or vms to test your config file, instead of a baremetal <snape>"guix system container" or "guix system vm" <rekado>rs404: you can use veth to give each container its own separate network card <rs404>thanks everyone. hopefully the last question, the GUIX channels, how closely do they follow the Nix channels? I'm looking at it from the nix flakes angle, where the git commits are recorded in a lock file to ensure everything is reproducible. <rekado>(FYI: it’s “Guix”, not “GUIX”. It’s not an acronym. The string that gets capitalized is “GNU” only.) <rekado>Guix channels don’t follow Nix channels. <rekado>you can use “guix describe -f channels” to record the commits in use for all active channels. <rekado>…and then restore that state of Guix with “guix time-machine --channels=thatfile.scm …” <rekado>or with “guix pull --channels=…” <xd1le>that's one of the things I like about guix is that, I still don't understand why nix needs this apparently controversial flakes mechanism for pinning instead of doing something like guix does. but I suspect flakes tackles something more than just pinning. <rs404>not really, basically just pinning. <rs404>and I don't think flakes is controversial anymore, it's become the standard, although you'll only figure that out once you've digested half the internet, and they've confused the crap out of you <takev>My impression of flakes is that they are essentially guix channels. Or I might be missing something. <apteryx>rekado: I think many people get the spelling wrong because of the Reddit GUIX group, or something <dariqq>hi could someone from the gnome team look again at #57292 resp #59489? <rs404>I'm really keen on Guix, but I'm hesitant. Could some please check my thinking to tell me if I'm petting the right side of the dog here. What I want it to be able to easily generate sd card images with a single'ish command, basically a customized distro, that boots, and then fire's up a bunch of containers for various services such as Nextcloud, jellyfin, an xmpp server, i2p, wireguard etc, and cockpit (or similiar). <rs404>There are soooo many pi tutorials out there on how to setup a homelab on a pi, but each one is someone's life story, and then lands up not working. Most homeusers are going for pretty much the same services, in the kind of environment. Why are there not more Pi tutorials for Guix which should be able to make this a scriptable affair as the hardware is the same for everyone (using pi's ovs) <ieure>No opinion on that, but "petting the right side of the dog" is a terrific expression. <snape>rs404: nextcloud will be difficult as its huge and there's much in Guix yet. Jellyfin isn't in Guix, cockpit isn't either <rs404>thanks, came to me a few weeks ago and kinda just described my situation at the time <snape>not sure Pi is that popular here <rs404>pi's are a great marketing tool to noobs though (which might be counterproductive in certain situations) if you wanted to increase number of users <takev>I feel like jellyfin and nextcloud could work via using the oci-container-service-type? A first class service would be ideal, but is there a reason one could not use that? <apteryx>rekado: there was a small bug with the js code for when handling the keyboard event on the copy message-id button; now fixed and deployed on berlin (version 0.0.8) <rs404>takev: oci is basically a docker container right? does guix have facilities to generate docker images declaratively? (nix version https://nix.dev/tutorials/nixos/building-and-running-docker-images.html ) or could I use nixos to generate a container using the nixos nextcloud package, and then convert that container to a docker image and then run it on Guix? What would the approach here be? <apteryx>dariqq: hi! could you cc the gnome team? <dariqq>apteryx: I don't have anthing new to add. Just waiting for a reply/ decision. <RavenJoad>Can guix shell set environment variables within the shell automatically? I need to set LC_COLLATE='en_US' in the shell (I run it with both --container and --emulate-fhs too) and I do not see a way to do that. Nix shells have a shellHook flag that lets you set anything. Is there something similar? <takev>The way that immediately springs to mind is to use --preserve. So, "LC_COLLATE='en_US' guix shell -C --preserve='^LC_COLLATE$'" <takev>Or, wait, does the search paths part of a package allow you to set arbitrary variables? That might be a better way, if so. <ulfvonbelow>alternative hack: guix shell ... -- env LC_COLLATE=en_US bash' <RavenJoad>In my normal environment, LC_COLLATE is unset for me. So preserving it will not do anything. The way this project is built _requires_ that LC_COLLATE be set to en_US for the testing scripts to work. So I might have to go with ulfvonbelow's hack. I wanted to describe that environment either in the manifest.scm or in a shell file that guix shell can read. <ulfvonbelow>RavenJoad: takev's suggestion has you setting LC_COLLATE (temporarily, just for the execution of the 'guix shell' command) in the same line you invoke 'guix shell', so preserving it should work <RavenJoad>That would work for my enter-container.sh script (which just wraps guix shell anyways). <ieure>ci.guix.gnu.org horked? Getting 504s from it trying to download libgnome. <apteryx>dariqq: OK, I think we could use the assets for now, until we come up with a refinement <dariqq>apteryx: i agree that it is not pretty. But the these would need to be added to XDG_DATA_ DIRS through some way. Either by slightly abusing the assets or rewriting the gdm service type to point to the system profile and adding the assets+gnome-shell+extra-packages to the profile which is essentially the same solution (but maybe easier to add further packages). Or do you (or someone else) have a better idea? <apteryx>could the gdm package refer to what it needs at the time it is built? <apteryx>e.g., via a wrap-accessibility-tools phase or the likes <apteryx>this would relieve the need for the special handling of its environment anywhere it gets used <apteryx>(add-after 'install 'wrap-accessibility-tools (lambda _ (wrap-program (string-append #$output "/bin/gdm") ...)) <apteryx>the tools would need to be added as inputs <dariqq>I think this should work. However than the assets could also be moved to the gdm inputs. However there is still a <dariqq>* However the assets could also be moved inside the wrapper, but there is still a dependency on gnome-shell which cannot be put into the inputs as gnome-shell currently depends on gdm <dariqq>and you can hardly call dconf an accessibility tool, however it would need to be present to be able to change the settings <apteryx>ah, so there's some cycle involved if we wanted to use a wrapping phase <apteryx>seems gnome-shell shoudn't ideally depend on gdm, is this still needed in its latest version? <jpoiret>apteryx: basically most of gdm's code is actually in gnome-shell <lilyp>well, for gnome the dependency is reversed <lilyp>Not sure if we can factor gdm out, but gnome-team is welcoming patches :) <apteryx>I just checked, currently gnome-shell -> gdm, but gdm doesn't require gnome-shell <dariqq>apteryx: yes but the gdm-service-type adds gnome-shell to XDG_DATA_DIRS of the shepherd service to run gdm <apteryx>lilyp: in case you needed more context, there is a proposed patch in bug#57292 <apteryx>adding things needed to the gdm-configuration assets to make the accesibility menu finally (yay!) work <apteryx>dariqq: do we know what gdm requires from gnome-shell exactly to be in XDG_DATA_DIRS? <apteryx>we need to ensure gnome-shell is strictly needed; if it is, then so be it, we can continue using the gnome-shell-assets approach for it. I think for the other resources/assets that GDM needs, it'd be nicer to have them wrapped in the gdm package itself <apteryx>then it could in theory work better in more environments <apteryx>and the day we don't need to propagate gnome-shell in an out of band manner, we can obsolete gnome-shell-assets <apteryx>does that sound like a good plan forward? <ulfvonbelow>remind me, what's keeping rust from working on i686-linux? <apteryx>some 2 GiB or something memory limit is busted <podiki>sneek: later tell mange: if you were the submitter of the nginx/certbot patches, you didn't cc the original bug reporter. might want to cc guix-devel for this one too, for visibility and i'm sure there's interest <podiki>sneek: later tell mange: if you were the submitter of the nginx/certbot patches, you didn't cc the original bug reporter. might want to cc guix-devel for this one too, for visibility and i'm sure there's interest <podiki>sorry for the double message sneek! <rekado>apteryx, civodul I think this has been resolved off-list. <lilyp>apteryx, dariqq: if it's just images, we could also pull them in from the package source without a cycle <snape>that would be great to receive emails from debbugs even when we are not cced <podiki>as far as i know that's not what debbugs does (email lists per bug number) even though i had assumed so when i first used it <dariqq>apteryx: did I understand you correctly that you want to add all gdm extra packages (cantarell, adwaita, dconf, gnome-control-center, maybe at-spi2, maybe orca, .... ) to a wrapper for gdm? <podiki>would be nice if we could default to "wide reply" in debbugs in emacs, is that something we can set somehow? or maybe suggest setting a keybinding for that in the guix manual <apteryx>dariqq: everything that is needed to have at least all its visible features work out of the box <apteryx>the font can stay in gnome-shell-assets as that's nice to be configurable <apteryx>but if it hard depends on a specific font, then it can be wrapped <podiki>anyone know how i could debug a networking issue on my guix system compared to a non guix sytem on same network? some server doesn't seem to respond <podiki>wireshark, though i don't know it, didn't seem to show me anything unusual <podiki>i saw ICMP not working, and default tcp_mtu_probing is off; changing that didn't seem to have an effect <dariqq>what would you think of instead of a wrapper gdm propagating the packages, the service adds gdm (and gnome-shell) to the system profile and then starts gdm with XDG_DATA_DIRS set to the system profile (similiar to sddm -service-type)? <snape>podiki: well, there is a keybinding <podiki>but if you just do "r" (as you might be used to in say mu4e) it does not do a wide reply <podiki>or if someone doesn't use gnus at all, they might not know to look for that "wide" part <podiki>nice digging, only 14 years old with no replies :( <podiki>any pipewire via home services users here? should i remove pulseaudio from my system services or does that not matter? <podiki>trying out guix home: do NOT like that it changes files i didn't set up a configuration for, granted it backs up and makes a store link instead <podiki>e.g. my .confg/fontconfig/fonts.conf was symlinked to the store when i have no home fontconfig service declared, so why did it touch that? <podiki>actually, it changed the fonts.conf to the guix home default, losing my setting (well it is backed up, somewhere) <ieure>podiki, Maybe the font service is in the list of default home services. <podiki>good point, i'll have to check. didn't think of that since the manual carefully documents if you don't use the shell service what you need to do on your own <podiki>it also changed my user shepherd init (i probably should have guessed that, since it'll use shepherd for some things) <podiki>ieure: where are the default services? not seeing any list (there are "essential home services") <avalenn>How do I add an environment variable to some build phase ? <podiki>for future reference: you can't roll back guix home from first generation; the backup is in home directory <some number??>-guix-home-legacy-configs-backup <podiki>i have to say, this first experience with guix home is exactly what i feared and put it off; just wanted to use the pipewire service and instead have a minor mess :( <civodul>i feared the exact same thing but it turned out to be okay for me back then <civodul>you meant “roll back from 1st generation” as in “leave Home”? <podiki>backups are there and my files are in git anyway <ieure>podiki, home-fontconfig-service-type is in home-environment-default-essential-services. So it's implicit unless you remove it. <podiki>i guess i'm the rare case of having setup a home shepherd already (within an init.d directory and services in there) <ieure>Looks like there are 10-ish things in the default home services. <podiki>ieure: thanks. where in the source is that? i'm not seeing it <civodul>for me the important thing was being able to test beforehand with ‘guix home container’ <podiki>i should have guessed the shepherd thing (and that is a motivation for guix home, i wanted to do it right so it was next on my list), the font one is unexpected; minor, but surprised <civodul>that limits the risk of bad surprises <podiki>that seemed to be okay but pipewire was crashing <sham1>One annoying part about guix home container I've noticed is that the /run/user/<uid> isn't created properly <ieure>podiki, somewhere in gnu/home <podiki>to answer my question of home essential services: gnu/home/scm <podiki>well, pipewire home service works :) deleted pulseaudio from my system config, though dunno if that was needed <podiki>my fonts.conf (that home replaced) was just to specify my desktop profile font directory, not sure if that is even needed <podiki>next to move my shepherd services to guix home.... <sham1>Just double-checking, but there's no Shepherd service for an Emacs daemon <sham1>Apparently not. Wow, the to-do list just keeps growing <podiki>sham1: there are some proposals and patches, for guix home at least <sneek>mange, snape says: I'll do it <sneek>mange, podiki says: if you were the submitter of the nginx/certbot patches, you didn't cc the original bug reporter. might want to cc guix-devel for this one too, for visibility and i'm sure there's interest <sneek>mange, podiki says: if you were the submitter of the nginx/certbot patches, you didn't cc the original bug reporter. might want to cc guix-devel for this one too, for visibility and i'm sure there's interest <mange>No worries. :) For some reason I thought debbugs would automatically send the message to the person who opened the issue. I'll copy them and guix-devel on my v2 patch series. <bdunahu>Hi, does anyone know where to access logs for Network Manager (or other services) on GuixSD? <bdunahu>I see that syslogd is started, but am not seeing any files in /var/log relating to NM <bdunahu>Oh, it looks like it is all just placed in the messages file. Not a problem <Guest40>alright, guix describe gives the same commit for two devices with the same architecture, but "guix build qutebrowser" tries to build store items with a different hash between the two machines