Bugzilla – Full Text Bug Listing
| Summary: | Equinox Compatibility Patches do not seem to be properly signed. | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Alexander Nyßen <nyssen> |
| Component: | RelEng | Assignee: | gef-inbox <gef-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | david_williams |
| Version: | 0.2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Alexander Nyßen
Here's the complete error message: An error occurred while collecting items to be installed session context was:(profile=epp.package.committers, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). Multiple problems occurred while downloading. Problems downloading artifact: osgi.bundle,org.eclipse.gef4.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7457880507044461912.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7457880507044461912.jar Problems downloading artifact: osgi.bundle,org.eclipse.gef4.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5074217657245975713.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5074217657245975713.jar Multiple problems occurred while downloading. Problems downloading artifact: osgi.bundle,org.eclipse.gef4.mvc.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7020954809902842649.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7020954809902842649.jar Problems downloading artifact: osgi.bundle,org.eclipse.gef4.mvc.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5010596054604478205.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5010596054604478205.jar Multiple problems occurred while downloading. Problems downloading artifact: osgi.bundle,org.eclipse.gef4.mvc.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile629029059806255831.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile629029059806255831.jar Problems downloading artifact: osgi.bundle,org.eclipse.gef4.mvc.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7792771402163740603.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile7792771402163740603.jar Multiple problems occurred while downloading. Problems downloading artifact: osgi.bundle,org.eclipse.gef4.zest.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5392554893713329820.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5392554893713329820.jar Problems downloading artifact: osgi.bundle,org.eclipse.gef4.zest.fx.compatibility.equinox,1.0.0.201605231620. Error reading signed content:/var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5207867547267376612.jar An error occurred while processing the signatures for the file: /var/folders/l2/mg3jhbmx7kd06ksqzwr_lg6w0000gp/T/signatureFile5207867547267376612.jar One question that comes to mind is the version of Java you are using when you do your build -- and when you do the "signing". Do these go through the "batch process" of signing? (After the build?) Or, is it a maven based build where the jars are signed "as they are built"? I am *guessing* even though not obvious from the error messages that there is a *jar.pack.gz" file for each of these fragments? If so, the "error" is likely in the pack200 step, not so much the jar signing itself. One final question. I assume these are jars you "build fresh"? Or are they some "binary" version, already processed to some degree and you may be trying to resign them again? If you provide this data I (or others) can probably help more. (In reply to David Williams from comment #2) Thanks for the quick response, David! > One question that comes to mind is the version of Java you are using when > you do your build -- and when you do the "signing". > > Do these go through the "batch process" of signing? (After the build?) > > Or, is it a maven based build where the jars are signed "as they are built"? They are build using Maven/Tycho based on the following config: <profile> <id>hudson.eclipse.org</id> <build> <plugins> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-compiler-plugin</artifactId> <version>${tycho.version}</version> <configuration> <useJDK>BREE</useJDK> <compilerArgument>-warn:+discouraged,forbidden</compilerArgument> </configuration> </plugin> <plugin> <groupId>org.eclipse.tycho.extras</groupId> <artifactId>tycho-pack200a-plugin</artifactId> <version>${tycho.version}</version> <executions> <execution> <id>pack200-normalize</id> <goals> <goal>normalize</goal> </goals> <phase>verify</phase> </execution> </executions> </plugin> <plugin> <groupId>org.eclipse.cbi.maven.plugins</groupId> <artifactId>eclipse-jarsigner-plugin</artifactId> <version>${cbi-plugins.version}</version> <executions> <execution> <id>sign</id> <phase>verify</phase> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>org.eclipse.tycho.extras</groupId> <artifactId>tycho-pack200b-plugin</artifactId> <version>${tycho.version}</version> <executions> <execution> <id>pack200-pack</id> <goals> <goal>pack</goal> </goals> <phase>verify</phase> </execution> </executions> </plugin> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-p2-plugin</artifactId> <version>${tycho.version}</version> <executions> <execution> <id>p2-metadata</id> <goals> <goal>p2-metadata</goal> </goals> <phase>verify</phase> </execution> </executions> <configuration> <defaultP2Metadata>false</defaultP2Metadata> </configuration> </plugin> </plugins> </build> </profile> The Tycho config has not changed since 0.2.0, where the signing was still successful, but I think we still used the Java 6 jar signer back then (passed via option to the build). > > I am *guessing* even though not obvious from the error messages that there > is a *jar.pack.gz" file for each of these fragments? If so, the "error" is > likely in the pack200 step, not so much the jar signing itself. Yes, there is a pack.gz for each of them. > > One final question. I assume these are jars you "build fresh"? Or are they > some "binary" version, already processed to some degree and you may be > trying to resign them again? They are build fresh from the sources. > > If you provide this data I (or others) can probably help more. gef4-master is executed using jdk1.8.0.latest, but interestingly I get the same errors when trying to install them from those artifacts produced by gef4-master-JavaFX-2.2.Eclipse-Luna, which runs with jdk.1.7.0.latest, so I assume the problem is not directly related to the Java version that we use for executing the build. (In reply to Alexander Nyßen from comment #4) > gef4-master is executed using jdk1.8.0.latest, but interestingly I get the > same errors when trying to install them from those artifacts produced by > gef4-master-JavaFX-2.2.Eclipse-Luna, which runs with jdk.1.7.0.latest, so I > assume the problem is not directly related to the Java version that we use > for executing the build. The maven (web service) jar signer I believe always uses Java 8 to sign with. Are you seeing these errors in the aggregator (for Sim. Release) or when you try to install? I'll assume the aggregator since hard to see when just trying to install. The aggregator uses Java 8 to "unpack200" the jar.pack.gz files. So, if seeing an error, in that case (when both Java's are Java 8), I'd recommend just not "packing" them. Tycho (I am pretty sure) does recognize the eclipse.inf file option of jarprocessor.exclude.pack=false https://wiki.eclipse.org/JarProcessor_Options (It does not recognize all eclipse.inf options.) So, I'd try that first. = = = = = For "more than you want to know" there are ways to find out *why* the pack200 is failing and in principle those can sometimes be fixed by other options to the Java's pack200 (such as to specify -E4 (default is 5) so a little less "effort" is used to pack them. And, many more specific options, such as to exclude a certain method from packing. Since all four fragments "fail", I suspect there is some similar method in each that unpack200 just does not handle correctly. These are often oddball cases like a method in an inner class which sets a static variable in the outer class (just to make up something). But, since not critical to pack200 each and every bundle, I'd say just skip these. (They are probably small anyway?) = = = = = = If Tycho won't recognize the eclipse.inf option I mentioned above, so they still end up "packed", then there are ways to remove them from the repository "after the fact" from your repository. If you need that, please say, and I'll point you to an example script. It seems that the eclipse.inf did the trick. As the fragments do not contain any sources (but just a manifest), I think its safe to have them unpacked. Resolving as fixed in 4.0.0 RC2. Thanks for your help, David! |