Re: [PATCH 0/5]: Add even more LV2 libraries

Ludovic Courtès writes: >> - serd >> - sord >> - sratom > > I think these should go to rdf.scm, no? I moved serd and sord to rdf.scm, but left sratom in audio.scm because it is very specific to LV2 atoms. >> - lilv >> - suil > > Its ‘description’ is bit long, IMO. The description has been shorte

Re: [PATCH 0/4]: Add various audio libraries

Ludovic Courtès writes: >> From 3bb3b7346f44f8e4849efc7a5fc8b465a974d625 Mon Sep 17 00:00:00 2001 >> From: rekado >> Date: Thu, 29 Jan 2015 10:12:00 +0100 >> Subject: [PATCH 4/4] gnu: Add LV2. >> >> * gnu/packages/audio.scm (lv2): New variable. > > [...] > >> +(synopsis "LV2 audio plugin stan

Re: Improving the usability of 'guix environment'

David Thompson skribis: > Ludovic Courtès writes: > >> David Thompson skribis: >> >>> But all of that boilerplate is unnecessary since it's not possible to >>> actually build the package successfully without a proper hash of the >>> source AFAICT. Really, I would rather just use a simple list

Re: Lack of locales in build environment

Federico Beffa skribis: > From my point of view it would be good to include en_US.UTF-8 by > default for two reasons: (i) we already are at 7 (4+3) packages > requiring an UTF-8 locale and, I guess, that this number is doomed to > increase in the following years. (ii) This is another small step i

Re: Lack of locales in build environment

John Darrington skribis: > The C locale is the canonical locale. UTF-8 is not the only characater > encoding in > the world. English is not the only language in the world, and US English is > not > the only dialect of English. You’re right, of course. For the packages discussed, what matters

CA certificates

The attached patch series 1) adds a (private) python script to extract single certificates in .pem format from a big textfile in mozilla source format; 2) adds the package nss-certs, which contains the certificates thus extracted in OUT/etc/ssl/certs, preprocessed with c_rehash for use with

Re: Lack of locales in build environment

John Darrington writes: > (i) we already are at 7 (4+3) packages requiring an UTF-8 locale > > Then that is a bug which should be filed against those pacakges. I just discovered the problem with the "scipy ecosystem" packages today and intended to fix them. But, before submitting changes, I w

Re: core-updates merged!

On Tue, Feb 10, 2015 at 7:46 PM, Andreas Enge wrote: > On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote: >> Guile-ncurses was fixed by adding a new phase to generate the >> "en_US.UTF-8" locale during the generation of the package > > This is interesting information! If I understand

Re: core-updates merged!

On Tue, Feb 10, 2015 at 07:46:48PM +0100, Andreas Enge wrote: On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote: > Guile-ncurses was fixed by adding a new phase to generate the > "en_US.UTF-8" locale during the generation of the package This is interesting inf

Re: core-updates merged!

On Tue, Feb 10, 2015 at 05:38:26PM +0100, Federico Beffa wrote: > Guile-ncurses was fixed by adding a new phase to generate the > "en_US.UTF-8" locale during the generation of the package This is interesting information! If I understand things correctly, I think a solution would be to have tons of

Re: A secure multimedia workstation

On Tue, Feb 10, 2015 at 04:21:27PM +0100, Dirk Scheuring wrote: > This is interesting. You seem to make packaging much easier than I > thought it would be. I wonder why that is. Most packages are easy, because they just require a few declarations. One should start from easy ones, learn and move on

Re: Improving the usability of 'guix environment'

Andreas Enge writes: > On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote: >> guix environment guile guile-sdl # let's tinker with SDL in Guile > > Is this not already covered by doing a "guix package -i ...", tinkering, > and a roll-back? There is one more line to type for the ro

Re: Locales not working

Ah, it turns out that I wrote my message before reading the ongoing discussion on locales. What a coincidence! So we were at least two being bitten by this bug (yes, yes) at the same time! I do not think it is reasonable to break systems for saving 100MB. The code of glibc states ;; In

Re: Improving the usability of 'guix environment'

On Tue, Feb 10, 2015 at 11:45:02AM -0500, David Thompson wrote: > guix environment guile guile-sdl # let's tinker with SDL in Guile Is this not already covered by doing a "guix package -i ...", tinkering, and a roll-back? There is one more line to type for the roll-back. The functionality with

Locales not working

Hello, after the latest upgrade of my profile, the locales do not seem to work any more. All the fancy utf8 in your messages is broken in mutt, and the locale command returns: locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale:

Re: Lack of locales in build environment

On Tue, Feb 10, 2015 at 06:36:58PM +0100, Federico Beffa wrote: On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> Guile-ncurses was fixed by adding a new phase to generate the >> "en_US.UTF-8" locale during the generation of the packag

Re: Improving the usability of 'guix environment'

Ludovic Courtès writes: > David Thompson skribis: > >> But all of that boilerplate is unnecessary since it's not possible to >> actually build the package successfully without a proper hash of the >> source AFAICT. Really, I would rather just use a simple list of >> packages: >> >> (list au

Re: Lack of locales in build environment

On Tue, Feb 10, 2015 at 6:13 PM, Ludovic Courtès wrote: > Federico Beffa skribis: > >> Guile-ncurses was fixed by adding a new phase to generate the >> "en_US.UTF-8" locale during the generation of the package, but wouldn't >> it be better to keep the "en_US.UTF-8" locale? That appears to be the

Re: Improving the usability of 'guix environment'

David Thompson skribis: > But all of that boilerplate is unnecessary since it's not possible to > actually build the package successfully without a proper hash of the > source AFAICT. Really, I would rather just use a simple list of > packages: > > (list autoconf automake guile-2.0 guile-jso

Lack of locales in build environment

Federico Beffa skribis: > Guile-ncurses was fixed by adding a new phase to generate the > "en_US.UTF-8" locale during the generation of the package, but wouldn't > it be better to keep the "en_US.UTF-8" locale? That appears to be the > default used by most packages. That’s an open question. The

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

Marek Benc skribis: > On 02/10/2015 05:25 PM, Ludovic Courtès wrote: > >> >> As I suggested to Manolis, could you make sure that this doesn’t break >> the existing GNU/Linux cross-toolchains? >> >> Namely, could you run: >> >>guix build -e '(@ (gnu packages cross-base) xgcc-armhf)' >> > > I'v

Improving the usability of 'guix environment'

As I use 'guix environment', I realize that I often do not want to create an environment from the inputs of a package, but rather that I want to create an environment from the package itself. I didn't think it was an issue when I did the initial development, but in practice it has proven to be inc

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

On 02/10/2015 05:25 PM, Ludovic Courtès wrote: As I suggested to Manolis, could you make sure that this doesn’t break the existing GNU/Linux cross-toolchains? Namely, could you run: guix build -e '(@ (gnu packages cross-base) xgcc-armhf)' I've tested most of my patches with: $ guix b

core-updates merged!

l...@gnu.org (Ludovic Courtès) writes: > • The ‘glibc’ package no longer has a “locale” output, making it > faster to build, and much smaller (the “locale” output was always > pulled, and it took 110 MiB.) I notice that this breaks some packages like guile-ncurses and the (all?) package

Re: [PATCH 4/4] gnu: gcc: Also substitute the dynamic linker name for GNU, (ie. Hurd) systems.

Marek Benc skribis: > On 02/08/2015 12:22 AM, Ludovic Courtès wrote: > >> >> Would this slightly more concise approach work: >> >> >> >> diff --git a/gnu/packages/gcc.scm b/gnu/packages/gcc.scm >> index 6143f5b..5cb7f8b 100644 >> --- a/gnu/packages/gcc.scm >> +++ b/gnu/packages/gcc.scm >> @@ -202

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

Manolis Ragkousis skribis: > From aaa968bbe01a57ceadf8d0c46c44e0d75d2f90cd Mon Sep 17 00:00:00 2001 > From: Marek Benc > Date: Thu, 5 Feb 2015 17:01:14 +0100 > Subject: [PATCH] gnu: cross-base: Make it aware of non-Linux (ie. Hurd) > systems. > > * gnu/packages/cross-base.scm (cross-gcc-argumen

Re: using guix in virtualbox

westlake skribis: > The setup is informative enough from the guix install page, on top of > which I create two empty .vdi disks, and can use qemu-nbd to transfer > the raw image of the usb-install. > > It's actually pretty easy to set this up, and it took under 20 > minutes. However after rebooti

Re: A secure multimedia workstation

Dirk Scheuring skribis: > "I performed the following changes to the files in /etc/pulse" > > when I realize that there is no /etc/pulse in Guix! Rather, the > configuration files are represented - as is everything else - by their > contribution to the hash values in /nix/store. Or that's how I cu

Re: A secure multimedia workstation

Dirk Scheuring writes: > This is interesting. You seem to make packaging much easier than I > thought it would be. I wonder why that is. It really *is* rather simple. I come from a background of packaging RPMs by writing spec files and I find packaging for Guix much less painful (to the point w

Re: A secure multimedia workstation

Andreas Enge wrote: > ... Definitely you could start helping the Guix project (and your own project) by packaging software that you are interested in and that we do not provide yet. Some guile/scheme knowledge is helpful, but not strictly required, see https://www.gnu.org/software/guix/guix-ghm-an

Re: [ART] Logo proposal

El lun, 09-02-2015 a las 23:35 +0100, Ludovic Courtès escribió: > Luis Felipe López Acevedo skribis: > > > I made some logos for Guix and GuixSD: > > > > * http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png > > * http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png > > > > I und

Re: bug#19805: Numpy failures

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Federico Beffa skribis: >> >>> At some point we should fix the support for '#:substitutable?' on hydra >> >> That probably means that #:substitutable? should be propagated–i.e., >> that anything depending on ATLAS should not be

Re: texlive failure

Federico Beffa skribis: > So, I guess grafting takes a very long time. For this package it is > not substantially faster than building the package itself. :-( Grafting takes time proportional to the input size. It’s OK for packages of up to several MiB (the vast majority of packages), but here

Re: [PATCH 2/4] gnu: cross-base: Make it aware of non-Linux (ie. Hurd)

Ludo is this okay to push? Wrapped lines to 80 chars. From aaa968bbe01a57ceadf8d0c46c44e0d75d2f90cd Mon Sep 17 00:00:00 2001 From: Marek Benc Date: Thu, 5 Feb 2015 17:01:14 +0100 Subject: [PATCH] gnu: cross-base: Make it aware of non-Linux (ie. Hurd) systems. * gnu/packages/cross-base.scm (cros

Re: texlive failure

On Tue, Feb 10, 2015 at 08:46:42AM -0500, Mark H Weaver wrote: > I wonder if we should consider setting #:substitutable? #f for texlive. > However, we would have to be careful not to propagate this setting, as > was recently proposed in the "Numpy failures" thread. I have been working on a split o

Re: texlive failure

On Tue, Feb 10, 2015 at 10:50:05AM -0300, Daniel Pimentel wrote: > I can install texlive after "guix pull", it work. You mean, you managed to pull all the data from hydra? Or did you compile locally? Andreas

Re: bug#19805: Numpy failures

l...@gnu.org (Ludovic Courtès) writes: > Federico Beffa skribis: > >> At some point we should fix the support for '#:substitutable?' on hydra > > That probably means that #:substitutable? should be propagated–i.e., > that anything depending on ATLAS should not be substituted. As I just wrote in

Re: texlive failure

On 2015-02-10 10:34, Andreas Enge wrote: On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote: So, I guess grafting takes a very long time. For this package it is not substantially faster than building the package itself. :-( The speciality of texlive is that it is relatively easy to

Re: texlive failure

Andreas Enge writes: > On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote: >> So, I guess grafting takes a very long time. For this package it is >> not substantially faster than building the package itself. :-( > > The speciality of texlive is that it is relatively easy to build - so

Re: texlive failure

On Tue, Feb 10, 2015 at 01:56:17PM +0100, Federico Beffa wrote: > So, I guess grafting takes a very long time. For this package it is > not substantially faster than building the package itself. :-( The speciality of texlive is that it is relatively easy to build - some CPU time for the binaries.

Re: bug#19805: Numpy failures

On Tue, Feb 10, 2015 at 12:07 AM, Ludovic Courtès wrote: >> At some point we should fix the support for '#:substitutable?' on hydra > > That probably means that #:substitutable? should be propagated–i.e., > that anything depending on ATLAS should not be substituted. I guess so. Is there a way to

Re: texlive failure

On Tue, Feb 10, 2015 at 1:55 PM, Ludovic Courtès wrote: > I think what happens is what Mark described in > . > > For now the workaround is to use --max-silent-time=1 or similar. Crossed emails... Yes, that's correct. Thanks, Fede

Re: texlive failure

On Tue, Feb 10, 2015 at 1:26 PM, Federico Beffa wrote: > This is the 'tail' of the output: > > [...] > starting phase `compress-documentation' > compressing documentation in > '/gnu/store/3vxysgl09laha9k2vhq0li8ijfqnnpn7-texlive-2014/share/man' > with "gzip" and flags ("--best" "--no-name") > comp

Re: texlive failure

Federico Beffa skribis: > I have trouble downloading the 3.3GB 'texlive-data' package and > therefore I'm trying to build it locally. The 'build' and 'check' > phases succeed. However, after the 'compress-documentation' phase a > guile process stays at 100% for 1 hour, after which the process tim

Re: using guix in virtualbox

On Tue, 10 Feb 2015, westlake wrote: Hi, I've noticed that people have been using virtualbox with guix, but over here with 0.8.1 (64-linux), i'm noticing a bootup issue upon post-install The setup is informative enough from the guix install page, on top of which I create two empty .vdi disks,

Re: [PATCH]: gnu: Add HISAT.

Ricardo Wurmus skribis: > From 5696a8227d98d60d38f0ff19b40a21ccb13e53f1 Mon Sep 17 00:00:00 2001 > From: Ricardo Wurmus > Date: Mon, 9 Feb 2015 12:13:26 +0100 > Subject: [PATCH] gnu: Add HISAT. > > * gnu/packages/bioinformatics.scm (hisat): New variable. LGTM, thanks! Ludo’.

Re: [PATCH] gnu: Add openntpd.

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis: > From 4ee696247b320144c16656fd525b20a3a4cf31d3 Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?= > > Date: Mon, 9 Feb 2015 21:39:41 +0100 > Subject: [PATCH] gnu: Add openntpd. > > * gnu/packa

Re: [PATCH]: gnu: Add STAR.

Ricardo Wurmus skribis: > Ludovic Courtès writes: >>> +(license license:gpl3))) >> >> GPLv3-only? > > Actually, searching the source tree shows me that LICENSE includes the > "or (at your option) any later version" phrase; but the included copy of > htslib that is built as part of the STAR al

Re: [ART] Logo proposal

On Sun, 8 Feb 2015, Luis Felipe López Acevedo wrote: Hi, I made some logos for Guix and GuixSD: * http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png * http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png I understand if you prefer using the current Guix logo and no logo for

texlive failure

Hi, I have trouble downloading the 3.3GB 'texlive-data' package and therefore I'm trying to build it locally. The 'build' and 'check' phases succeed. However, after the 'compress-documentation' phase a guile process stays at 100% for 1 hour, after which the process times out and is killed. This i

Re: [ART] Logo proposal

On 2015-02-09 19:35, l...@gnu.org wrote: Luis Felipe López Acevedo skribis: I made some logos for Guix and GuixSD: * http://sirgazil.bitbucket.org/static/temp/img/guix/Guix.png * http://sirgazil.bitbucket.org/static/temp/img/guix/GuixSD.png I understand if you prefer using the current Guix l

Re: [PATCH]: gnu: Add HISAT.

Ludovic Courtès writes: > If it’s possible to avoid the whole list using ‘find-files’ or > ‘scandir’, that would be nicer IMO. If it’s not, that’s fine. In the attached patch I used `find-files' instead. The expression is a bit long, but I think it's still clear enough to be preferable to the

Re: [PATCH] gnu: Add openntpd.

Updated patch: >From 4ee696247b320144c16656fd525b20a3a4cf31d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?= Date: Mon, 9 Feb 2015 21:39:41 +0100 Subject: [PATCH] gnu: Add openntpd. * gnu/packages/ntp.scm (openntpd): New variable. --- gnu/packages/ntp.scm

Re: [PATCH]: gnu: Add HISAT.

Ludovic Courtès writes: > If it’s possible to avoid the whole list using ‘find-files’ or > ‘scandir’, that would be nicer IMO. If it’s not, that’s fine. > >> +(license license:gpl3))) > > GPLv3-only? > > Thanks! > > Ludo’.

Re: [PATCH]: gnu: Add STAR.

Ludovic Courtès writes: >> +(license license:gpl3))) > > GPLv3-only? Actually, searching the source tree shows me that LICENSE includes the "or (at your option) any later version" phrase; but the included copy of htslib that is built as part of the STAR aligner is MIT licensed. I'll update t

Re: [PATCH] gnu: Add openntpd.

taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis: > From d9e0a4d07ee7e82582589b1e1cd3be218dd6b08f Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Taylan=20Ulrich=20Bay=C4=B1rl=C4=B1/Kammer?= > > Date: Mon, 9 Feb 2015 21:39:41 +0100 > Subject: [PATCH] gnu: Add openntpd. > > * gnu/packa

using guix in virtualbox

Hi, I've noticed that people have been using virtualbox with guix, but over here with 0.8.1 (64-linux), i'm noticing a bootup issue upon post-install The setup is informative enough from the guix install page, on top of which I create two empty .vdi disks, and can use qemu-nbd to transfer the

Re: [PATCH] gnu: Add smartmontools.

Mark H Weaver writes: > One more unrelated suggestion, while I'm at it: in the synopsis and > description, I think it would be better to write "S.M.A.R.T." rather > than "SMART". What do you think? Done. Thanks for the review. :-)