I can see org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 in /home/data/httpd/download.eclipse.org/linuxtools/update-docker-2.3.1/plugins, but it's definitely not in the aggregated repo.
On 20.04.2017 18:31, Jeff Johnston wrote: > Fred, > > The version of httpclient also changed in our update-docker-2.3.1 repo from: > > org.apache.httpcomponents.httpclient_4.5.2.v20161115-1643 > > to: > > org.apache.httpcomponents.httpclient_4.5.2.v20170210-0925 > > Not sure why this change isn't being seen as well. > > -- Jeff J. > > > > On Thu, Apr 20, 2017 at 12:21 PM, Frederic Gurr > <frederic.g...@eclipse.org <mailto:frederic.g...@eclipse.org>> wrote: > > Thanks Jeff, > > I ran a SimRel aggregation build. The only change I can see in the list > of "Non Unique Versions used in repository" is that a different version > of org.apache.httpcomponents.httpcore is now used. Instead of > 4.4.4.v20161115-1643 it's now 4.4.6.v20170210-0925. > > I compared > > http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt > > <http://download.eclipse.org/releases/neon/201703231000/buildInfo/reporeports/reports/nonUniqueVersions.txt> > and > > https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt > > <https://hudson.eclipse.org/simrel/job/simrel.neon.3_respin.runaggregator.BUILD__CLEAN/ws/aggregation/final/buildInfo/reporeports/reports/nonUniqueVersions.txt> > > @All: is that the intended result? > > Regards, > > Fred > > > On 19.04.2017 20:21, Jeff Johnston wrote: > > Hi Fred, > > > > I have just pushed a change to gerrit: > https://git.eclipse.org/r/#/c/95308/ > <https://git.eclipse.org/r/#/c/95308/> > > > > I only changed the docker repository and left the other Linux Tools > > features alone > > since they were only bumped as part of the point release to fix the > > Docker Tooling plug-ins. > > > > I assume I can merge the patch if the gerrit verification is > > successful. If this is wrong, > > let me know. > > > > -- Jeff J. > > > > On Wed, Apr 19, 2017 at 1:08 PM, Frederic Gurr > > <frederic.g...@eclipse.org <mailto:frederic.g...@eclipse.org> > <mailto:frederic.g...@eclipse.org > <mailto:frederic.g...@eclipse.org>>> wrote: > > > > Hi, > > > > Can you provide a patch for the SimRel build (branch > "Neon.3_respin") > > that references the new version? > > > > Regards, > > > > Fred > > > > On 19.04.2017 17:27, Jeff Johnston wrote: > > > Hi Ed, > > > > > > Linux tools spun a 5.3.1 release which now has a 2.3.1 > version of > > docker > > > tooling. The Linux tools download site has > update-docker-2.3.1 and > > > update-docker, both which have 2.3.1 versions of the docker.core > > plug-in > > > and docker feature. Not sure why you are not seeing this. > > > > > > -- Jeff J. > > > > > > On Wed, Apr 19, 2017 at 11:13 AM, Ed Merks > <ed.me...@gmail.com <mailto:ed.me...@gmail.com> > > <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>> > > > <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com> > <mailto:ed.me...@gmail.com <mailto:ed.me...@gmail.com>>>> wrote: > > > > > > Frederic, > > > > > > There seem to have been no notes/minutes taken during > the meeting: > > > > > > > https://wiki.eclipse.org/Planning_Council/April_05_2017 > <https://wiki.eclipse.org/Planning_Council/April_05_2017> > > <https://wiki.eclipse.org/Planning_Council/April_05_2017 > <https://wiki.eclipse.org/Planning_Council/April_05_2017>> > > > <https://wiki.eclipse.org/Planning_Council/April_05_2017 > <https://wiki.eclipse.org/Planning_Council/April_05_2017> > > <https://wiki.eclipse.org/Planning_Council/April_05_2017 > <https://wiki.eclipse.org/Planning_Council/April_05_2017>>> > > > > > > I recall agreeing to provide steps for reproducing the > problem so > > > that Thomas Watson could test if the wiring resolution > fix he made > > > for Oxygen also solves the problem for Neon.3. The fact > that he > > > encountered "the mirroring problem" didn't help in that > regard: > > > > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213> > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>> > > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213> > > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213 > <https://bugs.eclipse.org/bugs/show_bug.cgi?id=515213>>> > > > > > > In the end, he sent me a note saying (and I quote): > > > > > >> I see that now there is the same number of > httpcomponents bundles > > >> as there was in the messed up Oxygen M6 builds. But > here my back > > >> port of the resolver fix does not seem to have fixed > the issue. > > >> I'm unsure if that is because it gave up with the sheer > number of > > >> bundles or if something else is going wrong. But at > this point > > >> the backport of the resolver fix does not seem to be > the solution > > >> to the problem. > > > > > > I assumed (wrongly I guess) that Thomas would > investigate a more > > > general fix to address the wiring problem. > > > > > > In the end, I also wasn't sure which version of the docker > > tools is > > > proposed for contribution to Neon.3a. I tried to search for > > update > > > sites containing it like this: > > > > > > Nothing looks like a new version of 2.3. Goodness knows > where one > > > should find what's being proposed for contribution... > > > > > > In any case, the proposed "solution" (A) really just > changes the > > > version of httpclient to be one that's not broken (missing > > > packages), but it doesn't change the wiring problem in any > > > fundamental way. There will still be the four versions that > > can all > > > be installed simultaneously, so we really should expect > the same > > > wiring problem(s). In fact, I believe Oxygen M6 has > > effectively the > > > same four httpcomponents.httpclient bundle as does > Neon.3, so > > I'm a > > > little suspicious whether the wiring problem is in fact > really > > fixed > > > even for Oxygen. We won't know until M7 and that's a > month away. > > > It doesn't give me warm fuzzy feelings. > > > > > > So at this point it remains unclear the nature of the wiring > > > problem(s). Is it a bug? Is it fixable? Does the > knowledge, will, > > > and capacity to fix it exist? > > > > > > Without a fix to the wiring problem I think we can > eliminate A > > as a > > > solution, leaving B, C, and D (i.e., focus on problem > avoidance > > > approaches). But I think if the wiring problem is a > bug, it will > > > come back, and it will raise its ugly head again when users > > install > > > various technologies from various sources. To my > thinking, fixing > > > the bug seems important. > > > > > > Regards, > > > Ed > > > > > > > > > On 19.04.2017 12:49, Frederic Gurr wrote: > > >> Hi Ed, > > >> > > >> In the last planning-council meeting you offered to > evaluate > > if the > > >> fixed Linux Tools package works as expected and if > there are > > still > > >> wiring issues. > > >> > > >> Can you give us an update on the current state? > > >> > > >> Regards, > > >> > > >> Fred > > >> > > >> On 31.03.2017 11:14, Ed Merks wrote: > > >>> Hi, > > >>> > > >>> The original thread is fractured into many threads so its > > kind of > > >>> impossible to follow each thread with a reply but I'll try > > at the bottom > > >>> of this note, i.e., below the =========== > > >>> > > >>> But before doing that, I'd like to re-focus on the most > > important > > >>> questions: *We currently have a problem with Neon.3, > will we > > fix it, and > > >>> if so how will we fix it?* > > >>> > > >>> The discussion has quickly digressed (constructively) into > > solving the > > >>> issue of how Orbit dependencies should be managed by > > projects and by the > > >>> release train. Unfortunately I see this as a world hunger > > issue; not > > >>> one that is easily addressed and I believe not one we can > > wait for in > > >>> order to solve the Neon.3 problem. Let's face it, > we've not > > been able > > >>> to produce a proper Oxygen milestone in months, we still > > don't have one > > >>> now, and we won't have one until next month, we hope. > > >>> > > >>> For Neon we've done three maintenance releases. Neon.1 > > needed a respin > > >>> and Neon.3 looks to be in need of the same thing. Clearly > > something is > > >>> seriously wrong. But if we spend our time on solving the > > Orbit world > > >>> hunger issue, will we arrive at a solution in time for > > Oxygen, let alone > > >>> in time to fix Neon.3? I am very, very doubtful. > > >>> > > >>> As another data point, if I install the > > egg-laying-wool-milk-pig for > > >>> Neon.3. The following happens. I'm prompted to > accept this > > license: > > >>> > > >>> Red Hat, Inc. licenses these features and plugins > to you > > under > > >>> certain open source licenses (or aggregations of such > > licenses), > > >>> which in a particular case may include the Eclipse > > Public License, > > >>> the GNU Lesser General Public License, and/or certain > > other open > > >>> source licenses. For precise licensing details, > consult the > > >>> corresponding source code, or contact Red Hat, > Attn: General > > >>> Counsel, 100 East Davie St., Raleigh NC 27601 USA. > > >>> > > >>> I'm not sure how this license slipped into the release > > train. Aren't > > >>> there checks for this? (Sorry to digress, but this is > also > > unacceptable.) > > >>> > > >>> Launching the final installation comes up like this: > > >>> > > >>> Clearly a disgusting mess, but I've mentioned that before > > and the same > > >>> projects are still doing the same bad things, so we > clearly > > all accept > > >>> this situation as normal. > > >>> > > >>> The most important point here is the error log (first > > attachment) is > > >>> full of exactly the problem indications (bundle wiring > > problems) we > > >>> should have expected from the Neon.3 repository's > contents, > > if someone > > >>> were to install an arbitrary combination of the > repository's > > contents. > > >>> It's really not so hard to test this! > > >>> > > >>> If I create the same installation with my local build > of the > > Oomph 1.8 > > >>> installer---which installs my locally built version of > Oomph > > 1.8 so the > > >>> Oomph setup plugins are no longer disabled because I > made the > > >>> userstorage dependency optional and eliminated the strict > > <=4.4 upper > > >>> bound constraints on httpclient, which was such a bad > idea I > > can almost > > >>> have a canary to think this done to solve a problem > with no > > anticipation > > >>> of the problems it would cause---then I can visit all the > > preference > > >>> pages producing the second attached much larger log. It > > seems clear > > >>> that proper testing really doesn't happen for far too many > > projects on > > >>> the train. With distributed responsibility, no one is > > really responsible... > > >>> > > >>> ================================== > > >>> > > >>> Orbit Issues > > >>> > > >>> 1) Respinning Linux Tools against Oxygen Mx seems to miss > > the point that > > >>> we should only distribute released versions of > bundles, so > > no Neon > > >>> build should redistribute any unreleased version of > > anything. If a new > > >>> version of something is needed for security reasons or > other > > reasons, it > > >>> should be released first. And doing that in a maintenance > > train without > > >>> testing the overall impact is clearly something we should > > never do again > > >>> (without waving a bunch of red flags of warning). And > as Martin > > >>> Oberhuber asks, is nothing in place to check for this? So > > suppose we do > > >>> respin with a fixed released version, like what we > have for > > Oxygen M6, > > >>> then most likely we'd still have the problems we have in > > Oxygen M6 so > > >>> we'd need a fix to the resolver in Neon. Better would > seem > > to respin > > >>> with the old version(s) of the Orbit bundles, but > somehow we > > can never > > >>> delete the broken version from Neon and because it has a > > higher version > > >>> number is likely to slip back in unexpected (though > > hopefully not, given > > >>> that features have pinned their bundle versions). > > >>> > > >>> 2) Don't include Orbit bundles in your project's features. > > Sounds like > > >>> a great idea, but begs endless questions, and while > solving > > a problem > > >>> might well introduce more new problems than it > solves. The > > first > > >>> question (as Carsten points out) is how do these > things end > > up in a > > >>> repository, and if they are in a repository somehow, > how are > > they > > >>> categorized? It's hard to get them in and once you > do, they're > > >>> categorized poorly. The next question is, how do they end > > up in the > > >>> release train, if the projects that need them don't > > contribute them? > > >>> Directly from Orbit you say? But which ones should be > > pulled in from > > >>> Orbit and how is that discovered? Are those the ones the > > projects have > > >>> tested against? Then there is the question of whether an > > installation is > > >>> deterministic if the bundle version isn't pinned? > It's not; > > it will > > >>> depend on what's in the repos that are available at > resolve > > time. But > > >>> Gunnar argues that even packages are not deterministic, > > which I think is > > >>> false: if the feature pins the bundle version and the > > package requires > > >>> the feature, then the pinned bundle is definitely in that > > package. But > > >>> regardless, Gunnar's important point is that the runtime > > wiring seems > > >>> kind of non-determinstic, and while uses constraints might > > help, who the > > >>> heck understands those well, what tooling produces it > > correctly for us, > > >>> is that nicely integrated in PDE, and will it be properly > > maintained (in > > >>> contrast to lower bound constraints which you can pretty > > expect will > > >>> remain on whatever stale version they were initially set > > to). This may > > >>> well be the right direction in which to go, but getting > > there isn't > > >>> going to be even half the fun... > > >>> > > >>> Regards, > > >>> Ed > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> cross-project-issues-dev mailing list > > >>> cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>> > > >>> <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>>> > > >>> To change your delivery options, retrieve your > password, or > > unsubscribe from this list, visit > > >>> > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> > > >>> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> > > >>> > > >> _______________________________________________ > > >> cross-project-issues-dev mailing list > > >> cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>> > > >> <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>>> > > >> To change your delivery options, retrieve your password, or > > unsubscribe from this list, visit > > >> > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> > > >> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> > > > > > > > > > _______________________________________________ > > > cross-project-issues-dev mailing list > > > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>> > > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>>> > > > To change your delivery options, retrieve your password, or > > > unsubscribe from this list, visit > > > > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> > > > > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>>> > > > > > > > > > > > > > > > _______________________________________________ > > > cross-project-issues-dev mailing list > > > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>> > > > To change your delivery options, retrieve your password, or > > unsubscribe from this list, visit > > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > <mailto:cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org>> > > To change your delivery options, retrieve your password, or > > unsubscribe from this list, visit > > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>> > > > > > > > > > > _______________________________________________ > > cross-project-issues-dev mailing list > > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > <mailto:cross-project-issues-dev@eclipse.org> > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > <https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev> > > > > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev > _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
