From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andreas Enge <andreas@enge.fr>
Subject: Re: [PATCH] gnu: add kicad
Date: Thu, 4 Aug 2016 10:31:56 +0200
Message-ID: <20160804083156.GA1684@solar>
References: <20160215084046.62d5307a@scratchpost.org>
	<20160523041319.GA10803@jasmine>
	<20160804015445.3c0d1615@scratchpost.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55792)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas@enge.fr>) id 1bVE4S-0003g4-Rb
	for guix-devel@gnu.org; Thu, 04 Aug 2016 04:32:09 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <andreas@enge.fr>) id 1bVE4O-0006ab-SP
	for guix-devel@gnu.org; Thu, 04 Aug 2016 04:32:04 -0400
Received: from mailrelay7.public.one.com ([91.198.169.215]:44172)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas@enge.fr>) id 1bVE4O-0006aK-Fo
	for guix-devel@gnu.org; Thu, 04 Aug 2016 04:32:00 -0400
Content-Disposition: inline
In-Reply-To: <20160804015445.3c0d1615@scratchpost.org>
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Danny Milosavljevic <dannym@scratchpost.org>
Cc: guix-devel@gnu.org

Hello,

On Thu, Aug 04, 2016 at 01:54:45AM +0200, Danny Milosavljevic wrote:
> > Unusual choice but I don't object to it. This would be the first package
> > to refer to libressl in our tree.
> We can also use openssl, I don't have a strong preference, really. Both projects seem to merge each other's security patches so we can also use openssl.

why not use libressl? We considered switching to it completely at some
point in time, but so far did not try it out. It would require an almost
complete rebuild in a testing branch, so maybe we should keep it in mind
and wait until the new machine is ready. So having one package that uses
it and builds with it could be a start.

This is independent of the question whether TLS support is actually needed
for this package :-)

Andreas