Re: Building core-updates?

l...@gnu.org (Ludovic Courtès) writes: > ‘core-updates’ provides the long awaited fix for locales, and it’s > essentially ready to merge. > > We need to choose whether to revert 42e735d based on the discussion in > . Mark? Andreas? I think we should leave 42e735d for

Using 'system*' instead of 'system' in 'guix environment'

Hello Guix hackers, In an effort to finish up a patch to add a --container flag to 'guix environment', I've encountered a serious problem. The --exec flag allows the user to pass an arbitrary command to be run using 'system'. Unlike 'system*', 'system' spawns a command interpreter first and passe

Building core-updates?

Hi, ‘core-updates’ provides the long awaited fix for locales, and it’s essentially ready to merge. We need to choose whether to revert 42e735d based on the discussion in . Mark? Andreas? Either way, we should start building all of the branch. Ludo’.

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

Alex Kost skribis: > Ludovic Courtès (2015-10-07 15:23 +0300) wrote: > >> Alex Kost skribis: >> > [...] >>> I don't see a problem here, since a fake sha256 may be any string, >> >> Not really, since ‘base32’ is a macro that checks its argument at >> expansion time. So in practice one cannot C-

Re: [PATCH 0/2] native-search-paths for GHC

On 2015-10-07 11:07, Federico Beffa wrote: ericbav...@openmailbox.org writes: From: Eric Bavier The first of these patches lets search-path-as-list function correctly when a pattern is given and the 'directory file type is specified. The second adds a native-search-paths field to our ghc p

Re: Checking signatures on source tarballs

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver skribis: >> >>> IMO, we should rather be going in the other direction, to formalize and >>> automate the checking of signatures. IMO, our 'origin' objects should >>> include a set of fingerprints of acceptable GP

Re: 02/02: gnu: camlp4: Remove extra input.

On Wed, 07 Oct 2015 22:36:52 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Efraim Flashner skribis: > > > commit d04efa0fff908de0f8822a27582b4b1c3dcae553 > > Author: Efraim Flashner > > Date: Wed Oct 7 14:44:59 2015 +0300 > > > > gnu: camlp4: Remove extra input. > > > > * gnu/pac

Re: 02/02: gnu: camlp4: Remove extra input.

Efraim Flashner skribis: > commit d04efa0fff908de0f8822a27582b4b1c3dcae553 > Author: Efraim Flashner > Date: Wed Oct 7 14:44:59 2015 +0300 > > gnu: camlp4: Remove extra input. > > * gnu/packages/ocaml.scm (camlp4)[inputs]: Removed duplicate "ocaml" > entry from native-inputs

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

Quoting Alex Kost (2015-10-07 13:25:44) > > What about, instead, providing an interactive function that would > > prompt > > for a URL, run ‘guix download’ on that, and emit an ‘origin’ template at > > point with all the info? > > I see several problems here, but the main is: this sounds like it sh

Re: Checking signatures on source tarballs

On Wed, Oct 7, 2015, at 10:09, Mark H Weaver wrote: > > l...@gnu.org (Ludovic Courtès) writes: > > Most of the time the authentication model is trust-on-first-download: > > The packager fetches upstream’s public key when they first download a > > tarball (so this particular phase is subject to MiTM

Re: Checking signatures on source tarballs

Mark H Weaver (2015-10-07 05:07 +0300) wrote: > Alex Kost writes: > >> Ludovic Courtès (2015-10-05 18:55 +0300) wrote: >> >>> Alex Kost skribis: >>> Ludovic Courtès (2015-10-04 19:57 +0300) wrote: > However, if this is “too convenient”, I’m afraid this would give an > incentive

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

Ludovic Courtès (2015-10-07 15:23 +0300) wrote: > Alex Kost skribis: > [...] >> I don't see a problem here, since a fake sha256 may be any string, > > Not really, since ‘base32’ is a macro that checks its argument at > expansion time. So in practice one cannot C-M-x a package with a random > ba

Re: [PATCH 0/2] native-search-paths for GHC

ericbav...@openmailbox.org writes: > From: Eric Bavier > > The first of these patches lets search-path-as-list function correctly when a > pattern is given and the 'directory file type is specified. > > The second adds a native-search-paths field to our ghc package. It modifies > our haskell-bui

Re: Checking signatures on source tarballs

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> IMO, we should rather be going in the other direction, to formalize and >> automate the checking of signatures. IMO, our 'origin' objects should >> include a set of fingerprints of acceptable GPG signing keys for that >> packag

Re: [PATCH] gnu: imagemagick: Hard-code delegate paths.

Eric Bavier skribis: > On Tue, 06 Oct 2015 11:50:36 +0200 > l...@gnu.org (Ludovic Courtès) wrote: > >> ericbav...@openmailbox.org skribis: >> >> > From: Eric Bavier >> > >> > If --with-frozenpaths is given, then configure will retain absolute paths >> > discovered for delegate programs, otherwi

Re: [PATCH 2/4] emacs: Add 'guix-devel-download-package-source'.

Alex Kost skribis: > Ludovic Courtès (2015-10-05 18:55 +0300) wrote: > >> Alex Kost skribis: >> >>> Ludovic Courtès (2015-10-04 19:57 +0300) wrote: >>> > [...] In that case, I would suggest something based on the URL at point rather than the origin at point. >>> >>> It's neither URL at

Re: Reproducible environments

Konrad Hinsen skribis: > Here's an example (a simplified version of the real situation that motivated > me to check out Guix): > >- I need to use Program X that depends on libraries A and B. >- The current versions are A-1.1 and B-42.0.1. >- X requires "1.0 or later" for A but "41.*"

Re: Checking signatures on source tarballs

Mark H Weaver skribis: > IMO, we should rather be going in the other direction, to formalize and > automate the checking of signatures. IMO, our 'origin' objects should > include a set of fingerprints of acceptable GPG signing keys for that > package, as well as information on how to find the si

[PATCH] Some dependencies for the planned IPython upgrade.

Hi Guix, last time I sent a patch to upgrade IPython but forgot to actually send all the other required packages to make this upgrade work. So this email contains a first set of new packages that are needed for the upgrade. A couple of patches still need some work before I can send them out. ~~

Re: [PATCH] 11 little Ruby gems.

On 07/10/15 04:25, Thompson, David wrote: In short, yes, your patches are very welcome. Thanks! - Dave Here ya go then. Can I ask, would it be helpful to alphabetize the packages in ruby.scm, at least vaguely? Always adding new packages to the bottom of the file causes git merge conflicts I

Re: Checking signatures on source tarballs

This sounds all very good. In practice, the difference would unfortunately be only slight: Most packages have no signature, mainly the gnu packages do. But it would be useful for the cases where signatures exist, and show our commitment to security. Andreas