Marius Bakke <mba...@fastmail.com> writes: > ng0 <n...@we.make.ritual.n0.is> 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.
