Re: [yocto] Yocto "Long Term Support"

[Burton, Ross]

On 6 November 2016 at 15:33, Vuille, Martin (Martin) 
wrote:

> Has there ever been any discussion of making select releases
>
> “Long Term Support” releases, i.e., committing to support them
>
> for a number of years?
>
>
>
> Presumably that would entail having the resources to commit
>
> a maintainer to that release for the LTS interval.
>

Currently the Yocto Project commits to supporting the previous two releases
with security fixes.  If you want a longer life-cycle than that then it is
recommended to approach one of the many OSVs who support Yocto Project
derived build systems, such as Wind River / Mentor Graphics / ENEA / more.
These will have longer support cycles, at least one has the option of ten
years for security and critical bug fixes.

Out of curiosity, how much effort is required (on average) to
>
> maintain a non-current release with at least CVEs and maybe
>
> critical bug fixes from upstream?
>

Just CVEs requires a part-time person.  Tracking all upstreams for
non-security but critical bug fixes would be far more effort.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto "Long Term Support"

[Burton, Ross]

On 7 November 2016 at 09:09, Burton, Ross  wrote:

> Currently the Yocto Project commits to supporting the previous two
> releases with security fixes.  If you want a longer life-cycle than that
> then it is recommended to approach one of the many OSVs who support Yocto
> Project derived build systems, such as Wind River / Mentor Graphics / ENEA
> / more.  These will have longer support cycles, at least one has the option
> of ten years for security and critical bug fixes.
>

I should follow up by saying that
https://www.yoctoproject.org/ecosystem/member-organizations is a list of
everyone who is a member of the Yocto Project, and lists most of the OSVs
that support YP.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] ref-manual: fix typo

[Andrea Galbusera]

Signed-off-by: Andrea Galbusera 
---
 documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml 
b/documentation/kernel-dev/kernel-dev-advanced.xml
index 9e15f17..ed982fb 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -256,7 +256,7 @@
 When stored outside of the recipe-space, the kernel Metadata
 files reside in a separate repository.
 The OpenEmbedded build system adds the Metadata to the build as
-a "ktype=meta" repository through the
+a "type=kmeta" repository through the
 SRC_URI
 variable.
 As an example, consider the following SRC_URI
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] UTF-89 support

[Keskinarkaus, Teemu]

Hi,

I tried googling this and reading the manual, but I guess this is too trivial 
or I'm doing something wrong.

I'm trying to get UTF-8 support to my image. UTF-8 locale more specific. If I 
run locale -a command I get these locales listed:
C
POSIX
en_GB
en_US

I added this line to my local.conf:
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"

That didn't bring UTF-8 locales although by looking at the comment I would 
assume they should be already there?  I'm not entirely sure why the UTF-8 
locales are still missing and how do I get them there?


Teemu Keskinarkaus
Software system engineer
Cell: +358 400 330047
Fax: +358 207 669199
www.crosscontrol.com
CrossControl
making machines smart, safe and productive




Actuant Corporation Email Notice

This message is intended only for the use of the Addressee and may contain 
information that is PRIVILEGED and/or CONFIDENTIAL.
This email is intended only for the personal and confidential use of the 
recipient(s) named above. If the reader of this email is not an intended 
recipient, you have received this email in error and any review, dissemination, 
distribution or copying is strictly prohibited.
If you have received this email in error, please notify the sender immediately 
by return mail and permanently delete the copy you received.

Thank you.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] UTF-89 support

[Daniel.]

2016-11-07 9:48 GMT-02:00 Keskinarkaus, Teemu
:
> Hi,
>
>
>
> I tried googling this and reading the manual, but I guess this is too
> trivial or I’m doing something wrong.
>
>
>
> I’m trying to get UTF-8 support to my image. UTF-8 locale more specific. If
> I run locale –a command I get these locales listed:
>
> C
>
> POSIX
>
> en_GB
>
> en_US
>
>
>
> I added this line to my local.conf:
>
> GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"
>
>
>
> That didn’t bring UTF-8 locales although by looking at the comment I would
> assume they should be already there?  I’m not entirely sure why the UTF-8
> locales are still missing and how do I get them there?
>
>
>
>
>
> Teemu Keskinarkaus
> Software system engineer
> Cell: +358 400 330047
> Fax: +358 207 669199
> www.crosscontrol.com
>
> CrossControl
>
> making machines smart, safe and productive
>
>
>
>
> 
>
> Actuant Corporation Email Notice
>
> This message is intended only for the use of the Addressee and may contain
> information that is PRIVILEGED and/or CONFIDENTIAL.
> This email is intended only for the personal and confidential use of the
> recipient(s) named above. If the reader of this email is not an intended
> recipient, you have received this email in error and any review,
> dissemination, distribution or copying is strictly prohibited.
> If you have received this email in error, please notify the sender
> immediately by return mail and permanently delete the copy you received.
>
> Thank you.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Did you setted ENABLE_BINARY_LOCALE_GENERATION?

From 
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/glibc/glibc-locale.inc

> # Binary locales are generated at build time if 
> ENABLE_BINARY_LOCALE_GENERATION
> # is set. The idea is to avoid running localedef on the target (at first boot)
> # to decrease initial boot time and avoid localedef being killed by the OOM
> # killer which used to effectively break i18n on machines with < 128MB RAM.
>
> # default to disabled
> ENABLE_BINARY_LOCALE_GENERATION ?= "0"

-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Burton, Ross]

Hi Scott,

On 3 November 2016 at 20:21, Scott Rifenbark  wrote:

> See http://www.yoctoproject.org/docs/2.2/ref-manual/ref-
> manual.html#detailed-supported-distros and let me know if this is okay.
> If so, I will make sure the same commit is on my yocto-docs/morty branch.
> I updated master only for now
>


Both of the suse entries should be styled a "openSUSE ", the
change of case is due to technical nonsense and not what the user will see.

Apart from that, looks good.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] UTF-89 support

[Khem Raj]

On 11/7/16 3:48 AM, Keskinarkaus, Teemu wrote:
> Hi,
> 
>  
> 
> I tried googling this and reading the manual, but I guess this is too trivial
> or I’m doing something wrong.
> 
>  
> 
> I’m trying to get UTF-8 support to my image. UTF-8 locale more specific. If I
> run locale –a command I get these locales listed:
> 
> C
> 
> POSIX
> 
> en_GB
> 
> en_US
> 
>  
> 
> I added this line to my local.conf:
> 
> GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"

you also need to set IMAGE_LINGUAS to include it into image
e.g.

GLIBC_GENERATE_LOCALES = "en-gb"

> 
>  
> 
> That didn’t bring UTF-8 locales although by looking at the comment I would
> assume they should be already there?  I’m not entirely sure why the UTF-8
> locales are still missing and how do I get them there?
> 
>  
> 
>  
> 
> *Teemu Keskinarkaus
> *Software system engineer*
> *Cell: +358 400 330047*
> *Fax: +358 207 669199*
> *www.crosscontrol.com **
> 
> *CrossControl*
> 
> making machines smart, safe and productive
> 
>  
> 
> 
> --
> 
> Actuant Corporation Email Notice
> 
> This message is intended only for the use of the Addressee and may contain
> information that is PRIVILEGED and/or CONFIDENTIAL.
> This email is intended only for the personal and confidential use of the
> recipient(s) named above. If the reader of this email is not an intended
> recipient, you have received this email in error and any review,
> dissemination, distribution or copying is strictly prohibited.
> If you have received this email in error, please notify the sender immediately
> by return mail and permanently delete the copy you received.
> 
> Thank you.
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Supported "init" types

[Vuille, Martin (Martin)]

I see that "sysvinit" and "systemd" style init is supported.

Is there support for BSD-style init, or some other minimal init?

Does anyone know of such support in a separate layer?

MV
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Supported "init" types

[Khem Raj]

On 11/7/16 9:27 AM, Vuille, Martin (Martin) wrote:
> I see that “sysvinit” and “systemd” style init is supported.
> 
>  
> 
> Is there support for BSD-style init, or some other minimal init?
> 
>

there is busybox/mdev init option in OE-core if you are looking for
a minimal init and not specifially for BSD init.

its documented in meta/conf/local.conf.sample.extended

#
# Use busybox/mdev for system initialization
#
#VIRTUAL-RUNTIME_dev_manager = "busybox-mdev"
#VIRTUAL-RUNTIME_login_manager = "busybox"
#VIRTUAL-RUNTIME_init_manager = "busybox"
#VIRTUAL-RUNTIME_initscripts = "initscripts"
#VIRTUAL-RUNTIME_keymaps = "keymaps"
#DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"


> 
> Does anyone know of such support in a separate layer?



> 
>  
> 
> MV
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Supported "init" types

[Vuille, Martin (Martin)]

> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: November 07, 2016 12:37
> 
> On 11/7/16 9:27 AM, Vuille, Martin (Martin) wrote:
> > I see that “sysvinit” and “systemd” style init is supported.
> >
> >
> >
> > Is there support for BSD-style init, or some other minimal init?
> >
> >
> 
> there is busybox/mdev init option in OE-core if you are looking for a minimal
> init and not specifially for BSD init.
> 
> its documented in meta/conf/local.conf.sample.extended
> 

Thanks! Just what I was looking for.

Regards,
MV
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to handle meta-intel/openembedded repos with multiple developers

[Chris Z.]

Hi,

How you store your project configuration ? How you prepare workspace
(download each layer separately)?
Basic stuff, SW release should be reproducible (in easy way). Store
somewhere used hash of each piece or use tags. Non company assets should be
already somehow tagged or you use HEAD or master/-next ?

Br,
Chris Z

On Thu, Oct 27, 2016 at 8:22 AM, Edward Wingate 
wrote:

> On Thu, Mar 3, 2016 at 8:27 AM, Mark Hatle 
> wrote:
> >  At some point during product development a lead/architect needs to make
> the
> > decision to 'freeze' development and at that point everything is
> tagged/branched
> > and only backports are used from them on.  (If the number of backports
> gets too
> > large, you MIGHT decide to selectively rebase.)
>
> I'm currently trying to figure out with how to control external layers
> in my Yocto build and found this thread.  I'm a little unclear on how
> to track a release to the version used on non-company layers.  Say I'm
> using poky, meta-openembedded, meta-xilinx and then my own layer,
> meta-me. When I freeze development and do a release, I can tag
> meta-me, but because I also treat non-company assets as RO, I
> shouldn't tag poky, meta-openembedded nor meta-xilinx (or should I? Is
> this where I use git's lightweight tagging as opposed to annotated
> tags?) When "everything is tagged/branched", does that somehow include
> tagging the non-company assets?  Thanks for any help.
>
> Ed
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] UTF-89 support

[Paul Eggleton]

On Mon, 07 Nov 2016 09:24:18 Khem Raj wrote:
> On 11/7/16 3:48 AM, Keskinarkaus, Teemu wrote:
> > Hi,
> > 
> > 
> > 
> > I tried googling this and reading the manual, but I guess this is too
> > trivial or I’m doing something wrong.
> > 
> > 
> > 
> > I’m trying to get UTF-8 support to my image. UTF-8 locale more specific.
> > If I run locale –a command I get these locales listed:
> > 
> > C
> > 
> > POSIX
> > 
> > en_GB
> > 
> > en_US
> > 
> > 
> > 
> > I added this line to my local.conf:
> > 
> > GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"
> 
> you also need to set IMAGE_LINGUAS to include it into image
> e.g.
> 
> GLIBC_GENERATE_LOCALES = "en-gb"

I guess you meant IMAGE_LINGUAS = "en-gb"

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] UTF-89 support

[Khem Raj]

On Mon, Nov 7, 2016 at 11:48 AM, Paul Eggleton
 wrote:
> On Mon, 07 Nov 2016 09:24:18 Khem Raj wrote:
>> On 11/7/16 3:48 AM, Keskinarkaus, Teemu wrote:
>> > Hi,
>> >
>> >
>> >
>> > I tried googling this and reading the manual, but I guess this is too
>> > trivial or I’m doing something wrong.
>> >
>> >
>> >
>> > I’m trying to get UTF-8 support to my image. UTF-8 locale more specific.
>> > If I run locale –a command I get these locales listed:
>> >
>> > C
>> >
>> > POSIX
>> >
>> > en_GB
>> >
>> > en_US
>> >
>> >
>> >
>> > I added this line to my local.conf:
>> >
>> > GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8 en_GB en_US"
>>
>> you also need to set IMAGE_LINGUAS to include it into image
>> e.g.
>>
>> GLIBC_GENERATE_LOCALES = "en-gb"
>
> I guess you meant IMAGE_LINGUAS = "en-gb"

yes thanks for noting

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto 2.2 Morty supported Linux Distros

[Brian Avery]

To add more options, there's also a set of CROPS (YP subproject)  Docker
containers aimed at supporting a general build environment for YP, one
aimed at the extensible sdk, and several for toaster depending on the
desired version.

poky/oe:
https://hub.docker.com/r/crops/poky/

extensible-sdk:
https://github.com/crops/extsdk-container

toaster:
https://hub.docker.com/r/crops/toaster/  (last official release)
https://hub.docker.com/r/crops/toaster-krogoth/
https://hub.docker.com/r/crops/toaster-morty/
https://hub.docker.com/r/crops/toaster-master/




There are instructions for using the CROPS containers on Mac & Windows as
well.
https://github.com/crops/docker-win-mac-docs/wiki

BR,
Brian
an intel employee





On Tue, Nov 1, 2016 at 4:35 PM, Khem Raj  wrote:

>
> On Nov 1, 2016, at 4:22 PM, Burton, Ross  wrote:
>
>
> On 1 November 2016 at 22:20, Daniel.  wrote:
>
>> Just as a note, I've been using archlinux for about a year and have never
>> faced "distro related problems", except when the gcc6 comes out. Anyway I'm
>> using daisy in my work. I think that making old releases supported by X
>> distro doesn't make any sense...
>>
>
> The supported list of distros is just the list of distros that are known
> to work, and if something breaks then we'll notice and fix it.  If you want
> to use arch and face the periodic problems such as new toolchain meaning
> you can't build gcc-cross, then go for it.
>
>
> Another option perhaps is to use a debian stable container with docker (
> https://hub.docker.com/r/cbrake/oe-build/)
> and you can use your favorite distro for stuff you usually do and at same
> time let OE/YP build on  a known/supported distro e.g.
> Its a bit of mind shift but I am happily using it, while my distro stays
> bleeding edge arch.
>
> e.g. see
>
> http://bec-systems.com/site/1281/using-docker-for-oeyocto-builds
>
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Question about wic partition creation

[Ed Bartosh]

On Tue, Nov 01, 2016 at 11:14:48AM -0400, Nicolas Bigaouette wrote:
> We are using Yocto (jethro and krogoth) to build an image for a device.
> 
> I organized the compilation process into multiple stages for easier
> integration with our tooling. The last stage is a call to `wic` to
> create a drive image that we can then `dd` to a real drive to get a
> workable system.
>
Do you use wic images produced by bitbake or run wic after bitbake build?

> I am faced with a problem where I would like the top-level directory
> of one of the partition created by wic to have a different owner
> than root.
> 
> I am able to tell wic the partition information (size, filesystem,
> etc.) but I can't find a way to tell wic to change permissions of
> files/directories inside the partition...
>
> As an example I have an entry like the following at the end of my `.wks`:
> > part /opt/mnt--label extra  --fstype=ext4 --align 1024
> --ondisk sda --size=2040
> which will add an extra partition after all others on the final
> image. An entry in `/etc/fstab` will be added so that the partition
> will be mounted to `/opt/mnt`.
> 
> Note that the partition should be empty: I'm not populating it with
> any files or directories.
> 
> But after booting the system, the directory `/opt/mnt` will have the
> permissions of the top-level directory of the created partition, and
> by default those are `0755` and owned by `root:root`.
> 
> So my question is: How can I change this so that it's owned by a
> specific uid and gid (`1000:1000`)?

> I am investigating plugins for now (for example by having a
> `meta-mylayer/scripts/lib/wic/plugins/source/fsimage-mypartition.py`)
> but I still can't see how I can change the owner of the directory.
> Should I provide a rootfs-like directory which is empty but owned by
> the proper uid and gid?
>
Yes, that's what I'd suggest to do. rootfs plugin may help you with
this. If it doesn't work as expected please create bug for me in Yocto
bugzilla.

> Note that letting users be able to mount the partition (by adding
> `users` to `/etc/fstab`) is not what I want; it would _not_ change
> the permissions/owner of the top-level directory of the partition.

--
Regards,
Ed
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] FW: cmake version 3.0.0 or greater

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus

Our SDK has the Yocto Project 1.7 Dizzy version and it supports cmake 2.8.12 
version as show below:
./meta/recipes-devtools/cmake/cmake_2.8.12.2.bb
./meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb

We need to pulling the cmake 3.x.x version for our sdk-dslink-c recipe build.

I found  git://git.openembedded.org/openembedded-core has version  3.6.x
So I tried to pull it in. But this version got a trace back when integrated to 
our SDK Yocto Dizzy.

Can you advise which open embedded-core version/git location to pull in to SDK 
Dizzy version for cmake 3.x.x version

Thanks,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto