From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marius Bakke Subject: Re: [PATCH] gnu: Add whois. Date: Tue, 18 Oct 2016 16:10:23 +0100 Message-ID: <87lgxl7kww.fsf@duckhunt.i-did-not-set--mail-host-address--so-tickle-me> 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> <87k2d5dav4.fsf@we.make.ritual.n0.is> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56429) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwW2B-0006KL-82 for guix-devel@gnu.org; Tue, 18 Oct 2016 11:10:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwW26-0004gp-85 for guix-devel@gnu.org; Tue, 18 Oct 2016 11:10:31 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:33914) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwW26-0004ge-1e for guix-devel@gnu.org; Tue, 18 Oct 2016 11:10:26 -0400 In-Reply-To: <87k2d5dav4.fsf@we.make.ritual.n0.is> 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: ng0 , guix-devel@gnu.org ng0 writes: >> * 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? Since we only support glibc at the moment, I don't think adding a package for libiconv first is necessary. On the other hand, if it can cause problems on other libc's, it's nice to use an external one. IMO adding libiconv as input is something that can be done later, when there is an actual need for it. I guess there are more packages that will require it. But I don't really mind either way :) >> 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? I tried patching whois.c to use the glibc default in the call to bindtextdomain(3), instead of the LOCALEDIR build option. That almost worked: it searches the system locales, but also expect to find the translation files there. I'll see if I can cook up a fix for upstream, but don't think this should hold back the package.