[
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?
|
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.gurr@xxxxxxxxxxx <mailto: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
> <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.gurr@xxxxxxxxxxx <mailto:frederic.gurr@xxxxxxxxxxx>
> <mailto:frederic.gurr@xxxxxxxxxxx
> <mailto:frederic.gurr@xxxxxxxxxxx>>> 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>>
> > > <mailto: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>>
> > > <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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > >>> <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <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>>
> > >>>
> >
> <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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > >> <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <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>>
> > >>
> >
> <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@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>
> > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <mailto:cross-project-issues-dev@xxxxxxxxxxx>>
> > > <mailto:cross-project-issues-dev@xxxxxxxxxxx
> <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>>
> > >
> >
> <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@xxxxxxxxxxx
> <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@xxxxxxxxxxx
> <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@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>
> >
> _______________________________________________
> cross-project-issues-dev mailing list
> 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>
>
>
>
>
> _______________________________________________
> 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
>
