ng0 <n...@we.make.ritual.n0.is> writes: > Marius Bakke <mba...@fastmail.com> writes: > >> ng0 <n...@we.make.ritual.n0.is> 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? ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls mkpasswd whois ng0@shadowwalker /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) ng0@shadowwalker /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? >> > >