I see two failures of jdktools tests, which are not new ones.
Test org.apache.harmony.jpda.tests.jdwp.VirtualMachine.HoldEventsTest is known as intemittently failing on Windows (HARMONY-3508) and now it fails on Linux too. It make sense to move this test to common exclude list. Test mentioned as vmcarsh (org.apache.harmony.jpda.tests.jdwp.ThreadReference.FramesTest) failed due to exceeded timeout for tests run. You may want to increase default timeout (900000 milliseconds), e.g, specifying -Dhy.test.timeout=1200000 . Thanks. Ivan On 6/25/07, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 6/25/07, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2007/6/25, Stepan Mishura <[EMAIL PROTECTED]>: > > On 6/25/07, Mark Hindess wrote: > > > > > > On 25 June 2007 at 13:59, "Stepan Mishura" <[EMAIL PROTECTED]> wrote: > > > > On 6/24/07, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > > > > We have passed our code freeze date for M2 > > > > > > > > > > > > > Mikhail, > > > > > > > > Just to be clear - M1 milestone published snapshots include build for > > > > Windows x86, Linux (libstdc++ v5 and libstdc++ v6) x86 and Windows > > > > x86_64. > > > > > > Do you think it would be possible to produce source snapshots? The > > > Apache release FAQ (at http://www.apache.org/dev/release.html ) says: > > > > > > The Apache Software Foundation produces open source software. All > > > releases are in the form of the source materials needed to make > > > changes to the software being released. In some cases, binary/bytecode > > > packages are also produced as a convenience to users that might > > > not have the appropriate tools to build a compiled version of the > > > source. In all such cases, the binary/bytecode package must have > > > the same version number as the source release and may only add > > > binary/bytecode files that are the result of compiling that version of > > > the source code release. > > > > > > Currently binaries are our primary artifact. I appreciated that it may > > > be a little late to try to correct this for this release, but I think it > > > is important that we try to correct this before we get too comfortable > > > with the current release process. > > > > > > > I'd suggest to switch to using source snapshots right after M2. > > > > > It should now be possible to do: > > > > > > ant bundle_src > > > mkdir /tmp/build > > > tar -C /tmp/build -xzf target/apache-harmony-src-r550411-snapshot.tar.gz > > > cd /tmp/build/harmony-src-550411 > > > ant -Dauto.fetch=true > > > > > > which would seem to me to be more in-keeping with the Apache release > > > guidelines. > > > > > > On this subject, I'd like to permission to commit a patch to correct the > > > top-level directory name in the source tar.gz/zip files from: > > > > > > harmony-src-550411 > > > > > > to: > > > > > > apache-harmony-src-r550411 > > > > > > > I'm OK with it. > > will it require rebuild of the release candidate? > I think it is not required. OK, I've built and uploaded milestone candidates (r550333) for - Linux x86/x86_64 libstdc++ v5 (and v6 for x86 is in progress) - Windows x86/x86_64 The snapshots are available from "snapshots v5" page[1] (or can be taken from dir [2]) [1] http://harmony.apache.org/snapshots_v5.html [2] http://people.apache.org/builds/harmony/snapshots/r550333/ -Stepan. > Thanks, > Mikhail > > > > > Thanks, > > Stepan. > > > > > The format of the archive names changed over time and these have become > > > inconsistent. > > > > > > Regards, > > > Mark. > > > > > > > I assume that we still aimed to x86 architecture and I need to build > > > > milestone candidates for: > > > > - Windows x86 > > > > - Linux x86. BWT, again for both libstdc++ versions? > > > > > > > > And what about x86_64? > > > > > > > > As I said M1 includes Windows x86_64. Should we publish them to let > > > > the community test them to see how good they are? > > > > > > > > Thanks, > > > > Stepan.
