l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> From e6ddaf74f30ee5d6c8d76a3ae9cacdb14eb060c5 Mon Sep 17 00:00:00 2001
>> From: Mark H Weaver
>> Date: Tue, 18 Feb 2014 22:06:34 -0500
>> Subject: [PATCH] gnu: Add libgpg-error as propagated inputs to gnupg,
>> gpgme, and pine
Eric Bavier skribis:
> * gnu/packages/calcurse.scm: New file
> * gnu-system.am (GNU_SYSTEM_MODULES): Add it
Applied, thanks.
I can add you to the Savannah group so you can push by yourself, if
you’re familiar with Git. Do you have a Savannah account?
Thanks,
Ludo’.
Hi ludo.
Below is a list of GSoC ideas for GNU Guix.
Thanks, added to the page.
Howdy!
Did you see there’s a new ‘guix system’ command? It’s wonderful. Drop
the following in a file, say ‘os-config.scm’:
--8<---cut here---start->8---
(use-modules (gnu packages emacs)
(gnu packages xorg)
(gnu packages base)
Good evening!
Below is a list of GSoC ideas for GNU Guix.
Guix people: you’re welcome to put your name as the mentor of one of the
projects below, and to propose other ideas.
Thanks!
Ludo’.
Supporting binary package distribution through GNUnet
GNU Guix provides a transparent binary/source de
* gnu/packages/calcurse.scm: New file
* gnu-system.am (GNU_SYSTEM_MODULES): Add it
---
gnu-system.am |1 +
gnu/packages/calcurse.scm | 49 +
2 files changed, 50 insertions(+)
create mode 100644 gnu/packages/calcurse.scm
diff --git a/
Andreas Enge skribis:
> I still think that an infrastructure based on gnunet for distributing
> cryptographically signed packages would be interesting. In a nutshell,
> I would like arbitrary independent instances to inject signed packages
> into the network. A user could maintain a list of trust
Andreas Enge skribis:
> On Wed, Feb 19, 2014 at 05:46:17PM +, Manolis Ragkousis wrote:
>> With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
>> wondering if porting guix to hurd and creating a guix hurd system, which I am
>> currently working on, is worthy for a Gsoc i
Andreas Enge skribis:
> On Wed, Feb 19, 2014 at 02:40:42PM +0100, Ludovic Courtès wrote:
>> So, all in all, while this is not ideal, using this configure flag to
>> point to /etc/ssl/... sounds like a viable option to me. It’s
>> consistent with what other distros do, and it’s what we want to do
On Wed, Feb 19, 2014 at 05:46:17PM +, Manolis Ragkousis wrote:
> With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
> wondering if porting guix to hurd and creating a guix hurd system, which I am
> currently working on, is worthy for a Gsoc idea. I am an eligible student
Hello,
I still think that an infrastructure based on gnunet for distributing
cryptographically signed packages would be interesting. In a nutshell,
I would like arbitrary independent instances to inject signed packages
into the network. A user could maintain a list of trusted keys and try
to downl
On 02/19/2014 06:46 PM, Manolis Ragkousis wrote:
With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
wondering if porting guix to hurd and creating a guix hurd system, which I
am currently working on, is worthy for a Gsoc idea. I am an eligible
student, so that could be gre
With less than 12 hours for GNU to submit ideas for this year's Gsoc, I am
wondering if porting guix to hurd and creating a guix hurd system, which I
am currently working on, is worthy for a Gsoc idea. I am an eligible
student, so that could be great!
On 02/19/2014 03:08 PM, Andreas Enge wrote:
> The next question is, where do these certificates come from in our system?
> I think a reasonable solution would be to:
> - create a package with certificates (maybe inspired from those contained
> in debian);
> - have gnutls depend on it, and use the
On Wed, Feb 19, 2014 at 02:40:42PM +0100, Ludovic Courtès wrote:
> So, all in all, while this is not ideal, using this configure flag to
> point to /etc/ssl/... sounds like a viable option to me. It’s
> consistent with what other distros do, and it’s what we want to do
> eventually.
>
> (Also, I
Mark H Weaver skribis:
> From e6ddaf74f30ee5d6c8d76a3ae9cacdb14eb060c5 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Tue, 18 Feb 2014 22:06:34 -0500
> Subject: [PATCH] gnu: Add libgpg-error as propagated inputs to gnupg,
> gpgme, and pinentry.
>
> * gnu/packages/gnupg.scm (gnupg, gpgme
Mark H Weaver skribis:
> From ae342554c8bc60a2bd238a0869c7bd5ba33619e2 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Wed, 19 Feb 2014 02:06:13 -0500
> Subject: [PATCH] gnu: tor: Upgrade to 0.2.4.20.
>
> * gnu/packages/tor.scm (tor): Upgrade to 0.2.4.20.
OK to push.
Ludo’.
Mark H Weaver skribis:
> From ae342554c8bc60a2bd238a0869c7bd5ba33619e2 Mon Sep 17 00:00:00 2001
> From: Mark H Weaver
> Date: Wed, 19 Feb 2014 02:06:13 -0500
> Subject: [PATCH] gnu: tor: Upgrade to 0.2.4.20.
>
> * gnu/packages/tor.scm (tor): Upgrade to 0.2.4.20.
OK to push,
Ludo’.
Mark H Weaver skribis:
> Andreas Enge writes:
>
>> On Tue, Feb 18, 2014 at 11:09:16PM -0500, Mark H Weaver wrote:
>>> This adds gmime, another step toward notmuch (mail).
>>> + #:use-module (srfi srfi-1))
>>
>> Is this module needed in the sense that the solution is preferable to what
>> is don
Hello!
Thank you both for looking into this.
Andreas Enge skribis:
> On Wed, Feb 19, 2014 at 05:13:26AM -0500, Mark H Weaver wrote:
[...]
>> So, in the end, I don't think we should mess around with the way GnuTLS
>> was designed. I think we should provide a hard-coded system-wide
>> location
On Wed, Feb 19, 2014 at 01:47:56PM +0100, Sree Harsha Totakura wrote:
> A recent build of GNUnet-0.10.0 failed due to failed build it its
> dependency libmicrohttpd according to http://hydra.gnu.org/build/39760
>
> However, if you take a look at the log for libmicrohttpd, it seems it
> has been su
It is also unclear why gnunet package is built before libmicrohttpd when
libmicrohttpd is a dependency.
On 02/19/2014 01:47 PM, Sree Harsha Totakura wrote:
> Hi,
>
> A recent build of GNUnet-0.10.0 failed due to failed build it its
> dependency libmicrohttpd according to http://hydra.gnu.org/buil
Hi,
A recent build of GNUnet-0.10.0 failed due to failed build it its
dependency libmicrohttpd according to http://hydra.gnu.org/build/39760
However, if you take a look at the log for libmicrohttpd, it seems it
has been successfully built. And according to
http://hydra.gnu.org/build/39761 libmic
On Wed, Feb 19, 2014 at 05:13:26AM -0500, Mark H Weaver wrote:
> However, GnuTLS does not support an environment variable setting, so we
> would have to patch the code (add_system_trust in lib/system.c). I
> strongly considered doing this, but I'm worried about the possible
> security implications
This patch is actually a prerequisite to the "Add gmime" patch. I could
have added 'libgpg-error' as another input to 'gmime', but this seemed
the more proper solution.
What do you think?
Mark
>From e6ddaf74f30ee5d6c8d76a3ae9cacdb14eb060c5 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date:
On Wed, Feb 19, 2014 at 05:17:44AM -0500, Mark H Weaver wrote:
> srfi-1 is very widely used. It is certainly already loaded already, so
> importing it is a cheap operation.
>
> What do you think?
I was just asking and am definitely fine with it, if you want to push.
Andreas
Andreas Enge writes:
> On Tue, Feb 18, 2014 at 11:09:16PM -0500, Mark H Weaver wrote:
>> This adds gmime, another step toward notmuch (mail).
>> + #:use-module (srfi srfi-1))
>
> Is this module needed in the sense that the solution is preferable to what
> is done, for instance, to determine the
Hi Andreas,
Andreas Enge writes:
> On Tue, Feb 18, 2014 at 09:47:18PM -0500, Mark H Weaver wrote:
>> This patch is needed to allow gnutls to find the system-wide trust store
>> (trusted CA certificates).
>
>> +
>> "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
>
On 02/19/2014 12:53 AM, David Knight wrote:
> Wonderful, setting these solved the problem. Now guix package -i hello
> works for me!
Good. The namespaces are required for Guix to build new packages in a
chroot environment which should be independent of the host system and
consistent on all hosts
On Tue, Feb 18, 2014 at 11:09:16PM -0500, Mark H Weaver wrote:
> This adds gmime, another step toward notmuch (mail).
> + #:use-module (srfi srfi-1))
Is this module needed in the sense that the solution is preferable to what
is done, for instance, to determine the file name of qt?
Andreas
On Tue, Feb 18, 2014 at 09:47:18PM -0500, Mark H Weaver wrote:
> This patch is needed to allow gnutls to find the system-wide trust store
> (trusted CA certificates).
> +
> "--with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt")))
As there is no system, and we advertise per
31 matches
Mail list logo
