guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] gnu: Add whois.


From: ng0
Subject: Re: [PATCH] gnu: Add whois.
Date: Sat, 22 Oct 2016 11:24:57 +0000

ng0 <address@hidden> writes:

> Marius Bakke <address@hidden> writes:
>
>> ng0 <address@hidden> 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.

I have my uclibc-ng system not booted: When I specify libiconv in the
inputs, shouldn't it get reported by ldd?

address@hidden /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
mkpasswd  whois
address@hidden /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ 
ldd whois 
        linux-vdso.so.1 (0x00007ffcd84fe000)
        libidn.so.11 => 
/gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 
(0x00007f311084e000)
        libgcc_s.so.1 => 
/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 
(0x00007f3110638000)
        libc.so.6 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 
(0x00007f3110296000)
        
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 
(0x00007f3110a81000)
address@hidden /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ 
ldd mkpasswd 
        linux-vdso.so.1 (0x00007ffed81c7000)
        libcrypt.so.1 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 
(0x00007fc0328e5000)
        libgcc_s.so.1 => 
/gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 
(0x00007fc0326cf000)
        libc.so.6 => 
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 
(0x00007fc03232d000)
        
/gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 
(0x00007fc032b1c000)

> 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?
>>
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]