Re: new manifest format readers?

l...@gnu.org (Ludovic Courtès) writes: > Agreed. How about making these two changes: > > 1. Include (gnu packages) in the default evaluation environment of > manifests. > > 2. (define (package-specifications->manifest specs) >(packages->manifest (map (compose list specification->

Re: Performance on NFS

Ludovic Courtès writes: > Hi Roel, > > Roel Janssen skribis: > >> You should know that we have 'submit' nodes that use the guixr wrapper >> script to connect to the guix-daemon that runs on the 'hpcguix' node. >> >> Both have a /gnu mounted by a storage subsystem. >> >> I couldn't run the second

Anyone got ideas on how to make Gajim aware of plugins in store?

I'm currently looking into packaging gajim extensions and I don't know how to make Gajim aware of these new directories. Do I use native-search-paths? There is no variable which is used in Gajim, so I think maybe I need to include this in the wrapper and add something similar to the native-search-

(guix git) and guile-git finalizers.

Hi ! While integrating (guix git) into Cuirass, I noticed unexpected segfaults during "latest-repository-commit" evaluation. Segfaults can be narrowed to the following lines: --8<---cut here---start->8--- (use-modules (git)) (begin (libgit2-init!) (let

Re: Performance on NFS

Hi! Roel Janssen skribis: > From these timings, I don't think it has a big impact. Wait, wait. If we take the best timings of each series of runs, we get: hpc-submit1: 26.4s -> 18.0s (-30%) hpc-guix:26.2s -> 22.7s (-13%) This is arguably insufficient but still non-negligible. I’ve c

Re: Guix libification.

Adam Van Ymeren (2017-06-10 12:32 -0400) wrote: > On June 10, 2017 12:04:59 PM EDT, Alex Kost wrote: >> >>I also needed similar functionality, but since I didn't want to depend >>on guix modules > > Why not depend on guix modules? I'm not a scheme/guile expert just curious, > what's the downsid

Re: Anyone got ideas on how to make Gajim aware of plugins in store?

ng0 writes: > I'm currently looking into packaging gajim extensions > and I don't know how to make Gajim aware of these > new directories. > > Do I use native-search-paths? There is no variable > which is used in Gajim, so I think maybe I need to > include this in the wrapper and add something si

Re: … which cannot be found in RUNPATH

Hartmut Goebel writes: > Hi guix! > > I have a package installing a lib as …/lib/plasma/libDiscoverCommon.so > and a second lib as …/lib/other/lib.so. > > Building and linking works fine, but phase `validate-runpath' fails with: > > "…/other/lib.so depends on 'libDiscoverCommon.so', which cannot