Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

I have asked that several times already, but why do we allow individual projects to contribute Orbit bundles to simrel anyway? If the simrel aggregator would pull in the required Orbit bundles alone, it would have full control over which versions are bundled. Projects might yet bundle them in

Re: [cross-project-issues-dev] Neon.3 Update Problems

Switching to Neon.3 orbit won't solve the problem as the 3.6.8 docker-client there will still result in pulling in the newer httpclient which is also in the Neon.3 orbit repo. I have respun the Linux Tools to create a 5.3.1 release with the updated packages. If a re-aggregation will occur and I

Re: [cross-project-issues-dev] [orbit-dev] [eclipse.org-planning-council] Neon.3 Update Problems

> I think there is also another thing to consider. IMHO projects should stop > hard-pinning specific 3rd party versions in the feature.xml - at least in > the feature they submit into the common repo. This triggers p2 to install > multiple versions into packages. Speaking from the perspective of

Re: [cross-project-issues-dev] Neon.3 Update Problems

Ed Merks wrote: I don't know if the EGit update problems are at all related: https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_1758538 It definitely looks like a different problem, but org.slf4j.api_1.7.10.v20160921-1923 also comes from the update-neon-docker update site.

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

> On 30. Mar 2017, at 19:10, Daniel Megert wrote: > I have never seen an announcement from Orbit that service release builds for > Orbit got dropped, but that seems to be the current reality, see > https://bugs.eclipse.org/bugs/show_bug.cgi?id=509412#c19. I'm not

Re: [cross-project-issues-dev] [eclipse.org-planning-council] Neon.3 Update Problems

> But what seems even worse, though I don't fully understand the problem, is how this broken orbit bundle id='org.apache.httpcomponents.httpclient' version='4.5.2.v20161115-1643' got into the Neon release train repository. That's a good question. One could be that there was a critical /

Re: [cross-project-issues-dev] Neon.3 Update Problems

On Thu, 2017-03-30 at 17:11 +0200, Ed Merks wrote: > Hi, > I'm concerned about the number of problems I see regarding updates to > Neon.3.  For example, the missing MPC problem: >   https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#ms > g_1758538 > It looks just like the problem

Re: [cross-project-issues-dev] Neon.3 Update Problems

Regarding the Linux Tools issue. This was due to the Oxygen M4 orbit repo referenced as part of a patch that upgraded the level of docker-client. I will cut a 5.3.1 release of Linux Tools today using the Orbit M6 repo. Can this be aggregated or used to patch the issue? -- Jeff J. -

[cross-project-issues-dev] Neon.3 Update Problems

Hi, I'm concerned about the number of problems I see regarding updates to Neon.3. For example, the missing MPC problem: https://www.eclipse.org/forums/index.php/mv/msg/1085206/1758538/#msg_1758538 It looks just like the problem we've been having with Oxygen M5/M6. That problem I believe

[cross-project-issues-dev] Eclipse on Linux PPC -- ACTION REQUIRED for PPC developers

The Eclipse Project PMC is looking for community feedback on the use of the Eclipse SDK on Linux PPC. We believe that the Linux PPC community has largely moved to 64-bit platforms, and that within the 64-bit world that "Little Endian" (LE) platforms are becoming the de facto direction. In an

Re: [cross-project-issues-dev] Hitting traivs rate limits

I've raised the awareness of this issue to EMO. Feedbacks will come soon. Thanks for your patience. Mikael > Le 30 mars 2017 à 00:30, Tom Schindl a écrit : > > Hi, > > e(fx)clipse is also using Travis the reason is that this is IMHO the > standard way for