From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: [PATCH] gnu: Add whois. Date: Sat, 22 Oct 2016 11:04:37 +0000 Message-ID: <8760okve4a.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> <87k2d5dav4.fsf@we.make.ritual.n0.is> <87lgxl7kww.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]:47796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxu6e-0005mt-H3 for guix-devel@gnu.org; Sat, 22 Oct 2016 07:04:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxu6a-00034n-Gp for guix-devel@gnu.org; Sat, 22 Oct 2016 07:04:52 -0400 Received: from aibo.runbox.com ([91.220.196.211]:35621) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxu6a-00033K-9k for guix-devel@gnu.org; Sat, 22 Oct 2016 07:04:48 -0400 In-Reply-To: <87lgxl7kww.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: > >>> * 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. > I think we can bundle the patch until it/if gets accepts at all by upstream.