The version of icu in debian is very old. I have recently taken over maintainership of the package. I had originally intended to wait until after the g++ transition had completed to do the ICU transition, but I'm now strongly considering building new ICU packages to upload to unstable before the g++ transition is finished. The main reason for this is that icu 2.1 fails to build on ARM, but icu 3.4 beta succeeds. The only direct reverse dependencies of the icu package are the xerces packages which I also maintain. There are only three or four reverse dependencies of the xerces packages. Right at this moment, libxml-xerces-perl has succeeded on arm even though xerces25 has failed, which probably means that it is not in a stable state with respect to the g++ transition. Also, I'm about to move, go on vacation, and change jobs, so my available time will drop for a short time (from late August through mid September), and it might be good to have this done before then. There is also an icu28 package in debian, but it is not necessary to convert its reverse dependencies to use the new icu package at the same time -- that can wait until after the g++ transition.
If I start this transition as early as this weekend, it should not hold up the g++ transition, and I will be able to monitor it closely for two or three weeks before I start being much less available. Given all this, can anyone think of any reason why I should not start an ICU transition this weekend? An alternative would to resolve the FTBFS on arm for icu 2.1 (which worked before g++ 4.0) and to wait for xerces25 to rebuild and then to do a binary NMU rebuild of libxml-xerces-perl Thoughts? --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]