IRC channel logs

<mwette>Yes. I copy package `bar' from (gnu packages foo) to bar-local (local packages foo). But you're telling me `-local' is not needed.

<mwette>That should simply things. Thanks.

<ieure>mwette, Are you talking about the package name, or the symbol the package is bound to?

<mwette>right, i've been changing both the scheme identifier and the package "name" field

<donfelohke>offline update guix; offgrid systems updates?

<apteryx>ieure: back then I mistakenly erased my main OS while repartitioning for a dual boot setup. My transition to Guix System was complete ^^'.

<yaircul>Stockholm syndrome, that's what it's called.

<apteryx>I don't think that's an accurate depiction :-)

<ieure>untrusem, https://codeberg.org/librewolf/source/releases/tag/151.0.2-1

<apteryx>I'm succesfully reloading updated configs in nginx without restarting the service now with https://codeberg.org/guix/guix/pulls/8811

<apteryx>it also fixes common usages such as 'include fastcgi_params;' for a reverse proxy using the fastcgi protocol

<ieure>apteryx, Would it work to build the nginx config directory as a store item and symlink to that from /etc/nginx.conf (or whatever)? Also wondering if the copying of stuff from share/nginx/conf could be links instead of copies.

<apteryx>that's basically what the PR does :-)

<apteryx>it uses computed-file to build the directory, which is a store output, symlinked at /etc/nginx by the etc-service-type

<apteryx>lrwxrwxrwx 1 root root 60 May 27 01:44 /etc/nginx -> /gnu/store/0ilp03zc96pqynyly6k7xq5g7gajcw5n-nginx-conf-files

<ieure>apteryx, Gotcha. But within the store item, it's copying stuff from the nginx package, yeah? I see it calling install-file.

<apteryx>ah, yes, these could be links too

<apteryx>good idea

<apteryx>something like this? https://paste.guixotic.coop/magit_guix-spare-323-1254.html

<ieure>Yep!

<dcunit3d>would `guix copy` fail if i set `RequestTTY force` in ~/.ssh/config?

<dcunit3d>sshd on my arch install isn't setting up my profile for non-interactive commands. i've read somewhere that, technically, this is correct behavior for sshd/bash (for commands like `ssh myhost 'guix describe'`

<dcunit3d>that's not what happens on my nixos install though

<dcunit3d>i'm not sure why and i'm just trying get around it for now. i've spent time diffing the evaluated `/etc/sshd_config `on both hosts before ... i just don't feel like it right now

<apteryx>dcunit3d: easy fix would probably switch your shell in /etc/passwd to that of guix

<dcunit3d>thanks, i'll look into trying that.

<dcunit3d>i think once i'm building on a common server that's running Guix System, a lot of this will dissolve away

<apteryx>indeed

<dcunit3d>i just gotta get there to be more efficient lol

<apteryx>I'm starting to look at auto-discovering our define-configuration configs; so far I have: https://paste.guixotic.coop/define-configuration-discovery.html

<apteryx>I'm a bit puzzled by what I see at the REPL; I'd expect jami-configuration to be detected as one; there must be a bug :-) https://paste.guixotic.coop/_Geiser_Guile_REPL_guix-spare_-173349-382045.html

<apteryx>if someone can spot what's wrong there, shoot!

<apteryx>my basic idea is to then plug that in our Makefile.am (perhaps using GNU Make Guile integration? eh), dynamically creating Make rules e.g. doc/configurations/jami-configuration.texi: gnu/services/telephony.scm ...

<apteryx>and finally in our doc/guix.texi when can simply '@include configurations/jami-configuration.texi' when we want it

<apteryx>that'd automate things nicely, I think.

<apteryx>ah, I've found the reason; my code only works if the -fields variables are exported, which fossil-configuration-fields is

<jlicht>apteryx: what's your 'pastebin'? Just random files on a server, if I'm not mistaken?

<efraim>jlicht: looks like it's powered by scpaste.el https://paste.guixotic.coop/

<jlicht>efraim: ah thanks

<Air4x>Hi everyone, I'm having a problem with the gtk FileChooser in Jami, when I try to attach a file the entire program crashes with this error: "(jami:8183): GLib-GIO-ERROR **: 14:14:12.769: Settings schema 'org.gtk.Settings.FileChooser' is not installed". Searching online the only solution I found are to reinstall libgtk-3-common (from the ubuntu forum) or to copy the schemas from /gnu/store/..../gtk.../glib-2.0/schemas into

<Air4x>.local/share/glib-2.0/schemas (from the NixOS forum) which didn't work. Any tip?

<identity>Air4x: try installing gsettings-desktop-schemas, maybe?

<Air4x>identity: already tried, plus it doen't contain the FileChooser schema anyway

<identity>Air4x: what WM/DE are you using?

<Air4x>identity: sway

<Air4x>identity: it's strange as I'm sure that everything worked until a bunch of weeks ago.

<identity>Air4x: do you have xdg-desktop-portal-* installed? if not, try installing xdg-desktop-portal-gtk, xdg-desktop-portal-gnome and nautilus and see if that changes anything

<Air4x>identity: I have xdg-desktop-portal-wlr

<Air4x>identity: So adding xdg-desktop-portal-gtk solved the problem for a bunch of programs, but Jami still doesn't want to cooperate

<identity>no idea, then

<Air4x>identity: I'll come back to it in the future, and I don't expect to need to send files with Jami

<apteryx>jlicht: yep! scpaste.el, which I learned from rekado

<postroutine>Hello. By curiosity, is there a web applicatation, written in go/python/php/etc, containing some JS+CSS and already packaged in Guix ? I would like to learn how it is packaged, especially the JS part and how the frontend static files are stored.

<postroutine>My guess about static files (CSS and javascript) managment depend of it's part of the web app or if it's an independant project. For example a CSS framework or a JS package from NPM.

<postroutine>In the first case, static files part of the web app, the files would be stored in the web app package folder. In the Guix store.

<yelninei>looking at llvm.scm and it is just making me sad, even trying to make it more sensible is hard because of all the inheritance

<yelninei>also would love to move all the packages to the tarballs instead of the 2GB monorepo and it is completely inconsistent. llvm-12 and 13 are built from the tarballs, newer ones from the monorepo. Some are defined via helper procedures, some do their own thing and it is just a mess

<postroutine>In the second case, static files are independant projects, I guess each project have their own Guix package. But in this case, how to retrieve the static files from the web app ? I see two scenarios: The static files are provided by the web app itself or they are provided by the web server.

<postroutine>But, in both scenarios, how to tell to the running processus where to find the static files ? And what to do when the processus is made to search to a specific path you cannot change ?

<postroutine>And how to deal with a web app framework that ask to collect static files, like Django ?

<identity>yelninei: i think we are sort of moving stuff from tarballs to git repos (xz exploit and all that); it would be nice if we could do a sparse clone… or if people did not make git monorepos :3

<yelninei>identity: it is a sparse clone, the llvm monorepo is just 2GB and saved uncompressed on disk . When applying the patches you now have a second copy of the patched version. When building the entire 2 gb are copied from the store to the builddir. so you need at leat 6GB of free space just for the source and that is without any build artefacts (libraries, debug-info, etc)

<yelninei>(also not a huge fan of blindly preferring git-fetch over distribution tarballs, but thats my personal opinion)

<charlesroelli>postroutine: patchwork (use `guix edit patchwork` to view the source code) collects the static files in the build phase and leaves them in the share folder, where they can later be served by e.g. Nginx.

<PotentialUser-45>hi. im building openbox on a guix system and ran into an error that indicates there could be a package im missing but i dont know what. "C prepressor '/lib/cpp' fails sanity check". what should i do?

<ieure>PotentialUser-45, How are you building openbox?

<postroutine>charlesroelli: Thank you very much.

<ieure>PotentialUser-45, There's an openbox package, are you building that? Or manually from source?

<postroutine>I will look at it.

<PotentialUser-45>ieure manually from source.

<ieure>PotentialUser-45, Why are you doing that instead of using the existing package?

<PotentialUser-45>ieure it seems that openbox, when logging in, no longer works properly. my login manager freezes, and will appear on top of the desktop. this happens on another machine i own too.

<ieure>PotentialUser-45, Your best course of action is to report a bug on the issue tracker. If you want to try a newer openbox to see if that fixes it, you need to use the Guix facilities for that, you can't manually compile and copy stuff around onto the system.

<ieure>I see the openbox package is already the latest version, so there's no newer release to build.

<ieure>So you will need to file an issue or post on the help-guix mailing list.

<PotentialUser-45>oh ok. thank you.

<ieure>Maybe it's a problem with the DM, and not openbox?

<PotentialUser-45>it might be. on my other system the same thing happens even on a different dm.

<yelninei>oh god, llvm has changed how they distribute sources multiple times and coming up with something that works for all 10! versions that we currently have is impossible. Do we need that many?

<ieure>yelninei, I think there has been some guix-devel discussion about leapfrogging some versions, but the LLVM bootstrap is based on building newer versions with older versions.

<ieure>Rust, too.

<yelninei>afaik llvm can just be built with gcc, but we need at least 4 llvms for rust, almost all for zig bootstrap,... i hate my life

<yelninei>i guess i understand why nobody has been doing this because this is just misery

<yelninei>ACTION gives up

<bjc>i don't have the hardware for it

<bjc>it takes so long

<yelninei>all i want is to get clang for x86_64-gnu without losing my mind

<bjc>i need that python fix in so i can build my childhurd again

<yelninei>you could reconfigure from your local checkout, but you probably need to cross compiler almost everything yourself

<bjc>yeah, it'll be another long day of compiling

<cdegroot>I have the hardware for it but then there's the whole trust issue of sharing. In an ideal world, some keysigning-style activities and peer-to-peer binary sharing... No clue how it'd work though in a way that's practical. Just theoretical ;-)

<yelninei>ACTION spent 20h compiling llvm and clang

<trev>ACTION claps

<bjc>turns out there wasn't a huge rebuild after fixing the cross-build for python

<yelninei>i guess you need to build guix itself which is just slow

<untrusem>ACTION also commends yelninei's efforts

<bjc>yeah, guix always takes forever, but that was it

<simendsjo>Someone noted on Reddit that linux-libre points to 6.18, same as linux-libre-lts. Should linux-libre be bumped to 7.0? Or should we maintain a linux-libre-latest/linux-libre-stable? I guess linux-libre points to the Default, but are there reasons it's not at 7.0?

<identity>it probably points to the latest LTS instead of latest stable, or something

<yelninei>i think it should be latest mainline, probabaly forgotten?

<identity>maybe; i was thinking the same thing (i.e. «why not 7.0 yet?»)

<ieure>I don't think linux-libre tracks the very latest kernel, but I do agree that it's silly that linux-libre and linux-libre-lts point to the same thing.

<ieure>vagrantc might have context here.

<kaelyn>bjc: I wouldn't have expected a world rebuild, since as far as I'm aware only the cross-compiled derivation for python and python-minimal have changed, and native builds should still be the same (based on my understanding of a few past cross-compilation or arch-specific changes to packages that have a lot of dependents).

<bjc>kaelyn: my worry was that the cross environment itself (hurd64) would have to be rebuilt from near scratch

<kaelyn>bjc: Ah, I see. That makes sense!

<Alavi_me>Hi people. There's something I don't understand about guix. I have set `channel-with-substitutes` in my channels.scm . The way I understand substitutes, they are like the -bin packages from arch AUR. Instead of fully building the package from source, it just installs the pre-built version.

<Rutherther>qw

<Rutherther>sorry missclick

<vagrantc>ieure, simendsjo : yeah, probably should bump the default linux-libre to 7.0 ... we were about to update it to 6.19 only to realize that 6.19 was EOL and we hadn't had 7.0 yet and got lost in all the security updates :)

<Alavi_me>But still, when running `guix pull` it starts pulling gigabytes of packages. for example it was downloading qt-5 packages which is ~500mb by itself. Is this just how it is?

<Rutherther>Alavi_me: really guix pull itself was downloading qt-5? are you sure you don't mean guix upgrade?

<ieure>Alavi_me, Yes. In Guix (and Nix), when an input (approximately: dependency) of a package changes, the package is rebuilt. Traditional Unix-likes replace the dependencies without rebuilding downstream packages. So Guix/Nix tend to have much more package churn than other distros.

<ieure>I agree that `guix pull' should not be downloading qt-5, and I strongly suspect it wasn't a pull which caused that. A reconfigure after a pull, definitely.

<Rutherther>Alavi_me: channel-with-substitutes just ensures that the commit you land on will already have guix itself substitutable. It is in no way related to the issue you describe

<dcunit3d>i'm running through the free Guix ISO installer. when it tests the internet connection, it's getting an SSL error. I think this is running the `guix pull`, but when i run that manually, it also returns an SSL error for both codeberg and git.guix.gnu.org

<ieure>dcunit3d, Check your system time, it's probably way out of whack.

<dcunit3d>... oh lol

<dcunit3d>yep. thanks. that's probably it

<Rutherther>and do not try changing the time through date, that will not work

<Rutherther>does your system have rtc? and if so, do you have a battery in it?

<Rutherther>(specifically your installer will get stuck when you change the date)

<dcunit3d>i have several of these old dell 7020's and the battery's probably drained on all of them

<dcunit3d>ah i see. i've had to fix the battery or manually set the hwclock for a few computers

<Rutherther>that's going to be the easiest way probably. There is a bug in shepherd that prevents this from working right, you need to boot with the right time

<Rutherther>that goes for both the installer and also regular guix system

<Alavi_me>Rutherther: Oh yes sorry I mean guix upgrade

<dcunit3d>okay, thanks :)

<Alavi_me>Am I correct about the semantics of substitutes?

<vagrantc>ieure, simendsjo, et. al. : pushed the default update to kernel-updates, if that doesn't complain will push to master. thanks for the reminders!

<Rutherther>Alavi_me: partially. The guix source tells you how to build a package and based on the full recipe for the build, including all inputs, the /gnu/store path is computed. Then you can either build it or download this path from the substitute. While AUR bin packages are already hardcoded to only download a binary someone built somehow, not knowing how. Of course there is still trust involved, but there is a promise that it has been built the same way you...

<Rutherther>... would be building it

<Alavi_me>Rutherther: Thanks for the explanation. So this is normal? guix upgrade usually has to download a lot of packages?

<Rutherther>sure. And it has nothing to do with what you mentioned. Using vs not using substitutes has to do with builds or downloads. You're already substituting since it's downloading...

<Alavi_me>thank you

IRC channel logs

2026-05-27.log