IRC channel logs

<AlgorithmicInfor>Does anyone know if there are any services that offer GNU Guix VM's/compute platform?

<meatoid>AlgorithmicInfor: There is guix-hosting.com

<dajole>That's the only one I'm aware of as well. And there is https://the-dam.org/, though that's a bit different.

<dajole> https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-deploy also has Hetzner and Digital Ocean support, and the process of installing Guix on other VPS' is similar.

<meatoid>dajole: last i checked the-dam was a pubnix squeezed into a machine with like, 4GB ram and 30GB storage

<meatoid>it could be cool but guix as it is now just isn't built for such a resource-constrained environment

<dajole>agreed

<dajole>I like it as a lil' experiment, though :)

<janneke>apteryx: nice to see you in #guile, guess that helped thinking i "was" in #guix, hehe :)

<janneke>apteryx: using -m 8000 with qemu still gives me just 4GB, so there must be something more to it, dunno

<janneke>ACTION will try to remember asking yelninei when they wake up

<apteryx>janneke: o/

<apteryx>I forgot how PAE was to be enabled back in the days on intel; wasn't it handled in the BIOS?

<apteryx>and is there a reason yo don't go with x86_64 support? (I'm assuming you're using x86_64 hardware with QEMU on top)

<janneke>apteryx: ah, gnumach needs at least --enable-pae for that

<janneke>apteryx: see https://codeberg.org/guix/guix/pulls/8349#issuecomment-14331452

<apteryx>is this a configure flag, or some runtime argument?

<janneke>apteryx: that's a configure flag

<janneke>we don't want the 32-bit hurd to break

<janneke>esp. because i haven't been able to run the 64-bit hurd on real iron just yet

<janneke>the 32-bit hurd now runs on an x220 (a 64-bit machine), our 64-bit hurd doesn't boot there just yet

<apteryx>I see; I wouldn't expect --enable-pae to break 32-bit hurd, as it seems it'd be a rather well tested code path given the recent x86_64 support? Worth trying it; we have system tests for the Hurd, I presume?

<janneke>yeah i believe so

<janneke>ACTION goes to try --enable-pae

<janneke>hmm, --enable-pae doesn't even boot with current gnumach; it does boot with latest git (there were some fixes since beginning of april)

<janneke>but also with that, i get

<janneke>*those

<janneke>ext2fs: part:1:device:wd0: Input/output error

<janneke>so yeah, dunno

<apteryx>I think you'll need some help from the experts ^^'

<apteryx>maybe qemu needs something to enable pae too?

<apteryx>looks like PAE should be supported by default in QEMU if the qemu machine you use has a cpu which supports it (anything newer than pentium2 accordingy to cpu.c in qemu's source)

<apteryx>any clue as to how to compose/weave two monadic values into one? I want to do some cleanup after a monadic procedure (its value) has been run. I don't control where it's run, so I need to wrap that monadic procedure (which I can't change) with my cleanup routine

<apteryx>after its value has been run*

<apteryx>I guess I could wrap it with mlet, running the procedure there (binding its result), and doing my cleanup in the body, before returning the bound result

<apteryx>ACTION tries

<sneek>Yey! nckx is back :D

<jlicht>has anyone recently been using agitjo to open AGit pull requests for the guix repo on codeberg? I'm running into some issues with "Forgejo: Internal Server Error" and assuming this is a case of PEBKAC :-)

<iyzsong>not agitjo, but now I unable to make a comment on codeberg, with 500 server error

<jlicht>ACTION angrily shakes fist at AI DDoS situation

<yelninei>o/

<sneek>yelninei, you have 1 message!

<sneek>yelninei, janneke says: good call wrt --enable-cpus=8 for 32-bit, it gets *very* slow with only 4GB of memory, and we don't have pae just yet, have we?

<yelninei>janneke: i quickly tried --enable-pae but had got into issues even with all the fixes from git. With 4GB only 3 are actually usable and the problem is that guile ooms after using 2.7GB when building guix

<avigatori>o/

<janneke>yelninei: yeah, i tried that too; even upgraded to latest gratest gnumach git

<janneke>no idea

<apteryx>anyone used 'lift' from (guix monads) ?

<apteryx>it looks like you need to evaluate the resulting procedure of lift to get a monadic value out of it? it's odd: (run-with-state ((lift (const #t) %state-monad)) %state-monad) => #t

<apteryx>but (run-with-state (lift (const #t) %state-monad) %state-monad) => #<program 7f504a2640c0 7f506443e580>

<postroutine>Hello. I got a question about system service extension. If I have 2 service types, A and B, and the service type A extend the service type B: When an instance is explicitely made from the service type A but not the B, does an instance of B is automatically ? Or does the user need to explicitely instancate the 2 service types ?

<apteryx>I think extending implicitly requires/provision B, but I'd like a 2nd confirmation on that :-)

<apteryx>civodul: as our local monad expert, can you think of a way to do monadic exception handling? (e.g. at the time the monad runs?) I'd like to do just that in a 'deploy-machine' monadic procedure

<apteryx>hm, it looks like non-monadic code inside mbegin (or I assume, mlet) is delayed as well

<apteryx>so it may be possible to handle errors/insert a cleanup routine more or less as usual

<apteryx>see the been-there? value only set to #t after the monad value runs: https://paste.guixotic.coop/non-monadic-code-in-mbegin.html

<apteryx>this is awkward, but based on my REPL testing, this should do it (not sure about the guard though -- will have to check that one too): https://paste.guixotic.coop/hetzner-30639-32167.scm_gnu_.html

<penisilvania>Hi

<penisilvania>Does gnome-software work on guix

<ieure>penisilvania, No idea. There's a package for it, I assume that means it /should/ work, though using other package managers on top of Guix is not really the Guix way.

<penisilvania>There is a package of it in devuan too and it doesn't really work with DEVUAN sources

<penisilvania>:D

<penisilvania>It's a little bit retarded that you have to manually turn on a service in linux

<ieure>penisilvania, We do not use words like that here.

<penisilvania>What about "dumb"

<penisilvania>Imagine having to explain a windows person, yes you have to activate a service

<ieure>What exactly is your criticism here/

<ieure>?

<penisilvania>Well people don't come to Linux because it is hard to use.

<penisilvania>And Linux distros think it's smart to not make it simple

<kestrelwx>Oh, hi Simon.

<ieure>Do you have a specific criticism of Guix?

<penisilvania>@kestrelwx: we know us m

<penisilvania>?

<ieure>Plenty of people come to Linux, you're in a channel full of 'em. And there are many like it.

<kestrelwx>You were on @guix_en couple times.

<penisilvania>Yes

<penisilvania>But how did you notice

<penisilvania>Ieure and about 90% wont

<ieure>penisilvania, So/

<ieure>?

<penisilvania>ieure, we need more people on Linux in order to grow bigger eyes for bugs

<ieure>Millions of people use Linux.

<penisilvania>Not enough

<penisilvania>Otherwise programs wouldn't crash like that on many distros

<ieure>Okay, uh. Get a grant from the Linux Foundation, I guess?

<ieure>I'm hearing a lot of generalities, what do you expect anyone in here to do about it?

<ieure>Is there a specific issue you would like to see fixed? That is direct and actionable. "more people should use Linux" is not.

<penisilvania>Try to make guix simple such that it uses for example gnome-software

<ieure>Guix is not that kind of distro, and there's nothing wrong with that.

<penisilvania>Even though no idea if guix is possible to manage this because of the weird packagemanager

<penisilvania>:D

<ieure>Gobs of options for those who want a clicky-draggy thing to manage packages.

<penisilvania>Arch for example failed massively because they think they are elite and they don't need stuff for user

<penisilvania>Even though they have everything to do it

<ieure>We have very different definitions of success.

<penisilvania>One of the reasons people leave arch, because arch doesn't care. And then all the smart people leave arch and all the gamers left behind and then the whole infrastructure crashes

<ieure>Do you consider Windows to be successful?

<kestrelwx>Arch is doing just fine, people work on it for decades.

<ieure>Yeah, I disagree entirely with the premise that "Arch doesn't care." I've never used it, but they have some of the best documentation of any distro, at least in terms of the oldschool linux HOWTOs. I reference their docs all the time.

<ieure>Perhaps Arch is successful on its own terms, though not on yours.

<penisilvania>If arch cared, people wouldn't leave arch

<penisilvania>:-)

<penisilvania>Many security researchers just go because it's not convenient

<ieure>Maybe the people leaving it simply care about different things.

<penisilvania>Yes for simple good things and not extremely bloated shitware 😂

<penisilvania>🪳🪳

<penisilvania>But simple things yet not exist

<penisilvania>So they go to chimera and artix and devuan and void, and then they get disappointed again and again

<penisilvania>Because these distros "elitist" not caring about users

<penisilvania>🫠

<egnuun>Hello, fellow Guixers, currently I am playing around with guix build.

<egnuun>I am trying to build Icedove/Thunderbird with Mozilla's current "beta" (150) instead of the ESR release.

<egnuun>I've downloaded the gnuzilla.scm (https://codeberg.org/guix/guix/src/gnu/packages/gnuzilla.scm) Then I've added "icedove" in a newline at the end. Guix build It builds Icedove very quickly. So far no problems.

<egnuun>Then I've only updated the %icecat-build-id and %icedove-build-id and it suddenly started downloading a few packages and after 10 ?) I canceled the build and also updated the Icecat version.

<egnuun>Now it started downloading all kinds of packages and it ran for over an hour, before I canceled the build job.

<egnuun>Here are my questions: Is it normal, that it starts downloading so many packages and that it takes _over an hour_ (and is still not finished…) ?

<egnuun>I mean, I have a laptop with 32 GB RAM and a newer Core i7. So it really surprised me…

<egnuun>Also for Icedove/Icecat to build it requires some Gnuzilla tools. The script downloads them directly from Savannah. (git://git.savannah.gnu.org/gnuzilla.git)

<egnuun>These tools seem to have the current ESR version "hard coded".

<egnuun>So I am wondering, how to tell the Guix build script to use a custom/offline version of GNUzilla.

<Rutherther>so how much was the download speed? icedove has a lot of deps, so sure it can take some time, especially if the servers or connection on your side is slower

<Rutherther>if you want to change the source, ie. to a local file, you would just change the source field of the package, in case of icedove it's coming from the icecat-source variable

<Rutherther>as for "Guix build It builds Icedove very quickly. So far no problems.", presumably you just substituted it, not built it locally, so you did not need all those dependencies for the build

<ieure>egnuun, What you experienced is normal. When you "built" the package using the unmodified package definition, it did not compile anything, at most, it downloaded a precompiled substitute. When you modified the package, that changed the derivation; no substitutes were available, so it began downloading the source and tools to build it, and compiling.

<ieure>egnuun, I don't know how the IceDove build works, so I'm not sure what you need to update it. But it sounds like you'd need to both modify the upstream IceDove code *and* the Guix package definition to build it.

<egnuun>ieure, Rutherther: Ah, I see. I've already had Guix's Icedove installed. So, It didn't build it at all. That would explain the speed. :-)

<egnuun>Rutherther: So just changing the source field should be enough? I'll try that. I thought, it might want to have a special directory…

<Rutherther>with icedove you definitely cannot just point source to the directory, I did not mean it like that

<Rutherther>I meant it that the source specifies it, so if you go over it and track it, ie. icedove-source -> icecat-source, you will arrive at the place where the repo is fetched

<Rutherther>and you can change that for your own local source

<egnuun>> with icedove you definitely cannot just point source to the directory, I did not mean it like that

<egnuun>Rutherther: Haha, I know that. But I thought about doing the same thing with GNUzilla (which does the magic of actually polishing Firefox, so it becomes Icecat).

<egnuun>But it seems, that I don't need that, because the Guix build script just overwrites the "hard coded" version number in the GNUzilla script.

<loquatdev>If I'm using a single file in a service, is it good practice to make it into a package or is it fine keeping it file-like, similar to how artwork is handled in the Guix channel?

<loquatdev>I know I can do it however I want at the end of the day; I'm just curious what y'all consider to be "standard".

<ieure>loquatdev, I wouldn't make a package for one file.

<ieure>loquatdev, It's going in the store either way, a package just means it's one level of nesting down, and now you have to update a package and pull to change the file. IMO bad tradeoff.

IRC channel logs

2026-05-05.log