<andreas-e>Hello, cbaines! I am a bit confused as to the state of QA, maybe you can help me out. On the activity page, it looks like essentially nothing is happening, but there are still many open patches.
<sneek>Welcome back andreas-e, you have 1 message!
<sneek>andreas-e, ngz says: I have an idea. At the moment it is not possible for `guix shell' to extend a TEXMF tree without providing a full tree. For example `guix shell texlive-foo -- pdflatex file.tex' will not add `texlive-foo' to the available packages. However `guix shell texlive-bin texlive-foo -- pdflatex file.tex' will. My suggestion is to add `texlive-libkpathsea' as a propagated input for all TeX Live packages.
<cbaines>andreas-e, I think there might be some issue with submitting builds for patches, but I'm unsure
<cbaines>it doesn't help that the logs are filled with "Exception thrown while printing backtrace:"
<andreas-e>sneek: later tell ngz: This will break the compatibility of the monolithic texlive with packages such as texlive-biber, right? So I am not too fond of doing it for the time being.
<andreas-e>cbaines: Okay. On the emacs-team branch, it says "Exception checking changes between merge base and master." The same potential bug, or does it mean that master needs to be merged into that branch?
<rekado>but I don’t know off hand if it’s possible to create a socket file for an existing file descriptor
<rekado>I messed around with /proc/PID/net/unix and socat, but I haven’t yet found a way to bind to a socket from the command line with just this information
<drewjose>hmm i sent a patch via git send-mail a few hours back and it's not on the ML archive
<cbaines>drewjose, if this is the first time you've sent a patch, it can take a little while to be manually approved
<rekado>I just noticed that update-package-inputs in guix/upstream.scm will always return #false for unchanged?, because it compares a list of symbols with a list of strings.
<graywolf>Hi, I am trying to properly sign my guix fork, and cannot figure out how to do so. I am looking into git-authenticate.scm, and it looks like it uses intersection of signing keys from all direct parents of a commit? Does that mean that when I authorized my key on my master, the merge commit merging updates from official master will fail to validate?
<graywolf>How exactly is one supposed to keep guix fork up to date?
<jpoiret>graywolf: you want to use the fork for guix pull?
<jpoiret>if so, you'll want to change the introduction commit to one adding your own key
<jpoiret>maintaining an authenticated guix fork is pretty hard
<graywolf>Well yeah, I did so. And commits to master directly correctly validates. But merging guix' master fails with error regarding the signing.
<pastor>Good evening. Any hint on this error? `guix pull: error: Git error: config value 'safe.directory' was not found`
<pastor>I've been using guix for a few months now and this is the first time I see it
<pastor>Seems that removing `~/.cache` fixes the issue. How could this have happend?
<euouae>pastor: some git cache thing? newer git is more careful about safe.directory because git hooks can be malicious
<minima>i use password-store and gpg-agent and all works fine except for cron jobs; pass can't access gpg-agent unless i prepend the cron job command with `BASH_ENV=.../.bash_profile'
<minima>is there any recommended alternative here? or should i rely on `BASH_ENV' as above?
<minima>apologies this might not be very guix specific
<minima>it doesn't feel very elegant to pass the whole `.bash_profile'
<minima>all the commands involved are provided via g-expressions and have full path, i think the issue is for pass to access the gpg-agent
<vivien>Hi! QA did not pick the latest revision for my patch series: https://qa.guix.gnu.org/issue/65828. More specifically, the git branch that qa uses does not aggregate the latest revision of the patch series (the latest revision uses gegl 0.4.44 as a dependency for gnome-photos, instead of 0.4.46). Is there a way to reset the branch?
<vivien>Also, my patch series seems to be applied on top of a random commit on the master branch, and not on top of gnome-team. Why is that?
<minima>(of course, there's also the problem for pass to know where the PASSWORD_STORE_DIR is... and similarly for gpg to know of its homedir)
<minima>(or possibly those are the only problems with my config)
<minima>how do i reload mcron after "guix home reconfigure ..."? i've tried `herd restart mcron' but that doesn't seem to read the new job definitions
<apteryx>ah, Debian says: "Packages install rules in /lib/udev/rules.d), while the /etc and /run locations provide a facility for the administrator to override the behavior of a package-provided rule." (https://wiki.debian.org/udev)
<apteryx>so packages really should install their files to lib/udev/rules.d
<apteryx>ACTION forgets about that every now and then
<nckx>Yes. This is the general etc/lib rule in FHS distroes.
<apteryx>oh? maybe that's good enough for me to remember it :-) thanks
<nckx>Where I guess FHS is systemd now, de facto, because if they ever move, everyone's along for the ride.
<ssouth>jpoiret: I was going to say, it doesn't make Emacs see newly installed packages automatically. But actually, it's not supposed to do that.
<bienjensu>Does the environment switching functionality in guix-emacs make visible the packages in the switched-to profile?
<ssouth>It _does_ make Emacs "see" packages installed by Guix at start-up, which is what it's meant to do. So really, that works, and I'm pretty sure it's documented in the Guix manual (I obviously got it from somewhere).
<ssouth>I don't think there's anything that allows Emacs to automatically discovered new Emacs packages installed by Guix. Unless someone can enlighten me...
<jpoiret>ssouth: i don't know what you mean by _automatically_
<jpoiret>you have to do something manual to load a package, right?
<ssouth>jpoiret: As in, you install an Emacs package via "guix package --install" at a shell, and it's just automatically available in Emacs aferwards.
<ssouth>I should clarify: I do everything from within Emacs (from within EXWM, actually), including running shell comman ds.
<jpoiret>that should work OOTB though, since it'll be available at a path that's in emacs' load path
<jpoiret>if you need autoloads you'll probably need to run the guix-autoloads thing
<ssouth>So as an example: If I were to run "guix package --install emacs-elpher" at a shell prompt from within a shell running inside Emacs/EXWM, I could not then type "M-x elpher" and expect the command to work until I'd first done the "M-x load-file ..." dance I outlined above.