From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: [PATCH] gnu: Add whois. Date: Tue, 18 Oct 2016 13:50:55 +0000 Message-ID: <87k2d5dav4.fsf@we.make.ritual.n0.is> References: <20161018080454.4775-1-ng0@we.make.ritual.n0.is> <20161018080454.4775-2-ng0@we.make.ritual.n0.is> <87oa2h7qsp.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:32802) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwUnR-00077Z-GL for guix-devel@gnu.org; Tue, 18 Oct 2016 09:51:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwUnO-0004FX-DU for guix-devel@gnu.org; Tue, 18 Oct 2016 09:51:13 -0400 Received: from aibo.runbox.com ([91.220.196.211]:48420) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwUnO-0004Ew-7o for guix-devel@gnu.org; Tue, 18 Oct 2016 09:51:10 -0400 In-Reply-To: <87oa2h7qsp.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Marius Bakke , guix-devel@gnu.org Marius Bakke writes: > ng0 writes: > >> * gnu/packages/networking.scm (whois): New variable. > > Thanks! This works for me. I have a couple of remarks that can be added > before committing if you agree, no need to send an updated patch. > > * The source headers seems to indicate that this is GPL2+. > * The only reference to this program on the home page is a link to > GitHub, do you think we should use that as home-page? > * Gettext only seems used for building locales and is not referenced at > runtime, perhaps it should be a native-input? Ok. > * The Debian package is built with HAVE_ICONV=1, should we set that too? I can send an updated patch with libiconv in the inputs. This is when you use a libc which does not provide a (usable) iconv, which is why Gentoo provides the option to build it with this too. As we are _currently_ only providing options to do one libc globally this is not so inmportant. I will even build uclibc-ng (I am working on that) with an outside iconv because reportedly their iconv is in bad shape. So with this information, should I send a new patch which adds libiconv and the build option? > Additionally it installs locales, but looks for /usr/share/locale at > runtime. Fixing this would probably require upstream help, I don't want > to hardcode either "/run/current-system/locale" or ~/.guix-profile. The > current version probably works on foreign distros, if nothing else. If you know how to fix it, try to bring it to upstream or include a patch / substitute phase at our end? > Are these changes sensible? >