IRC channel logs

<oliverD>When I install a package in guix (like ungoogled-chromium) the app icon in gnome is just the default unless I restart. Is this a bug?

<oliverD>(I could probably just restart gnome or something but I'm not that smart)

<hugohugo>How is it decided which CI builds can be restarted? emacs on aarch64 fails because its dependency m17n-lib failed (a year ago). I could restart the m17n-lib job (it succeeded), but I get a 403 if I try to restart the emacs job

<hugohugo>my raspberrypi is chugging along for over 12 hours now, building emacs, so I thought it would be good for everyone to have the CI build it

<hugohugo>bordeaux also does not have an aarch64 substitute for emacs, but I don't know how to see the logs there, is that possible? (or on qa or data)

<hugohugo>hmm my laptop CPU has about 5000 bogomips, the raspberry pi only 100, so I guess it is going to take 50 times as long to compile emacs...

<efraim>I've been told that bogomips is a number you can ignore, and that it doesn't actually work that way

<Rutherther>hugohugo: I am afraid that when there is failed (dependency) and no dependency failing found in Dependencies, it's not possible to see any logs

<Rutherther>hugohugo: QA still has the build scheduled, so I think it's just slower. As for CI, I think it could be some kind of a transient failure. For me emacs built on AArch64 recently

<Rutherther>I have restarted the build of emacs, we need it for the release as it's part of desktop services

<efraim>I'm manually started emacs for aarch64 on master a little bit ago

<Rutherther>oh, hmm, hope I haven't done anything wrong with restarting it on CI then

<efraim>it'll be fine, worst case scenario it'll tie up one of the workers waiting for it to finish

<efraim>given how slow some of the builders are that might be a good thing

<Rutherther>I built the whole release-desktop manifest for aarch64 on my RPi on version-1.5.0 branch. So I think it should be possible to build it... not sure what problems CI has

<efraim>I'm thinking we should disable the tests on llvm-18+ and llvm-for-mesa for ppc64le and leave a TODO to fix it

<Rutherther>I think that is blocking a lot of packages there, yeah, sounds like a good idea to me, unless we know how to fix them easily

<efraim>the normal plan would be to skip those specific tests or fix them, but I'm not even sure why they started failing

<efraim>someone should've noticed by now and cared enough to fix them, so I think just skipping them and working on the rest of the stack for ppc64le is a better choice

<efraim>want me to add the commit to skip the tests?

<hugohugo>The problem that the CI had with emacs on aarch64 was that m17n-db failed in 2024, and it never retried that, so it could not build emacs either: https://ci.guix.gnu.org/build/16542429/details (but I could restart that job)

<hugohugo>Rutherther: thanks for verifying that everything builds on a raspberry pi; I'll let it do its thing then

<Rutherther>hugohugo: sorry on second observations I think I did not build the emacs myself, it was substituted. Seems that the derivation changed in last few days and I haven't realized it did

<Rutherther>no I take that back. I did build it, I have a log existing

<efraim>Rutherther: testing this now on berlin: https://bpa.st/5R6Q

<Rutherther>hugohugo: phase `build' succeeded after 5456.8 seconds for me, so I am quite surprised you're building it for 12 hours

<efraim>what arm boards are you two using?

<Rutherther>I am using RPi5

<efraim>IIRC I built libreoffice on my RPi5 in about 3 hours

<hugohugo>RPi400 (the one integrated in a keyboard) (next up is compling guix on my C64!)

<Rutherther>efraim: hm, I am wondering if your change might turn on tests for cross compilations, which would be wrong

<efraim>I already caught that tests were disabled for i686

<Rutherther>ah, make-llvm has "(not (or (%current-target-system)" in the #:tests? so as long as that is inherited, it should be fine

<Rutherther>I have been the one to add that check, yeah, I have vaguely remembered I was trying to get mesa to crosscompile and faced tests in llvm

<efraim>yeah, I started by writing a new one, and then realized I just wanted to add (not (target-ppc64le?)) to whatever was existing

<Rutherther>I think this works only because the base packages has this argument, though. I think if it didn't have it, it would go with the default value you've put as #t. But I would have to do some testing to verify that. Maybe would be nice if we came up with something like "(default-tests?)" that would help in such use cases

<efraim>the default is (not (%current-target-system)), but I didn't test what would happen if the #:tests flag was removed from make-llvm

<efraim>commenting out that block didn't change the derivation for ppc64le

<civodul>Hello Guix!

<sneek>civodul, you have 1 message!

<sneek>civodul, yelninei says: thanks a lot for the quick fix

<civodul>guix/build-system/cargo.scm:231:41: warning: possibly unbound variable `default-guile-json'

<civodul>(seen on next-master)

<civodul>does that ring a bell?

<Rutherther>civodul: it's fixed on master already

<Rutherther>civodul: it was just wrong variable name, it should be cargo-guile-json now

<Rutherther>civodul: (also, hi :))

<hugohugo>for those folowwing along: emacs build on my raspberry pi, but 1 test "did not finish", src/process-tests.log . I'll try again tonight, or I'll wait for the CI to catch up

<hugohugo>*built

<civodul>Rutherther: excellent, thanks :-)

<civodul>(hi!)

<civodul>Rutherther: i’m looking at https://codeberg.org/guix/guix/issues/5324, is that the most pressing issue?

<Rutherther>civodul: I believe it's the most pressing that doesn't have a known fix. I would deem the %desktop-services gdm/sddm etc. more pressing, but that one is not so technical, it's mostly about doing the right decisions. It leaves the i686 system artifact published in quite a bad state - https://codeberg.org/guix/guix/issues/5400

<hanker>Is it possible to add something to `(default-environment-variables)` at runtime?

<hanker>In shepherd

<zenmaya>civodul: i am finally back with an irc bouncer, so i can chat about it more. Regarding the sd_notify, should I contribute a service that is "deemed ready" immedietely or would shepherd open to adding sd_notify?

<zenmaya>also as a sidenote, if i have multiple packages (that is emacs-acm and emacs-lsp-bridge) where lsp-bridge depends on acm, can I push them both in one PR, or do I need to make two?

<hugohugo>I think it is usually fine (or even preferred) to do them both in one PR, but with one commit per package

<psycotica0>Hey folks! I was having some trouble guix pull'ing all day yesterday, and was very confused.

<psycotica0>I was getting timeouts, not errors, but tested curl and git, even from inside guix, and was able to fetch manually.

<psycotica0>I tried overriding the url manually to codeberg, I tried using a `git://` url and a `ssh://` url, and nothing worked.

<psycotica0>I eventually got around it by just doing a git clone locally, outside of guix, and then doing a guix pull pointing at that repo on disk.

<psycotica0>That worked, and I thought maybe it would fix my problem because maybe there was a fix in guix itself. But no.

<psycotica0>So today I came to ask what the next thing to test would be, but everything is working today...

<psycotica0>So... yay? But also this is a pretty unsatisfying answer for me...

<psycotica0>So I guess I'm asking if anything changed yesterday with regards to the servers, or certs, or dns, or something that made `guix pull` break?

<andreas-e>Happy new year, Guix!

<civodul>zenmaya: hi! yes, we could add it to shepherd, but only if we can’t avoid it (because less code is better)

<civodul>in the short term, the best course of action for the VPN service you were looking at is to see if it has another startup method

<zenmaya>it does not sadly, you can only call it as `nebula -c config.yaml` where the config has no mention of a different startup

<FuncProgLinux>o/

<gabber>what library provides OpenCl so that ld is happy and does not "ld: cannot find -lOpenCL: No such file or directory" at me?

<librecat>there are multiple implementations

<librecat>try mesa opencl for a start

<gabber>librecat: thanks!

<librecat>can i make a troll question?

<librecat>"How do i compile this on my mac?"

<gabber>does Guile Scheme run on mac?

<librecat>it doesnt

<librecat>good thing

<gabber>than i'd first look into that (:

<librecat>once my mac model gets a linux kernel port im gonna try porting parabola arm64 :)

<librecat>after i get basic things working with only libre i will add blobs later for personal use only

<gabber>when you get a linux kernel running you can also just directly install Guix System

<librecat>then put guix on there to have reproducible build environments :)

<librecat>also i think the nix syntax is overly complex for little benifit

<librecat>i remember guix packages being alot cleaner

<gabber>Guix is better in every way

<librecat>also nix encourages the use of systemd

<librecat>gabber: yep :(

<librecat>:)

<gabber>i say without having even the slightest cue about nix ;)

<librecat>i tried guix in 2021 as a noob user

<librecat>i tried nix today

<librecat>i think even ideology aside guix has the better syntax

<librecat>also the whole commitment to freedom

<librecat>like inventing gnu mes to make bootstrapping much more transparent

<gabber>not sure bootstrapping really existed before

<librecat>lemme swap nix with guix on my modded nonfree hyperbola i guess

<librecat>i have a super nonfree desktop

<librecat>so i had to compile my own kernel and use nvidia .run file

<librecat>then i realized hyperbola doesnt have enough packagers to keep up with webkitgtk

<librecat>so i am now finding some solution to run vimb using only binaries from my home folder :)

<librecat>i tried nouveau but it would not modeset

<librecat>normally i remember novueau without blobs giving me a good display output and modesetting on this rtx 3080

<librecat>actually if i can already make linux-libre work and only need newer packages why not parabola

<zenmaya>can i call the `,build` pseudocommand in the repl with scheme code? I want an example that doesn't depend on the repl, and I already have a derivation, I am just wondering how can force the build of the drv

<gabber>mesa-opencl does *not* provide OpenCL as in `-lOpenCL`

<librecat>gabber: then look for a opencl loader

<zenmaya>okay i found build-things and with a bit of elbow grease i even managed to build the drv

<Minall>Hello Guix Community!

<Minall>I need NodeJS tools to work with, mostly two versionsof node so I use nvm. Is there something similar already in guix?, I se eonly one version of node...

<Minall>I wonder if I could install both at the same time also

<dthompson>there's only one version packaged but it's not hard to make variants for the version you need. you typically wouldn't have multiple versions installed in the same profile but rather make multiple profiles

<Minall>Okay, that makes sense

<dthompson>the only downside with node is that it takes a long time to compile. I used to compile bleeding edge versions often for dev purposes.

<Minall>Weird question, I'm checking about the reproducible part of Guix... Would I be able to make a manifest to for example, have a small lab that proves a vulnerability, say in Apache or something. And know that it will work after a lot of years?. What would happen if packages aren't available?, would they be built at all?

<Minall>So a small cybersecurity lab like

<Minall>Just making sure it is the right tool for what I want to do, looking at guix time-machine

<Minall>Not sure how that would be different than installing a package by version?

<Minall>Or for going to a specific version of a package, I always have to see the commit on which the package version is the right one?, or can I specify a manifest with certain files in my current guix?

<civodul>Minall: sure, why not; someone was working on a channel containing known vulnerabilities (was it you?)

<abralek>Hi Guix!

<ieure>Hello!

<abralek>Is there a way to download r6rs-discuss maillist? )

<abralek>I would also download r7rs as well

<abralek>gmane does contain reports of wg1 and wg2

<ieure>abralek, #scheme is probably a better place for your question.

<abralek>ieure: hmm I am there actually. Thanks.

<civodul>Rutherther: i have some news on the installer C-c issue (and they’re not good)

<ieure>I'm still missing something fundamental about derivations. I can: (run-with-store (open-connection) (gexp->derivation ...)) and get a #<derivation ...> back, but this doesn't seem to actually build the drv / put it in the store.

<ieure>How do I do that?

<ieure>ex. if I replicate the manual's "The Store Monad" code, I get: #<derivation /gnu/store/33kri2ygfc3p15q7w69zj48mz7b05381-sh.drv => /gnu/store/cx59gzkkfh0n4h5p7b08sf1jf345cz9i-sh 7fbe12e98370>

<ieure>The .drv exists, but the output does not.

<ieure>I found `build-derivation', but it seems like that only works with the non-monadic store API.

<ieure>I would like to... build? derive? the derivation

<abralek>ieure: build it

<abralek>ieure: run guix build --derivations hello

<ieure>abralek, This is in Guile.

<ieure>And it is not a package.

<abralek>ieure: yes, it is not a package, it will be send to daemon to build it

<ieure>abralek, I need to do this from Guile, not from the shell.

<ieure>I found `build-derivations', but cannot make it work. (build-derivations (open-connection) (list the-derivation-record)) gives: In procedure display: Wrong type argument in position 2: #<closed: string 7fbe279da0e0>

<abralek>ieure: guix repl and pas this https://paste.debian.net/hidden/7029d2bb

<abralek>ieure: https://guix.gnu.org/en/blog/tags/dissecting-guix/

<ieure>abralek, When I run your code, I get the same "In procedure display: Wrong type argument in position 2: #<closed: string 7fbe279da0e0>" error as I mentioned above.

<ieure>Stacktrace shows it trying to print substitute update status. It seems like the extent of with-store is shorter than the build process?

<abralek>drop me the full backtrace

<ieure>Ooooh, this only happens in my *Geiser Guile REPL* in Emacs. It works fine in `guix repl' in the shell.

<abralek>Ah

<ieure>That's very frustrating, makes it very difficult to test this code. :/

<ieure>abralek, This is the trace: https://paste.debian.net/hidden/06a55aed

<ieure>Can I turn off substitutes for this build?

<abralek>yes you can (set-build-options store #:use-substitutes? #f)

IRC channel logs

2026-01-07.log