patches follow to solve both Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 49491 [details, diff] ebuild diff to correct nocxx/nls issue
Created attachment 49492 [details, diff] ngettext is not defined for -nls , this patch solves it
epunt_cxx has been added a while ago there is no nls USE for gtk+, I'm not gonna add hacks for no good reasons.
if you believe this is a hack, read the original code that is above the added line
This patch corrects a flaw in the gtk+ code. It's not a HACK It does the correct thing. It should be added to our ebuild and pushed upstream.
epunt_cxx was added at the false location, it has to go after autoconf, else the result is overwritten
gtk+ ebuilds include epunt_cxx since 2.6.2. That line was moved after autoconf since 2.6.4-r1. Gtk+'s configure script doesn't understand the '--enable-nls' flag, so including $(use_enable nls) and adding 'nls' to IUSE would have no effect. The ngettext patch looks fine, but I couldn't test it as I don't have a system without ngettext(). It might have to be modified since now there are two files calling ngettext() in Gtk+: gdk-pixbuf/gdk-pixdata.c and gtk/gtkfilechooserdefault.c. What do you think, foser?
ngettext in the second file is commented (within #if 0/#endif), the patch is ok as it is
I think the embedded team has an old-time focus on getting english only devices out there. I think this patch has little merit in a generic tree and might open the floodgates for similar stuff, the whole -nls thing is discouraged by upstream and has been long disabled. I've seen no compelling argument to add it.
it's about making stuff smaller, not about being 'english only' if they're so intent about supporting just nls, then upstream should remove their half-assed no-nls support until then i dont see anything wrong with correcting a minor oversight
It's no secret what it is for (not that it has been mentioned here - i just get 'do this, don't ask questions'), but I doubt if you can do gtk the difference in size is really a problem. This is not an oversight, it is just untouched code, you know how large projects work. It's probably more of an oversight that it is still there.
Why is making something functional that is not functional a problem for you when clearly other people can benefit said functionality? What do you gain from blocking it? How does that help the Gentoo community?
the gettext patch is not accepted for the following reasons : a) it's non functional (comment #7) b) upstream is moving away from optional NLS, this is just a remnant of gtk+-1 times.
I hope you retire soon.
the ngettext is functional, the comment #7 is faulty I am running glib2 and gtk+ without installing any gettext and nothing fails. foser, you mix up things, what the full gettext package would provide if it wouldn't be installed along w/ glibc is the libintl functionality, libintl.[h,a,so] ( on a new glibc this is provided by libc itself), so no need that gettext installs these. This lib (and for glibc libc) allows you to have *.po/*.mo files having internationalisation mostly on the console. None of the "big" pkgs, like mozilla, kde rely on having it (although some ebuilds add it as requirement), everything can be built w/o it The ngettext stub is a stub like the others in the same file, won't hurt anybody who has USE=nls and gettext installed (see in which part of #ifdef ENABLE_NLS it is added), but helps all who don't need nls and gettext Until #ifdef ENABLE_NLS is not removed from glib upstream, I don't see a reason why not adding this, it is only you who (for some unknown reason) don't want to add it and think that gentoo will be better by your attitude
I know what it does, but it is non-functional as it is and only benefits you (it doesn't work out of the box - not with the ebuild, probably not with the patch even as leonardos comment indicates). The question should not be 'why shouldn't this be added?', but why should it. Afaic this is unused, unmaintained code & upstream treats it as such, I see no reason to dig up these corpses. Look I can leave this forever open and ignore it, but that won't change a thing about it.
see upstream: http://bugzilla.gnome.org/show_bug.cgi?=308717 they applied the patch within 1 working day
this was applied upstream, resolved
