See http://sourceforge.net/project/showfiles.php?group_id=71654 Notice that in this version, the configure script is GPL, yet the files are BSD-licensed. Reproducible: Always
*** Bug 165159 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > *** Bug 165159 has been marked as a duplicate of this bug. *** > [SIGH] I searched, but did not find this bug when I posted Bug 165159.... Quoting from Bug 165159: After copying the ebuild from libuninameslist-20030713.ebuild to libuninameslist-20060907.ebuild, edit the SRC_URI and replace the ${PV:2:6} with just ${PV}, since the filenames have since switched from two to four digit years. I've tested with that change, and it works as designed. media-gfx/fontforge needs this to correctly describe newer unicode characters while editing fonts.
Created attachment 109035 [details] ebuild for media-libs/libuninameslist-20060907 Ebuild edited as described above.
Created attachment 118099 [details, diff] my changes to utf-8 I see this is one of those bugs that nobody cares about. Well, anyway... As I was playing with a program using this lib, I noticed something "funny". Namely, an upstream bug, affecting this version, but probably earlier versions too. One of this library source files was generated from a file that looked as if it was pure ascii, however it was really latin1. This should be addressed upstream, however my fix uses -std=gnu99, so it may not be the best solution.
*** Bug 182342 has been marked as a duplicate of this bug. ***
I've bumped the version, but I'll leave this bug open for the latin1 issue. I'm not really sure what to do about that. I'd rather not use -std=gnu99.
New version of libuninameslist-20080409 is in the tree for some time and I hope this bug is fixed there. Reopen if it is still an issue there. Thank you.
