[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Galileo mirroring problem. Need help!
|
> 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.
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? Also ... since this seems to
happen for buckminser, and buckminster is currently installed in the
Platform that is running the build, any chance that is causing some
mix-up? We seemed, for a while, to see issues when the "legacy update
site" support was being used for one site, where the whole site was
downloaded and meta data was being re-generated ... any chance similar
issues are coming into play here? I know you don't specify a 'site.xml' in
your url ... but, if there is a local, installed version available also
then maybe ... I don't know, sounds crazy.
From:
Thomas Hallgren <thomas@xxxxxxx>
To:
P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:
05/08/2009 12:20 PM
Subject:
Re: [p2-dev] Galileo mirroring problem. Need help!
Sent by:
p2-dev-bounces@xxxxxxxxxxx
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
Thomas Hallgren <thomas@xxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx
05/08/2009 11:45 AM
Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>
To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
[p2-dev] Galileo mirroring problem. Need help!
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
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
