IRC channel logs

<ArneBab_>sneek: later tell flurando: your page is now also avaiable in Hyphanet via USK@eSbvP4grxyJQTNvkHMNm5OE3GXGwN8iyQ97KtUeA~~A,ECF~JY5Cj8-Jrlschj0EXmxGuGmkDC7lP8I58lM~ysI,AQACAAE/install-guix-on-root-vps/0/

<sneek>Okay.

<RavenJoad>What is the license to use for something with a custom license? I have this: https://github.com/LispCookbook/cl-cookbook/blob/master/license.md and am not sure how to attach the license info.

<RavenJoad>Actually, nevermind. I just found licenses:non-copyleft. That should work well-enough for my needs.

<bdunahu>paste.debian.net/1411276 There should be no chance something like this builds right? For some reason it fails, but only because it still tries to build with the default flags, so it seems like it's not being evaluated at all. Even though it's never been fully built, is it possible guix build cached something somewhere? And are the '#~' and '#$' a form of quasiquoting? I can't find if correct usage is documented anyw

<bdunahu>here.

<bdunahu>I might mention look, because you might recognize some of this code. Thanks for the help by the way.

<flurando>I wonder how to set up curiass? adding curiass would say "no target of type 'postgresql' for service 'cuirass'" error, even adding postgresql-role service does not help.

<sneek>flurando, you have 1 message!

<sneek>flurando, ArneBab_ says: your page is now also avaiable in Hyphanet via USK@eSbvP4grxyJQTNvkHMNm5OE3GXGwN8iyQ97KtUeA~~A,ECF~JY5Cj8-Jrlschj0EXmxGuGmkDC7lP8I58lM~ysI,AQACAAE/install-guix-on-root-vps/0/

<flurando>ArneBab_: Thanks! I have noted it down in order to share the "link" with others though I don't use Hyphanet myself.

<ieure>flurando, I have a machine running Cuirass and guix-publish, adding postgresql and cuirass services works for me.

<ieure>flurando, I don't know what you mean by "adding postgres-role," you need postgresql-service-type.

<nckx>bdunahu: It builds fine because the division is never evaluated. If you ‘#:cargo-build-flags flags’ → ‘#:cargo-build-flags flags '()’ you'll see a different story. The third element here specifies the default to use if the parent package lacks the keyword, which I presume your eww package does, and it's a quirk of substitute-keyword-arguments that it then ignores the clause.

<flurando>ieure: I was following a blog. Gonna try adding (service postgresql-service-type).

<nckx>bdunahu: (2) No, it's not possible that Guix caches a sorta goodenough probabuild and returns it instead.

<nckx>bdunahu: (3) #~ are #$ are ‘gexp’ and ‘ungexp’ respectively and they are extremely documented. You can survive by treating it as a weird (un)quote for a while, but you should read up on G-expressions to understand what they actually mean.

<flurando>ieure: Good, interestingly there is postgresql requires configuration set and postgresql package added

<bdunahu>nckx: okay, that explains it, thanks for answering all that!

<nckx>To expand on (2): Guix isn't ccache, it's actually very good at hashing things. :) Chasing down [nonexistent, pointless] ways to make Guix ‘forget a stale build!’ and ‘force a fresh build!’ is a popular time-waster for new users until they learn that two different-looking package expressions returning the same result (/gnu/store file name) *must* be evaluating to the same thing, no matter what was intended.

<nckx>The ensuing ‘fun’ is mandatory and will be strictly enforced.

<nckx>Speaking of, does anyone know if there's a fun™ reason for our fritzing package being so old?

<look>bdunahu: sorry about that! I didn't test it before sending the code, but yes its as nckx said

<look>btw I noticed you're trying to remove gtk-layer-shell from the x11 package variant, since its not really needed

<look>That shouldn't be hard to do, but won't be as direct as you might expect

<look>Because currently, with cargo-build-system, there is no way to pass additional cargo flags to the install phase

<bdunahu>yes, I had noticed that, lol

<bdunahu>I was going to ask

<bdunahu>the only thing I could think of would be substituting the default flags in the Cargo.toml before building, but that seems wrong

<bdunahu>and it's no problem you didn't test before running, I need to figure out how to use substitute-keyword-arguments eventually

<look>I think that is going to be the easiest way of accomplishing that though, that is, snippetting out the default features from 'crates/eww/Cargo.toml'

<look>The best way would be to add better support for features on cargo-build-system, so that tests and install also handle features, and allow passing custom flags

<bdunahu>alright, that fix sounds good

<bdunahu>one other thing, I tried `cargo update`, but found the build no longer worked (exact error: https://github.com/elkowar/eww/issues/1062).

<bdunahu>I looked to see if I could lock dbusmenu-glib's dependencies before generating the lockfile, but it seems like that change would have to take place in this Cargo.toml: `https://github.com/ralismark/dbusmenu-rs`, which means I would have to fork it (that is my interpretation of https://rust-lang.github.io/rfcs/1969-cargo-prepublish.html).

<bdunahu>I can ask this in the pull request too if it makes more sense there

<look>You could not run 'cargo update' tho, only 'cargo generate-lockfile' is needed here, we only need to update the lock dependencies to semver-compatible ones

<look>That seems like a problem for upstream to fix, so we shouldn't have to worry about it

<bdunahu>look: I misspoke, the I only used cargo generate-lockfile, not update (this say https://doc.rust-lang.org/cargo/commands/cargo-generate-lockfile.html implicitly updates in the description).

<bdunahu>it seems like the consensus is dbusmenu-glib is unmaintained because it was generated with a tool

<bdunahu>it looks like it may be possible to use cargo update to avoid updating a specific package

<look>hmmm, this doesnt seem to have an easy fix

<look>I manually edited the lock and got the package to build, so I guess thats it...

<bdunahu>did you update, then manually change the glibc version for dbusmenu-glib from 0.21.4 to 0.18.5?

<look>I updated, then manually removed every 0.21.x package from the lock

<RavenJoad>Can someone on a low-core count machine build the mu package after Guix commit dffaaf19c2c767598251f32c2f54512340ca5525? I'm almost done with a bisect and it seems like the cmake change there breaks mu's tests on very low-core-count machines.

<RavenJoad>My 2-core 4-thread laptop seems to fail building mu after that commit, but is fine before it.

<bdunahu>look: what did you replace them with?

<look>I simply removed them, because 0.18.x would be the only one remaining for everything

<bdunahu>oh I see

<bdunahu>okay, I don't mind doing that, thanks for figuring that out

<look> https://codeberg.org/guix/guix/compare/master...look:eww-fix I pushed the lock, together with the crates (already unbundled everything) on separate commits, if you wanna grab it

<look>The only crate that needed snippetting was rust-toml-edit-0.20.2 from what I could see

<bdunahu>alright, thanks! is it intentional you left out eww/wayland? I haven't checked but assume the size difference on that one is small

<look>oh, the reasoning is simply because its too late rn (1 am) so im about to head to bed haha so I won't have time to figure out and read what dependencies to remove (if any)

<bdunahu>I think none, but I'll double check. Goodnight then!

<look>we should definitely have the wayland variant too, the package should be similar to the x11 tho. If there are no inputs to be removed, then we can at least build only the wayland feature and call it the wayland variant

<look>ACTION goes to bed o/

<apostolis>hello there, i am interested in buying the raspberry pi 500+ keyboard/computer, but I am worried about guixsd compatibility.

<kestrelwx>o/

<Deltafire>apostolis: i imagine you could get it to work, but with a lot more effort than running raspberry pi os

<cdegroot>If you already have a pi, test it first? I have only one "in production" and as it is working fine, it's still running the regular RPiOS. Keep punting on testing Guix. RPi has, IIRC, some oddities around booting with "device trees" and stuff that I think the distro needs to support. Once it's running it's just a regular OS of course.

<cdegroot>tl&dr: if hardware or docs don't explicitly state "it works", it likely won't work.

<kestrelwx>RavenJoad: I've built it earlier today, but not too sure if the commit was fresh enough, I'll do it again.

<nckx>You insult my lappy's core count then ask me to build mu‽ This… this I will do.

<nckx>RavenJoad: Any requests for -{M,c}?

<RavenJoad>nckx: On the ./pre-inst-env guix build? Nope. On this low-core-count laptop, it's just a normal ./pre-inst-env guix build. I assume that means -M=1, -c=4.

<nckx>Built fine, let's try 5 rounds.

<RavenJoad>Odd. I'm going to try to let this bisect finish. Currently in the middle of building gpg.

<nckx>(Not odd, s/built/grafted/ because I didn't look at the output. Now actually building.)

<kestrelwx>Built fine for me 2 core 2 threads.

<RavenJoad>I'll be waiting on this bisect for a while longer, I guess. I finished a brotli and pybrotli build recently and am onto glib right now.

<nckx>Built fine for me too, -{M1,c4}, 2C4T.

<nckx>Upstream commit 2efb4f3b (which is after dffaaf19, but I didn't try the latter).

<nckx>This machine has notably little RAM (4GiB, and it's running a lot of desktop stuff). I don't know whether that's a factor in how CMake schedules tests.

<RavenJoad>Neither do I. This laptop is decently barebones right now. I was testing Sway and Quickshell. But I have 36G of RAM. The scheme tests (mu-scm) are the ones breaking for me. It seems to always be the same tests that fail.

<RavenJoad>The tests fail because of the actual output is different than the expected. But the actual output is sensible, it looks like output for a different test.

<bhoot>Hello. I was trying to figure out what brought in the super-slow-to-download qtbase-6.9.2-debug.drv when I didn't have any explicit Qt/KDE software installed. So I built a system graph. The following is the dependency chain: gnome-shell-46.10.drv -> gtk-4.16.13.drv -> gst-plugins-bad-1.26.3.drv -> zxing-cpp-1.2.0.drv -> zint-2.15.0.drv -> qttools-6.9.2.drv -> { qtdeclarative-6.9.2.drv, qtbase-6.9.2.drv } -> { qtdeclarative-6.9.2-debug.drv, qtbase-6.9.2-debug.drv

<bhoot>}. Pretty pervasive. So would this mean that GNOME in guix would always depend on qtbase?

<pers0n>looks like i messed up and i made a guixsd update where i am dropped to the grub shell. any guides or advice to find and set a previous linux/initrd from grub shepl?

<ColdSideOfPillow>hello guix!

<ColdSideOfPillow>apologies if this is not an appropriate request, but could someone with the necessary time (and commit access) please take a look at https://codeberg.org/guix/guix/pulls/2478 ?

<ColdSideOfPillow>it's been unreviewed for two months despite being a one-line change in a single string

<RavenJoad>ColdSideOfPillow: I don't have commit access, but looks fine to me.

<ColdSideOfPillow>RavenJoad: Ha, I guess it would certainly be an impressive accomplishment if it DIDN'T look fine :P

<untrusem>how to know the size of your current system generation?

<identity>untrusem: feed the canonical filename from ‹guix system describe› to guix size

<untrusem>it gives 0 mib

<untrusem>nvm

<untrusem>fed the wrong file

<untrusem>can we make `guix gc` to only removes substitutes that are one month old

<untrusem>I just download 4gig of stuff today don't want to redownload it but I am low on space

<nckx>untrusem: There's no way to make guix gc (dis)prefer individual store items, but there's no technical reason that such features couldn't be added.

<nckx>--gc-keep-{derivations,outputs}=yes can improve some workflows but if you're already running near capacity they probably won't be of much help.

<nckx>(These are daemon options.)

<listentolist>untrusem: Doesn't `guix gc -d 1m` do that?

<Rutherther>no, that deletes generations older than one month. Still if something is not gc rooted and has been downloaded 5 minutes ago, it might get removed

<Rutherther>it is common for either build dependencies or for non-grafted outputs (when grafted outputs are used) that they aren't gc rooted

<listentolist>Ah ok.

<Rutherther>with grafts it can be even GB or tens of GB depending on how many grafted packages are in your profiles

<Noisytoot>nckx: I think you use coreboot, could you have a look at https://issues.guix.gnu.org/67403? it's sat unreviewed for 2 years and fixes a freedom bug

<Noisytoot>and also I want to package ectool but I'm blocked by this

<Noisytoot>currently I have to build ectool myself in order to set battery charge thresholds

<weary-traveler>what's a way to find which version of the packages are available?

<weary-traveler>s/packages/package binaries/

<ieure>Substitutes?

<weary-traveler>yeah, in the substitutes

<weary-traveler>sorry my guix syntax is rusty after some months

<ieure>weary-traveler, `guix weather'

<weary-traveler>ieure: thanks

<weary-traveler>ieure: after move to codeberg, is the place to look for bugs codeberg or both debbugs and codeberg?

<weary-traveler>okay at least the issue i'm running into seems to be mentioned on codeberg issue list

<ieure>weary-traveler, Codeberg is where recent stuff should be getting filed, older issues are still in debbugs.

<weary-traveler>shame, but understandable

<pers0n>looks like i messed up and i made a guixsd update where i am dropped to the grub shell. any guides or advice to find and set a previous linux/initrd from grub shell? have no way to live boot atm.

<bdunahu>pers0n: have you seen https://guix.gnu.org/manual/devel/en/html_node/Chrooting-into-an-existing-system.html?

<ieure>pers0n, Are you using full disk encryption? I've gotten that occasionally when I enter the wrong passphrase.

<pers0n>bdunahu - i cant get to a live image at the moment

<pers0n>ieure - i have luks but its not grb rescue. i unlock successfully but i am droppes to grub shell. i have access to drive but it seems it got bnalked with me experimenting a system config. i just need to find the previous linux/initrd files to boot from grub shell. i was hoping there was a way so i didnt have to wait to get a live usb.

<ieure>pers0n, I'm not sure how to do that with Guix. With Debian, the kernel and initrd are in /boot, so you can pretty easily point grub at them and boot manually. They're somewhere in /gnu/store on Guix, I'm not sure if there are symlinks somewhere or what.

<weary-traveler>does codeberg have a decent emacs interface?

<ieure>weary-traveler, There's fj.el, I haven't tried it.

<weary-traveler>ack

IRC channel logs

2025-11-30.log