The file was reconditioned with a Java 1.5 Pack200, and then signed at
Eclipse.org, and then packed again with a Java 1.5 Pack200.
That is a little different than the flow many of us use. Since the
Eclipse.org script also does a re-pack (conditioning) many of us do not do
that before submitting to be signed. While this shouldn't be a problem (to
-repack twice) it might expose some other bug the rest of us do not see.
Hmm, if the signing is Java 6 at Eclipse.org now, could it be that the
repack is Java 6 too?
BUT, you say you can 'manually' unpack and verify the pack.gz file, so I
think it must be more than that.
Any ideas are greatly appreciated. I'm starting to drain out of them.
Ok, you asked, so if it is any ideas you want, here's some more wild ones.
I hate to suggest this to _you_ ... but are you sure the files the build
is "getting" are really in the same repo as the ones you are checking
(i.e. urls in artifacts.xml/jar are correct?
The builder mirrors the files into the buildresult/final/aggregate
repository. I made my checks right there. I also renamed the last
buildresult to buildresult.old so that it doesn't go away in case
anyone else would like to try the same.