From mboxrd@z Thu Jan  1 00:00:00 1970
From: Arun Isaac <arunisaac@systemreboot.net>
Subject: Re: [PATCH] gnu: Add darkhttpd.
Date: Sat, 10 Sep 2016 18:00:38 +0530
Message-ID: <cu7vay4djip.fsf@systemreboot.net>
References: <20160909204158.GA4337@jasmine>
	<20160910065157.5289-1-arunisaac@systemreboot.net>
	<87oa3wtekf.fsf@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40634)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <arunisaac@systemreboot.net>) id 1bihR1-0007PJ-KX
	for guix-devel@gnu.org; Sat, 10 Sep 2016 08:31:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <arunisaac@systemreboot.net>) id 1bihQx-0005C7-CA
	for guix-devel@gnu.org; Sat, 10 Sep 2016 08:31:02 -0400
Received: from [117.218.232.8] (port=34752 helo=systemreboot.net)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <arunisaac@systemreboot.net>) id 1bihQw-0005Bq-QT
	for guix-devel@gnu.org; Sat, 10 Sep 2016 08:30:59 -0400
In-reply-to: <87oa3wtekf.fsf@gmail.com>
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: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org


> Why 'git-fetch'?  There is a release tarball:
>
> https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2

Yes, there is a release tarball. But, there is some server side issue
with the url. When I try to download it with wget, I get a "The server
name sent was not recognized" warning. wget ignores this warning and
moves on. The guix downloader fails completely. Should the guix
downloader be patched to ignore this warning as well?

The guix downloader output is shown below.

$ guix download https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2

Starting download of /tmp/guix-file.9jzMRu
>From https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2...
ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum A TLS warning alert has been received.> handshake)'.
failed to download "/tmp/guix-file.9jzMRu" from "https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2"
guix download: error: https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2: download failed

The wget downloader output is shown below.

$ wget https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2

--2016-09-09 23:58:53--  https://unix4lyfe.org/darkhttpd/darkhttpd-1.12.tar.bz2
Resolving unix4lyfe.org (unix4lyfe.org)... 64.62.188.248, 2001:470:1:41::403e:bcf8
Connecting to unix4lyfe.org (unix4lyfe.org)|64.62.188.248|:443... connected.
GnuTLS: A TLS warning alert has been received.
GnuTLS: received alert [112]: The server name sent was not recognized
HTTP request sent, awaiting response... 200 OK
Length: 20184 (20K) [application/x-bzip2]
Saving to: 'darkhttpd-1.12.tar.bz2'

darkhttpd-1.12.tar.bz2            100%[===========================================================>]  19.71K  39.6KB/s    in 0.5s    

2016-09-09 23:58:56 (39.6 KB/s) - 'darkhttpd-1.12.tar.bz2' saved [20184/20184]

I have initiated a conversation about this problem with the darkhttpd
developer. But, he has no idea what the problem might be. I'll have to
do some research on the Internet. Any ideas?

If you insist on a tarball instead of the git repo, we can add this
package after this tarball download url problem is fixed.

> I think (file-name (string-append name "-" version "-checkout")) is a
> cleaner name for a git checkout directory (but using the tarball is
> preferred).
>
> If a phase succeed, it should return non-false value, while the value of
> 'install-file' is unspecified.  In such cases we add #t to the end of
> the phase.  BTW I would shorten that last line by moving "/bin" to the
> next one.

Sure, I'll make these changes as well.