IRC channel logs
2024-12-13.log
back to list of logs
<mange>No, I don't believe so. I think everything in the store is owned by root, and package definitions are user-provided and not trusted, so that would be a pretty big problem. Any use could write a package definition to produce a root setuid binary. <mange>You can define setuid programs at the operating-system level, which is documented in the manual: "(guix) Privileged Programs" <marmar>plasma desktop seems to not change volume if I scroll on the speaker icon anymore <marmar>but scrolling while having the applet open works <s777>Hello, I am on aarch64 and haven't been able to successfully build guix on "guix home reconfigure" for like 2 weeks, and I'm having trouble making sense of the error <bigbookofbug>hi all ! quick question: i find myself using (guix build utils) quite a bit even in non-guix related personal projects because some of the procedures like copy-recursively are helpful <bigbookofbug>now im packaging one such project for guix and find that i'm not able to use it as an input as its not in the repo - is this indeed the case or am i missing something about a way to import (guix) guile modules? <mange>You can't add (guix build utils) as an input, but you can use it in a gexp with (use-modules) and a bit of extra boilerplate (there are lots of examples in the repo). <mange>In general, though, Guix is not available in the build environment, unless Guix itself is declared as an input. <homo>there seems to be a bug in plan9port as fontsrv is not available, making it impossible to use system fonts <lilyp>what's this with atf/kyua in gnu/packages/check missing? has anyone debugged it yet? <lilyp>mhh, probably a cycle, i see <dariqq>hello, would it be possible to update the guix package again s.t. the default daemon is built with offloading again? <xelxebar>guix offload test reports that my childhurd is happy, but guix build -s i586-gnu isn't actually offloading <dariqq>xelxebar: The actual problem is that currently guix-daemon is built without offloading due to (the related) #74800 <dariqq>youd need to add the patch that fixes the m4 macro to your guix in guix-configuration <dariqq>(which is why i was asking for an update to the guix package earlier) <xelxebar>Oh, interesting. Turns out this is an actually juicy issue. <xelxebar>Also, massive congrats to the shepherd dev teams for the v1.0 release! <xelxebar>Holy crap. The action discoverability and documentation are _way_ better now. <xelxebar>Awww... herd: error: service 'repl' could not be found <xelxebar>Looks like the docs have a snippet for enabling it. <dariqq>hmm tests/guix-package.sh failing for anyone else? <rekado>The "Computing Guix derivation" part of "guix pull" is particularly slow today on my x86_64 laptop. Not sure what's going on here. <yarl>I would like to ask why libsndfile is in gnu/packages/pulseaudio? <yarl>Also why pulseaudio by default? <yarl>as sound service, as mpd output, for packages inputs that do not absolutely _require_ it. <yarl>I am asking because pulseaudio brings a lot of dependencies. <janneke>rekado: completely unrelated, i noticed that bordeaux was really slow for me yesterday night <yarl>For example, I want an headless mpd server, pulseaudio will bring graphical needs. I could of course made services and package variants. I am just wondering if that's the best choice. <rekado>yarl: I have a headless mpd server (on aarch64) <yarl>Just now, I need libsndfile with mp3 support, I then added mpg123 and lame to libsndfile's propagated inputs, but that calls in many uneeded dependencies. <rekado>I configure (service alsa-service-type ...) with (alsa-configuration (pulseaudio? #f) ...) <rekado>why libsndfile is in (gnu packages pulseaudio): history and a lack of foresight. <rekado>same reason why audio.scm and music.scm have somewhat unpredictable contents <homo>err, isn't pipewire a new standard? <rekado>very often in Guix the answer to "why" is "because history, and nobody felt strongly enough to change it" <rekado>pipewire requires a component that runs as the logged in user, so you cannot easily configure pipewire system without seat management etc <rekado>I'm using pipewire, but this doesn't mean that we can just drop pulseaudio from the inputs of all packages <rekado>those packages still expect pulseaudio libraries <rekado>none of the big migrations in Linux audio have ever allowed for simple drop-in replacement. <rekado>pipewire is no different in this regard. <homo>but there is pipewire-pulse for compatibility with pulseaudio <rekado>correct, this doesn't contradict what I just wrote. <yarl>rekado: I personaly was refering to packages that do not absolutely require pulseaudio, where pulseaudio is optional, between other options, as mpg123 <rekado>yarl: yes, for better or worse Guix defaults to configuring packages with a close to maximum number of optional features <homo>can't inputs of all packages be changed from pulseaudio to pulseaudio-pulse? <homo>s/pulseaudio-pulse/pipewire-pulse/ <rekado>homo: I don't say this with a snarky tone. I really do mean that you're welcome to try. I'd be happy to see an RFC with associated patch sets to unify the audio backend. <yarl>rekado: well not in that case, only alsa and pulseaudio, while there is (in the case of mpg123) optional support for coreaudio, jack, portaudio, sdl, etc <homo>rekado: do you mean you have custom config for seat management? <yarl>Not that I'm happy all these are not dependencies... <rekado>yarl: guess that was the easy choice by whoever packaged it. We usually only oppose adding optional inputs when this would blow up the package closure of popular packages by too much. <rekado>a few years back pulseaudio was unavoidable on a graphical system, so it made sense to enable pulseaudio support wherever it was available. <rekado>it's only through discussions like this and investigations prompted by them that we revisit these choices <homo>also I guess optional inputs might ruin builds for anything other than amd64, like gdm is not available on other arches, making it impossible to use gnome <rekado>yarl: if you can make the case that pulseaudio is no longer a good option here (e.g. because pulseaudio is on the way out and mpg123 works fine with pipewire) I'd be happy to see some audio packages slimmed down. <homo>you mean mpg123 doesn't work through pipewire-pulse? <yarl>Yes I think too, that's why I came here to ask. I am just wondering if there would be a third way between making a choice for default as a developper or even as a community for every users, making a working by default thing. And having the user to choose its option for every package/service that depends on one of N libraries. <yarl>What about multiplying packages? For example mpg123-pulse, mpg123-jack, etc. Is that an acceptable practise? <rekado>yarl: there was work on package parameters. I don't know what happened to that project. <homo>fortunately with guix it's very easy to experiment with configurations without breaking anything <homo>the worst thing that happenned to me was kernel corrupting file system while I was figuring out how to enable simpledrm driver <homo>I mean file system got damaged because I had to hold power button a lot of times <homo>speaking of that, I often cannot shutdown/reboot my laptop without holding power button after running "guix system reconfigure", how to make it not switch generation before reboot? <lilyp>do you still encounter this issue with shepherd 1.0= <taeaad>How do QT and GTK themes work when installing apps via Guix on a foreign distro? Do they sometimes/never/always use the foreign distro's settings? For example, VLC doesn't have theme buttons for me. Should I install something alongside VLC via Guix? <taeaad>I think I have asked this before, but I am just trying to wrap my head around how Guix installs work on Desktop. <homo>qt themes are quite dangerous, as they are .so libraries <taeaad>Hmm, OK, so the functionality is removed? <homo>I don't know, I'm new to guix and I run it as a full system <taeaad>homo: Do your apps all match your system settings? <homo>well, I use default theme and fonts, but everything is visible <homo>jami and blender work fine on gnome <taeaad>I just don't like apps that blast my face with white light. <homo>understandable, it's difficult to find good light theme <rekado>I'm trying to switch from Gnome to sway, but I can't figure out what configuration I need, especially when it comes to the greeter <rekado>do I need to use wlgreet? I tried it but the keyboard layout is wrong, and I don't see a way to configure it. <Rutherther>and most of the common greeters (sddm, lightdm, gdm) should work fine with wayland <rekado>I'd like to log in automatically and directly launch sway on boto <rekado>I cannot seem to find documentation on how to launch sway automatically <rekado>the home service appears to only generate a config file, and the manual for the system config only speaks of sway in relation to greeters <Rutherther>to launch sway, you do "sway" if you are using guix home with dbus service or something else that launches dbus. If not, then "dbus-launch-session sway". <Rutherther>After that's established, to auto launch it, it depends on what you are using for launch. For example if you use a simple tty that you auto login to, just put the launch to your shell profile file, inside of an if like [ $(tty) == /dev/tty1 ] <Rutherther>if not, you will also need to take care of XDG_RUNTIME_DIR <civodul>unrelated, but i just had an idea: what if on the first run ‘guix pull’ would populate the Git object store with a copy of itself? <rekado>Rutherther: I'm converting a system configuration that currently uses %desktop-services, so elogin-service-type is among the list of services. I don't know where it fits in in the login process. <Rutherther>it sets XDG_RUNTIME_DIR and creates it. sway needs it <Rutherther>you don't need to worry about that as long as you have it <rekado>(I mentally checked out when greeters, seats, login managers, etc became a thing. Ever since I've relied on the defaults.) <elpogo>civodul: what do you mean by "populate the git object store"? doesn't 'guix pull' already create a git object store with a copy of itself at $HOME/.cache/guix/checkouts/hash/.git ? <civodul>elpogo: yes, but it essentially does “git clone” from scratch the first time <civodul>what i’m suggesting is that it could first copy all its files to ~/.cache/checkouts/… and do something similar to “git init && git add . && git commit” <civodul>that way, i assume that when running ‘git fetch’ from there, it should be much faster because a large part of the data would already be available <civodul>i haven’t checked that hypothesis, but how could it be wrong? <reedm>Is there a way to set the disk size when running "guix system vm --persistent"? <reedm>It seems to default to ~2.7 gigabytes <elpogo>reedm: did you try the "--image-size" option mentioned in the manual? <reedm>Let me give that a try. I think I wrote that off since it says it is only for "guix system image" <reedm>ahh, I see that now. Thanks! <elpogo>csantosb: maybe to reduce the load on the /api/latestbuilds service that needs to be queried to find the latest commit with a guix substitute. i'm guessing though <civodul>hmm what’s going on in ‘rust-ring-0.16-sources’? <jsbiff>Hi all. I'm a little unclear what the difference is, given that you have a channels.scm file, between invoking: <jsbiff>guix time-machine -C channels.scm <jsbiff>I've tried reading the guix manual and it doesn't seem super clear what difference there is <ekaitz>jsbiff: i'm not sure but I'd say the time-machine also takes a commit and let's you travel to the past <Rutherther>jsbiff: the difference is that time-machine is temporary, it just gives you one usage of guix with that channels. Guix pull is more permanent, it updates your guix profile, so the underlying guix you are using will change - specifically it will change what ~/.config/guix/current symlink points to <ekaitz>jsbiff: listen to Rutherther, he's right <Rutherther>you can also switch back to your previous guix profile generations if you needed, see the --list-generations/--delete-generations/--roll-back/--switch-generations arguments on guix pull <jsbiff>Thanks - yeah, I'm aware of that, but what I'm investigating right now is replicating guix environments/profiles, across different machines, by starting with a dev/primary/template machine, where you would install maybe the latest version of stuff, do some testing, then if happy, export channel and package manifest files. <jsbiff>I think then on another machine that you want to replicate that too, you'd probably then use pull instead of time-machine. <jsbiff>Near as I can tell, given ch.scm (exported channels file) and mf.scm (exported manifest), I would want to do: <jsbiff>guix pull -C ch.scm && guix package -m mf.scm <jsbiff>So in the above example, other machines won't have the previous generation to rollback to <jsbiff>So I'm trying to do a more declarative style <jsbiff>although time-machine sounds useful for doing a quick test, like if something broke somewhere along the way, you can use time machine to just quickly check back to a previous set of channels and packages to find out the last time things work properly, so you can then do pull to get back to that version <jsbiff>Rutherther I'm not exactly clear what you mean by vcs locked channels, other than, I guess, that you export the channels.scm and manifest.scm when doing development on a codebase, and commit those files when committing your whole codebase, so your guix environment is pinned to a code commit? So you're still using the same fundamental mechanism? <jsbiff>In my use case I'm thinking of, the environment would be separate from the app version, but want to validate environment upgrades before replicating to QA and later prod machines. Because I want to be able to push, e.g. security and bug fix upgrades for an environment separate of the app which might not update for months. <Rutherther>what I mean is that you track both ch.scm and ch-locked.scm, where if you do an update on one machine you copy that. Then you can go back to any arbitrary ch-locked.scm on any of the machines, because you know the versions <jsbiff>Well, yes, I would version control the channels (and probably the package mf file too, as that might change over time), so I can check out any past combination of channels and manifest to rollback any system to any point in time. <jsbiff>Is that what you mean? I'm still not clear why you have two channels files? <homo>upgrading entire system takes way too much time only because of the kernel alone <Rutherther>because when you pull/time-machine from a non locked channel you get latest commits <Rutherther>you could of course make a script that would remove the commits from the locked channel file if you wanted and keep it just in one file, but it's more work <jsbiff>Ohh, I thought the channels file's whole point was to lock to specific commits? So it doesn't? <jsbiff>when you do guix package --export-channels , does it not pin the commits? <podiki>anyone know what QA status is? doesn't want to show anything for the current branches <jsbiff>Thanks for clarifying. Much appreciated. <weary-traveler>does guix have an OCI container image that can run on codeberg/gitlab's CI? <PotentialUser-85>I would just like to report, that the theming issue I reported same days ago, have solved itself over the course of the last uppdates <civodul>i mean on top of the actual work, the thing is very well written and insightful <civodul>and gives advice for Java bootstrapping at the end <ekaitz>btw, we should fix the encoding... there are many weird symbols there <janneke>"they deserve to be sacked." -- there might be an alternative view as to why they didn't (if they didn't) jupm on this opportunity -- they didn't need to <janneke>in fact, it already is a blog post, just not posted on the blog <robin>i looked into this in the hopes of enabling c# support for godot and got about as far as "probably we should use dotgnu as the starting point" :p <robin>this is amazing work and the write-up is absolutely fantastic <janneke>in a way i'm pretty happy to see that people who believed in the gnu ideas got things right <gabber>why do i get "guix home: warning: ambiguous package specification `glibc'"? <gabber>when trying to reconfigure my home? <civodul>gabber: because you’re asking for “glibc” and there are two glibc@2.39, that’s the ambiguity <janneke>civodul: hmm i was going to say: yes! .. but what if one wants guix shell glibc on the hurd? <janneke>giving it a different name, "glibc-hurd" won't work in all kind [cross] build situations either i guess? <janneke>in any case, at the moment the ux on linux is more important... <gabber>i am failing to fetch (or push) from a git-daemon installed on local host. i get "detected dubious ownership in repository [...] To add an exception for this directory, call: git config --global --add safe.directory /srv/git/guix-configs". <gabber>what global context does this relate to? the root user's? <gabber>or as the user that executes the git-daemon? <civodul>janneke: yes, it’s tricky! or we can set ‘supported-systems’ to the Hurd, and i *think* it will no longer show up on Linux <janneke>civodul: oh, that would be *beautiful* <janneke>i'm puszled as to how this could have gone undetected for so long?