bug#60361: renpy-launcher can't be used to create new projects

Running renpy-launcher and trying to create a new project fails with error "The selected projects directory is not writable" Trying to change the projects directory in preferences fails with the same error. Setting the projects directory using the renpy build from the renpy website allows

bug#57867: Tealdeer build fails

I don't get it. How can a package "used to work" and "fail" now? If that is the case, how is guix "declarative"?

bug#60383: [PATCH] services: pulseaudio: Fix /etc/pulse/default.pa not being used.

Hello, Maxim Cournoyer writes: > Fixes . > > * gnu/services/sound.scm (pulseaudio-etc): Produce daemon.conf > unconditionally, with the correct default-script-file location. Produce > client.conf unconditionally. > > Reported-by: Bruno Victal > --- Applied

bug#60383: [PATCH] services: pulseaudio: Fix /etc/pulse/default.pa not being used.

Fixes . * gnu/services/sound.scm (pulseaudio-etc): Produce daemon.conf unconditionally, with the correct default-script-file location. Produce client.conf unconditionally. Reported-by: Bruno Victal --- gnu/services/sound.scm | 18 +++--- 1 file

bug#57775: guix shell --root fails

I can no longer reproduce this. -- Ricardo

bug#55120: “guix import cran” fails for some git repositories

This has been fixed in the meantime. If you still have this problem you may need to remove your git checkout cache in ~/.cache/guix/checkouts. -- Ricardo

bug#60207: ci build of latest guix for armhf

"pelzflorian (Florian Pelz)" writes: > Julius Schwartzenberg writes: >> Op 24-12-2022 om 22:40 schreef pelzflorian (Florian Pelz): >>> If you want `guix pull` without compiling, then look at >>> . >> >> I added

bug#60383: Pulseaudio does not source 'extra-script'files' from pulseaudio-configuration

Pulseaudio ignores any files under /etc/pulse/default.pa.d/ even though according to /etc/pulse/default.pa this shouldn't be the case: --8<---cut here---start->8--- $ cat /etc/pulse/default.pa

bug#48468: substitute server connection timeout

Hello, So I had an other look to that one, > (From .) > > Plausible explanations that come to mind: > > 1. ‘guix publish’ returning 404, but not due to baking. Instead the > .drv is simply not in store, hence 404. > > 2. Client timeout

bug#47980: guix patches debuggs not supporting TLS?

I can confirm this is still an issue at the moment. Same email provider requiring TLS by default, and still only happening when replying to the debuggs adress. > <60...@debbugs.gnu.org>: TLS is required, but was not offered by host > debbugs.gnu.org[209.51.188.43] > > Reporting-MTA: dns;

bug#60363: Texlive importer is broken

Sorry if the message is duplicated, my previous attempts at replying bounced because debbugs.gnu.org doesn't support TLS. On Wed, Dec 28 2022, Josselin Poiret wrote: Quick question, is `svn` available in your environment? I usually do `guix shell subversion -- guix import texlive ...`. This

bug#60363: Texlive importer is broken

Hi Elias, Elias Kueny writes: > Hello, > > The texlive importer doesn't return any package definition anymore, for > example: > >> guix import texlive siunitx >> command "svn" "export" "--non-interactive" "--trust-server-cert" "-r" >> "59745" >>