Hi, I see my build failing and succeeding at will because of pack200 problems. So I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=465527
Tom On 24.04.15 16:26, David M Williams wrote: > Might be related. I can't look much now, need to be offline a few > hours, but suggest anyone having trouble with signing or packing to open > a cross-project bug, and I'll try to look at this afternoon. > > Be sure to specify what builder and which VM version all parties use. > > Thanks, > > > > > > > From: Wim Jongman <[email protected]> > To: Cross project issues <[email protected]>, > Date: 04/24/2015 09:21 AM > Subject: Re: [cross-project-issues-dev] Notice of change to batch > "signing service" - reverted > Sent by: [email protected] > ------------------------------------------------------------------------ > > > > David, Nebula got a report from a user that his build no longer works > [2]. Does this relate to the changes of the signing service? > > I have added the eclipse.inf file but that did not make a difference [1] > > [1] **************************************** > Thanks for investigatio but the build is still broken - sorry to say. > Ist there a chance to sign with SHA-1 instead of SHA-256? > > Caused by: java.lang.RuntimeException: "Messages while trying children > repositories.": ["": ["Problems downloading artifact: > osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504221032.": > ["Error reading signed > content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6052487094287027653.jar"]]] > > > > > [2] ***************************************** > > I'm using nebula gallery widget and get follwowing errors since April, 15th. > > It seems that signing has changed between version 0.6.0.201504080923 and > 0.6.0.201504150758 from SHA1-Digest to SHA-256-Digest. > > What are the consequences and implications for users? How can I get my > project compiling again? > > Thanks in advance > > Maven-Output > > [INFO] Downloading org.eclipse.nebula.widgets. > gallery > [INFO] Fetching > org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (0B of > 114,42kB at 0B/s) from > _http://download.eclipse.org/technology/nebula/snapshot/plugins/_ > [INFO] 1 operation remaining. > [INFO] Fetching > org.eclipse.nebula.widgets.gallery_0.6.0.201504200907.jar (4kB of > 114,42kB at 0B/s) from > _http://download.eclipse.org/technology/nebula/snapshot/plugins/_ > [ERROR] Internal error: java.lang.RuntimeException: "Messages while > trying children repositories.": ["": ["Problems downloading artifact: > osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200 > 907.": ["Error reading signed > content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]] > -> [Help 1] > org.apache.maven.InternalErrorException: Internal error: > java.lang.RuntimeException: "Messages while trying children > repositories.": ["": ["Problems downloading artifact: > osgi.bundle,org.eclipse.nebul > a.widgets.gallery,0.6.0.201504200907.": ["Error reading signed > content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]] > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:168) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: java.lang.RuntimeException: "Messages while trying children > repositories.": ["": ["Problems downloading artifact: > osgi.bundle,org.eclipse.nebula.widgets.gallery,0.6.0.201504200907.": ["Erro > r reading signed > content:C:\Users\fgdrf\AppData\Local\Temp\signatureFile6731347807242863988.jar"]]] > at > org.eclipse.tycho.p2.impl.resolver.ResolutionContextImpl.downloadArtifacts(ResolutionContextImpl.java:515) > at > org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:105) > at > org.eclipse.tycho.p2.impl.resolver.P2ResolverImpl.resolveProject(P2ResolverImpl.java:69) > at > org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.doResolvePlatform(P2TargetPlatformResolver.java:342) > at > org.eclipse.tycho.p2.resolver.P2TargetPlatformResolver.resolvePlatform(P2TargetPlatformResolver.java:162) > at > org.eclipse.tycho.core.resolver.DefaultTychoDependencyResolver.resolveProject(DefaultTychoDependencyResolver.java:85) > at > org.eclipse.tycho.core.maven.TychoMavenLifecycleParticipant.afterProjectsRead(TychoMavenLifecycleParticipant.java:91) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > ... 11 more > > _______________________________________________ > nebula-dev mailing list_ > [email protected]_ <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit_ > __https://dev.eclipse.org/mailman/listinfo/nebula-dev_ > > On Tue, Apr 14, 2015 at 5:56 PM, David M Williams > <[email protected]_ <mailto:[email protected]>> wrote: > Since I sent the original notice, guess it is up to me to send this one. > > The Eclipse Foundation has decided to revert this change. > > Details in *_Bug 463510_* > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510> > > I do not know that their plan is, nor do I know what to recommend to > anyone, at this point. I guess ask in *_Bug 463510_* > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>, if anyone does > have questions. > > > > > > From: David M Williams/Raleigh/IBM@IBMUS > To: Cross project issues <[email protected]_ > <mailto:[email protected]>>, > Date: 04/11/2015 02:02 PM > Subject: Re: [cross-project-issues-dev] Notice of change to batch > "signing service" > Sent by: [email protected]_ > <mailto:[email protected]> > ------------------------------------------------------------------------ > > > >> ... we are using Tycho for our builds, but our jobs provide the > following option when calling Maven >> (which seems to be used by a couple of other hudson jobs as well; >> it was probably recommended in some instructions I don’t remember): > >> > -Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin" > >> I assume we will have to adopt this to something like the following > then, right: > >> > -Dorg.eclipse.update.jarprocessor.pack200="/shared/common/jdk1.8.0_x86-latest/jre/bin“ > > This was probably recommended because you were using Java 7 or 8 to "run > your build" but it was determined to "minimize issues" to use the lower > version of pack200 (Especially when many users or pre-reqs were using > Java 6). So, a) yes, eventually you'll "minimize issues" by using jdk 7 > or 8 version, but b) that should be "automatic" if you are using Java 7 > or 8 to run your builds, so I'd try leaving it out .. perhaps commented > out, for when you need it again when you move to Java 9 :) > > As far as checking yourself, Ed has already described one basic > procedure. The b3 aggregator will also check, but only if you select the > "build" option, which can take a long time, if you are trying to build > the whole Sim. Release. It is possible, though, so set up your own b3 > aggregator job (just for testing) that uses only your contribution, plus > the minimum number of "prereq" contributions. It is not exactly easy to > set this up -- the first time -- but, once set up, is relatively easy to > keep up to date. > > One more: There are some bash scripts in the sim release test project, > that are not very efficient, but are an easy way to check a whole > directory of jars and pack.gz jars. Those two scripts are _verify.sh_ > <http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verify.sh>and > _verifydir.sh_ > <http://git.eclipse.org/c/simrel/org.eclipse.simrel.tests.git/plain/bundles/org.eclipse.simrel.tests-bundle/verifydir.sh>(both > need to be in your on your path, and you execute verifydir.sh (and it > calls verfiy.sh). You may need to make your own copy and adjust for your > system, and your needs. > > Another almost-off-topic tidbit: Many are surprised they "have errors" > because they have tested "installing" or "updating" using p2, and it > works fine. The reason is that p2 tries it's best to "recover from > errors" so often if there are problems with *.jar.pack.gz, then it will > simply try the *.jar file directly, which would work. But, for our Sim. > Release repo (and should for all repos) we want the repo to be "perfect" > and not allow it to contain "badly packed" jars. Doing so ends up > causing "extra downloads", and wasting users time when they do an update. > > I realize it is not easy to get a "perfect repo", it takes extra effort, > but that's part of the whole purpose of having or joining the Sim. > Release, so everyone's extra effort is acknowledged, and appreciated. > > Thanks for the questions! > > > > > > From: Alexander Nyßen <[email protected]_ <mailto:[email protected]>> > To: Cross project issues <[email protected]_ > <mailto:[email protected]>>, > Date: 04/11/2015 03:59 AM > Subject: Re: [cross-project-issues-dev] Notice of change to batch > "signing service" > Sent by: [email protected]_ > <mailto:[email protected]> > ------------------------------------------------------------------------ > > > > David, > > I admit I am not very acquainted with the internals of signing and > pack200. However, we are using Tycho for our builds, but our jobs > provide the following option when calling Maven (which seems to be used > by a couple of other hudson jobs as well; it was probably recommended in > some instructions I don’t remember): > > -Dorg.eclipse.update.jarprocessor.pack200="/shared/common/sun-jdk1.6.0_21_x64/jre/bin" > -Xmx768m > > I assume we will have to adopt this to something like the following > then, right: > > -Dorg.eclipse.update.jarprocessor.pack200="*/shared/common/jdk1.8.0_x86-latest*/jre/bin“ > > > Is there a way to confirm that a build behaves as expected (do the > sim-rel repo-reports for instance cover this)? > > Cheers > Alexander > > Am 11.04.2015 um 08:48 schrieb David M Williams > <[email protected]_ <mailto:[email protected]>>: > > I wanted to let everyone know that "we" are changing the version of > Java's pack200 at the infrastructure service I call "batch signer". > (*_Bug 463510_* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>) > It was using Java 6 level of pack200, and we have moved to the Java 8 > level of pack200. > > This command is described at _ > __https://wiki.eclipse.org/IT_Infrastructure_Doc#ZIP_and_JAR_files_from_the_Commandline_.28Queued.29_ > > This does not directly impact Tycho users or Buckminster users (which do > their own re-pack and pack, based on the VM the build is running, I > assume) but might effect PDE users, which traditionally have used this > service to "re-pack" (condition) and sign jars -- and, then at some > short later time are "packed". At that "some later time", it is the > release engineers responsibility to use the same version to 'pack' as > was used to 'repack'. > > While no direct impact to Tycho or Buckminster builders, the principles > and consequences of moving from one level (Java 6) to another (Java 8) > apply with any builder, so the following points may be useful > information to all. > > If you have "old byte codes", or, even new ones, compiled at the Java 4, > Java 5, or Java 6 level, you *might* find some of those bytes codes no > longer survive the "re-pack", sign, and "pack" process (where as maybe > the would survived, when using Java 6 to run your build (and hence your > repack/pack). That is, if user tries to download the pack.gz file, and > unpack into a normal jar, it may be reported to have in "invalid > signature" or in some other way "broken". > > In my experience, with Orbit jars, the "error rate" is about 1.7%. > Others, for some unknown reason, see higher rates (such as 20-30%?) . > Some of these cases *might* be bugs in the pack/unpack programs, but > it's just as likely that there are "bugs" (fringe cases) where the byte > codes for lower levels of Java are not quite "right". All I know for > sure: it has never been perfect. > > But, luckily, easy to solve. > All three builders (PDE, Tycho, and Buckminster) allow you to specify an > 'eclipse.inf' file in the META-INF directory, with a directive (line) > that is: > jarprocessor.exclude.pack*=true* > > Thus, that one problematic jar is not packed, but is still signed. > > So important point 1: be sure you "pack200" with the same version you > used to do "repack" (if the builder doesn't do it for you automatically). > Important point 2: I wouldn't recommend studying the byte codes and > trying to find a pattern of code that is the cause (unless you just > happen to love byte codes), ... just slap in an eclipse.inf file and > move on to more important things. > Important point 3: You should not, ever never, "re-sign" and certainly > not re-pack or pack200 a jar that has already been signed or processed > by pack200. That pretty much guarantees the jar will be broken. In more > ways than one. (*_Bug 461669_* > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=461669>) > > The reason for making this move, now, is that it is best to "keep up" > with what our users are using, and, with versions of Java that are > expected to stay in service for a while ... otherwise, we might have to > monkey around with this during a service release, which is less than ideal. > > * Bonus, for reading this far in my wordy note: Why jump two levels, > from 6 to 8, why not move to Java 7 first? Well it turns out, at the > moment, the versions of pack200 and unpack200 that ship with Java 7 and > Java 8 are _exactly the same_ > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510#c27>. But, the > advantage is, in some service release, there might be a new version and > we'd pick it up automatically, as long as we use > */shared/common/jdk1.8.0_x86-latest* consistently. Double bonus: > remember that pack200 and unpack200 have little to do with Java source > code they are stand-alone executables, written in C-code, that simply > manipulate byte codes. Which is how p2 can let you _specify any version > of pack200 you want_ > <https://wiki.eclipse.org/JarProcessor_Options#Other_properties>, no > mater which version of Java you are using. > > Naturally, feel free to comment in *_Bug 463510_* > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=463510>if any questions > or concrete problems known. > > > > > _______________________________________________ > cross-project-issues-dev mailing list_ > [email protected]_ > <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit_ > __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ > > -- > Dr. Alexander Nyßen > Dipl.-Inform. > Principal Engineer > > Telefon: _+49 (0) 231 / 98 60-202_ > <tel:%2B49%20%280%29%20231%20%2F%2098%2060-202> > Telefax: _+49 (0) 231 / 98 60-211_ > <tel:%2B49%20%280%29%20231%20%2F%2098%2060-211> > Mobil: _+49 (0) 151 / 17396743_ > <tel:%2B49%20%280%29%20151%20%2F%20%C2%A017396743>_ > > __http://www.itemis.de_ <http://www.itemis.de/>_ > [email protected]_ <mailto:[email protected]> > > itemis AG > Am Brambusch 15-24 > 44536 Lünen > > Rechtlicher Hinweis: > > Amtsgericht Dortmund, HRB 20621 > > Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, > Jens Trompeter, Sebastian Neus > > Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Michael Neuhaus, Jennifer > Fiorentino > > > [attachment "signature.asc" deleted by David M Williams/Raleigh/IBM] > _______________________________________________ > cross-project-issues-dev mailing list_ > [email protected]_ > <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit_ > __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev________________________________________________ > cross-project-issues-dev mailing list_ > [email protected]_ > <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit_ > __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ > > _______________________________________________ > cross-project-issues-dev mailing list_ > [email protected]_ > <mailto:[email protected]> > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit_ > __https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_ > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > > > _______________________________________________ > cross-project-issues-dev mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
