On Dec 24, 10:40 am, "Bert Huijben" <[email protected]> wrote: > > -----Original Message----- > > From: Bhuvaneswaran A [mailto:[email protected]] > > Sent: donderdag 24 december 2009 5:15 > > To: Hyrum K. Wright > > Cc: Subversion Development > > Subject: Re: 1.6.7 up for signing/testing > > > On Wed, 2009-12-23 at 09:35 -0600, Hyrum K. Wright wrote: > > > A little late, but never never, here's the promised tarballs for > > > Subversion > > 1.6.7. The magic revision is r893529, and you can find the tarballs here: > > > >http://orac.ece.utexas.edu/pub/svn/1.6.7/ > > > > Please be sure to test the bindings. > > > > You know the drill: signatures from full committers back to me, and > > enthusiastic tester feedback is welcome. At this point, this candidate is > > not > > yet blessed for wide release, so please don't make it available to people > > not > > interested in test-driving the new release. > > > For those who are going to sign it for Solaris, the following 3 tests > > seem to fail. I'm not sure if it is related to environment where I run > > the build, or the code. > > prop_tests.py 22: test prop* handle invalid property names > > utf-test 3: test svn_utf_cstring_to_utf8_ex2 > > utf-test 4: test_svn_utf_cstring_from_utf8_ex2 > > > For more details, refer to this build result: > >http://hudson.zones.apache.org/hudson/view/subversion/job/subversion- > > 1.6.x-solaris/49/ > > All these errors are related to converting characters to and from UTF8. It > could be that these characters can't be represented in the system locale or > that the iconv library has limited support for converting from the encoding > used by these specific tests. > > I don't think any of our normal release signers uses Solaris for his > releases, so I don't guess they see this. > > Can you check if you have the same issue with 1.6.6 (or earlier releases) on > this platform. I would guess that it is not a regression, but an existing > problem which is likely outside the subversion code.
sparc solaris machines are slow perfomance on a single thread, but have up to 128 threads. what is the best possibility to run the tests multi-threaded? for http://opencsw.org packaging we had to switch of testing as it does run forever. rupert.
