Andrew Niefer wrote:
Could the pack.gz file hav been
created
with Java 1.6?
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.
An interesting observation is that the signer seems to be using Java
1.6. But that should be true for all projects (this is the top of the
ECLIPSE.SF file):
Signature-Version: 1.0
SHA1-Digest-Manifest: jHnvFjNM4/Rn9koUBVOpVOoWEJY=
Created-By: 1.6.0 (IBM Corporation)
SHA1-Digest-Manifest-Main-Attributes: UxN2vuHWF3kmruwHHkDdtAxBZQ4=
unless this changed very recently of course so that only newly signed
projects are affected. Could that be the case?
- thomas
I don't know if this
makes a difference
here since it is complaining about a manifest and not a .class file.
I assume that buckminster.maven
contains
some classes, so the pack200 tool should output a 1.5 compatible file
(assuming they aren't 1.6 classes).
But the signing and conditioning
were
done with java 1.5.
-Andrew
I have a major problem with the P2 mirroring in
Galileo
Builder. I would
really appreciate some help pinning it down.
The problem occurs during the mirroring phase. A RawMirrorRequest is
executed to fetch a xxx.jar.pack.gz file and it succeeds without
problems. Next, I try to unpack this jar as a sibling. This also
succeeds on most files, but not all. The problem manifests itself like
this:
org.eclipse.core.runtime.CoreException: Unable to unpack artifact
osgi.bundle,org.eclipse.buckminster.maven,1.1.350.r10157 in repository
file:/shared/galileo/buckyBuild/buildresults/final/aggregate: Error
reading signed content:/tmp/signatureFile5703.jar
Caused by: java.security.SignatureException: Either the manifest file
or
the signature file has been tampered in this jar:
/tmp/signatureFile5703.jar
It only manifests itself when running Java 5 on the build machine (a J9
for ppc). If I run the same build locally on my machine, pointing to
the
exact same repository, everything is fine. Moreover, to verify the
consistency of the file on the actual machine where it fails, I tested
using unpack200 (from the same JVM). That completes without problems
and
leaves a resulting jar file. I checked this jar file with jarsigner
-verify <jar> and it claims the file is OK.
So what can happen here that makes P2 complain when unpacking? And why
only with one particular VM? Any ideas are greatly appreciated. I'm
starting to drain out of them.
- thomas
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
|
