Hi,
as we noticed last week, CDT's target file (cdt-e4.5.target) is pointing to an old Orbit version, labelled Luna SR1. I haven't dealt with Orbit before. Should we use the Mars version? That seems to be the right thing to do based on David Williams recent
mail (see below).
What is the process to handle orbit? Should I make 'check Orbit version' a part of our RC1 build process from now on? (see https://wiki.eclipse.org/CDT/release_engineering#How_do_we_release_builds.3F)
If we upgrade that version now for 8.7/Mars, I'll re-spin RC3 to provide more soak time.
Any recommendations?
Marc
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [cross-project-issues-dev-bounces@xxxxxxxxxxx] on behalf of David M Williams [david_williams@xxxxxxxxxx]
Sent: June 1, 2015 5:07 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Status of Mars "repo report" results
Also, I should remind everyone to use the latest repository from Orbit (R20150519210750).
We've had one bug report that the latest from Orbit is not being used (Bug 468505) and it's is unclear
if there is a reason for it ... or if things will break for anyone trying to use the latest from Orbit, along with things from Mars (that happen to use the same logging fragment/framework where this was noticed).
Thanks,
From: David M Williams/Raleigh/IBM@IBMUS
To: cross-project-issues-dev@xxxxxxxxxxx,
Date: 06/01/2015 03:13 AM
Subject: [cross-project-issues-dev] Status of Mars "repo report" results
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
I've fixed (most of) the URLs of the "repo report". You can get to the most recent one from the most recent successful clean build, at
Repo Reports from last successful
CLEAN BUILD
That link is always at the top of the "Sim Release" Hudson instance ( https://hudson.eclipse.org/simrel/ )
One surprise, something we don't see often (don't think I ever have for this repository) is that someone is contributing an "invalid jar" to the repo ... normally this comes in the form of an invalid *jar.pack.gz, but this time, the rare event, is it only
the *.jar file. (No pack.gz file is provided, or else the b3 aggregator would fail).
And it is for a new bundle from Orbit,
org.mozilla._javascript__1.7.5.v201504281450.jar
(And, yes, I checked Orbit, and it is correct in that repository).
See Jars
that fail to verify (if any)
(which does not have much information, actually, but I documented in the bug how to see more.
I have opened Bug 467449
to track this issue.
= = = == =
Other reports that deserve special attention (AFAIK, there are bugs opened for these already).
- Missing legal files: Bundles
missing required files
- Unsigned jars (just a few left): Unsigned
bundles and features
- BEPL and GMT have features and plugins, still, that *decrease* in version number from Luna SR2a
Feature versions
compared to reference repository
Bundle versions compared
to reference repository
- As far as "multiple versions of same plugin", I think that report is looking fair (i.e. most cases are legitimate) but there is one case that really stands out: Use of
org.apache.batik.dom at the 1.6.0 level. We went to a lot of effort to replace that one with 1.6.1 (for security fix), so, please, get it out of your builds and your own repositories, and
make sure Sim. Release repo does not have it. See
List of non-unique
versions
org.apache.batik.dom
1.6.0.v201011041432
1.6.1.v201505192100
1.7.1.v201505191845
org.apache.batik.dom.source
1.6.0.v201011041432
1.6.1.v201505192100
1.7.1.v201505191845
Thanks to everyone who have been working hard to clean up previous issues.
My hope is that by RC3 we will be completely "clean". At least for the reports mentioned here, which I take to be the most important,
but, by all means, please work on the others too!
Thanks again,
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|