IRC channel logs

<mwette>graywolf: Are you suggesting source tarball inside a release tarball? Just wanting to clarify, as I have repos on github and have started looking at the API for making releases.

<mwette>#guile

<cow_2001>not a real complaint, just that it's a lot of guix derivation to do ~;~ https://codeberg.org/guix/guix/issues/6708 and it fails, but it fails because the first zig in the daisychain of zigs fails, not because the last one fails, so it's the most merciful way of failing

<hanker>hi, can I get some eyes to review this PR please? it's a small fix on lesspipe https://codeberg.org/guix/guix/pulls/4786

<podiki>efraim: commit 12a9f53dd2a1f951ef42cfa2bfb4916864f997ad causing xremap-wlroots to not work right for me, i think it was the #:features that got dropped (inherited packages won't add that argument then?), testing now

<efraim>Oops, sorry. I guess adding back the empty features or adding in a default value should both work

<apteryx>would someone know the right --share recipe to expose video hardware acceleration in a container?

<apteryx>actually I'm not sure if that's the issue, I'm running 'jami' in a container and I don't see the left panel and can't access the settings, it's odd

<efraim>I think it's /dev/dri/<something>

<efraim>sounds like it's missing Qt something

<podiki>efraim: no worries, one of those inherit subtleties; it worked, i'll push a change with the added empty features

<futurile>morning all

<theesm>good morning o/

<janneke>hello guix!

<seres_>o/

<amano>Does guix have services that act like docker compose?

<futurile>amano: there's a Guix service for running Docker containers, and I guess you would continue to use docker compose for those containers, no need to do anything differently

<futurile>amano: or are you trying to define and build containers using Guix?

<futurile>amano: guix pack may be what you want

<amano>futurile: I want guix to act like docker compose.

<amano>Or, I can make guix delegate to docker compose.

<futurile>futurile: well those are your two options - use the `Docker` service to run containers, or use `guix pack` to create a container.

<futurile>duh heh

<futurile>amano -^

<janneke>zulip is getting out of hand...

<janneke>maybe i should refrain from commenting there...

<janneke>or maybe i should just retire :-(

<futurile>janneke: you know you can turn off notifications for channels right?

<futurile>janneke: right click on the channel and tell it "mute"

<futurile>janneke: then you'll only get an email alert if someone @ mentions you

<janneke>futurile: sure...but what i mean is that conversation is moving there

<futurile>janneke: and you can permanently unsubscribe from a channel - I've unsubscribed from the "Official Communities" email lists because I don't need those

<janneke>not being notified doesn't change that :)

<futurile>oh I see - sorry

<janneke>futurile: but maybe you're right -- i can close the browser and ejoy the silence here :)

<janneke>fomo => jomo

<janneke>futurile: no need to say sorry, happy i didn't know about the email feature when unmuted, eg

<janneke>*happy to learn

<janneke>also, i do like pastor's initiatives to make things better; i'm really ambivalent

<amano>futurile: So, docker service is basically like docker compose?

<amano>`guix pack` to turn an entire OS into a container sounds cool as well.

<janneke>ACTION has never seen any need for docker and has no idea what docker compose might be...

<amano>Docker is good for taking a working snapshot of an application with its environment so that you can deploy it in the future when the environment might not be reproducible.

<amano>Docker is like retro game emulator for apps.

<janneke>guix can do that, right?

<amano>Not necessarily if guix upstream drops older packages.

<janneke>as i understand it, docker is never reproducible

<amano>Docker images capture a working snapshot.

<janneke>well, you can copy the binary and the action of copying is reproducible

<amano>You can use gnu guix to create a reproducible docker image.

<janneke>sure

<amano>If you write in clojure, you can also create an uberjar, but you have to package jvm with it.

<janneke>but if you have guix, there's no point; if you don't have guix, you can create a guix pack tarball?

<amano>I know guix focuses on reproducbility, but I don't think it focuses on preservation of history as retro game emulators do.

<amano>I think docker images are good for preservation of old web applications.

<janneke>what good is it to have "a binary that runs"?

<janneke>it's better than nothing, but "we" want source-lever reproducibility

<janneke>think -- trusting trust attacks

<janneke>*source-level

<amano>I don't care so much about that personally... I just want to be able to run old web applications without troubles.

<amano>Not everyone cares about the same things.

<janneke>right, well we have complimentary needs then, i guess that's OK

<amano>I just accept that software is going to be unsafe.

<janneke>i wouldn't want to run a binary that i know i cannot reproduce :)

<amano>If you have old customers who like the old web application, docker images are good.

<janneke>hehe, yeah, well i've been working for 10y to ensure software can be trusted :)

<amano>I care more about keeping old customers.

<amano>Money in.

<janneke>i'm using guix pack tarballs for that

<amano>What does guix pack do? I am not good with guix, yet.

<janneke>guix pack creates the entire closure of a package, as a binary tarball that can be run on any system

<amano>I'm not sure that I can do that for a jar and jvm.

<janneke>try: guix pack hello --symlink=/gnu/bin=bin --no-offload

<janneke>unpack it, you can run: gnu/bin/hello

<janneke>on most every system; you may have to use --relocate on guix pack (possibly even two times for ancient systems)

<amano>guix pack supports docker.

<janneke>yes, you can make a guik pack tarball a lot bigger by wrapping it in docker

<janneke>apparently, there's some need for that!

<janneke>(and then, require the user to have a docker service running too)

<amano>futurile: Have you had any success with making guix packages for openjfx and clojure libraries?

<amano>I suspect clojure libraries can be turned into clojure libraries, but I can't possibly make guix packages for openjfx. It's too complex.

<amano>I mean I suspect clojrue libraries can be turned into guix packages.

<futurile>amano (gah missed you). We have some Java packages, creating Clojure lib packages didn't seem that useful in the end. The Clojure tooling is basically declarative so it just seemed to be repetition.

<folaht>Hey there, I still have the same issue, no thumbnails for webp

<folaht>And I use XFCE/Thunar

<redacted>Weird. guix-1.5.0 is failing to build on my machine.

<redacted>guix weather says there's no substitutes

<redacted>But I'm seeing successful builds with a hash that matches the derivation my machine tries to build https://ci.guix.gnu.org/build/18960455/details

<ieure>redacted, I noticed when I reconfigured some stuff yesterday that they were building guix instead of using substitutes. Not sure what's up with that.

<ieure>They were able to build, but it was very slow.

<jab>does anybody know if guix system would run on GNU Boot BIOS ?

<jab>specifically is anyone running Hurd guix system on real hardware with GNU Boot ?

<jab>rms said that he might like to try running the hurd with GNU Boot.

<redacted>ieure: running reconfigure with --no-grafts doesn't attempt to rebuild guix in this case. Hmmm

<ieure>redacted, hmmm

<redacted>Maybe this is related to that bug I encountered with torbrowser.

<redacted> https://logs.guix.gnu.org/guix/2026-03-01.log#212513

<redacted>ieure: oh nevermind. It *is* building guix

<redacted>I missed it in the derivation list

<jab>what other Thinkpad should I purchase to see if the Hurd will run on it ?

<jab>I'd prefer a laptop that can still run X. I think damien got the Hurd running on a "carbon" thinkpad that had no CD drive. So should be pretty fast.

<ieure>jab, Depends how old it is, they've been making the X1 Carbon for ~14 years.

<jab>that might be the one that damien used...

<vagrantc>hrm. ci appears to not be evaluating the kernel-updates branch :(

<vagrantc>or at least, it has gone over 6 hours without noticing updates to the kernel-updates branch...

<Rutherther>vagrantc: just trigger the evaluation manually

<vagrantc>Rutherther: and that is done ... how?

<vagrantc>i see a drop-down for restarting an evaluation, but only for evaluations it has already seen...

<vagrantc>restart/retry/reschedule

<vagrantc>i have stumbled upon the evaluatin dashboard, which seems to provide a much more compact view of things, at least... :)

<futurile>url?

<vagrantc>to the dashboards?

<vagrantc> https://ci.guix.gnu.org/eval/2139259/dashboard vs. https://ci.guix.gnu.org/eval/2139259

<Rutherther>vagrantc: there is a hook url for evaluation. I will send it after I get home. Cannot find it in mobile client email for some reason.

<Rutherther>It is not available option in the UI, you need to wget /curl

<apteryx>it'd be handy to have a public 'expand-mirror' API to resolve mirror:// URLs into their actual ones.

<apteryx>currently maybe-expand-mirrors is internal only to (guix download)

<xtls_>Does Guix only require the set of binaries defined in bootstrap.scm to bootstrap itself from source code?

<Guest21>if i am satisfied with my guix config, what would be the procedure to install i on a pyhsical machine?

<mange>Usually I would use the Guix installer to install a minimal OS, then I would log into it and "guix pull; guix system reconfigure my-config.scm". I expect there's a way to do it which skips the minimal install, but I've never bothered to learn how.

<sneek>Welcome back mange, you have 1 message!

<sneek>mange, RavenJoad says: I don't have anything yet. I just figured out this problem on Friday and don't know if there is already a solution. I have texlive-scheme-full installed in my home-environment. For example, "texdoc hyperref" does not work because texlive-hyperref's doc output is not installed because texlive-scheme-full only uses the out output.

<Guest21>k thanks

<folaht>Hey there! I still don't have thunar thumbnails working for webp. Can anyone help me with this?

<folaht>On the guix system that is.

<ieure>folaht, Does Thunar support webp?

<folaht>It did on my previous OS, so yes.

<folaht>Including the thumbnails

<ieure>Same version?

<folaht>Same version of what?

<ieure>Thunar.

<folaht>Either same or older version.

<mange>Have you looked at something like this? https://spacebums.co.uk/thunar-webp-thumbnails/

<ieure>Does it need a compile flag to enable webp?

<mange>Not Guix-specific, but it might translate somehow.

<folaht>mange, yes, I just tried that a minute ago

<folaht>And that also happens to be written for the previous OS I was on.

<folaht>ieure, what is a compile flag?

<folaht>Oh, webp itself works by the way. I'm just not getting thumbnails.

<ieure>folaht, An option given to the build process, typically the ./configure script, which controls what features get enabled in the build.

<ieure>folaht, Ah, okay. So it has support, just part of it is broken. Best to file an issue about this.

<folaht>You mean stuff written in config.scm? Or files found in ~/.config...?

<ieure>folaht, Neither.

<ieure>folaht, configure is a script produced by autotools, to determine the properties of the system and libraries available. It's part of the build process.

<folaht>Oh, you mean like a file typically found in the same folder as a makefile?

<ieure>Sometimes? The configure script creates the Makefile.

<folaht>Right, but like I said, the webp filetype itself is supported. It's just that the thumbnailer somehow doesn't load it and I'm not sure why.

<ieure>folaht, I understand. Like I said, it sounds like a bug, so you should file an issue.

<folaht>Where would I be filing an issue?

<ieure> https://codeberg.org/guix/guix/issues

<mange>I mean, upstream's closed issues seem to be saying this should be configured in the way that blog post says. E.g. https://gitlab.xfce.org/xfce/thunar/-/issues/527

<mange>I wonder if on Guix you need to put the thumbnailer in $HOME/.local/share/thumbnailers/ instead of /usr/share/thumbnailers

<ieure>Well, what package in Guix even provides a webp.thumbnailer file?

<ieure>The listed one uses Imagemagick.

<folaht>mange, I already tried putting the thumbnailer in $HOME/.local/share/thumbnailers/ to no avail.

<mange>Do you have imagemagick installed? Also the /usr/bin/convert path would need to be changed to just "convert" (so it's looked up on $PATH).

<folaht>mange, yeah, did that too.

<folaht>ieure, webp-pixbuf-loader I think?

<folaht>I have not copied that one to ~/.local/share/thumbnailers yet though.

<folaht>Alright, I'll relogin into my machine then, see if the new thumbnailer does anything.

<folaht>Nope

<ieure>folaht, Please file an issue.

<folaht>ieure, I will.

<mange>Have you tried debugging tumbler? https://docs.xfce.org/xfce/tumbler/start#debugging_support

<robin>patches with semi-independent prerequisites: one PR or two? (in this case, fixing a gettext bug so that l10n for more subcommands can be enabled in git)

<ieure>robin, I'd send that one as two PRs.

<ieure>Might want to stack the second on the first.

<mange>Huh, I was going to say one PR with two commits.

<mange>Committers have to push the commits independently anyway, so the PR is just a handy grouping for review purposes. If they can be reviewed together then I think it's reasonable to combine them.

<robin>thanks ieure & mange. i'll combine this time, as the git change has been reviewed already and breaks without the other commit

IRC channel logs

2026-03-03.log