[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Neon.3 Update Problems: To Fix and How to Fix?

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.gurr@xxxxxxxxxxx> 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
and
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/
>
> 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.gurr@xxxxxxxxxxx <mailto:frederic.gurr@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.merks@xxxxxxxxx
>Â Â Â<mailto:ed.merks@xxxxxxxxx>
>Â Â Â> <mailto:ed.merks@xxxxxxxxx <mailto:ed.merks@xxxxxxxxx>>> 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>>
>Â Â Â>
>Â Â Â>Â Â Â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>>
>Â Â Â>
>Â Â Â>Â Â Â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@xxxxxxxxxxx>
>Â Â Â>>>Â Â Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
>Â Â Â<mailto: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
>Â Â Â<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@xxxxxxxxxxx>
>Â Â Â>>Â Â Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
>Â Â Â<mailto: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
>Â Â Â<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@xxxxxxxxxxx>
>Â Â Â>Â Â Â<mailto:cross-project-issues-dev@xxxxxxxxxxx
>Â Â Â<mailto: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
>Â Â Â<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@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
>Â Â Â<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@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
>Â Â Â<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