bug#53591: Audacity can't find FFmpeg

Between Audacity 2.4.2 and 3.1.3, upstream changed how Audacity finds FFmpeg. It no longer links to it but instead loads it at runtime: https://github.com/audacity/audacity/issues/2161 I detailed my hapless attempts to do that in the upstream bug report:

bug#53594: no matching pattern #

Hello Guix, I obtained a latest dev ISO for guix system and tried installing it just now. With the graphical installer, I received the error below for two times. Perhaps it's a bug? In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception

bug#53591: Audacity can't find FFmpeg

On Thu, Jan 27, 2022 at 06:14:30PM -0500, Leo Famulari wrote: > Although Audacity 3.1.3 includes FFmpeg in its direct dependencies, it > does not keep a reference to it and cannot find it at runtime. One consequence is that Audacity can't read Ogg files containing Opus or Vorbis audio, or any

bug#53591: Audacity can't find FFmpeg

Although Audacity 3.1.3 includes FFmpeg in its direct dependencies, it does not keep a reference to it and cannot find it at runtime. This is a regression from Audacity 2.4.2. -- $ git describe v1.3.0-15323-gf00ed43653 $ guix gc --references $(./pre-inst-env guix build --no-grafts audacity)

bug#53463: ci.guix.gnu.org not building the 'guix' job

On Sun, Jan 23, 2022 at 06:00:40PM -0500, Leo Famulari wrote: > Also, the 'master' job hasn't been run in ~2 days: > > https://ci.guix.gnu.org/jobset/master > > I think the build farm is waiting to finish collecting garbage. Unfortunately, the 'master' jobset is broken again, and the 'guix'

bug#44571: Cannot configure a static IPv6 with static-networking-service-type

Hi, I believe this was fixed in c8609493ba6fd36c05815cad198060e54ea8c4f9 (and related commits before and after). See the manual about the new static-networking-service-type and welcome to the future! Cheers, Jack

bug#53559: [PATCH] gnu: mutter: Disable timeline tests.

* gnu/packages/gnome.scm (mutter)[disable-problematic-tests]: Also disable timeline tests. --- gnu/packages/gnome.scm | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index e3fac534c4..b341fb4c97 100644 ---

bug#53588: Missing keys for ISO image

Leo Famulari writes: > On Thu, Jan 27, 2022 at 08:18:06PM +0300, André A. Gomes wrote: >> $ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig >> gpg: no signed data >> gpg: can't hash datafile: No data > > This means that you only downloaded the signature file, but not the ISO > image.

bug#53588: Missing keys for ISO image

On Thu, Jan 27, 2022 at 08:18:06PM +0300, André A. Gomes wrote: > $ gpg --verify guix-system-install-1.3.0.x86_64-linux.iso.sig > gpg: no signed data > gpg: can't hash datafile: No data This means that you only downloaded the signature file, but not the ISO image. Or at least, it's not where GPG

bug#53588: Missing keys for ISO image

Hi Guix, I followed the instructions found at info node (info "(guix) USB Stick and DVD Installation") and it failed with the following error: --8<---cut here---start->8--- $ wget https://sv.gnu.org/people/viewgpg.php?user_id=127547 -qO - | gpg --import -

bug#53561: Failing: guix package -i gtkmm@3

The above command produces The following package will be installed: gtkmm 3.24.5 guix package: error: profile contains conflicting entries for libsigc++ guix package: error: first entry: libsigc++@3.0.6 /gnu/store/ng4k2yl94d758p5vnashd4nvyb1aw8s1-libsigc++-3.0.6 guix package: error:...

bug#48007: computing derivations through inferior takes twice as long

Ricardo Wurmus skribis: > These patches look great to me and they work. > My real-world test case is now down to about 12 seconds. Good! Fixed the typo you mentioned on IRC and pushed as e778910bdfc68c60a5be59aac93049d32feae904. To summarize, the INFERIOR=y case still takes about twice as

bug#53580: (No Subject)

i forgot to add that i'm working on a shepherd service, and this may be due to errors in the service's user code, like the start gexp.

bug#53580: /var/run/shepherd/socket is missing on an otherwise functional system

the systems seems to work fine. Gnome is up, i can log in with my user, and everything seems to work, except herd. i encounter this broken state every once in a while. IRC logs also mention this multiple times, but without many insights:

bug#48007: computing derivations through inferior takes twice as long

Ludovic Courtès writes: > Ricardo Wurmus skribis: > >> I tried it in the GWL with the big RNAseq workflow I adopted from PiGx >> and the step to generate job scripts (which reference inferior packages) >> became considerably faster. There is still potential for improvement, >> but this

bug#48007: [PATCH 4/4] inferior: Move initialization bits away from 'inferior-eval-with-store'.

* guix/inferior.scm (port->inferior): In the inferior, define 'cached-store-connection', 'store-protocol-error?', and 'store-protocol-error-message'. (inferior-eval-with-store): Use them. --- guix/inferior.scm | 76 ++- 1 file changed, 42 insertions(+),

bug#48007: [PATCH 1/4] inferior: Create the store proxy listening socket only once.

Previously, each 'inferior-eval-with-store' call would have the calling process create a temporary directory with a listening socket in there. Now that listening socket is created once and reused in subsequent calls. * guix/inferior.scm ()[bridge-file-name, bridge-socket]: New fields.

bug#48007: computing derivations through inferior takes twice as long

Hi, Ricardo Wurmus skribis: > I tried it in the GWL with the big RNAseq workflow I adopted from PiGx > and the step to generate job scripts (which reference inferior packages) > became considerably faster. There is still potential for improvement, > but this change is the difference between

bug#48007: [PATCH 3/4] inferior: Inferior caches store connections.

Fixes . Reported by Ricardo Wurmus . Previously, at each 'inferior-eval-with-store' call, the inferior would create a new object with empty caches. Consequently, when repeatedly calling 'inferior-package-derivation', we would not benefit from any caching and

bug#48007: [PATCH 2/4] inferior: Keep the store bridge connected.

Previously, each 'inferior-eval-with-store' would lead the inferior to connect to the named socket the parent is listening to. With this change, the connection is established once for all and reused afterwards. * guix/inferior.scm ()[bridge-file-name]: Remove. (open-bidirectional-pipe): New