The 3.5M5 Eclipse and Equinox builds, as well as the new and noteworthy have been replicated to eclipse.org. The milestones p2 repo has the M5 bundles available.
M5 wasn’t without drama. Late Friday afternoon, the UI team asked for a rebuild toward 3.5M5 to include a new splash screen. How could this go wrong? A rebuild with one file change. What could be simpler?
I woke up on Saturday morning confident that the build would be ready to promote. Instead of quality time with my laptop I’d be able to spend time snowshoeing with my favourite mathematician. Unfortunately, this was not to be. The build was missing the eclipse executables (eclipse.exe, eclipsec. exe etc). Hmm, I don’t think this is a cosmetic bug. One file change and the executables went away? This seems like overkill.
When running the p2 director to provision the bundles for the build from the repo, there were signing errors in the .logs. I ran a test build with signing. The build had the same error. I ran a test build without signing. The executables were back. I ran jarsigner -verify on the bundles on a signed build. The junit 3.8.2 bundle had a signing error in the manifest. Interestingly enough, Denis had changed the signing certificate on eclipse.org on Friday.
At this point I suspected the problem was that the Orbit bundles were signed by the old certificate and the new bundles that we had just compiled in our build were signed in the old certificate. We resign the Orbit bundles in our build. (I’ve opened this bug to avoid this in the future).
Martin Oberhuber and David Williams ran a Orbit build on Sunday night which was signed by the new certificate. I ran a test build with this new build. The executables were back! Monday morning I promoted an Orbit build to Stable, and started a new build toward M5. Andrew Niefer determined that the root cause of the problem was that the junit bundle had a nested jar with a bogus signature. The end was near of this milestone saga! I could finally start releasing my patches that I had prepared for M6.
I was pinged on IRC by a certain PDE committer from Austin who will remain nameless. “Kim? Is there another build toward m5?” This PDE bug was approved by the PMC for inclusion in M5 yesterday afternoon. Another rebuild.
Here are the bugs with the details.
Certificate will expire within six months.
JUnit jars should exclude nested jars from signing and packing
[jarprocessor] Should we be signing nested jars?
I’ll celebrate the release of M5 with a cookie. Enjoy.
At least there wasn’t a 3.5 M5a 😉
M5a is such a great Eclipse tradition though. We simply must find a reason for it as soon as possible. I’m doing my best right now…
Ed, please keep your “great traditions” in the modeling project 😉
I’ve done everything I could to get us an M5a. I have failed.
Kim, thank you so much for doing a great job! It sure must be annoying to spoil your weekend with releng work…
Denis, I celebrate your failure.>>Peter, you’re welcome.
I think Chris should be punished severely.
Upgrade via p2 doesn’t work as always. I can’t remember even smallest upgrade of smallest bundle being successful using p2. There is always something wrong with dependencies and I can’t perform upgrade of anything. Maybe that’s because I use unstable versions of Eclipse’s bundles. It’s ironic, because unstable versions need upgrades the most.
Seweryn, Please open a bug with the problem you are seeing against RT->Equinox->p2