Tizen IVI GENIVI work

[Ylinen, Mikko]

All,

The release we made yesterday contains a lot of GENIVI stuff we've
been working on.

Since that may not be visible to everybody, I've created a GENIVI summary
wiki page to highlight the work items:
https://wiki.tizen.org/wiki/IVI/GENIVI

Especially the Murphy team has put huge effort in finishing the integration
of two
key GENIVI OSS components in Tizen:

- Audio manager w/ Murphy controller plugin
- Compositor: weston + ivi-shell + LayerManagement + Murphy system
controller

Additionally, we've enable 64bit target including all GENIVI OSS compoents.
This
required some extra fixing due to build issues. The patches are not yet
submitted
GENIVI OSS upstream.

Short term plans:

- improve lifecycle integration (TC-1646)
- write a CommonAPI C++ Tizen HOWTO

-- Mikko
___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

wrt-plugins-ivi-bt test.

[McGee, Art]

I'm looking for pre-existing test wgit's for the bluetooth and phone api.

Thanks.

-- 
*Art McGee*
Infotainment Engineer



Jaguar Land Rover North America, LLC
1419 NW 14th Ave, Portland, Oregon, 97209
JaguarUSA.com   |  LandRoverUSA.com

___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Re: Tizen IVI 3.0-M3-Oct2014 has been released

[Rees, Kevron]

W00t!  Congrats.

On Thu, Oct 30, 2014 at 1:20 PM, Hofemeier, Ulf  wrote:
> The IVI team is pleased to announce the release of the Tizen IVI
> 3.0-M3-Oct2014 Release for In-Vehicle Infotainment.
>
> With this release we deliver a much improved Modello UI experience. The OS
> is available in 32-bit and 64-bit backed by a Long Term Support Initiative
> Linux kernel. The multi-user application framework has support for
> single/all-user app deployment scenarios. Developing applications for
> Modello is easier than ever using the Tizen_IVI_SDK with support for vehicle
> webAPIs powered by Crosswalk. For lower level development Automotive Message
> Broker (AMB) contains CAN plugin generator tools and a JavaScript engine for
> rapid plugin prototyping. System resources are now handled by Murphy.
> MinnowBoard MAX will run this latest installment of Tizen IVI 3.0 M3 and
> offers customers an affordable entry-level SDP.
>
> We are also excited to announce the availability of our new Tizen IVI
> project landing page hosted on Tizen.org. This landing page provides quick
> and easy access to everything you need to get started with Tizen IVI. If you
> would like to reach out you can find us on the Freenode.net IRC #automotive
> chat channel.
>
> Note: The engineering name for this release in JIRA is M14.3 but its
> official name is Tizen IVI 3.0-M3-Oct2014
>
>
>
> The complete release notes are available here:
>
> https://wiki.tizen.org/wiki/IVI/Tizen-IVI_3.0-M3-Oct2014
>
>
>
> For more information about the Tizen for In-Vehicle-Infotainment (IVI)
> project, please go and visit our new landing page on Tizen.org at:
> https://www.tizen.org/ivi.
>
>
>
>
>
> Regards,
>
>
>
> Ulf (on behalf of the Tizen IVI team)
>
> Technical Marketing Engineer
>
> System Software Division
>
>
>
>
>
>
> ___
> IVI mailing list
> IVI@lists.tizen.org
> https://lists.tizen.org/listinfo/ivi
>
___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Tizen IVI 3.0-M3-Oct2014 has been released

[Hofemeier, Ulf]

The IVI team is pleased to announce the release of the Tizen IVI 3.0-M3-Oct2014 
Release for In-Vehicle Infotainment.

With this release we deliver a much improved Modello UI experience. The OS is 
available in 32-bit and 64-bit backed by a Long Term Support 
Initiative Linux kernel. The multi-user 
application framework has support for single/all-user app deployment 
scenarios. 
Developing applications for Modello is easier than ever using the 
Tizen_IVI_SDK with support for 
vehicle webAPIs 
powered by Crosswalk. For lower level 
development Automotive Message Broker 
(AMB) contains CAN plugin generator 
tools and a JavaScript engine for rapid plugin prototyping. System resources 
are now handled by Murphy. MinnowBoard 
MAX will run this latest 
installment of Tizen IVI 3.0 M3 and offers customers an affordable entry-level 
SDP.

We are also excited to announce the availability of our new Tizen 
IVI project landing 
page hosted on Tizen.org. This landing page provides quick and easy access to 
everything you need to get started with Tizen 
IVI. If you would 
like to reach out you can find us on the Freenode.net 
IRC #automotive chat channel.

Note: The engineering name for this release in JIRA is 
M14.3 but its official name is Tizen IVI 3.0-M3-Oct2014

The complete release notes are available here:
https://wiki.tizen.org/wiki/IVI/Tizen-IVI_3.0-M3-Oct2014

For more information about the Tizen for In-Vehicle-Infotainment (IVI) project, 
please go and visit our new landing page on Tizen.org at: 
https://www.tizen.org/ivi.


Regards,

Ulf (on behalf of the Tizen IVI team)
Technical Marketing Engineer
System Software Division


___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Re: Tizen and GENIVI yocto layers, and future of IVI builds

[Dominig Ar Foll]

for info :copy of my response to Genivi list.

>
> > As long as Genivi is happy to work without any security, that will
> > work.
>
> That's a very silly statement, Dominig.  Are you nowadays trying to make
> cooperation difficult, or is it only by mistake?


>
>

It might just be control of nuances in language, I do like to been
seen silly but in my experience, today most of embedded projects are
not setup with an internal security model. Trusted Boot and closes
input/output has delivered what was needed until now.
Running all a system as root is still a common practice from many well
respected project.
I am not willing to make things difficult, I just wanted to express
that not implementing an internal security model was still a valid
option and plenty of people were still happy with it.

>
> After all it's not the
> first instance in recent times I hear you using misleading language constructs
> in some apparent attempt to discredit GENIVI.  Do you see the GENIVI Alliance
> a competitor to Tizen or something?  When we have talked before I thought you
> understood what GENIVI actually does, so I don't understand why you would
> think that now?

I would hope that this is not the case, I have been putting a lot of
effort and involved several of Tizen engineers to make sure that Tizen
model was well understood and that we were understanding your
requirement in order for Tizen to remain compliant with Genivi
specifications. Tizen has no goal to write Spec neither to create
certification.
Tizen is proud to claim it's compliance with Genivi, it would be silly
to discredit it.
>
>
> It also makes little sense, so it seems you took the chance to comment for
> another reason.  I know you understand as well as anybody that particular
> implementation details should be kept independent of the general build
> instructions, such that generic layers are possible.

We discussed Genivi model in Vannes and I understand that Tizen
position is simpler because, we can afford direct choice. Tizen goal
is to be Genivi compliant not to be Genivi spec.

>
>   If any security related
> details ultimately _must_ influence the original component (its source or its
> build recipes) then this ought to be carefully designed taking into account
> the upstream where the shared home is.  Meta-openembedded is one of the
> defacto homes for shared Yocto build recipes and I see no reason why it could
> not continue to play a part in a secure system considering the ability to
> design using both .bb and .bbappends.  But if you can, please provide more
> explanation, leaving out any childish cheapshots.

This was the topic of my presentation at Linux Con in Düsseldorf, so I
can only agree with you, it can be done but it is invasive, so you
cannot bolt it after the fact.
>
>
> At another time maybe there is time to explain what GENIVI actually does in
> terms of security work which is significant but I don't know if there is
> interest to listen.

I am interested enough to have taken the time to provide feedback on
your initial spec. It is in my (and Tizen) interest that security
become important in Genivi because it would drive both of the projects
to focus on a key common ground.

>
>  Everyone would have to stop throwing around this big
> word "security" however and starting saying _access control_ when we are
> talking about that, and use other precise terms when we are talking about
> other things.

You are right, the short cut is a bit simple, but some time simple
word helps to keep focus. A trade off which is not always ideal.

In the mean time, if my response was badly received, I would like to
apologize for the lack of clarity. Tizen interest is to work with
Genivi and we still aim at not only be compliant but to be the most
attractive implementation of a Genivi compliant system.


>
> Dominig


2014-10-30 17:54 GMT+01:00 Andersson, Gunnar :
> Dominig,
>
>> From: Dominig Ar Foll [mailto:dominig.arf...@fridu.net]
>> Sent: den 24 oktober 2014 04:06
>> To: Andersson, Gunnar
>> Cc: genivi-...@mail.genivi.org; ivi@lists.tizen.org; Bourcier, Frédéric
>> (frederic.bourc...@windriver.com)
>> Subject: Re: Tizen and GENIVI yocto layers, and future of IVI builds
>>
>> 2014-10-22 17:04 GMT+02:00 Andersson, Gunnar
>> :
>> > Hello all
>> >
>> >
>> > OTOH meta-tizen seems a bit intrusive to me. It appears to essentially
>> > repackage a lot of components using its own build scripts, including
>> > the adopted GENIVI components.
>> >
>> > The reasons might be, (and I'm speculating here so feel free to set me
>> > straight), that conversion from OBS to Yocto was made in a quick fashion,
>> and
>> > IIRC using some auto-translation.
>>
>> This is correct but will not stay like that. We have selected a two
>> steps approach, the first one by using a translator from OBS to Yocto
>> (spec2yocto project) we have enabled the creation of a valid image in
>> order to understand what was missing in Yocto to enable the building
>> of an image with all the Tize

RE: Tizen and GENIVI yocto layers, and future of IVI builds

[Andersson, Gunnar]

Dominig,

> From: Dominig Ar Foll [mailto:dominig.arf...@fridu.net]
> Sent: den 24 oktober 2014 04:06
> To: Andersson, Gunnar
> Cc: genivi-...@mail.genivi.org; ivi@lists.tizen.org; Bourcier, Frédéric
> (frederic.bourc...@windriver.com)
> Subject: Re: Tizen and GENIVI yocto layers, and future of IVI builds
> 
> 2014-10-22 17:04 GMT+02:00 Andersson, Gunnar
> :
> > Hello all
> >
> >
> > OTOH meta-tizen seems a bit intrusive to me. It appears to essentially
> > repackage a lot of components using its own build scripts, including
> > the adopted GENIVI components.
> >
> > The reasons might be, (and I'm speculating here so feel free to set me
> > straight), that conversion from OBS to Yocto was made in a quick fashion,
> and
> > IIRC using some auto-translation.
> 
> This is correct but will not stay like that. We have selected a two
> steps approach, the first one by using a translator from OBS to Yocto
> (spec2yocto project) we have enabled the creation of a valid image in
> order to understand what was missing in Yocto to enable the building
> of an image with all the Tizen security features. This phase has
> allowed us to add all the required features in Yocto 1.7 which is in
> RC candate stage as we speak.
> 
> The second phase has just started and covers two areas :
>   - the alignement where possible (in regard of Tizen security model)
> of Yocto and Tizen packages version (a mail was sent in the Tizen Dev
> mailing list with the upgrade candidates).
>   - alignment of the tizen-Meta layer toward a more traditional Yocto fashion.
> 
> > This strategy might also make Tizen more independent which could be a risk
> management strategy.  But unless I'm
> > mistaken it is taking a step away from the layered approach that OE/Yocto
> > really aims for?
> 
> No, that is not the case, it's just a side effect of the step approch
> described earlier.
> 
> If combining for example meta-tizen and other layers (like
> > meta-ivi) wouldn't this trigger a lot of work to indicate which recipe for
> > each component you want bitbake to select, if they exist in multiple layers?
> (I
> > am guessing here, haven't tried it).
> 
> Yocto manages that situation quite well. But as explained before,
> beside of the packagres affected by the security model, full alignment
> is the selected working model.
> >
> > In terms of naming, the current content of meta-ivi suggests it should 
> > really
> > be seen as a "meta-genivi".  (When GENIVI started there was no reason to
> > believe this wouldn't be the one and only layer for IVI extensions).  But 
> > note
> > that -genivi in this case would mean only the new software projects that
> were
> > started in GENIVI, not the whole scope of the GENIVI specification!
> > Adopted components are typically built using standard layers, meta-oe,
> > meta-multimedia etc.
>
> As long as Genivi is happy to work without any security, that will
> work. 

That's a very silly statement, Dominig.  Are you nowadays trying to make
cooperation difficult, or is it only by mistake?  After all it's not the
first instance in recent times I hear you using misleading language constructs
in some apparent attempt to discredit GENIVI.  Do you see the GENIVI Alliance
a competitor to Tizen or something?  When we have talked before I thought you
understood what GENIVI actually does, so I don't understand why you would
think that now?

It also makes little sense, so it seems you took the chance to comment for
another reason.  I know you understand as well as anybody that particular
implementation details should be kept independent of the general build
instructions, such that generic layers are possible.  If any security related
details ultimately _must_ influence the original component (its source or its
build recipes) then this ought to be carefully designed taking into account
the upstream where the shared home is.  Meta-openembedded is one of the
defacto homes for shared Yocto build recipes and I see no reason why it could
not continue to play a part in a secure system considering the ability to
design using both .bb and .bbappends.  But if you can, please provide more
explanation, leaving out any childish cheapshots.

At another time maybe there is time to explain what GENIVI actually does in
terms of security work which is significant but I don't know if there is
interest to listen.   Everyone would have to stop throwing around this big
word "security" however and starting saying _access control_ when we are
talking about that, and use other precise terms when we are talking about
other things. 

> As Poky has no security model, you cannot build a secured distro
> directly on top of Poky (Security is invasive and must be built in).
> >
> > One could propose to rename the layer to meta-genivi but in the long term
> as
> > GENIVI-initiated implementation projects become adopted, the distinction
> of
> > which project they belong to would be of less importance.  I'm hoping the
> same
> > would hold true for Tizen IVI

Re: [Dev] Issues with latest emulator image on qemu-yagl

[Monika Kistler]

Hi Vasily,

sorry for the delayed answer, I've been out of office since last
Thursday.

On Thu, 2014-10-23 at 14:11 +0400, Vasily Ulyanov wrote: 
> Hi, Monika.
> 
> If it is still relevant for you, actaully there are few ways to run tizen
> emulator on other Linux distros. Though they are a bit tricky...

At the moment I'm working on another topic, so it's not really relevant
anymore. By the time it was, I finally used the emulator on an Ubuntu
vm, which worked perfectly well.

> 1) You can install a minimal Ubuntu system in a chroot and then perform
> a typical tizen SDK istallation from there. Thre are tools which make the
> process a lot easier (e.g. debootstrap). I also want to find some time
> and try it out. In theory everything should work with such an approach.

I tried that (using debootstrap) before I found the qemu-yagl solution,
but it didn't work for me. Cannot remember what the issue was though.
Maybe I should give it another try some time. 

> 2) If you have the SDK already installed on another machine (or perhaps
> in a chroot) you can simply move it to your system (e.g. using tar/untar).
> You will just need to update tizen-sdk/sdk.info with valid paths.
> Perhaps some manipulations with libraries/linker vars (e.g. LD_LIBRARY_PATH)
> may also be required (depends on what you have installed in your system).
> 
> 3) Build the emulator from sources.
> 
> Anyway from what I can see the main problem is to get tizen SDK installed.
> I use Gentoo Linux and sometimes on my system the SDK installer simply reports
> an error in the middle of the installation and terminates... and actually
> unpacking all the necessary packages by hand is a bit tedious. So currently 
> the
> 2nd and the 3rd approaches work quite well for me.

Thank you very much for these insights, if I need the emulator running
natively again, I'll certainly give those approaches a try.

Thanks a lot,
Moni


___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Re: [Dev] Issues with latest emulator image on qemu-yagl

[Monika Kistler]

Hi Sangho,

sorry for the delayed answer, I've been out of office since last
Thursday.

Thank you very much for offering your help. I'm very sorry having to say
though, that I'm currently working on another topic and won't have a lot
of time to spend on this issue. At the time I needed the emulator
running, I chose to use the standalone emulator in an Ubuntu 14.04
vm, which worked perfectly well.

When I tried the standalone emulator on openSUSE, I used
standalone-emulator_20140923_ubuntu-64.zip, which I downloaded here:
http://download.tizen.org/sdk/IVI/m14.2/standalone-emulator/standalone-emulator_20140923_ubuntu-64.zip

With that I only get the following logs:
* emulator.klog
* emulator.log
* emulator-skin.log

Find these logs attached. But please do not spent too much time on them,
if at all, as I'm currently not in any need to get the emulator running
on openSUSE.

By the time I find some time to further investigate on the emulator
issue, I'd report back here and also add some comments in the wiki.

Cheers,
Moni

On Thu, 2014-10-23 at 14:07 +0900, Sangho Park wrote: 
> Hi, Monika
> 
> Even though tizen emulator does not officially support openSUSE, could you
> send emulator logs on openSUSE so that we might help you?
> The logs may located at
> ~/tizen-sdk-data/emulator/emulator-manager.log
> ~/tizen-sdk-data/emulator/vms/{VM_NAME}/logs/*
> 
> Thanks,
> Sangho Park
> -Original Message-
> From: IVI [mailto:ivi-boun...@lists.tizen.org] On Behalf Of Monika Kistler
> Sent: Thursday, October 09, 2014 8:49 PM
> To: Ylinen, Mikko
> Cc: ivi@lists.tizen.org
> Subject: Re: [Dev] Issues with latest emulator image on qemu-yagl
> 
> Hi Mikko, 
> 
> On Thu, 2014-10-09 at 09:22 +0300, Ylinen, Mikko wrote: 
> > We recently made it slightly easier for developers to use the Emulator 
> > images without having to install the full SDK. For that, you need to 
> > follow https://wiki.tizen.org/wiki/Tizen_Standalone_Emulator
>  
> thanks a lot for pointing me to the standalone emulator. I already came
> across this page when searching for a solution to my problem. But I still
> chose to give the community qemu-yagl another try, because I have a native
> openSUSE 13.1 installation and the qemu-yagl solution let me run the
> emulator image directly on my native installation.
> 
> I tried to run the standalone emulator on Suse and after some tweaking with
> the libraries it even started up, but then I don't get any UI just a black
> screen. 
> 
> In the meanwhile I tried out the standalone emulator in an Ubuntu 14.04 vm
> and it does work out of the box. That helps for now, to get my job done. But
> I still prefer having the emulator run directly on my developing machine. As
> soon as I find some time to further investigate here, I'll try to get it
> running. If I succeed, I would add it to the Wiki pages and also report back
> here.
> 
> Thanks,
> Moni
> 
> ___
> IVI mailing list
> IVI@lists.tizen.org
> https://lists.tizen.org/listinfo/ivi
> 



standalone-emulator-logs.tar.bz2
Description: application/bzip-compressed-tar
___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi

Re: Application Framework documentation / HOWTO

[Monika Kistler]

Great work, thanks a bunch, this wiki is really helpful. :)


On Fri, 2014-10-24 at 14:42 +0200, Baptiste Durand wrote: 
> Hi all, 
> 
> 
> I've recently created a wiki page about application Framework
> 
> https://wiki.tizen.org/wiki/Application_framework
> 
> 
> We can find HOWTO Section that provides a good way to launch /
> kill /install / uninstall  applications etc...
> 
> 
> open_app has disapeared (https://bugs.tizen.org/jira/browse/TC-1883)
> it has been replaced by app_launcher 
> 
> 
> open_app is avaible only if you install aul-test package
> 
> 
> 
> So now on Tizen Common image & for the next IVI image (delay can be
> expected due to sync process).
> 
> 
> Here is an extract of the HOWTO section
> 
> Packages Management 
> 
> Installation 
>  pkgcmd -i -t  -p  (-G) (-q)
>  Uninstallation 
>  pkgcmd -u -n  (-G) (-q)  // NOTE the pkgid should be used NOT the 
> appid.
>  List the installed packages 
>  pkgcmd -l
>  Kill all applications associated to a package ID (usefull in case of 
> uninstallation)
>  pkgcmd -k -n 
> 
> 
> 
> 
> Applications Management 
> Legacy HOWTO Tizen IVI 14.3 Release: 
> 
>  list available application IDs
>  ail_list
>  launch an application
>  open_app 
>  launch an application with debug mode
>  open_app  -d
> 
> 
> 
> There is a new app_launcher tool (Feature TC-1883) on Tizen Common.
> 
>  list available application IDs
>  app_launcher -l
>  launch an application
>  app_launcher -s 
>  launch an application with debug mode
>  app_launcher -s  -d
>  Get all running applications of the current user
>  app_launcher -S
>  kill an app
>  app_launcher -k 
>  Status of a specific app
>  app_launcher -r 
> 
> BR 
> 
> Baptiste
> 
> -- 
> Baptiste DURAND
> Eurogiciel Vannes/FR
> ___
> IVI mailing list
> IVI@lists.tizen.org
> https://lists.tizen.org/listinfo/ivi


___
IVI mailing list
IVI@lists.tizen.org
https://lists.tizen.org/listinfo/ivi