IRC channel logs

<apteryx>applying a patch to flex causes a circular dependency issue ^^'

<apteryx>resolved by wrapping the flex origin in bootstrap-origin

<sham1>What was the command to tell someone something in the future

<tomenzgg>sham1: it's sneek. Do something along the lines of "sneek: later tell <username> <message>".

<sham1>Nice, thanks

<sham1>sneek: later tell ekaitz While I can't be really sure, having one commit per package might be a vestige of the email-based patch workflow. It probably also makes bisecting easier

<sneek>Got it.

<tomenzgg>sneek: botsnack

<sneek>:)

<untrusem>hello I am having problem running an application from nix that is flufllychat, I get `(fluffychat:5269): Gdk-CRITICAL **: 10:32:32.914: gdk_gl_context_make_current: assertion 'GDK_IS_GL_CONTEXT (context)' failed`

<untrusem>** (fluffychat:5269): WARNING **: 10:32:32.914: Failed to initialize GLArea: No GL implementation is available

<untrusem>I also seem to have problem runnning application that needs opengl, do I need some kind of setup

<lilyp>trev: yes, but it's complicated; you'll have to inherit the package and then set the #:system or #:target argument

<sham1>untrusem: you probably need to install some dri-driver things from nix for it to pick up on your hardware acceleration

<sham1>untrusem: see also: <https://github.com/nix-community/nixGL>

<apteryx>efraim: hi! why is our grub named per-platform now?

<apteryx>I also think there should be some deprecated variables to ease the migration from grub -> grub-*

<untrusem>sham1, I will try this

<untrusem>thanks

<sham1>Nix and Guix of course mix a bit like oil and water, although that's of course on purpose since things should only depend on stuff that are within their respective stores

<apteryx>(at least it broke my user manifest, where I was keeping 'grub' for its documentation :-))

<apteryx>hm, I see there's a 'grub' variable still, but my user manifest uses specifications->manifest, which works onnames

<apteryx>on names*

<apteryx>I guess if you use the deprecation procedures that will DTRT

<untrusem>sham1, nix-gl works :)

<untrusem>I wonder what could be missing from guix

<vhns>Hi. Is there any way to get guix-home to igore that directories and or files exist? I currently can't get it to place certain configuration files due to that warning. Here's an excerpt from its output: https://paste.debian.net/plainh/7e9dd63d

<vhns>From my understanding, even if it detects an existing file that isn't a symlink to the store, it oughta replace it with a symlink to the store and save a backup of the original file at ~/TIMESTAMP-xxx, no?

<lilyp>can anyone build python on an unprivileged daemon?

<lilyp>I tried with the new kvm group patch, but I'm getting an unexpected OSError (22; Illegal Argument)

<vhns>Can (local-file) not accept an absolute path?

<vhns>Ok.

<vhns>I think I found a bug

<lilyp>it should resolve to an absolute path

<vhns>yeah

<vhns>I think the bug is in guix-home

<vhns>I'm a bit tired today

<vhns>should be able to reproduce by the weekend or something

<trev>can someone trigger the CI on this PR so I don't have to overheat my laptop? https://codeberg.org/guix/guix/pulls/3727

<untrusem>apretyx , cbaines might be able to, how does bot selects pr to build programs of?

<trev>i thought a maintainer has to trigger it

<cbaines>I don't know anything about it, but I though this was the URL for the Cuirass instance https://pulls.ci.guix.gnu.org/

<cbaines>but it doesn't seem to be working

<csantosb>"502 Bad Gateway"

<efraim>snorenotify broke with the extra-cmake-modules update, project is archived by upstream

<andreas-e>efraim: File a removal request? But it has a dependent. Which also looks outdated, last release in 2022.

<efraim>andreas-e: I'm still using quassel, so I noticed :)

<efraim>They're still working on porting quassel to qt6

<efraim>sneek: later tell civodul I'll try my pine64 image again with shepherd-1.0.8

<sneek>Okay.

<efraim>sneek: botsnack

<sneek>:)

<andreas-e>efraim: I use hexchat, but this is also archived. At least it still builds for the time being.

<cow_2001>is there a way of converting an existing installation into a guix? without reinstalling everything

<apteryx>yes

<apteryx>into Guix System you mean?

<cow_2001>yes

<apteryx>also yes

<cow_2001>O_O

<cow_2001>nice!

<apteryx>I assume that by 'without reinstalling everything', you mean, without having to go through the boot from USB drive classic installation method, right?

<cow_2001>oh, yes, right

<sham1>Changing a foreign distro into guix. It sounds possible but also quite error-prone

<cow_2001>oh boy

<apteryx>The host OS you run 'guix system init' from would make your old system mostly unusable, but it also won't clean up the directories everywhere, so you may want to do some manual house cleaning post installation.

<apteryx>sham1: it's a relatively common thing done; I think that's how I installed Guix System on my OVH VPS (https://lists.gnu.org/archive/html/help-guix/2024-08/msg00125.html)

<untrusem>sham1: i filed a issue about the opengl error for nix programs, https://codeberg.org/guix/guix/issues/3740

<cow_2001>alternatively, can the external drive installation program keep the old files and only write the guixy files?

<cow_2001>/home/ and /var/

<cow_2001>keep those intact

<apteryx>if you worry about old files, a backup is a must, although /home should be left mostly untouched.

<cow_2001>i see

<cow_2001>thank you!

<apteryx>you're welcome! have fun!

<sneek>Welcome back tomenzgg!!

<tesseract>guys, guix has arm64 too, righT?

<tesseract>can i install it on raspberry pi os?

<tesseract>the official script will work?

<ieure>tesseract, Which script, install.sh?

<tesseract>ieure: yeah

<ieure>tesseract, There's an example operating-system for raspi in the repo if you want to run Guix System. Note that rpi requires firmware blobs for some functionality (GPU, I believe) which Guix can't include.

<tesseract>ieure: yeah. i want to try it on raspi os trixie

<tesseract>ieure: install.sh will work,?

<tesseract>if the gpu needs blob, does that mean icecat won't work on raspi?

<ieure>tesseract, Weeeeell. It should work about as well as any other platform.

<ieure>No idea.

<tesseract>alright

<ieure>tesseract, If you're installing on Raspi OS, that has the blobs. Missing firmware blobs should only be an issue on Guix System.

<tesseract>ieure: but GUI software would work no matter what, righT?

<tesseract>i mean gui software installed from guix

<tesseract>wow. there is even mullvad browser in repo

<ieure>tesseract, I believe I already answered that question.

<tesseract>what is the different between icecat and icecat-minimal?

<tesseract>i think "guix install icecat" installed "icecat-minimal" for me

<ieure>I don't know the difference. I don't believe it's possible to have installed a different package than you told it.

<tesseract>i am doing "guix search icecat". it shows me both "icecat" and icecat-minimal" packages

<tesseract>and some other packages

<ieure>Yes.

<Rutherther>of course it does it searches by a regular expression in names, synopsis, description & maybe something else

<tesseract>ahhh. there is no arm version icecat

<ieure>Why do you think that?

<identity>tesseract: when you know the exact name of the package, you can do ‹guix show icecat›

<tesseract>ieure: "systems" section shows available architectures of packages

<tesseract>identity: yeah it did the job

<tesseract>"systems: x86_64-linux"

<tesseract>all packages are approved by GNUers, right?

<identity>which means what?

<ieure>tesseract, I'm not sure what "systems" represents, but aarch64-linux is definitely supported.

<tesseract>identity: i mean, there must be leaders who allows packages, right?

<identity>tesseract: ‹guix weather --system=aarch64-linux icecat› shows that a substitute available

<identity>tesseract: what leaders? allows on what basis?

<identity>what does ‹allow› even mean?

<identity>s/substitute/& is/

<tesseract>identity: ieure for example for weechat "systems: x86_64-linux i686-linux"

<tesseract>it supports both 64 bit and 32 bit

<tesseract>but for icecat it is only 64 bit

<tesseract>identity: i mean, some people who approves packages to entering in the repo?

<identity>tesseract: i have no idea what the system field means, but it is definitely not supported-systems

<identity>tesseract: commiters? sure

<tesseract>for example a guy is building unofficial icecat. i read they wanted to approve their icecat but GNUer guy didn't

<ieure>tesseract, Are you running `guix show icecat' on an x86 machine of some sort? I only see "x86_64-linux" on my Intel box; I believe it's the builds which can work on the system you're currently using, not every system a build exists for.

<ieure>tesseract, Do you have a link or reference to this "GNUer guy" situation?

<tesseract>ieure: yes i am using x86 machine

<ieure>tesseract, I am truly baffled by your question about this.

<tesseract>let me find it

<ieure>Will just say, Guix makes it very easy to run your own channel with whatever packages you want. You don't have to include a package in Guix proper to use it like any other.

<andreas-e>In principle, we accept all free software.

<tesseract>andreas-e: even the malicious ones?

<tesseract>how do you trust the maintainer?

<ieure>How do you trust the maintainer of any software?

<Rutherther>but usually not forks of software that's already packaged. So if someone was making their own icecat version, I wouldn't be surprised if that wasn't accepted to guix channel

<identity>you trust the maintainer(s) the way you always do

<andreas-e>As for web browsers, it is a lot of work to keep them updated (thanks to the contributors who are tirelessly busy with these important pieces of software :)), so it is not a good idea to accept an infinite number of variations.

<tesseract>ieure: https://lists.gnu.org/archive/html/gnuzilla-dev/2023-10/msg00013.html

<ieure>tesseract, How does this have anything to do with Guixz?

<ieure>*Guix

<tesseract>ieure: he says "I won't be able to officially promote them" "officially"

<ieure>Yes, and?

<tesseract>i don't know man

<ieure>They also say "Yes, of course. As long as you comply with the license, you don't need anyone's permission to do this. If you needed permission, it wouldn't be free software."

<ieure>tesseract, So what's your concern? Why did you bring this up?

<tesseract>nevermind

<ieure>okay then

<tesseract>is there something like, key packages are maintained by known people? like people work for fsf etc?

<ieure>tesseract, No, Guix is a volunteer project. Anyone can apply for committer access, and you can contribute without being a committer.

<ieure>This is the same as most non-commercial distros.

<ieure>If you feel like this isn't a good idea, I have some extremely bad news for you about Raspberry Pi OS.

<tesseract>say please

<identity>other non-commercial distros have more contributors…

<ieure>tesseract, There are two kinds of people: those who can infer from missing data

<Rutherther>ieure: and the second?! jk

<PotentialUser-10>Hi

<sham1>Hi

<ieure>Hello.

<sham1>And the person left

<vagrantc>hrm. julia faild to build locally ... but i only was building julia becuase of git ... and on the second try i get substitutes for git

<sham1>One thing that annoys me about `modify-services` is that I cannot unconditionally `delete` a service that may or may not be there. Like, does it matter whether `sddm-service-type` is in use in the list of services if I'm doing a (delete sddm-service-type)

<ieure>sham1, That is annoying.

<sham1>> An exception is raised if a clause attempts to modify a missing service.

<sham1>But why tho

<vagrantc>just need to implement delete-or-not-what-do-i-care

<vagrantc>well, that's functional programming for you

<vagrantc>"you asked me to delete a thing, there was nothing to delete, EEEEYK!"

<sham1>Honestly? Yeah. Or if the idea is that you might not want an inadvertent remove then it could be an optional boolean argument after the service name

<sham1>(delete sddm-service-type #:force? #t) or something along those lines

<vagrantc>maybe delete-if-present or something could be implemented

<vagrantc>(and consider weather making it the default would make sense)

<ieure>sham1, I think error on modifying makes sense; extensions really ought to be used for most of those cases, and it seems confusing to silently noop if the services aren't what you expected.

<sham1>I can also see that, which is why I feel the no-opping behaviour ought to be an explicit thing that one needs to knowingly do

<sham1>Sure, I can always use the standard filter for that, but it's not quite as nice

<ieure>IMO there's an argument to be made that delete should noop, but modify shouldn't.

<tux0r>every time i think the guix system could be a good choice for a certain server project, i see a severe lack of the exact packages i'd need. i think that's a trick to get me to 1) just run guix in some vm and 2) make me write and commit the missing packages myself, right? :|

<trev>tux0r: don't forget to look up packages on https://toys.whereis.social/

<tux0r>trev: whoops!

<tux0r>TIL..

<tux0r>ACTION takes notes

<foobar_>Hi

<sneek>foobar_, you have 1 message!

<sneek>foobar_, raghavgururajan says: You do not exist.

<foobar_>Wdym I don't exist. I'm real as it can get

<tux0r>there is no aarch64 ISO right now, or am i missing ongoing community debates? :)

<untrusem> can you make a recursive loop for a shepherd service and make system unbootable?

<untrusem>asked by someone

<Rutherther>yes

<untrusem>ohh ok

<ekaitz>sham1: i see the point on the bisect, but also, if a commit breaks things, i don't think that should be allowed

<sham1>Eh, probably shouldn't, but those things happen. And as the other part of the message implies, it more likely is a vestige of the email workflow

<sham1>Since with that, each package definition would be its own message in the email thread

<ekaitz>yeah... i understand...

<ekaitz>but in reality sometimes guix is broken between commits in master branch, which is weird

<trev>guix pull with responsibility

<trev>err...responsibly

<alanz>I am trying to configure an old laptop running guix as a server. So no gnome, just elogind. But I have not succeeded in stopping it from going to sleep when unattended. And it seems that the current desktop.scm does not expose the elogind sleep.conf settings AllowSuspend, AllowHibernation, AllowSuspendThenHibernate, AllowHybridSleep. Is there some simple way to do this?

<trev>alanz: (handle-lid-switch-external-power 'ignore) on elogind-configuration is enough for me. Of course, using `modify-services' to add that. Laptop doesn't sleep when plugged in

<alanz>trev: thanks. I have that, but it still goes to sleep. I think. It stops responding to the world until I try to ssh into it. And during the "off" time it does not log things, like I have a 2 min mcron to check connectivity to 8.8.8.8, it shows nothing during the off time.

<andreas-e>alanz: If you start with %base-services instead of %desktop-services, you will end up in a text based environment, which does not go to sleep.

<alanz>For some reason (home?) I needed /run/user/1000 stuff, which seems to only come from elogind

<Rutherther>you definitely do not *need* that, it just happens to be the default XDG_RUNTIME_DIR, just set that env var to a folder you prefer, ie. something under /tmp

<alanz>Rutherther: good to know.

<alanz>My config for this stuff is https://gist.github.com/alanz/bef47af26e1dd18d5a9f0a6343f88aea, and it does modify %base-services

<alanz>But I am just prepending to %base-services, let me try modify-services instead

<andreas-e>My configuration: https://codeberg.org/guix/maintenance/src/branch/master/hydra/thinkpad.scm

<andreas-e>without elogind

<alanz>andreas-e: thanks

<alanz>ACTION slaps forehead. elogind manages a user session. So it only becomes alive when I login to the laptop, via a ssh session.

<Deltafire>alanz: i have (handle-lid-switch 'ignore) in addition to the -external-power variant - just to be sure

<alanz>so me logging out kills what I have set.

<Deltafire>hmm.. i'm running a laptop server also and it doesn't fall asleep

<Deltafire>but there are services running on it under tmux

<Deltafire>so maybe that's why?

<alanz>Well, my actual problem is a delta-chat bot I have written, that stops responding when I am not logged in. And I assumed it was a power off thing, as in it simply stopped responding when I left it alone

<Deltafire>leave something running on your user session, see if that stops it

<Deltafire>i feel like i should be using Delta Chat..

<alanz>My bot is a proof of concept. https://git.sr.ht/~alanz/guix-channel-az/tree/master/item/az/deltachat-bot-az.scm

<Deltafire>oh, nice choice of language :)

<alanz>Well, parens are good

<foobar_>Will guix run out of money and die?

<ieure>Uh, no?

<foobar_>Last update was 2 years back it looks like

<foobar_>1.4.0

<foobar_>Is it getting updates

<ieure>That's the last release, not the last update. Commits are pushed every day. It's a rolling release distro.

<kjartanoli>Last commit was 30 minutes ago.

<foobar_>Is the documentation up-to-date?

<foobar_>Atleast is it better than nix docs?

<kjartanoli>As long as you make sure to read the development manual (https://guix.gnu.org/manual/devel/en/), not the 1.4.0 one then it should be up to date yes.

<Deltafire>"1.4.0 — 9 July 2025", that doesn't seem right

IRC channel logs

2025-10-22.log