genivi-projects Digest, Vol 14, Issue 75

Joel Hoffmann joel.hoffmann at renesas.com
Sun Jun 5 07:25:03 EDT 2016


Augustin,

I am aware of your great efforts, not only to manage the GDP project, but to communicate the work to the members. You stand out in your dedication to the effort to spread the word.

My comments are not targeted to your communications, but rather to a much larger industry level audience that will not understand the technical attributes, but rather will care about how cars sales are going to be affected. 

There are big players working in this space and they capture the ear of the end customer, in turn the industry tries to respond with great stories. My concern is that beyond the broad concept of bringing OSS into the IVI business and competing with legacy approaches like QNX, that GENIVI's message is fading in light of all the hype around advanced driving, native smartphone integration, software management and a major shift in the software center of the car. IVI will be important, but other areas are the growth space. I think GENIVI and its talented members can go further. 

This is where marketing usually pulls the cart. Industry analysts can raise attention to the new strategy of GDP and how automakers should take serious the results. This is not your responsibility in the technical teams, but the development of a meaningful message depends on his kind of dialogue. I am frustrated that GDP communication has happened on a limited level without a compelling external story behind it. Your team deserves better support from the marketing talents within the member base, and that goes beyond the administrative work of GENIVI staff. I know you called out to marketing for this message development, but despite some limited and slow assessment, the results have not been there to help you build excitement around GDP. 

Google android (embedded .car) is still getting much more attention, and while the engineers may agree we have a better approach, the vehicle planners will eventually decide what they will work on. Of particular concern is the lack of interest in GENIVI with the NA big three. There seems to be little progress engaging them, while EMEA has a progressive interest, there is not enough for them to work with yet (check PSA and Renault exec keynotes in Paris to confirm). Meanwhile Japan is not aware of any benefits of GDP for their work, so we have at least 2 organizations inventing the same wheel.

GDP has a much broader potential message that could draw reporters, and ultimately more OEMs, such as the largest ones in the world. While the team under your lead has told the story through developer channels (ELC, ALS, internal blogs, private social media groups, secure internal wiki) the average automotive reporter will not understand the implications, let alone hear of them. I was delighted to read some of Jeremiah's descriptions, and besides some periodical tweets on private groups, the world has not hear these. I watch GENIVI closer than most marketing folks and certainly learned something from this thread.

I welcome Vildan to join this conversation and give another perspective, perhaps the limited distribution of this info is intentional, but I think GENIVI needs to move faster, not become more private.

Sent from my iPad using my Renesas mail account

> On Jun 5, 2016, at 6:02 AM, Agustin Benito Bethencourt <agustin.benito at codethink.co.uk> wrote:
> 
> Hi,
> 
>> On 04/06/16 23:24, Joel Hoffmann wrote:
>> Jeremiah,
>> 
>> Thanks for your thoughtful response.
>> 
>> See inline below…I’m learning engineering - slowly. :-)
>> 
>> There was a “GDP Marketing Task Force” created but only had one meeting
>> and an unpublished report to the board. I’m not sure what happened after
>> that, but one call to you would have helped greatly to create a message
>> that will benefit GENIVI members and make the alliance highly
>> influencial as a thought leader.
> 
> I am open to put effort in any communication activity towards providing info to Members about GDP. I work already with GENIVI marketing on regular basis.
> 
> Some links that might help:
> * GDP Out There: https://at.projects.genivi.org/wiki/display/GDP/GDP+Out+There
> * Blog posts and announcements: https://at.projects.genivi.org/wiki/pages/viewrecentblogposts.action?key=GDP 
> 
>> 
>> Joel Hoffmann
>> Open Platform Marketing Manager
>> Renesas Electronics Corporation
>> +1 248-345-7947
>> 
>> joel.hoffmann at renesas.com <mailto:joel.hoffmann at renesas.com>
>> 
>> 
>>> On Jun 4, 2016, at 2:26 AM, Jeremiah Foster
>>> <jeremiah.foster at pelagicore.com
>>> <mailto:jeremiah.foster at pelagicore.com>> wrote:
>>> 
>>> 
>>> 
>>> On Fri, Jun 3, 2016 at 10:38 PM, Joel
>>> Hoffmann<joel.hoffmann at renesas.com
>>> <mailto:joel.hoffmann at renesas.com>>wrote:
>>> 
>>>    Great speech from Agustin, has there been any progress on this
>>>    issue with Qt since May 25th?
>>> 
>>> 
>>> There has been more discussion. There will be more at the board
>>> meeting this June.
>> 
>> Looking forward to hearing more, are you engaged with Alistair Adams on
>> this topic? He has some ideas you might want to consider.
>> 
>>> 
>>>    Apologies for top posting, I'm a marketing guy, one mentioned that
>>>    needs to weigh in.
>>> 
>>> 
>>> :-)
>> 
>> Based on your response below, I think you straddle the fence between
>> engineering and marketing too. :-)
>> 
>>> 
>>>    My real question is why is auto still afraid of GPL v3, or is it
>>>    more about paying fees to Qt?
>>> 
>>> 
>>> I don't think the problem is the purchase of commercial licenses, that
>>> is quite straight forward for most, if not all, companies. The issue
>>> is that GENIVI wants to produce software that goes into cars. *This
>>> includes the image created by the GDP*.
>> 
>> Have you told GENIVI marketing about this? Is it true that GENIVI
>> expects the GDP image to go into production cars? *This is a big story,
>> far beyond a “development” platform! *I did see that downloadable images
>> of GDP for Raspberry Pi and Intel Minnowboard Max are available, are the
>> automakers going to use these in production?
>> 
>> I thought the *components* (hardened through production programs) would
>> be the path to adoption and the architecture was a guideline with
>> multiple paths to deployment by each Tier1/OSV. This differs from the
>> AGL and Android approach where the middleware section comes as a fixed
>> distro adapted to each silicon platform, thus creating an API structure
>> for developers to build standard apps across vehicles. This latter
>> approach actually aligns well with GENIVI’s aspiration to enable
>> connected cars, although most cars will not be running Linux until about
>> 2020/22 timeframe. The APIs need to be there now to hit that window.
>> 
>> As it stands today GDP (as originally designed) seems to have little to
>> do with production systems which will still require substantial
>> customization by the OSV and Tier1. This does not allow the suppliers to
>> leverage validation and testing since taking out a single component
>> breaks the stack and starts validation over again. Perhaps this is part
>> of the GDP-next aspiration.
>> 
>>> If it has GPLv3 anywhere in the final image, then car makers have to
>>> provide installation instructions as well as the encryption key for
>>> the entire image. For safety reasons the encryption key cannot be
>>> released. Therefore no software that requires encryption key release,
>>> as GPLv3 software does, can be installed in the image.
>> 
>> I was not aware that this is the specific issue, and does not come out
>> in any messaging I’ve heard. Thanks for raising the encryption key topic
>> beyond the technical discussion forums. This seems to relate closely to
>> the GDP image in production concept above.
>> 
>> I think most people assume the automakers do not like GPLv3 over the
>> “Replay TV” issue, perhaps this has progressed. Again a great topic for
>> GENIVI Marketing to tackle. I think GENIVI can be a thought leader in
>> education on licenses for automotive. Why make all the automakers figure
>> this out over and over when GENIVI can provide the direction.
>> 
>>>    It seems there may be many issues to resolve before GDP can become
>>>    a "development" platform beyond a derivative for demos.
>>> 
>>> 
>>> I think GENIVI in fact can produce production ready software.
>> 
>> This is great news, are there any examples beyond the “pick and mix”
>> approach used by BMW, JLR, and PSA probably? Which GENIVI components are
>> “production ready”? GENIVI Marketing could promote these components in
>> the marketplace well beyond simply promoting the brand and membership
>> benefits. I’ve always felt we should create a data sheet on each of the
>> components and promote them.
>> 
>>>    How does GDP compete with Android-N being adopted by a major share
>>>    of the worlds automakers?
>>> 
>>> 
>>> The GDP is highly customizable, it runs on a broad range of automotive
>>> production hardware with a broad range of HMI options as well as
>>> optimization for automotive specific use cases like fastboot. It
>>> supports the use of Android on top of GENIVI images *(Android Auto has
>>> already been integrated onto GDP)*
>> 
>> This must be a little know fact, last I saw the AA implementation it was
>> independent of GDP (was there a new round of funding to tie these
>> together?), and GDP itself is trying to bring itself in alignment with
>> other innovations, such as the latest versions of Qt, SDL, and even RVI.
>> I suspect General Motors or FCA will find a way to make Android-N.car do
>> fast boot, perhaps learning from GENIVI but not using any of its
>> components. In the past we went around and around trying to figure out
>> how to integrate embedded android with a GENIVI compliant stack, has
>> this been solved? Fantastic news again!
>> 
>>> as well as other third party software. The Open Connectivity
>>> Foundation also recently demonstrated their software running on the
>>> GDP. In short, I think GENIVI is a real platform where Android is
>>> merely an interface to the platform. I don't think that Android, in
>>> any of its many, many forms, offers real competition to GENIVI
>>> software, rather it is a complement -- it is one way to create an
>>> interface to the platform.
>> 
>> Again a great topic for GENIVI Marketing to talk about in the industry.
>> I don’t think Android Auto is quite the same as Android.car announced at
>> Google.IO, although they now work together and you can bolt a large
>> android tablet into your Maserati and have full phone integration very
>> quick. Has anyone looked at that yet? I think many car OEMs GENIVI would
>> like to engage are seriously committed to it embedded Android.car. This
>> makes things hard for the supply base to support all these different
>> Linux platforms.
>> 
>> I’ve seen OCF demo and its a great start. Is GENIVI contributing to it,
>> or is this entirely a contribution from Samsung for the demo? An OEM
>> strategy to integrate the OCF server components in the car would be a
>> great story for IoT support from cars to connected devices like your
>> garage door opener.
>> 
>>>    What about the maturing AGL distro?
>>> 
>>> 
>>> The AGL distro is obviously hugely important and carefully followed by
>>> GENIVI. GENIVI has no interest in reinventing the wheel so looks to
>>> AGL to see if there is software that fulfills GENIVI's needs as well
>>> as collaboration points on existing software.
>> 
>> Keep an eye on that reinvention of the wheel, it may be the elimination
>> of the steering wheel someday. At that point the IVI platform will be
>> long solved and the next challenge is functional safety, a new domain
>> for Linux itself. Please let GENIVI Marketing know what components from
>> AGL work are being adopted as part of the GENIVI compliance spec. There
>> are some real deliverables here, but only the GENIVI members know about
>> them.
>> 
>>> Software design decisions may be different in the two projects and
>>> that is likely healthy.
>> 
>> Healthy, given an infinite amount of time. Google is a strong
>> competitor, although I fully support the concept of an underlying Linux
>> base with both Android Auto and Apple Carplay running on top. The
>> carmaker UI can be controlled in the Linux space with Qt or Web apps.
>> Automakers already lost the app store challenge by the big phone OS
>> ecosystems. Even big GM or Toyota will struggle to maintain their own
>> ecosystem for developers, it is very expensive. It would really be good
>> for GENIVI to get the big OEMs on board.
>> 
>>>    Fragmentation is GENIVI's biggest enemy.
>>> 
>>> 
>>> I don't think so. Of course fragmentation is a problem when you have
>>> multiple, robust, commodity software components. When you're in that
>>> situation there is really no point in having fourteen different web
>>> servers for example, its better to consolidate on a standard to save
>>> effort. But part of the distinct advantage of GNU/Linux is the fact
>>> that it is highly customizable. This allows different hardware
>>> manufacturers to produce software that takes advantage of their
>>> particular hardware features and for differentiation in the user
>>> interface.
>> 
>> Good point, I think Google and Apple have figured out how to do this, I
>> use Chrome on my mac, I like having the choice, yet all the standard
>> APIs are supported well so I can share the ecosystem with the rest of
>> the world. At the same time I think the whole system would break if
>> Apple went back to IBM Power PC chips from Intel or tried to put ARM in
>> the mac like Microsoft failed with, despite billions invested. Google
>> forces all other silicon providers to bundle an interpreter to keep
>> their ecosystem in the ARM instruction set, of course with recent
>> developments there is no competing architecture for phones and tablets.
>> 
>>> 
>>> Looking from the outside I think that it might appear that there are
>>> two separate automotive software stacks, but that is actually not the
>>> case. They both share a common base, namely the Linux kernel, they
>>> both use the same init system, they both use Wayland, Qt runs well on
>>> both, Yocto is used for both. There is a very large shared code base.
>>> AGL then goes a bit deeper into the safety-critical domain, at least
>>> that is the stated intention, GENIVI doesn't work in that domain.
>>> GENIVI's focus is IVI so naturally it will have a different scope but
>>> that does not mean that there is significant fragmentation per se, I
>>> think it is the right amount of difference actually.
>>> 
>>> Its a difficult balance at times to find the equilibrium between
>>> customization and standardization, but I think currently that balance
>>> is pretty good and healthy.
>> 
>> I’m less concerned about AGL/GENIVI conflicts than the competitive
>> positioning of Google Android.car in the market. GM, FCA and others seem
>> to be sold and are only watching GENIVI from afar. When you move back to
>> US perhaps you can help with getting OEM adoption in markets besides the EU.
>> 
>>> 
>>> Cheers,
>>> 
>>> Jeremiah
>>> 
>>> 
>>>    Sent from my phone, please accept my apologies for any typos and
>>>    brevity.
>>> 
>>> 
>>> Sent from my computer, with spell checking on. :-D
>>> 
>>> 
>>>    Joel Hoffmann
>>>    Open Platform Marketing Manager
>>>    Renesas Electronics
>>>    Joel.Hoffmann at Renesas.com <mailto:Joel.Hoffmann at renesas.com>
>>>    Text to+1 (248) 345-7947 <tel:%2B1%20%28248%29%20345-7947>
>>> 
>>>    > On May 25, 2016, at 6:09 AM,
>>>    "genivi-projects-request at lists.genivi.org
>>>    <mailto:genivi-projects-request at lists.genivi.org>"
>>>    <genivi-projects-request at lists.genivi.org
>>>    <mailto:genivi-projects-request at lists.genivi.org>> wrote:
>>>    >
>>>    > Send genivi-projects mailing list submissions to
>>>    > genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    >
>>>    > To subscribe or unsubscribe via the World Wide Web, visit
>>>    > https://lists.genivi.org/mailman/listinfo/genivi-projects
>>>    > or, via email, send a message with subject or body 'help' to
>>>    > genivi-projects-request at lists.genivi.org
>>>    <mailto:genivi-projects-request at lists.genivi.org>
>>>    >
>>>    > You can reach the person managing the list at
>>>    > genivi-projects-owner at lists.genivi.org
>>>    <mailto:genivi-projects-owner at lists.genivi.org>
>>>    >
>>>    > When replying, please edit your Subject line so it is more specific
>>>    > than "Re: Contents of genivi-projects digest..."
>>>    >
>>>    >
>>>    > Today's Topics:
>>>    >
>>>    >  1. Re: Qt version on GDP 10 (Agustin Benito Bethencourt)
>>>    >  2. Error when trying to run the SOTA server (Kumar-Mayernik, Nisha)
>>>    >  3. Re: Error when trying to run the SOTA server (Arthur Taylor)
>>>    >  4. Re: Error when trying to run the SOTA server
>>>    >     (Kumar-Mayernik, Nisha)
>>>    >
>>>    >
>>>    >
>>>    ----------------------------------------------------------------------
>>>    >
>>>    > Message: 1
>>>    > Date: Wed, 25 May 2016 14:21:52 +0200
>>>    > From: Agustin Benito Bethencourt <agustin.benito at codethink.co.uk
>>>    <mailto:agustin.benito at codethink.co.uk>>
>>>    > To: "genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>"
>>>    >   <genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>>
>>>    > Subject: Re: Qt version on GDP 10
>>>    > Message-ID: <574598E0.4090303 at codethink.co.uk
>>>    <mailto:574598E0.4090303 at codethink.co.uk>>
>>>    > Content-Type: text/plain; charset=utf-8; format=flowed
>>>    >
>>>    > Hi,
>>>    >
>>>    > long mail, apologies.
>>>    >
>>>    >>> On 25/05/16 01:19, James Thomas wrote:
>>>    >>> On 23/05/16 01:36, Agustin Benito Bethencourt wrote:
>>>    >>> Hi,
>>>    >>>
>>>    >>> we are starting to focus on the next GDP version this week.
>>>    >>>
>>>    >>> Which version of Qt should we include in GDP 10 ?
>>>    >>>
>>>    >>> Changhyeok opened a ticket[1] to track this discussion. There
>>>    is a previous
>>>    >>> discussion[2] in this list that touched the topic.
>>>    >>>
>>>    >>> [1]https://at.projects.genivi.org/jira/browse/GDP-220
>>>    >>>
>>>    [2]http://lists.genivi.org/pipermail/genivi-projects/2016-May/002229.html
>>>    >>>
>>>    >>> Best Regards
>>>    >>
>>>    >> Can we target 5.7 [1]?
>>>    >>
>>>    >> We'd have upstream support for ivi-shell in QtWayland this way
>>>    >
>>>    > ++ Personal note
>>>    >
>>>    > First let me say that the Qt licensing is not managed by the Qt
>>>    Company
>>>    > but by the Free Qt Foundation. 50% of that foundation is "owned"
>>>    by KDE.
>>>    >
>>>    > Funny enough I was part of the KDE e.V Board during some of the key
>>>    > moments of the negotiation of the new license model for Qt with
>>>    Digia. I
>>>    > have a strong opinions on Qt license model, as you can imagine.
>>>    >
>>>    > I avoided the proposal of Qt 5.7 on purpose to save lots of
>>>    explanations
>>>    > and discussions at this point although it was a matter of time
>>>    so....
>>>    > here I come.
>>>    >
>>>    > ++ Context
>>>    >
>>>    > The work GDP delivery team will do the coming weeks is to
>>>    upgrade GDP to
>>>    > meta-ivi10 which means Qt 5.5.1. In 3-4 weeks we will be able to
>>>    define
>>>    > the roadmap for the next version, which includes a very
>>>    important decision:
>>>    >
>>>    > -- Do we release GDP 10 or after some basic integration, we work to
>>>    > catch up with meta-ivi and go directly for GDP 11?--
>>>    >
>>>    > This decision needs as input effort estimations, requests
>>>    > prioritization, how to face the integration of the components
>>>    that are
>>>    > on the pipeline...
>>>    >
>>>    > ++ Scenarios
>>>    >
>>>    > There are two scenarios related with Qt and GDP (so GENIVI) that
>>>    I see.
>>>    > I am advancing them without all the required input described
>>>    above so
>>>    > please have this in consideration.
>>>    >
>>>    > 1.- The decision is to release GDP-10.
>>>    >
>>>    > Although having the new GDP 11 version cooking already, probably we
>>>    > would arrive to the 15th AMM with meta-ivi 11 and a solid GDP-10.
>>>    >
>>>    > I think we should consider to go for Qt 5.6 instead of the
>>>    default Qt
>>>    > 5.5.1, since this version will be very popular among this
>>>    industry for
>>>    > long. It will depend on the effort involved though and the expertise
>>>    > available but the idea can be to extend the life cycle of Qt 5.6
>>>    tot to
>>>    > two GDP releases.
>>>    >
>>>    > 2.- If we decide to go for GDP 11, skipping the release of GDP
>>>    10, like
>>>    > we did with GDP-ivi8, it would mean the we ship Qt 5.6. The
>>>    effort would
>>>    > be focused in arriving to the 15th AMM having meta-ivi 11 and
>>>    GDP 11 in
>>>    > shape.
>>>    >
>>>    > +++ When will we face the change towards a (L)GPLv3 version of Qt
>>>    >
>>>    > In the first scenario, we would face an upgrade to a (L)GPLv3 based
>>>    > version of Qt late this year or early 2017, depending on the
>>>    decision
>>>    > for GDP to skip or not a meta-ivi 11. So the decision might be taken
>>>    > during 15th AMM.
>>>    >
>>>    > In the second scenario though, we would face the challenge right
>>>    after
>>>    > the 15th AMM.
>>>    >
>>>    > So the decision should be taken before the 15th AMM. The ideal
>>>    situation
>>>    > would be to link it to the decision of going for GDP 11, in a
>>>    few weeks
>>>    >
>>>    > ++ My opinion about the topic
>>>    >
>>>    > In short, I believe discussing if Qt 5.7, so (L)GPLv3 in GDP,
>>>    yes or no
>>>    > is pointless.
>>>    >
>>>    > And I say this because I am convinced that it will be
>>>    unsustainable from
>>>    > the technical AND financial point of view to become maintainers
>>>    of an
>>>    > older version of Qt in newer versions of a distribution, in this
>>>    case
>>>    > poky, and at the same time, intend to have several releases per
>>>    year of
>>>    > a "product" that target developers.
>>>    >
>>>    > 1.- ... older version of Qt in a newer version of a distribution
>>>    >
>>>    > GDP is not a distribution, it is a derivative. GENIVI chose that
>>>    model
>>>    > and moving out of it requires investment.
>>>    >
>>>    > To backport (like we did with weston 1.9 in GDP-ivi9) is
>>>    expensive but
>>>    > is a one shot effort. To forward port, which would be required if we
>>>    > stay in a specific Qt version, is the "road to hell" for a non
>>>    > commercial project.
>>>    >
>>>    > 2.- ... ... intend to have several releases per year...
>>>    >
>>>    > We would require a financial commitment and experts to carry on this
>>>    > effort. And this is the kind of work that becomes harder, so more
>>>    > expensive, over time.
>>>    >
>>>    > In summary, it goes against everything that represents the Open
>>>    Source
>>>    > development and delivery model. Even the most conservatives and
>>>    > experienced distributions, like RHEL and SLE, works hard on
>>>    reducing the
>>>    > impact of moving through this "road of hell" in every update.
>>>    >
>>>    > 3.- ... of a product that targets developers.
>>>    >
>>>    > Let me start by saying that I do not see any problem from the
>>>    commercial
>>>    > point of view in staying some time on Qt 5.6. But our target are
>>>    > developers and innovation.
>>>    >
>>>    > Even if we explain the situation, our explanations are
>>>    understood and
>>>    > assumed and, due to GDP increasing energy, we perceive little impact
>>>    > right after taking the decision of staying in a fixed version of Qt
>>>    > (best scenario), over time the interest on GDP will become lower
>>>    among
>>>    > what today seems GDP best support, the Qt ecosystem.
>>>    >
>>>    > I believe, these three goals are unachievable at the same time
>>>    even for
>>>    > organization with more resources and experience than we have. It
>>>    is a
>>>    > "empty road of hell" in non-commercial environments.
>>>    >
>>>    > ++ My Conclusion
>>>    >
>>>    > 1.- The real decision here is how we ship key components that,
>>>    in terms
>>>    > of license, might represent a risk for OEMs business models. It
>>>    should
>>>    > not be about shipping them or not, specially in an industry that is
>>>    > changing rapidly towards Open Source adoption but not in a
>>>    uniform way.
>>>    >
>>>    > I would not put myself in front of the train without finding out
>>>    first
>>>    > what happened to those who did it before.
>>>    >
>>>    > There are several strategies we can follow that saves adoption
>>>    costs of
>>>    > GDP related with those key components. There will be cases though in
>>>    > which we will provide to GENIVI members zero options or having
>>>    options,
>>>    > none of them are compatible with our current goals, so we will
>>>    not offer
>>>    > them on regular basis.
>>>    >
>>>    > 2.- Having discussions about GDPv3 yes or no remind me so much
>>>    to the
>>>    > GPLv2 days that I admit it is hard for me to go through it again.
>>>    >
>>>    > I see GENIVI also as a forum to educate and advise, do you all?
>>>    >
>>>    > Discussing this topic only at one level (technical, legal, business,
>>>    > strategy) makes it very hard to reach to realistic conclusions.
>>>    Mixing
>>>    > them all in the right way is harder and cannot obviously be
>>>    limited to
>>>    > this channel.
>>>    >
>>>    > I presented a paper about GDP for QtCon in September. My
>>>    personal hope
>>>    > is that, by then, we have a position we can all feel comfortable
>>>    with so
>>>    > I can defend it and promote it, specially in the second scenario.
>>>    >
>>>    > Since 15th AMM is taking place the same days and city that the
>>>    Qt World
>>>    > Summit, it will be a great opportunity to reinforce GENIVI
>>>    position as
>>>    > industry leader in Open Source by promoting conversations that
>>>    provide
>>>    > the whole picture from both sides if the situation has not been
>>>    solved
>>>    > before.
>>>    >
>>>    > Best Regards
>>>    >
>>>    > --
>>>    > Agustin Benito Bethencourt
>>>    > Principal Consultant - FOSS at Codethink
>>>    >agustin.benito at codethink.co.uk
>>>    <mailto:agustin.benito at codethink.co.uk>
>>>    >
>>>    >
>>>    > ------------------------------
>>>    >
>>>    > Message: 2
>>>    > Date: Wed, 25 May 2016 05:27:10 -0700
>>>    > From: "Kumar-Mayernik, Nisha" <nkumarm1 at jaguarlandrover.com
>>>    <mailto:nkumarm1 at jaguarlandrover.com>>
>>>    > To: Arthur Taylor <arthur at advancedtelematic.com
>>>    <mailto:arthur at advancedtelematic.com>>
>>>    > Cc:genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    > Subject: Error when trying to run the SOTA server
>>>    > Message-ID:
>>>    >
>>>     <CANLsUs74kMvvmKzg_JiE9sHK+C1jCrXcN2=hss-x0dm1h2WB4A at mail.gmail.com
>>>    <mailto:hss-x0dm1h2WB4A at mail.gmail.com>>
>>>    > Content-Type: text/plain; charset="utf-8"
>>>    >
>>>    > Hi Arthur,
>>>    >
>>>    > I tried to set up a SOTA server locally on my dev machine. I am
>>>    getting
>>>    > this error:
>>>    >
>>>    > ProvisionException: Unable to provision, see the following errors:
>>>    >
>>>    > 1) Error injecting constructor, java.lang.IllegalArgumentException:
>>>    > requirement failed: Key store file certs/client.jks does not exist!
>>>    > at
>>>    org.genivi.webserver.Authentication.LdapAuth.<init>(LdapAuth.scala:35)
>>>    > at
>>>    org.genivi.webserver.Authentication.LdapAuth.class(LdapAuth.scala:35)
>>>    > while locating org.genivi.webserver.Authentication.LdapAuth
>>>    >   for parameter 2 at
>>>    >
>>>    org.genivi.webserver.controllers.Application.<init>(Application.scala:29)
>>>    > while locating org.genivi.webserver.controllers.Application
>>>    >   for parameter 1 at router.Routes.<init>(Routes.scala:35)
>>>    > while locating router.Routes
>>>    > while locating play.api.inject.RoutesProvider
>>>    > while locating play.api.routing.Router
>>>    >
>>>    > 1 error
>>>    >
>>>    > Any ideas? I am using the docs here:
>>>    >http://genivi.github.io/rvi_sota_server/doc/building-installing.html.
>>>    I am
>>>    > running this on Ubuntu 16.04.
>>>    >
>>>    > Thanks
>>>    > *Nisha Kumar-Mayernik*
>>>    > Software Developer
>>>    >
>>>    >
>>>    >
>>>    > *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA*
>>>    > *jaguar.com <http://jaguar.com/><http://jaguar.com/>  |
>>>    landrover.com <http://landrover.com/><http://landrover.com/>*
>>>    >
>>>    > Business Details:
>>>    > Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK
>>>    > Registered in England Number: 1672070
>>>    >
>>>    > This e-mail and any attachments contain confidential information
>>>    for a
>>>    > specific individual and purpose.  The information is private and
>>>    privileged
>>>    > and intended solely for the use of the individual to whom it is
>>>    addressed.
>>>    > If you are not the intended recipient, please e-mail us
>>>    immediately.  We
>>>    > apologize for any inconvenience caused but you are hereby
>>>    notified that any
>>>    > disclosure, copying or distribution or the taking of any action
>>>    in reliance
>>>    > on the information contained herein is strictly prohibited.
>>>    >
>>>    > This e-mail does not constitute an order for goods or services
>>>    unless
>>>    > accompanied by an official purchase order.
>>>    > -------------- next part --------------
>>>    > An HTML attachment was scrubbed...
>>>    > URL:
>>>    <http://lists.genivi.org/pipermail/genivi-projects/attachments/20160525/fef4e241/attachment-0001.html>
>>>    >
>>>    > ------------------------------
>>>    >
>>>    > Message: 3
>>>    > Date: Wed, 25 May 2016 15:01:37 +0200
>>>    > From: Arthur Taylor <arthur at advancedtelematic.com
>>>    <mailto:arthur at advancedtelematic.com>>
>>>    > To: "Kumar-Mayernik, Nisha" <nkumarm1 at jaguarlandrover.com
>>>    <mailto:nkumarm1 at jaguarlandrover.com>>
>>>    > Cc:genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    > Subject: Re: Error when trying to run the SOTA server
>>>    > Message-ID: <5745A231.6080206 at advancedtelematic.com
>>>    <mailto:5745A231.6080206 at advancedtelematic.com>>
>>>    > Content-Type: text/plain; charset=utf-8
>>>    >
>>>    > Hi Nisha,
>>>    >
>>>    > Thanks for the report. We're investigating. We think it's
>>>    related to the
>>>    > recent changes we made to add LDAP support.
>>>    >
>>>    > We're hoping to get a resolution or update today - will let you
>>>    know as
>>>    > soon as we have something.
>>>    >
>>>    > Thanks,
>>>    >
>>>    > Arthur
>>>    >
>>>    >> On 25/05/16 14:27, Kumar-Mayernik, Nisha wrote:
>>>    >> Hi Arthur,
>>>    >>
>>>    >> I tried to set up a SOTA server locally on my dev machine. I am
>>>    >> getting this error:
>>>    >>
>>>    >> ProvisionException: Unable to provision, see the following errors:
>>>    >>
>>>    >> 1) Error injecting constructor, java.lang.IllegalArgumentException:
>>>    >> requirement failed: Key store file certs/client.jks does not exist!
>>>    >> at
>>>    >>
>>>    org.genivi.webserver.Authentication.LdapAuth.<init>(LdapAuth.scala:35)
>>>    >> at
>>>    org.genivi.webserver.Authentication.LdapAuth.class(LdapAuth.scala:35)
>>>    >> while locating org.genivi.webserver.Authentication.LdapAuth
>>>    >>   for parameter 2 at
>>>    >>
>>>    org.genivi.webserver.controllers.Application.<init>(Application.scala:29)
>>>    >> while locating org.genivi.webserver.controllers.Application
>>>    >>   for parameter 1 at router.Routes.<init>(Routes.scala:35)
>>>    >> while locating router.Routes
>>>    >> while locating play.api.inject.RoutesProvider
>>>    >> while locating play.api.routing.Router
>>>    >>
>>>    >> 1 error
>>>    >>
>>>    >> Any ideas? I am using the docs here:
>>>    >>http://genivi.github.io/rvi_sota_server/doc/building-installing.html.
>>>    >> I am running this on Ubuntu 16.04.
>>>    >>
>>>    >> Thanks
>>>    >> *Nisha Kumar-Mayernik*
>>>    >> Software Developer
>>>    >>
>>>    >>
>>>    >>
>>>    >> *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA*
>>>    >> *jaguar.com <http://jaguar.com/><http://jaguar.com/>  |
>>>    landrover.com <http://landrover.com/>
>>>    >> <http://landrover.com/>*
>>>    >>
>>>    >> Business Details:
>>>    >> Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3
>>>    4LF, UK
>>>    >> Registered in England Number: 1672070
>>>    >>
>>>    >> This e-mail and any attachments contain confidential
>>>    information for a
>>>    >> specific individual and purpose.  The information is private and
>>>    >> privileged and intended solely for the use of the individual to
>>>    whom
>>>    >> it is addressed.  If you are not the intended recipient, please
>>>    e-mail
>>>    >> us immediately.  We apologize for any inconvenience caused but
>>>    you are
>>>    >> hereby notified that any disclosure, copying or distribution or the
>>>    >> taking of any action in reliance on the information contained
>>>    herein
>>>    >> is strictly prohibited.
>>>    >>
>>>    >> This e-mail does not constitute an order for goods or services
>>>    unless
>>>    >> accompanied by an official purchase order.
>>>    >
>>>    >
>>>    > --
>>>    > Arthur Taylor, ATS Advanced Telematic Systems GmbH
>>>    > Kantstrasse 162, 10623 Berlin
>>>    > Managing Directors: Dirk P?schl, Armin G. Schmidt
>>>    > Register Court: HRB 151501 B, Amtsgericht Charlottenburg
>>>    >
>>>    >
>>>    >
>>>    > ------------------------------
>>>    >
>>>    > Message: 4
>>>    > Date: Wed, 25 May 2016 06:09:26 -0700
>>>    > From: "Kumar-Mayernik, Nisha" <nkumarm1 at jaguarlandrover.com
>>>    <mailto:nkumarm1 at jaguarlandrover.com>>
>>>    > To: Arthur Taylor <arthur at advancedtelematic.com
>>>    <mailto:arthur at advancedtelematic.com>>
>>>    > Cc:genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    > Subject: Re: Error when trying to run the SOTA server
>>>    > Message-ID:
>>>    >
>>>     <CANLsUs5ud95h3q6b92huccOir0jckbfw6t6O0_F=Svyxw-H_5Q at mail.gmail.com
>>>    <mailto:Svyxw-H_5Q at mail.gmail.com>>
>>>    > Content-Type: text/plain; charset="utf-8"
>>>    >
>>>    > Arthur, I appreciate the quick response. Thanks!
>>>    >
>>>    > *Nisha Kumar-Mayernik*
>>>    > Software Developer
>>>    >
>>>    >
>>>    >
>>>    > *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA*
>>>    > *jaguar.com <http://jaguar.com/><http://jaguar.com/>  |
>>>    landrover.com <http://landrover.com/><http://landrover.com/>*
>>>    >
>>>    > Business Details:
>>>    > Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK
>>>    > Registered in England Number: 1672070
>>>    >
>>>    > This e-mail and any attachments contain confidential information
>>>    for a
>>>    > specific individual and purpose.  The information is private and
>>>    privileged
>>>    > and intended solely for the use of the individual to whom it is
>>>    addressed.
>>>    > If you are not the intended recipient, please e-mail us
>>>    immediately.  We
>>>    > apologize for any inconvenience caused but you are hereby
>>>    notified that any
>>>    > disclosure, copying or distribution or the taking of any action
>>>    in reliance
>>>    > on the information contained herein is strictly prohibited.
>>>    >
>>>    > This e-mail does not constitute an order for goods or services
>>>    unless
>>>    > accompanied by an official purchase order.
>>>    >
>>>    >> On 25 May 2016 at 06:01, Arthur Taylor
>>>    <arthur at advancedtelematic.com
>>>    <mailto:arthur at advancedtelematic.com>> wrote:
>>>    >>
>>>    >> Hi Nisha,
>>>    >>
>>>    >> Thanks for the report. We're investigating. We think it's
>>>    related to the
>>>    >> recent changes we made to add LDAP support.
>>>    >>
>>>    >> We're hoping to get a resolution or update today - will let you
>>>    know as
>>>    >> soon as we have something.
>>>    >>
>>>    >> Thanks,
>>>    >>
>>>    >> Arthur
>>>    >>
>>>    >>> On 25/05/16 14:27, Kumar-Mayernik, Nisha wrote:
>>>    >>> Hi Arthur,
>>>    >>>
>>>    >>> I tried to set up a SOTA server locally on my dev machine. I am
>>>    >>> getting this error:
>>>    >>>
>>>    >>> ProvisionException: Unable to provision, see the following errors:
>>>    >>>
>>>    >>> 1) Error injecting constructor,
>>>    java.lang.IllegalArgumentException:
>>>    >>> requirement failed: Key store file certs/client.jks does not
>>>    exist!
>>>    >>> at
>>>    >>>
>>>    org.genivi.webserver.Authentication.LdapAuth.<init>(LdapAuth.scala:35)
>>>    >>> at
>>>    >>
>>>    org.genivi.webserver.Authentication.LdapAuth.class(LdapAuth.scala:35)
>>>    >>> while locating org.genivi.webserver.Authentication.LdapAuth
>>>    >>>   for parameter 2 at
>>>    >>>
>>>    org.genivi.webserver.controllers.Application.<init>(Application.scala:29)
>>>    >>> while locating org.genivi.webserver.controllers.Application
>>>    >>>   for parameter 1 at router.Routes.<init>(Routes.scala:35)
>>>    >>> while locating router.Routes
>>>    >>> while locating play.api.inject.RoutesProvider
>>>    >>> while locating play.api.routing.Router
>>>    >>>
>>>    >>> 1 error
>>>    >>>
>>>    >>> Any ideas? I am using the docs here:
>>>    >>>http://genivi.github.io/rvi_sota_server/doc/building-installing.html.
>>>    >>> I am running this on Ubuntu 16.04.
>>>    >>>
>>>    >>> Thanks
>>>    >>> *Nisha Kumar-Mayernik*
>>>    >>> Software Developer
>>>    >>>
>>>    >>>
>>>    >>>
>>>    >>> *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209,
>>>    USA*
>>>    >>> *jaguar.com <http://jaguar.com/><http://jaguar.com/>  |
>>>    landrover.com <http://landrover.com/>
>>>    >>> <http://landrover.com/>*
>>>    >>>
>>>    >>> Business Details:
>>>    >>> Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3
>>>    4LF, UK
>>>    >>> Registered in England Number: 1672070
>>>    >>>
>>>    >>> This e-mail and any attachments contain confidential
>>>    information for a
>>>    >>> specific individual and purpose.  The information is private and
>>>    >>> privileged and intended solely for the use of the individual
>>>    to whom
>>>    >>> it is addressed.  If you are not the intended recipient,
>>>    please e-mail
>>>    >>> us immediately.  We apologize for any inconvenience caused but
>>>    you are
>>>    >>> hereby notified that any disclosure, copying or distribution
>>>    or the
>>>    >>> taking of any action in reliance on the information contained
>>>    herein
>>>    >>> is strictly prohibited.
>>>    >>>
>>>    >>> This e-mail does not constitute an order for goods or services
>>>    unless
>>>    >>> accompanied by an official purchase order.
>>>    >>
>>>    >>
>>>    >> --
>>>    >> Arthur Taylor, ATS Advanced Telematic Systems GmbH
>>>    >> Kantstrasse 162, 10623 Berlin
>>>    >> Managing Directors: Dirk P?schl, Armin G. Schmidt
>>>    >> Register Court: HRB 151501 B, Amtsgericht Charlottenburg
>>>    > -------------- next part --------------
>>>    > An HTML attachment was scrubbed...
>>>    > URL:
>>>    <http://lists.genivi.org/pipermail/genivi-projects/attachments/20160525/6dd5e2ba/attachment.html>
>>>    >
>>>    > ------------------------------
>>>    >
>>>    > _______________________________________________
>>>    > genivi-projects mailing list
>>>    >genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    >https://lists.genivi.org/mailman/listinfo/genivi-projects
>>>    >
>>>    >
>>>    > End of genivi-projects Digest, Vol 14, Issue 75
>>>    > ***********************************************
>>> 
>>> 
>>>    Disclaimer: This message and any files or text attached to it are
>>>    intended only for the recipients named above and contain
>>>    information that may be confidential or privileged. If you are not
>>>    an intended recipient, you must not forward, copy, use or
>>>    otherwise disclose this communication or the information contained
>>>    herein. In the event you have received this message in error,
>>>    please notify the sender immediately by replying to this message,
>>>    and then delete all copies of it from your system. Thank you.
>>>    _______________________________________________
>>>    genivi-projects mailing list
>>>    genivi-projects at lists.genivi.org
>>>    <mailto:genivi-projects at lists.genivi.org>
>>>    https://lists.genivi.org/mailman/listinfo/genivi-projects
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Jeremiah C. Foster
>>> GENIVI COMMUNITY MANAGER
>>> 
>>> Pelagicore AB
>>> Ekelundsgatan 4, 6tr, SE-411 18
>>> Gothenburg, Sweden
>>> M: +46 (0)73 093 0506
>>> jeremiah.foster at pelagicore.com <mailto:jeremiah.foster at pelagicore.com>
>>> 
>>> <PELAGICORE_RGB_Black_horizontal.png>
>> 
>> 
>> 
>> _______________________________________________
>> genivi-projects mailing list
>> genivi-projects at lists.genivi.org
>> https://lists.genivi.org/mailman/listinfo/genivi-projects
> 
> -- 
> Agustin Benito Bethencourt
> Principal Consultant - FOSS at Codethink
> agustin.benito at codethink.co.uk



More information about the genivi-projects mailing list