IRC channel logs

<wakyct>yep that's it exactly...I wonder if a note in the manual would help people who are clueless like me ;)

<wakyct>as it seems lan use would be common for radicale

<jA_cOp>It's been a long time since I last played around with Radicale so I can't really say, but I'm sure patches would be appreciated! I'm still new myself, hoping I can contribute back to Guix at some point in the future

<makx>is there some way to remove the most recent guix system generation; for some reason i get guix system: error: unrecognized boot parameters at '/var/guix/profiles/system-15-link/parameters'

<makx>(that file is empty)

<cow_2001>what is "substitute-keyword-arguments"? i cannot find any documentation

<cow_2001>oh, i guess i should read the source

<cow_2001>it is in ./guix/utils.scm

<cow_2001>huh, it is plist operations but with keywords

<hanker>how can I rebuild the official ISO?

<hanker>what's the file I need to `guix system image` ?

<hanker>nevermind, found the relevant section

<drewverlee>In emacs, how do i get the docs for the use-modules function?

<divya>drewverlee: You go to Guile Reference manual using `C-h i`, then do `m` and search "Guile". After opening the manual, go to Procedure Index similarly, and then search use-modules and hit RET.

<drewverlee>divya: thanks!! looking now.

<divya>No worries :)

<rekado>"Scanning the generated tarball for blobs..." for a full day.

<rekado>shouldn't we get a substitute for the deblobbed Linux sources? I've had to run this locally on my aarch64 machine for many times in the past. It takes much too long and discourages building a custom kernel.

<cbaines>rekado, do you have the /gnu/store/... output to hand?

<rekado>I don't have the derivation name ("guix deploy" does not print it), but it is building /gnu/store/dypx3rhdjpfhffr3v7ijm1k06cjpap69-linux-libre-6.13.3-guix.tar.xz

<cbaines>derivations are less useful now that the fixed output derivations vary so much

<cbaines>there is a build for that output on the bordeaux build farm, it just hasn't happened yet unfortunately https://bordeaux.guix.gnu.org/build/6c7487ce-3cbf-4222-b08b-b41ac200a0be

<lilyp>anyone here to give gnome-team a final test before we go?

<efraim>I have 3 patches, 1 each for aarch64, riscv64 and ppc64le

<lilyp>in progress, under review, or ready to commit?

<viaken>What is peoples' workflow for updating packages? Make edits in a git tree and use pre-inst-env to test?

<futurile>viaken: yes, that's the best way if you know you'll be sending a patch series to Guix itself

<noob`>i am having problems with the installation of guix, after the graphical installation i cannot boot to the efi partition, my computer didn`t recognize it

<noob`>also if i selected a disk i enter the grub rescue mod and all partitions show as unknown filesystem

<Rutherther>noob`: so did you check if you have an esp partition with vfat(fat32) fs, marked as esp, with EFI/Guix/grubx64.efi file existing?

<viaken>futurile: Thanks!

<futurile>viaken: if you're interested I recorded a video on how I do updates to guix packages: https://youtu.be/PSn1_NZzQ7o (it's too long, but might help)

<dariqq>lilyp: I had a problem with the test suite of farstream on gnome-team branch ~1 month ago (probably because of gstreamer updates)

<cow_2001>how do you inspect the build directory tree in between phases without sprinkling print commands in between phases? https://forum.systemcrafters.net/t/how-do-you-looking-at-the-state-of-a-gnu-guix-package-building-between-different-phases/1437

<futurile>cow_2001: you are probably best doing that. The other option is to crash out of the build and use --keep-failed

<dariqq>cow_2001: I'd add a phase that errors out after the phase you want to check and then keep the build directory (the -K option of guix build)

<cow_2001>hmm

<futurile>cow_2001: so basically create a custom phase with: (throw 'debug_error "dropping out")))))) (exit EXIT_FAILURE) and then --keep-failed will work

<cow_2001>i see!

<cow_2001>let's see

<cow_2001>why the (exit EXIT_FAILURE)? is it in the added debug error phase right after the throw? if it is right after the throw it will never be reached

<cow_2001>it worked without an (exit ...)

<cow_2001>WOO! there is the directory under /tmp/guix-.../

<dariqq>cow_2001: https://guix.gnu.org/manual/devel/en/html_node/Debugging-Build-Failures.html might also be helpful

<cow_2001>is it okay if i mention you, futurile and dariqq, in the solution reply to myself in the forum?

<dariqq>sure

<cow_2001>hmm, no ok from futurile

<wakyct>hey all, to date my Guix system management has looked like reconfigure -> adding pkgs with guix install -> look at --list-installed and sort pkgs into system or Guix home && reconfigure. However this bumps into the issue of reconfigures for minor service/config changes including all those pkgs, it would be nicer (I think?) to keep the list of packages in a separate manifest.

<wakyct>But Guix Home doesn't upgrade pkgs separately from home reconfigure

<wakyct>what do you long-time system users do to avoid big reconfigures for config tweaks?

<Rutherther>just always use the same guix instance until you're ready for an update, that way if you just change a service, the packages will not be redownloaded / rebuilt (provided if you didn't gc out the non-grafted packages)

<wakyct>thanks Rutherther, yes I didn't realize that about gc until yesterday

<wakyct>I think I will need to reinstall and repartition as I've had to aggressively gc with a too small /

<ieure>Anyone know why the mumi CLI can't find any patches for #76686?

<peanuts>"[PATCH emacs-team 00/45] Test emacs packages by default" https://issues.guix.gnu.org/76686

<ieure>"mumi current 76686 && mumi am" just gives me "No patches found."

<lilyp>ieure that's strange… i did send them

<ieure>lilyp, I know, I don't think there's anything wrong with your patches, mumi just fails like this on some patches for me.

<jlicht>sneek: later tell graywolf: Is it okay if I drag your ngtcp2 and nghttp3 bump patches into javascript-team? They mostly impact node AFAICT

<sneek>Got it.

<df>what is the equivalent of debian's alternatives? eg if two packages provide a binary with the same name (such as findutils and mlocate), how is precedence decided (assuming they're in the same profile - I can see how one profile coould take precedence over another)

<ieure>df, I don't think there's anything like that in Guix. In that situation, whatever ends up on $PATH first will get used.

<ieure>df, Since users can install whatever they want, alternatives aren't much of a problem in Guix.

<ieure>Do you have an example of two packages that ship identically named binaries?

<df>yes, findutils and mlocate, although it's a bit of a tricky example since findutils is in %base-packages

<df>but I guess gcc and clang?

<df>if they're in the same profile, there is one bin dir in the profile so it can only contain one symlink with the name 'cc'

<df>ok looks like that's a bad example too, the gcc package doesn't appear to provide a cc symlink

<ieure>Well, I also don't know why you'd put both in the same profile.

<df>well, they might provide more than just that binary

<df>I'll try to find a good example

<ieure>Sure. I agree this could be a problem, but I'm struggling to come up with a situation where it occurs that's not a "doctor, it hurts when I do this" kind of thing.

<df>well, it's actually come up as part of a wider problem I'm having with trying to replace the locate/updatedb part of findutils with mlocate on my system

<Rutherther>df: clang-toolchain and gcc-toolchain can't work together in the same profile, basically because of this problem you're describing, not specifically because of cc, but because of their header files, libraries etc.. One of them takes precedence, and the other then can't compile well in most cases

<df>I've been struggling with various aspects of it

<df>but you can see why I wouldn't want to replace findutils wholesale because it provides find and xargs as well as locate

<Rutherther>df: so just make a package that will have two files in its bin folder that are symlinks to findutils's xargs and find

<ieure>At least with `guix shell', the $PATH order reflects the order given to packages. Not sure if that's how it works for other setups.

<ieure>guix shell findutils mlocate -- locate --version # -> mlocate 0.26

<ieure>guix shell mlocate findutils -- locate --version # -> locate (GNU findutils) 4.9.0

<df>hmm, but in reality there can only be one symlink under $GUIX_ENVIRONMENT/bin

<Rutherther>ieure: it is not the $PATH order, it is the order of the file union files being replaced, the $PATH will end up just with one bin folder, pointing to the profile

<ieure>Ah, okay.

<ieure>Well. You can shadow whatever's in your env with `guix shell' either way,

<df>currently for example on this machine I have both findutils and mlocate in my operating-system definition, and mlocate appears to take precedence

<df>I guess it appears first in the package list

<df>so... everything's working as I want it in fact :)

<df>I was just idly wondering

<df>on debian I might want to temporarily switch between alternatives but I guess in guix I could just use guix shell

<Rutherther>I wouldn't rely on that because as far as I know this is not a defined behavior, so I wouldn't be surprised if it changed because someone touched something in the profile file union build and didn't realize

<df>hmm, well that could end up being a problem if only one locate db is updated and I end up with the wrong one in my bin/

<df>is there a way to explicitly exclude a file provided by a package?

<ieure>df, No.

<ieure>df, You can make a new package that inherits from it and deletes some of its outputs.

<Rutherther>I would rather recommend symlinking as that way you don't have to build it yourself from the scratch

<df>well, it'll be pretty obvious if it happens anyway, locate will complain that its database is a year old or whatever

<df>Rutherther: symlinking to somewhere higher in my PATH precedence? yes, that could work

<Rutherther>no, making a package that symlinks to coreutils bin files

<Rutherther>s/coreutils/findutils

<df>oh, but then how would I ensure *that* package had precedence?

<df>anyway, I think I'll leave it until it becomes an actual rather than a theoretical problem

<Rutherther>you don't ensure that. I am reacting to "is there a way to explicitly exclude a file provided by a package?"

<df>since I have quite a few actual problems still to solve

<lilyp>efraim: just saw your patches: is gnome-team good to go?

<efraim>lilyp: I have another one queued up but I can push it to master if gnome-team is otherwise ready to merge. I haven't been following the branch

<efraim>I think at least some of it is broken on master also

<lilyp>okay, I've updated gnome-team and will now push to master

<lilyp>aaaand it's pushed

<lilyp>time to run `guix pull` (:

<futurile>lilyp: whoop whoop!

<df>I'm struggling to understand when it is necessary to extend a service (with eg simple-service) rather than configure an instance of the service type

<df>for example, in the manual, mcron-service-type is extended with simple-service: https://guix.gnu.org/manual/en/html_node/Scheduled-Job-Execution.html

<df>but looking at the source (mcron.scm), there is an example of using mcron-service-type directly with a job list in an mcron-configuration

<df>does the use of extensions mean that each job is a service in its own right?

<ieure>df, I'm fuzzy on this, but I believe extensions change the configuration of another service, so you can compose different configurations together by adding new simple-services.

<ieure>df, home-environment-variables-service-type is a decent simple example, instead of putting all your environment into a single service, you can do (simple-service 'mpd-environment-service home-environment-variables-service-type (list '("MPD_HOST" . "some.host")))

<df>ah... so there is only one service

<df>and in the case of mcron it is in %base-services already

<df>so rather than mess around using modify-services, you can add extension services on top?

<ieure>Again, kind of fuzzy on this, but I believe that's the case, for services which support extension.

<df>hmm, I'm currently using modify-services to add an extra substitute server and it's a bit ugly, I wonder whether that can be done with an extension too...

<df>I'll try to get mcron set up first anyway

<Rutherther>df: yes it can, guix service type accepts guix-configuration as argument for extension and will merge it

<df>hmm, and it looks like file-database-service-type and package-database-service-type use extensions to mcron-service-type too

<df>is a % prefix just a convention for a global variable?

<lilyp>it means "implementation detail"

<df>ok, thanks

<df>is that a guile convention or a guix one?

<lilyp>guile, or more generally scheme

<jackhill>I'm afraid I still don't understand seeming few people experince #76660. I would have assumed the no one would be able to move past the problematic commit. Is this a case where it would be appropriate to re-write history?

<peanuts>"current guix pull doesn't authenticate" https://issues.guix.gnu.org/76660

<df>cheers

<dariqq>(value "Unbound variable: ~S") (value (icu4c-73) when trying to pull rn

<Rutherther>dariqq: and what channel is the one failing to build with that error?

<dariqq>oh jsut noticed, that comes from another channel

<jlicht>my guix pull progress bar seems to be jumping back and forth between 90%, 95% and 100% (both the number, and the actual bar)

<rekado>jackhill: FWIW I just ran "guix pull" successfully

<jackhill>rekado: thanks for checking. I wonder what that means

<lilyp>jlicht: that's normal in my experience; guix pull runs several tasks, which have their own progress bars

<lilyp>confusing, but it's similar to `build' and `check' progress bars for packages

<ngz>Oh gnome-team branch has been merged. Good job!

<jackhill>I've tried removing .cache/guix/checkouts in case my local repository had become corrupted, but that didn't change it, and since Tomas had the same problem, I figured it was a problem with the commit and guile-git has they described, but why wouldn't it happend to everyone 🤔. I really would like to understand what happened to know how to proceed safely.

<lilyp>for the record, what's your pull/authenticate frequency?

<jackhill>oh, I see there are some more comments in the ticket (my mail got slow) catching up now.

<jackhill>lilyp: every day or two

<jlicht>lilyp: thanks, that makes sense

<podiki>lilyp: thanks for merging gnome-team! looks like this patch didn't cc gnome-team though? https://issues.guix.gnu.org/73520#5 (i can look a bit later to see if it applies still)

<lilyp>it didn't, and tests failed for me when I tried to apply it

<lilyp>in any case, xdg-desktop-portal is fair game on master so if you have a proper fix, it'd be appreciated

<podiki>gotcha

<podiki>i don't know if i encountered the issue that was mentioned originally, but also not i'm not on gnome

<podiki>will take a look later though

IRC channel logs

2025-03-02.log