IRC channel logs

2025-07-25.log

back to list of logs

<dodoyada>anybody got an example of setting up ejabberd on guix? I would like to start/stop it as a service but I don't see how to handle the config files
<Kolev>dodoyada, I was going to set up Snikket on Guix.
<dodoyada>Kolev I see there's a pretty straightforward snikket setup using docker. I could use docker for ejabberd but I saw guix does have the package for it
<Kolev>dodoyada, but does Guix have the service type for it?
<dodoyada>for ejabberd and snikket, no. There's a service type for prosody but I'm led to believe it's broken, I had trouble getting anything to connect to it
<meaty>when an operating-system "inherits" from another, do services in its "service" field replace those defined in the parent operating-system, if they exist?
<meaty>i.e. if I inherit from hetzner-os-x86, which defines an openssh-service-type, do I need to use modify-services or should I just define my own openssh-service-type and it will replace the old one?
<RavenJoad>I'm using cuirass and it cannot checkout one of my channels. I get "Git error invalid content-type text/plain; charset=UTF-8". I looked and Cuirass is calling into Guix's latest-channel-instances function. This seems like a Git thing, but manually cloning works fine.
<robin>hm, i have a wrap-program-generated script ends in 'exec -a "${0##*/}" ...', but i don't see that in wrap-program (the format string is "#!~a~%~a~%exec -a \"$0\" \"~a\" \"$@\"~%"), only in packages modifying wrapped programs, where would that "${0##*/}" be coming from?
<robin>meaty, you'll need to use modify-services, the new services field will override the inherited one
<sovrcat>meowdy chat
<sovrcat>I get some gnarly error when trying to download pdf from overleaf on icecat, seems very odd https://bpa.st/MGZA
<sovrcat>then it crashes
<jlicht>hey guix!
<sneek>ekaitz: wb :)
<ekaitz>sneek: botsnack
<sneek>:)
<PotentialUser-62>Hi, I wanted to try guix on a thinkpad T60, and burned an install CD. Grub loads the kernel and initrd, but then immediately drops to an 80-width terminal with a blinking cursor and no output, keyboard frozen. replacing quiet with earlyprintk=vga nomodeset vga=text text didn't help. Where should I turn next?
<identity>PotentialUser-62: can you switch to tty2/3/etc (with C-M-2/3/etc)?
<csantosb_gamja>Test, sorry
<PotentialUser-62>Sorry if I pop in and out, web client. I check the logs when I come back.
<PotentialUser-62>Changing virtual terminals doesn't work, not even the caps lock light lights
<PotentialUser-62>I was thinking on a future day I'd have to get a serial cable to look for a boot log or try another OS like debian or arch and compare the kernel and grub if they boot
<jlicht>could someone with access to CI evaluations remove the node-team one, and create a javascript-team one please?
<jlicht>(or rename it + the branch it refers too, I'm not picky)
<apteryx>ACTION discovers about emacs-mistty; works well as a M-x shell alternative with the best both have to offer (emacs editing/shell completion)
<andreas-e>jlicht: I did something confusing, since renaming is not possible in the CI web interface, and I did not want to add yet another branch. So I kept the "node-team" specification, but internally use the javascript-team branch now. Currently only on x86_64, that should be a good first step to check whether things are working.
<apteryx>what does VFS stands for in VFS Mapping service? Virtual file system?
<nikolar>yup
<lynnn>good afternoon. im using manifest.scm to create a reproducable build environment for a project of mine. it relies on some libraries to link to, which are in $GUIX_ENVIRONMENT/lib. for some reason though, this environment does not set LD_LIBRARY_PATH.
<lynnn>I would expect it to set this, so the libraries can be used. is this something that can be set for the shell? or must i handle that myself in my build script
<Rutherther>why would it set LD LIBRARY PATH in the first place?
<lynnn>so the libraries can be used for building? the same reason the $GUIX_ENVIRONMENT/bin get's added to the path
<Rutherther>ld library path is a hack for putting runtime libraries in compiled sw. Guix isn't much about hacking around, you typically compile the paths to the sw you're using, not using LD LIBRARY PATH. If you want it set, sure you could do that, but there is no need
<Rutherther>lynnn: but LD LIBRARY PATH is for runtime, not for building. LIBRARY_PATH is for building
<Rutherther>and if you don't have LIBRARY_PATH set, then you're missing gcc-toolchain in the manifest
<lynnn>gcc-toolchain is there, i added that in because i thought i had this issue earlier but it was LIBRARY_PATH not LD_LIBRARY_PATH
<lynnn>I think this library needs to link on run time which is annoying. i'll just use something else then
<jlicht>sneek: later tell andreas-e: thanks! It should most certainly build, as I just synced it up with master. I'm just planning to start merging stuff into it soon
<sneek>Got it.
<sham1>Which package contains the locale command again?
<sham1>lesspipe.sh has some trouble without it
<Rutherther>sham1: glibc
<sham1>oh
<sham1>It's odd that it's not in the PATH by default
<sham1>Although lesspipe does get patched in the package definition. It'd probably make more sense to also patch the locale invocation
<Rutherther>it should definitely be patched. Dependencies should rarely be added to path of a profile
<Rutherther>if anything, it can be wrapped, but patching is preferred
<sham1>I guess I should report the issue on codeberg. Like, it's not a critical error, but it's weird to see it even though it does work
<Kabouik>cdegroot, identity, I've been looking at direnv/envrc and the emacs-envrc package and this looks very intersting for my use (providing the recipe for a reproducible guix shell with channels.scm and manifest.scm in a project) but I'm concerned about one thing that is described here: https://dev.to/allenap/some-direnv-best-practices-actually-just-one-4864
<Kabouik>guix shell is long, not only for the first ultra long invocation when it's compiling, but even after that it can get old if it takes a few seconds. What would be the best way? Making it prompt the user instead of automatically sourcing .envrc?
<Kabouik>Maybe I could turn my .envrc into a shell script that prompts the user with `read` and then run the guix shell only if approved?
<PotentialUser-62>I diagnosed my T60 issue :) debian live dvd boot indicates I am trying to run x86_64 kernels on an i686 cpu, oops
<PotentialUser-94>Dear Guixers, I can't connect to #guile channel… so… ill try my little question here if no one minds ?!  Is there an equivalent of "Scheme Procedure: defined?" for local bindings (inside let or other non-top-level bindings) ?
<identity>PotentialUser-94: i struggle to come up with a valid use for that, but (false-if-exception binding) should work (assuming that the binding, if defined, is accessible)
<gabber>vagrantc: i figure the wip-pinebook-pro branch is not in active use anymore? would you mind if i used it to get working (desktop) images to build from there?
<PotentialUser-94>identity Thank you Identity. Im trying to handle an exception raised when a (ice-9 match) does not match and the name of the variable is used in the "body" part of the match clause.
<PotentialUser-94>identity  and I dont know how to handle exceptions... yet ^^ So i was trying to catch this before the exception is raised
<vagrantc>gabber: yeah, most of it was merged or otherwise obsoleted. there was some documentation added that never quite made it.
<vagrantc>gabber: also haven't used guix on the pinebook-pro for a while ... just barely was usable.
<vagrantc>gabber: i have gotten pestered about pushing branches to the guix repository that were not part of a team before ... not really sure where things stand with that.
<gabber>vagrantc: i currently achieved to get a booting image and am looking forward for building my laptop system (sway). now i am stuck with the `glib-networking` build failure
<vagrantc>gabber: yeah, i ran sway on it.
<vagrantc>gabber: i "solved" that by building it in a loop until it succeeded... at least it is a relatively fast build.
<vagrantc> https://codeberg.org/guix/guix/issues/1377
<vagrantc>i have seen 0, 1 and 2 test suite failures when building it ... i did a loop of 100 builds, 65 of which failed.
<vagrantc>that was on x86 ... on aarch64 i just built it till it suceeded ... honestly no idea how many tries it took ... seemed more prone to fail on aarch64
<gabber>do we call this the jackhammer method?
<vagrantc>gabber: currently using the mnt/reform which has significantly more capability :)
<gabber>i envy you in this regard
<gabber>still, i kinda got to like my pinebook (except for the OS it shipped with)
<vagrantc>(well, the original mnt/reform was actually maybe even slower, but upgraded to the rk3588 w/ lots of ram)
<vagrantc>yeah, i still use the pinebook-pro a bit, just not with guix.
<gabber>vagrantc: is the glib-networking issue a Guix or an upstream bug?
<vagrantc>gabber: i would guess upstream, but possibly some combination with the new toolchains makes it more likely to trigger?
<vagrantc>it triggers a lot of rebuilds, so is not easy to patch out the tests on guix master... :/
<vagrantc>seems the proposal is to patch out the tests on an upcoming (unrelated?) branch merge
<vagrantc>hako: do you have a bot that tags pull requests ... or are you really doing that manually? :)
<gabber>vagrantc: unfortunately my first 100 tries were not successful :(
<mghackerlady>Is anyone else having problems with the download speed for the ISO? I'm pretty sure it isn't my internet as it's working fine for everything else, but trying to download CUPS is giving speeds slightly better than dialup. I had this problem when downloading the ISO, but it cleared up after a few hours
<gabber>mghackerlady: have not downloaded the ISO in quite a while but what you describe does not surprise me