Update target platform for 2024-12 development cycle

[ptziegler]

No description provided.

[ptziegler]

Great... some of the mirrors are not up-to-date :/

[merks]

Note that I don't expect the p2 metadata from a mirror to be used at all, so if a mirror is missing the following, I'd expect it not to be used:

https://download.eclipse.org/releases/2024-09/202409111000/

But my comments are about what p2 does via it's own repository loading implementation. I think Tycho does quite a bit of its own processing such that my statement might not hold true. Perhaps @laeubi can comment...

[laeubi]

It depends.... if a mirror is used as a P2 mirror, then only artifacts is relevant, if you configure it as a site mirror then metadata would be loaded (quite unlikely in this case).

So is there any particular problem we are facing here?

[ptziegler]

So is there any particular problem we are facing here?

I don't think there is... Tycho itself is sending all requests to https://download.eclipse.org/releases/2024-09, but is then redirected to one of the mirror sites. The baseline check fails because some of the mirrors haven't been updated yet.

I've seen the same problem throughout previous releases and it usually took about a week before everything is synchronized again.

From my naive understanding, Tycho would have to check whether mirror is synchronized with the main repository and then request different mirrors until it gets one that's good. But this clearly falls outside Tycho's responsibility.

[merks]

Here's how p2 works. It gets all the metadata from the URL you specify, It only knows to check for mirrors based on the information in that metadata. So in https://download.eclipse.org/releases/2024-09/202409111000/ the artifacts.jar contains this property:

<property name='p2.mirrorsURL' value='https://www.eclipse.org/downloads/download.php?format=xml&amp;file=/releases/2024-09/202409111000'/>

So it uses this URL to find mirror URLs:

https://www.eclipse.org/downloads/download.php?format=xml&file=/releases/2024-09/202409111000

That returns this:

But that looks wrong to me because this doesn't exist:

https://mirrors.jevincanders.net/eclipse/releases/2024-09/202409111000

That looks like a bug in download.php which should never return a URL for which the requested file= value doesn't exist.

The p2 framework by itself uses only the first couple of URLs listed; the first 4 I think. Oomph's enhancements probes them all and use the fastest ones, so a couple broken ones are generally not a big problem for either.

A help desk issue would be useful.

[ptziegler]

You're right. I've created https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5007

[ptziegler]

But my comments are about what p2 does via it's own repository loading implementation. I think Tycho does quite a bit of its own processing such that my statement might not hold true.

If I understand the implementation correctly, then all of the artifact handling is delegated to p2 and Tycho simply reacts to the response. If p2 detects a bad mirror and returns a RETRY response, then Tycho treats this as a generic error and throws an exception.

I've created eclipse-tycho/tycho#4276 as a PoC, where I improved the handling of such a case.