Declare 4.32 RC1 #2044
Comments
|
JDT Core needs time for analysis of two issues found very late:
We are working on that. |
|
FYI, we have a bit of a disaster on your hands that pretty much affects everyone. In particular, this build failing alerted me to the problem: https://ci.eclipse.org/oomph/job/repository-analyzer/lastCompletedBuild/testReport/ The signing certificate has expired and so content is being signed by a certificate after it has expired, making the signature invalid: |
Ed, could you please create dedicated ticket for that? Does it affect every bundle we ship or only few recently (or not recently) changed etc? |
|
I created the following general ticket since this affects everyone: eclipse-simrel/simrel.build#363 This link shows the affected artifacts: https://ci.eclipse.org/oomph/job/repository-analyzer/lastCompletedBuild/testReport/ As far as I'm concerned this is a stop ship issue. We cannot less artifacts work their way into bundle pools where they will fester and cause problems forever. |
|
I'm concerned that this problem is very likely to recur now that we (will) have new certificates: https://bugs.eclipse.org/bugs/show_bug.cgi?id=531640 Specifically the org.eclipse.core.runtime package is split across three bundles and these bundles must all be signed by the same certificate:
So the problem might not immediately happen, but as soon as one of those bundles produces a new version with a new signature, then all three bundle will need to use that new certificate and will need a new version. We might be best off to proactively force new versions of these three, versions that do not differ only in qualifier because either all three should be published newly to Maven central on none of the three. How best to proceed? |
Do we only have three bundles with split packages in SDK, or only these are affected by certificate changes?
Assuming we have already new certificates:
|
|
Good question. I thought the SDK4Mvn.aggran decorated all split packages with ** but now I see that's not the case:
This search helps find such things:
Assuming they have been declared in a consistent similar way. It's typically only the bundles that are used in a restrictive runtime that cause the signing problem, not in the IDE itself. I will see if I can improve the tool to produce a better list... |
|
It's hard to make a really good list. Here's an exhaustive list with red herrings included:
|
This doesn't include some bundles that I would expect. For example, I would expect
|
|
On the left are the package names/versions and on the right is the bundle contributing it. So I think this is correct and expected isn't it?
|
|
@merks : if you could create a list of bundles grouped per repo, we could start preparing PR's. |
Ah, yes it is. Thank! So next step is to touch each of these bundles? |
|
Even though @merks mentioned it already I wanted to make it clear again because it was mentioned twice now. the bundles not need to be touched, the need to increment the micro version at least! |
|
It's probably easier for me to make the changes than to describe where each thing is located. I.e., I can just do a search in my Oomphed SDK workspace for this regex to find the bundle and then change the version:
I don't know the JDT structure as well. Should we do all the ones listed? Or ignore the batch compiler duplicates. I'm not 100% sure, but if the minor version has already been incremented in this release cycle then nn probably just a forced qualifier change is enough; the minor increment during this current cycle is only needed if we want to be 100% sure the artifact is newly published to Maven central... |
I'm not 100% either ... I assume above you mean any version change, not just minor. A micro version change for this cycle should be enough and not require another micro version bump, just the qualifier bump when we touch the bundle. If no version has change has been made this cycle yet then we MUST increment the micro version for the bundle so that it is published with the right certificate to match the certificate of the other bundles that provide the "parts" of the split package. |
There shouldn't be batch compiler duplicates. What exactly is not clear for JDT? I assume you only want check https://github.com/eclipse-jdt/eclipse.jdt.ui.git and https://github.com/eclipse-jdt/eclipse.jdt.core.git repos. |
|
Yes, that matches my understanding. So this is how I am proceeding.
I check manifests of the bundles with the split packages. Check if the version has at least a minor increment, double check the previous release's p2 metadata to be 100% sure there was at least minor increment, and when that's the case, copy this issue into the forceQualifierUpdate.txt. |
|
This looks potentially like a split package:
But is really just the bundle exporting its import. It's a bit confusing to me, but I assume this is not a split package case. |
That is a split package if |
This package contains classes in both bundles, so it is a split package. |
|
Did I mention how evil split packages are? The use if |
|
|
|
Back on topic, this on the other hand is a split package, but it doesn't provide information about that in the package exports:
So package imports would work very poorly for this, and we'd likely never find this case with a tool (that unfortunately also produces false positives right now). I feel a little like the janitor left is charge after the sewage system has gotten backed up. 😱 😬 |
|
I remake the list with check boxes so I can keep track of which are done. The
|
|
Ed, should fragments also be touched together with host bundles? |
|
It wouldn't hurt. Which fragments did you have in mind? |
|
SWT, equinox launcher and platform file system. |
|
I think the only candidate (a fragment for which the host is touched) is this one:
FYI, all the increments turned out to be touches not actual version increments. Now I will create draft PRs for all the affected repos now, and touch this one too. Good thinking on your part! ❤️ We should only merge them after the certificate is available for use, which seems to be stalled. |
|
If they are baseline replaced from a previous I-build (with bad signatures), rather than from the previous release (with good signatures), then they must necessarily have had a non-qualifier increment. 😬 |
Indeed, that makes sense. 😅 All SWT binaries have been rebuilt and have a new qualifier: |
|
I see this was killed: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/565/ This just finished: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/566/ But this just started: https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/master/567/ I'm not sure what's going on. 😕 FYI, I am able to kick off build when the time is right: |
Yes, this was the known problem that builds get sometimes killed.
A second build is not necessary because it is caused by the just built binaries that are pushed to the master branch by the releng.bot and therefore it is aborted since the event cannot be supported (at least I don't know how): So all is fine now.
At least from SWT point of view everything should be fine now. If everything else is also fixed, please go ahead and trigger an I-build. |
|
Okay the SWT thing detected it wasn't needed and completed. Therefore I've started this build: https://ci.eclipse.org/releng/job/Builds/job/I-build-4.32/121/ |
We have already Scheduled IBuild at 6am EST , if build 121 build is fine then will cancel scheduled build. |
|
Oh dear, my "source" removal from the list overlooked that this one has "source in the name too:
😱 So there is one problem left. 😭 |
|
I kicked of this build: https://ci.eclipse.org/releng/job/Builds/job/I-build-4.32/122/ What could go wrong now? 😖 |
|
The gremlins are still busy. The build fails like this:
Maybe something else needs an increment? Maybe a hick-up? I'm need to run in the next half hour and I will only have my phone available after that, so very, very limited what else I can do to help. I can maybe test a repo given the URL... I will kick off another build assuming it's a glitch, but if someone else knows better, cancel it and correct whatever needs correcting... |
Further above the qualifier for the I have just created #2047. |
|
It should be done in just minutes. |
|
I get the sense that all builds are taking much longer the last days. Maybe just kill it and proceed. This is like watching grass grow. |
|
After 3 hours it got past where it failed last time. Just as a watched kettle never boils, grass grows slower when watched. |
Yes, but finally it passed. 🎉 |
|
New RC1 Candidate Eclipse downloads: Build logs and/or test results (eventually): Software site repository: Specific (simple) site repository: Equinox downloads: |
Declare 4.32 RC1
A "go" is needed from all the components below to declare this milestone.
Current Candidate
Eclipse downloads:
https://download.eclipse.org/eclipse/downloads/drops4/I20240522-1800
Build logs and/or test results (eventually):
https://download.eclipse.org/eclipse/downloads/drops4/I20240522-1800/testResults.php
Software site repository:
https://download.eclipse.org/eclipse/updates/4.32-I-builds
Specific (simple) site repository:
https://download.eclipse.org/eclipse/updates/4.32-I-builds/I20240522-1800
Equinox downloads:
https://download.eclipse.org/equinox/drops/I20240522-1800
Deadlines:
Friday, 2024- May -24, around 1 AM (Eastern): deadline for sign-off (or, by then, comment in this issue when you expect to sign-off).
Friday, 2024 -May - 24, around 3 AM (Eastern): promote approved build to S-4.32RC1-*, contribute to simultaneous release repo, and announce to mailing lists.
Remember to investigate and document here any failing JUnit tests.
The text was updated successfully, but these errors were encountered: