| Summary: | sys-libs/glibc: nl_NL.UTF-8 locale | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Aurelus <aurelus> |
| Component: | [OLD] Core system | Assignee: | Please assign to toolchain <gcc-porting> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | m.debruijne |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Aurelus
2003-10-27 11:53:21 UTC
This to me sounds like something that needs to be taken up with the glibc people, unless you have a patch or something that can implement this. Otherwise, it more or less falls outside the realm of Gentoo, as it's not a bug within Gentoo itself, but more a feature request for a component used by multiple Linux distributions. Unless you have any other information (i.e., Patch) or additional information that can implement this, I will resolve this bug as INVALID in a day or so. The reason I reported it like this, is that a support request for the en_US.UTF-8 locale (bug number 18744) was done the same way. What I currently do to manually add the support is: # localedef -i nl_NL -c -f UTF-8 nl_NL (Sorry for not giving this additional info directly.) Ahh, so it isn't a patch to glibc then, just a command that needs to be run in say, the ebuild? That would work, yes. I've taken a further look at the glibc source package, and it turns out there's a localedata/SUPPORTED file, from which those locales seem to be generated. I think the best way would be to add this locale to that file (upstream), but I'm still in the dark about how the other bug I mentioned is solved (there's no support for en_US.UTF-8 in the SUPPORTED file). I'll contact the glibc developers, and report here what's the result (I think that's easiest). FYI: this should be fixed in the next version of glibc (upstream) |