Please, test this thing w/ stuff that you maintain before it gets commited, since it breaks API once again, see http://icu-project.org/download/3.8.html for a list of changes. You can grab the ebuild from PHP overlay: http://overlays.gentoo.org/svn/proj/php/testing/migration/dev-libs/icu/ app-office/openoffice - openoffice app-text/sword - theology dev-db/firebird - wltjr dev-lang/parrot - perl dev-libs/boost - dev-zero/cpp net-misc/suite3270 - robbat2/jieryn@gmail.com net-nntp/tin - net-news
JFYI, openoffice fails with unpatched icu 3.8. see openoffice bug with workaround: http://qa.openoffice.org/issues/show_bug.cgi?id=83146
Tested with Firebird 2.0.3, 2.1.0 keeps hanging during merge for me on amd64. Known issue, not icu related. Comes and goes, working issue on another bug. Upstream did comment about ICU 3.8 being fine on Linux. They had some windows specific issues, wrt to build system and etc. Nothing API breakage related or etc. Compiles fine, and 2.0.3 runs fine afterward. So signing off on icu 3.8 for Firebird :)
Sorry for the delay, holidays and all. :-) Signing off for net-misc/suite3270-3.3.6 with the caveat that I do not have access to any CJK enabled mainframes. I built against the linked dev-libs/icu-3.8 successfully. For sanity, I ran the programs to normal mainframes with an application-set CJK character set (but have no CJK characters to render..). Hopefully this is good enough.
(In reply to comment #1) > JFYI, openoffice fails with unpatched icu 3.8. Should be fixed in 2.3.1 if I read the upstream bug correctly? :)
(In reply to comment #4) > (In reply to comment #1) > > JFYI, openoffice fails with unpatched icu 3.8. > > Should be fixed in 2.3.1 if I read the upstream bug correctly? :) > Yes it should, but I didn't find the time to test until now, that's why I didn't post about it. So if someone wants to step in...
(In reply to comment #4) > Should be fixed in 2.3.1 if I read the upstream bug correctly? :) The configure check to see if you have a patched icu package so that i18npool won't break compilation. I do not see the patch for icu there. I wonder what I saw. Debian patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448745 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=24;filename=icu-3.6-setBreakType-interdiff.diff;att=1;bug=448745
(In reply to comment #6) > The configure check to see if you have a patched icu package so that i18npool > won't break compilation. Sigh, why's the OO.org bug resolved? This is no real fix? I've added the patch to overlay with appropriate comments, someone test w/ OO.org compile, but this definitely isn't the way to approach such issues. :/
Well, it seems that OOo vanilla 2.3.1 source has not the fix for a bug in OOo that _requires_ the setBreakType function as public since it compiled with system-icu and setBreakType function as private(or protected) for Andreas(suka) afais. I work on OOo 2.4 and there you will see OOo configure failing if setBreakType function is private(or protected) which it is in vanilla ICU. Therefor the patch for ICU. If you delete the configure check for setBreakType being public or not the compile fails in module i18npool. So, either you use internal ICU in openoffice or patch system ICU to have setBreakType function public. That's it. :) ___ That openoffice bug is to add that configure check.
(In reply to comment #8) Hanno, I understand what does the OO.org patch do and that otherwise it fails to compile, my concern rather is that we are making something public which by design was protected by upstream. ;) Oh well... Meanwhile, 3.8.1 is out and will appear in the overlay in couple of minutes, so if someone's going to test w/ OO.org, don't forget to svn up and upgrade ICU before. :)
So I misinterpreted your questionmarks. Just fine. ;)
dev-libs/xerces-c-2.8.0 is reported to be broken w/ ICU-3.8.x (BTW, moved to http://overlays.gentoo.org/svn/proj/php/migration/dev-libs/icu/)
InCVS w/ the OO.org patch; blocker added to dev-libs/xerces-c. If something else breaks that we got no response from the maintainers here, not our fault. :) Closing.
