<morgansmith>I haven't been here for a while. I just wanna say: guix home really rules!! It makes me very happy :)
<morgansmith>I still don't quite understand how all the service stuff works though. I'd like to setup my mpd daemon using guix home which I think is possible using shepherd but I have no clue how all that works :P
<nckx>florhizome[m]: This sounds like you're using an old copy of Guix (e.g., the one installed by your distribution package manager) instead of a pulled copy. Unless that's deliberate, make sure you're running ~/.config/guix/current/bin/guix .
<nckx>florhizome[m]: In a different location (/run/current-system/profile/share/fonts vs ~/.guix-profile/share/fonts) but both should be searched. Maybe an application's caching the previous location (either on disc or in RAM), or fontconfig itself is confused (fc-cache -r should fix that).
***tom is now known as tom19281
<tom19281>Hi. I'm trying to install transmission-gtk on Guix System. I see package "transmission" has an output "gui". I am using (specification->package+output "transmission:gui") to install this, but I cannot see transmission-gtk in my $PATH afer a system reconfigure. Any ideas why this isn't in $PATH?
<tom19281>I see that /gnu/store/s698nhfqckpkf3zb2kkcm4329qrqcvih-transmission-3.00-gui/bin/transmission-gtk exists, and I can execute that.
<tom19281>(Other transmission binaries, such as transmission-show, are in $PATH)
<florhizome[m]><nckx> "florhizome: This sounds like you..." <- I think i have the appropriate lines in my .bash-profile.. and i've tried running guix package --search-package-paths (or similar) after pulling, too..
<vivien>teddd, I’m not proficient in latex enough to understand what goes wrong. Your document seems fine to me. If I had your problem, I would try to first delete ~/.texlive2019 and retry, but maybe you have valuable files in there.
<teddd>I didn't know about this folder. I'll check it out
<civodul>efraim: actually i'm silly: /var/log/shepherd.log is a thing of the past, now it writes to /dev/log (syslog)
<teddd>how come however that the difference doesn't appear in the generation list ?
<teddd>anyway removing ~/.texlive2019 didn't solve the problem :/
<teddd>I would be interested in investigating the differences between two generations. Which way would you suggest ?
<civodul>i know how tempting it is and now i speak like an old wise person ;-)
<florhizome[m]>Another thing- on guix system profile generation runs extremly long. I thought i had too many packages, but i'm down to 10 in the user profile and don't experience much change. It seems to jump between cores while exhausting them each time.
<civodul>florhizome[m]: "profile generation" as in when running "guix install foo bar baz"?
<katco>hey all, i'm creating a new service, and i'd like to see in my guile repl what the `define-configuration` record looks like, serialized. i found `(gnu services configuration):serialize-configuration`, but it returns a gexp which i have not entirely understood yet. what's the best way to do this?
<lilyp>I.e. if I "guix install man-db" I'm requesting the man-db hook, otherwise not?
<rekado>upgrading diffoscope doesn’t fix the problem. We already disable one other test because of a problem with our libfile.
<rekado>I’ll try to build pigx on core-updates-frozen next and fix whatever might still be broken.
<civodul>katco: hi! i'm not really familiar with define-configuration, but the way i do in similar circumstances is by building just the relevant derivation
<civodul>so for instance, in the output of "guix system build", you look for whatever.conf.drv
<civodul>and then you explicitly run "guix build /gnu/store/...-whatever.conf.drv" to see the result
<katco>civodul: hiya! yes, i'm surprised there's not more documentation on this! i think i could certainly get into a workflow where i'm using the guix CLI to build things and then look at the store, but i'd really rather have a repl driven workflow for something with a quicker iterative loop
<katco>i tried some `(with-store store (run-with-store` shenanigans, but i don't fully understand how to drive that code yet.
<civodul>katco: nice; perhaps you can eventually share your debugging tricks on the list, and maybe someone will come up with a nice way to factorize it
<civodul>jpoiret: there is not :-) there are things in hurd-boot.scm to set up essential translators (which is akin to "mounting" something)
<katco>civodul: yeah, i am really bad at following through on this kind of thing, but i'd like to do a little write-up on my experience of developing a guix service having never done so before. i don't think there is enough documentation, and i am wishing their were a more iterative approach to hack on one.
<jpoiret>civodul: but then, when does guix discriminate between both methods in the file-system services?
<jpoiret>i'm not sure how we should differentiate between both systems though… maybe have a hurd-swap-service instead of swap-service in a separate file? but then, that'd be a lot of redundant code too
<jpoiret>civodul: it'd be great to have something akin to guix build syscalls for hurd, something like guix build herd-protocols
<jpoiret>also, tangentially, what's the exact dichotomy between guix and gnu? eg gnu build file-systems vs guix build syscalls
<jpoiret>i'd say guix is the "base" library while gnu is the actual definitions using that but it might be quite blurry in some instances
<civodul>jpoiret: yes, it'd be nice to have a module implementing the Hurd RPCs
<lilyp>GNU has stuffs to build the GNU system, where as Guix has internal machinery
<civodul>right, (gnu ...) is for the distro/packages, whereas Guix is for the core machinery
<jpoiret>nckx: thanks for the review by the way. The initial motivation behind the naming difference is that we might want to know that it is a swap file (eg to make use of it in automatic hibernation file offset detection)
<jpoiret>i could be inclined though to instead remove the string device support and keep only uuid and file-system-label instead, so that strings would always denote actual files (and so we could simply it a bit)
<vats>Hello. How can I set the kernel parameters to be set by bootloader for the default menuentry? I want to install GuixSD with an LVM on LUKS setup, and want to configure the bootloader to prompt for the decryption passphrase.
<jpoiret>i'll send a follow up mail tomorrow i think with the changes you suggested.
<jpoiret>vats: by default, without specifying anything, the bootloader prompts for the decryption passphrase
<jpoiret>nckx: what would you think of a root-filesystem-service rename to filesystem-/?
<jpoiret>this would make it more consistent with dependencies
<jpoiret>that's why the example (that i should've rightfully tested) did not work
<jpoiret>or just keep the corner-case of "don't specify a dependency on the root filesystem or otherwise expect breakage"
<robin>vats, i *think* there's a way to enable TRIM on LVM without kernel arguments, setting a flag in its internal configuration info, presumably. i switched to plain btrfs-without-LVM though so i'm not sure
<robin>ah, yeah, btrfs-on-LUKS without LVM (i wasn't using LVM for anything but a swap partition and btrfs has good enough swapfile support now...)
<robin>(and the FS might need an option set to enable auto-TRIMming too, although i think the preferred approach is to use...hdparm, iirc, to manually TRIM once in a while, a bit like reference counting vs. GC)
<cybersyn>and last, should I add this definition to an existing package or send it as a new package? i didn't see guidelines for this in the contributing section of the manual, although its a bit long so i could have missed it
<notmaximed>do you mean adding it to a new file/module, or an existing file/module?
<jgart>I'll have to try again on Guix System. I've tried with/without --ad-hoc
<jgart>I've been able to load sbcl libs by importing the full store path but I'd like the experience to be similar to python libs in guix
<jgart>where I can just enter the cl repl and they're there
<civodul>rekado: re search-input-file & java: i found a similar issue in hdf-java, fixed in 22e753b9b1aedc74b50d79c048ac34037add8193; that problem was already there AIUI but the wrong file name just went through silently
<civodul>the issue in this case is that the .jar is installed in a maven subdir, with a versioned file name
<civodul>which apparently has not always been the case
<jgart>I'm able to compile the .cmo (bytecode) and .cmi (interface code) files but I get the above error
<tom4345>Hi. I'm trying to get Emacs daemon to start on GNOME login. I'd like to do this with Shepherd user services, so I can manage the lifecycle of this in a uniform way. Does this exist? If not, is guix/gnu/home/services/emacs.scm a reasonable place to put this?
<jgart>Might be nice to add an emacs service in upstream for convenience or an entry in the cookbook
<jgart>So, we won't have to find these basic services in random blog posts/user configs in the wild
<civodul>roptat, jgart: re composer, it was also quite a chore to review so i'm all for pushing it past the finish line :-)
<jgart>civodul, Yes, the php ecosystem managed by scheme/guix would be quite interesting to experience. I'll get to work on it in my free time. If anybody would like to work on it together just ping me. I could use some help.