Re: [yocto] Install mozroot-certdata package on a read only root file system

[Jussi Kukkonen]

On 19 October 2016 at 21:55, Burton, Ross  wrote:

>
> On 18 October 2016 at 23:26, Nick Wareing 
> wrote:
>
>> However I'm running into an issue with a recipe in the meta-mono layer:
>> mozroot-certdata. I see the culprit is the pkg_postint script (
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-mono/tree/re
>> cipes-mono/mozroot-certdata/mozroot-certdata_1.0.0.bb) which needs to
>> modify the root file system on first boot which the build system is
>> correctly flagging as impossible with a read only root file system:
>>
>>
> You'll have to extend the recipe to run mono inside a qemu, there are
> plenty of other recipes that demonstrate how to do this (fontcache and
> gio-module-cache classes come to mind, although they also use intercept
> scripts to avoid running qemu more than once).  Basically, use the qemu
> class.
>

Why qemu? There's a mono-native which I would expect to work unless the
certdata is somehow platform specific (?)

There's also an additional problem that came up on stack overflow:
mozroots.exe is hard coded to output to a specific file so that would have
to be fixed as well.


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

[yocto] Manuals for ROOT LABELS INITRD and INITRD_IMAGE

[Robert Yang]

Hi Scott,

The LIVE (such as iso) and VM images (such as vmdk) can't use the same
settings for ROOT LABELS INITRD and INITRD_IMAGE, either of them may fail
to boot, so when the user uses one of them, they will get warnings like:

WARNING: core-image-minimal-1.0-r0 do_bootimg: Found potential conflicted var 
LABELS, please use LABELS_LIVE rather than LABELS"


We should use _LIVE or _VM version to instead of, would you please update
the manual for them ?

ROOT_VM: Boot loader's root options for vm images, e.g., root=/dev/sda2.
ROOT_LIVE: Boot loader's root options for live images, e.g., root=/dev/ram0.

LABELS_VM: Boot loader's actions for vm images, e.g., "boot".
LABELS_LIVE: Boot loader's actions for live images, e.g., "boot install".

INITRD_VM: Path to initial RAM disk (initrd) for vm images.
INITRD_LIVE:  Path to initial RAM disk (initrd) for live images.

# There is no warnings when use INITRD_IMAGE, I will fix it in Yocto 2.3.
INITRD_IMAGE_VM: INITRD's image name (PN) for vm images
INITRD_IMAGE_LIVE: INITRD's image name (PN) for live images

--
Thanks

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

Re: [yocto] Install mozroot-certdata package on a read only root file system

[Burton, Ross]

On 20 October 2016 at 07:59, Jussi Kukkonen 
wrote:

> You'll have to extend the recipe to run mono inside a qemu, there are
>> plenty of other recipes that demonstrate how to do this (fontcache and
>> gio-module-cache classes come to mind, although they also use intercept
>> scripts to avoid running qemu more than once).  Basically, use the qemu
>> class.
>>
>
> Why qemu? There's a mono-native which I would expect to work unless the
> certdata is somehow platform specific (?)
>
> There's also an additional problem that came up on stack overflow:
> mozroots.exe is hard coded to output to a specific file so that would have
> to be fixed as well.
>

Erm, yeah.  Next time I'll think for a second - of course mono-native
should work!

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

[yocto] meta-odroid status for XU4

[sebastian.ro...@tu-dortmund.de]

Hi,

I am interested in the current status of meta-odroid. I am targeting the XU4 
platform and I am interested whether it is supposed to work out of the box with 
the jethro branch.
I noticed that there are incompatibilities of meta-odroid/master (from 
https://github.com/akuster/meta-odroid) with open-embedded jethro, in 
particular concerning uboot-sign.bbclass recipes, which is obviously fine as 
there is a jethro branch available.

However, meta-odroid/jethro on the other handy seems to be missing some patches 
for xu4 (still untested, no HW available yet), e.g. 
https://github.com/akuster/meta-odroid/commit/867a844ad2c7060731c96aeef77160ab65f6aa33
 .

Consequently, I am struggling when it comes to the requirements for a 
successful XU4 build and deployment:

-  Is meta-odroid supposed to work out of the box in a jethro setup?
or

-  Is it supposed to have issues that should be easily solved (e.g. 
through backporting single patches)?
or

-  Do I currently need the master branch (for all my layers, including 
some custom layers, hence suboptimal but possible) in order o fully support XU4?

Help is very much appreciated!

Cheers,
Sebastian

Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist 
ausschließlich für den Adressaten bestimmt. Sollten Sie nicht der für diese 
E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Vielen Dank.
Unbeschadet der Korrespondenz per E-Mail, sind unsere Erklärungen 
ausschließlich final rechtsverbindlich, wenn sie in herkömmlicher Schriftform 
(mit eigenhändiger Unterschrift) oder durch Übermittlung eines solchen 
Schriftstücks per Telefax erfolgen.

Important note: The information included in this e-mail is confidential. It is 
solely intended for the recipient. If you are not the intended recipient of 
this e-mail please contact the sender and delete this message. Thank you. 
Without prejudice of e-mail correspondence, our statements are only legally 
binding when they are made in the conventional written form (with personal 
signature) or when such documents are sent by fax.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libtomcrypt libtomfastmath recipe

[Vivek Per]

Hi All,

Thank you very much this recipe worked for me.

Thanks and Regards,


On Thu, Oct 20, 2016 at 3:40 AM, Burton, Ross  wrote:

> Please considering posting these recipe into meta-oe or similar, tomcrypt
> etc comes up every few months.  And posting a recipe to the list implies
> you want review, right? :)
>
> On 19 October 2016 at 10:12, Markus Volk  wrote:
>
>> DESCRIPTION = "tomcrypt"
>> HOMEPAGE = " http://www.libtom.net"; 
>> LICENSE = "DWTFYW"
>>
> Second worst license known to man.  :(
>
>> LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=71baa
>> cc459522324ef3e2b9e052e8180"
>>
> These URLs are relative to ${S} so just file://LICENSE works.
>
>> SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
>> "
>>
>> SRCREV = "${AUTOREV}"
>>
> In general it's recommended to use a fixed SHA and then override SRVREV if
> you need to for testing/CI/whatever.
>
>> PV = "${SRCPV}"
>> PR = "1"
>>
> No need for PR in general.
>
>> S = "${WORKDIR}/git"
>>
>> inherit autotools-brokensep
>>
> Boo.  Is upstream fixable or is it beyond help?
>
>> SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
>> SRC_URI[sha256sum] = "d0ff89397f9a5fd1d13b1cbc419d5
>> d426e14473135515d72bfcb58e5babf5032"
>>
>> No need for SRC_URI if you're using git fetcher.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libtomcrypt libtomfastmath recipe

[Vivek Per]

HI,

Thank you very much.


regards,
 vivek

On Wed, Oct 19, 2016 at 2:42 PM, Markus Volk  wrote:

> tomcrypt builds like this for me:
>
>
> DESCRIPTION = "tomcrypt"
> HOMEPAGE = " http://www.libtom.net"; 
> LICENSE = "DWTFYW"
> LIC_FILES_CHKSUM = "file://${S}/LICENSE;md5=71baacc459522324ef3e2b9e052e81
> 80"
>
> SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
> "
>
> SRCREV = "${AUTOREV}"
> PV = "${SRCPV}"
> PR = "1"
>
> S = "${WORKDIR}/git"
>
> inherit autotools-brokensep
>
> SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
> SRC_URI[sha256sum] = "d0ff89397f9a5fd1d13b1cbc419d5d
> 426e14473135515d72bfcb58e5babf5032"
>
>
> note, that tomcrypt wants latex installed for creating doc. You proably
> want to edit the makefile or define NODOC
>
> Am 19.10.2016 um 09:19 schrieb Vivek Per:
>
> Hi,
>
> I am trying to build tomfastmath and tomcrypt shared libraries using
> yocto, I couldn't get recipes for libtomcrypt and tomfastmath in web. So
> started to write one but i am failing to write correct recipe every time.
>
> the skeleton   i used is both the recipes
>
> S = "${WORKDIR}/git"
> inherit autotools
> EXTRA_OEMAKE = " 'CFLAGS=${CFLAGS} "-I${S}/src/headers" -DTFM_ARM '
>  'CC=${CC}' 'RANLIB=${RANLIB}' 'AR=${AR}' 'LD={LD}'   'BUILDDIR=${S}'
> 'D=${DEST_DIR}' "
> do_compile() {
> make -f ${S}/makefile  libtfm.a DESTDIR=${D} SBINDIR=${sbindir}
> MANDIR=${mandir}
> }
>
> Can any one help  please help me in creating tomcrypt and tomfastmath
> recipes. or any point our if recipes already exist.
>
>
> Thanks and Regards,
>   Vivek
>
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] confusion about DEPENDS vs RDEPENDS vs PROVIDES

[윤영석]

Hi, 
Is there anyone who explain to me..?
 
thanks 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe for Turbo.lua ?

[Dinh Nguyen (dinhn)]

> I checked at layers.openembedded.org and it seems there is no recipe for this.



Thanks much Khem, I googled too, but unable to find any.

Best,
  —Dinh 

On 10/19/16, 7:53 PM, "Khem Raj"  wrote:

>On Wed, Oct 19, 2016 at 6:56 PM, Dinh Nguyen (dinhn)  wrote:
>>
>> Hi Yocto Gurus,
>>
>> I am trying to use the Turbo Lua as a framework for building Lua JIT.
>> https://github.com/kernelsauce/turbo.git
>>
>> Is there any existing recipe for “turbo lua” ?
>
>I checked at layers.openembedded.org and it seems there is no recipe for this.
>
>>
>> Many thanks in advance,
>>   —Dinh
>>
>> --
>> ___
>> 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] confusion about DEPENDS vs RDEPENDS vs PROVIDES

[Burton, Ross]

On 20 October 2016 at 13:06, 윤영석  wrote:

> Is there anyone who explain to me..?
>
>
The documentation covers these:

http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PROVIDES
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-DEPENDS
http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-RDEPENDS

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

Re: [yocto] libtomcrypt libtomfastmath recipe

[Andrea Galbusera]

Hi Vivek,

Il 20 ott 2016 1:42 PM, "Vivek Per"  ha scritto:
>
> Hi All,
>
> Thank you very much this recipe worked for me.

If it worked, as already suggested by Ross, please consider posting it to
the mailing list for further review and hopefully for merging into meta-oe
or where it belongs best.

Instructions for contributing can be found at
https://github.com/openembedded/meta-openembedded/blob/master/README and in
READMEs from each layer.

>
> Thanks and Regards,
>
>
> On Thu, Oct 20, 2016 at 3:40 AM, Burton, Ross 
wrote:
>>
>> Please considering posting these recipe into meta-oe or similar,
tomcrypt etc comes up every few months.  And posting a recipe to the list
implies you want review, right? :)
>>
>> On 19 October 2016 at 10:12, Markus Volk  wrote:
>>>
>>> DESCRIPTION = "tomcrypt"
>>> HOMEPAGE = " http://www.libtom.net";
>>> LICENSE = "DWTFYW"
>>
>> Second worst license known to man.  :(
>>>
>>> LIC_FILES_CHKSUM =
"file://${S}/LICENSE;md5=71baacc459522324ef3e2b9e052e8180"
>>
>> These URLs are relative to ${S} so just file://LICENSE works.
>>>
>>> SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
>>> "
>>>
>>> SRCREV = "${AUTOREV}"
>>
>> In general it's recommended to use a fixed SHA and then override SRVREV
if you need to for testing/CI/whatever.
>>>
>>> PV = "${SRCPV}"
>>> PR = "1"
>>
>> No need for PR in general.
>>>
>>> S = "${WORKDIR}/git"
>>>
>>> inherit autotools-brokensep
>>
>> Boo.  Is upstream fixable or is it beyond help?
>>>
>>> SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
>>> SRC_URI[sha256sum] =
"d0ff89397f9a5fd1d13b1cbc419d5d426e14473135515d72bfcb58e5babf5032"
>>
>> No need for SRC_URI if you're using git fetcher.
>>
>> 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

Re: [yocto] 2.2 release note material

[akuster808]

Paul


On 10/19/2016 07:25 PM, Paul Eggleton wrote:

Hi all,

I've been gathering material for the 2.2 release notes, here is what I have at
the moment. Things missing:


Thanks for putting this together.



* Any new features/enhancements for the kernel tools - Bruce, is there
anything worth noting?

* Known issues that are worth calling out

Note that I haven't included all of the bugfixes in this release since we
haven't been recently and there are a lot of them. I do have a list of them if
we want to include them but not only is it very long, it's not guaranteed to
be devoid of fixes for regressions within the release and I also haven't
tweaked any of the items to be more understandable out of context as I have
with the features/enhancements.

Let me know if I've missed or misrepresented anything.


Regarding the CVE list. I see some info is based on what was in the 
commit messages for package updates. I suspect the list would be bigger 
because of general package updates. Should the release notes make note 
of that?
 Should the community in general provide more info in the commits to 
help with release notes if that is a source used for that process?



- Armin


Cheers,
Paul





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

[yocto] ODROID-C2 and meta-odroid

[Yile Ku]

I am having some issues getting the odroid c2 board to boot with images
built with meta-odroid and yocto 2.2.  Is there someone I can correspond
with regarding these issues?

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

[yocto] Deciding between yocto kernels and soc vendor kernels

[Davis Roman]

Hello Yocto Community,

As I understand it, the Yocto project team cherry-picks certain kernel
versions from kernel.org to be dedicated as Yocto Project Linux Kernels
that have support for the officially supported arm target boards.

However, if I'm using a silicon vendor, such as nxp, for a custom i.mx6
board then I'll need to stick with nxp's kernel but the problem that I see
here is that they may not support that version of kernel for too long.

Are there any best practices or advice when it comes to how to avoid
getting locked into an evil vendor kernel ?

Thank you,

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

[yocto] [meta-mingw][krogoth][PATCH 0/1] binutils: enable plugins

[Juro Bystricky]

This meta-mingw patch for jethro by Mark Hatle is also needed for
krogoth and morty/master as well, otherwise the linker will fail, not being able
to load lto plugins.

Original patch:
https://git.yoctoproject.org/cgit/cgit.cgi/meta-mingw-contrib/commit/?h=mgh/jetho/meta-mingw



Juro Bystricky (1):
  binutils-cross-canadian: Fix LTO failure

 recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4

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

[yocto] [meta-mingw][PATCH 1/1] binutils-cross-canadian: Fix LTO failure

[Juro Bystricky]

GCC was failing with a message similar to:

e:/windri~1/lx8.sdk/qemux8~1.800/sysroots/i686-w~1/usr/bin/i586-w~3/../../libexec/i586-wrs-linux/gcc/i586-wrs-linux/5.2.0/real-ld.exe:
 unrecognized option '-plugin'

The issue was that by default plugin support was disabled in binutils.  By
enabling the plugin support, the LTO support should also now work properly.

Signed-off-by: Mark Hatle 
Signed-off-by: Juro Bystricky 
---
 recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend 
b/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
index 026c932..5845fe0 100644
--- a/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
+++ b/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
@@ -1,4 +1,4 @@
-EXTRA_OECONF_append_sdkmingw32 = " --disable-plugins --disable-nls"
+EXTRA_OECONF_append_sdkmingw32 = " --disable-nls"
 LDFLAGS_append_sdkmingw32 = " -Wl,-static"
 
 DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
-- 
2.7.4

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

Re: [yocto] ODROID-C2 and meta-odroid

[akuster808]

On 10/20/2016 09:25 AM, Yile Ku wrote:
I am having some issues getting the odroid c2 board to boot with 
images built with meta-odroid and yocto 2.2.


The C2 integration to support 2.2 is not complete. Krogoth branch should 
work as it uses the hardkernels u-boot and 3.18 kernel. Neither will 
build with the 6.0 Gcc.


I have the latest u-boot (2016.06) booting on the C2 and everything 
compiling. Just have not figured out the magic to get a 4.8 kernel to boot.



Is there someone I can correspond with regarding these issues?

You did not explain with the issue is.

- Armin



Thanks,
Yile




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

Re: [yocto] Deciding between yocto kernels and soc vendor kernels

[Khem Raj]

> On Oct 20, 2016, at 10:32 AM, Davis Roman  wrote:
> 
> Hello Yocto Community,
> 
> As I understand it, the Yocto project team cherry-picks certain kernel 
> versions from kernel.org  to be dedicated as Yocto 
> Project Linux Kernels that have support for the officially supported arm 
> target boards.
> 
> However, if I'm using a silicon vendor, such as nxp, for a custom i.mx6 board 
> then I'll need to stick with nxp's kernel but the problem that I see here is 
> that they may not support that version of kernel for too long.
> 
> Are there any best practices or advice when it comes to how to avoid getting 
> locked into an evil vendor kernel ?

You can try to check if needed support for the given SOC is upstreamed. 
Sometimes, vendor kernel have additional stuff but the base support is 
upstream, if you are lucky
and dont need the things which are on top of such base port then you can try 
switching to kernel.org kernel and unshackles yourself.

Secondly, you can work with vendor to upstream the needed bits at priority, may 
be helping out with testing or whatever you can.

if vendor kernels are having too much stuff that is essential to support the 
basic stuff on chip then you are at the vendors behest for support, there may be
some OSVs that can help may be or some other consultancies.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-mingw][PATCH 1/1] binutils-cross-canadian: Fix LTO failure

[Khem Raj]

> On Oct 20, 2016, at 10:35 AM, Juro Bystricky  wrote:
> 
> GCC was failing with a message similar to:
> 
> e:/windri~1/lx8.sdk/qemux8~1.800/sysroots/i686-w~1/usr/bin/i586-w~3/../../libexec/i586-wrs-linux/gcc/i586-wrs-linux/5.2.0/real-ld.exe:
>  unrecognized option '-plugin'
> 
> The issue was that by default plugin support was disabled in binutils.  By
> enabling the plugin support, the LTO support should also now work properly.
> 
> Signed-off-by: Mark Hatle 
> Signed-off-by: Juro Bystricky 
> ---
> recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend 
> b/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
> index 026c932..5845fe0 100644
> --- a/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
> +++ b/recipes-devtools/binutils/binutils-cross-canadian_2.2%.bbappend
> @@ -1,4 +1,4 @@
> -EXTRA_OECONF_append_sdkmingw32 = " --disable-plugins --disable-nls"
> +EXTRA_OECONF_append_sdkmingw32 = " --disable-nls”

This looks ok to me.

> LDFLAGS_append_sdkmingw32 = " -Wl,-static"
> 
> DEPENDS_remove_sdkmingw32 = "nativesdk-gettext"
> --
> 2.7.4
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus,

I am trying to build the luajit_2.0.3.bb recipe on our Yocto-1.7 base.
It failed to path the ppc-fixplt.patch. Hers is my build configuration.

Please give me any idea why I got HUNT # failed that ending up causing 
ppc-fixplt.patch error?

Build Configuration:
BB_VERSION= "1.24.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "powerpc-poky-linux-gnuspe"
MACHINE   = "isr800-lxc"
DISTRO= "poky"
DISTRO_VERSION= "1.7.2"
TUNE_FEATURES = "m32 spe ppce500v2"
TARGET_FPU= "ppc-efd"
meta-cisco-iox-base
meta-fsl-ppc-dizzy-12.0.2 = ":"
meta-efl
meta-filesystems
meta-xfce
meta-ruby
meta-webserver
meta-systemd
meta-python
meta-perl
meta-networking
meta-multimedia
meta-initramfs
meta-gnome
meta-oe   = "dizzy:70beecb2716bca1b9dfbc7d6a264233e1f05e82b"
meta-cisco-isr800
meta-fsl-ppc-dizzy-12.0.2
meta
meta-yocto
meta-yocto-bsp= ":"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Command Error: exit status: 1  Output:
Applying patch ppc-fixplt.patch
patching file src/host/buildvm.c
Hunk #1 FAILED at 107.
1 out of 1 hunk FAILED -- rejects in file src/host/buildvm.c
patching file src/vm_ppcspe.dasc
Hunk #1 FAILED at 1390.
Hunk #2 FAILED at 1405.
Hunk #3 FAILED at 1437.
Hunk #4 FAILED at 1471.
Hunk #5 FAILED at 1484.
Hunk #6 FAILED at 1503.
Hunk #7 FAILED at 2399.
7 out of 7 hunks FAILED -- rejects in file src/vm_ppcspe.dasc
Patch ppc-fixplt.patch does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_ppc/tmp/work/ppce500v2-poky-linux-gnuspe/luajit/2.0.3-r0/temp/log.do_patch.32583
ERROR: Task 1 
(/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/sys/yocto-1.7/isr800/meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.3.bb,
 do_patch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 369 tasks of which 366 didn't need to be rerun 
and 1 failed.
No currently running tasks (369 of 379)

Summary: 1 task failed:
  
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/sys/yocto-1.7/isr800/meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.3.bb,
 do_patch
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


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

Re: [yocto] Deciding between yocto kernels and soc vendor kernels

[Davis Roman]

Hi Khem,

That makes sense.

Thank you for replying!

-Davis

On Thu, Oct 20, 2016 at 1:46 PM, Khem Raj  wrote:

>
> On Oct 20, 2016, at 10:32 AM, Davis Roman  wrote:
>
> Hello Yocto Community,
>
> As I understand it, the Yocto project team cherry-picks certain kernel
> versions from kernel.org to be dedicated as Yocto Project Linux Kernels
> that have support for the officially supported arm target boards.
>
> However, if I'm using a silicon vendor, such as nxp, for a custom i.mx6
> board then I'll need to stick with nxp's kernel but the problem that I see
> here is that they may not support that version of kernel for too long.
>
> Are there any best practices or advice when it comes to how to avoid
> getting locked into an evil vendor kernel ?
>
>
> You can try to check if needed support for the given SOC is upstreamed.
> Sometimes, vendor kernel have additional stuff but the base support is
> upstream, if you are lucky
> and dont need the things which are on top of such base port then you can
> try switching to kernel.org kernel and unshackles yourself.
>
> Secondly, you can work with vendor to upstream the needed bits at
> priority, may be helping out with testing or whatever you can.
>
> if vendor kernels are having too much stuff that is essential to support
> the basic stuff on chip then you are at the vendors behest for support,
> there may be
> some OSVs that can help may be or some other consultancies.
>
>
> Thank you,
>
> Davis
>
>
>
>
>
>
>
>
>
> --
> ___
> 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] 2.2 release note material

[Paul Eggleton]

Hi Armin,

On Thu, 20 Oct 2016 08:26:37 akuster808 wrote:
> Regarding the CVE list. I see some info is based on what was in the
> commit messages for package updates. I suspect the list would be bigger
> because of general package updates. Should the release notes make note
> of that?
>   Should the community in general provide more info in the commits to
> help with release notes if that is a source used for that process?

We really should include that - unfortunately I didn't have time to track down 
all of those, assembling this list took several days of grinding through the 
commits as it was. I did check upstream for some of the upgrades where a CVE 
patch was removed just to verify that fix was indeed included in the upgrade, 
and for those I collected any others that were listed as having been fixed, 
but I wasn't really systematic about that.

Do you know if there's any central resource we can use to find out which 
versions of upstream software included which CVE fixes, or is it perhaps time 
we started gathering links to the changelogs for each recipe? (Maybe we should 
do the latter anyway.)

Cheers,
Paul

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

Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

[Burton, Ross]

On 20 October 2016 at 19:41, Dinh Nguyen (dinhn)  wrote:

> I am trying to build the luajit_2.0.3.bb recipe on our Yocto-1.7 base.
> It failed to path the ppc-fixplt.patch. Hers is my build configuration.
>

Looking back in history it's possible that both your BSP and meta-oe are
both attempting to apply the same patch, so check that your BSP layer
(meta-fsl-ppc-*) isn't bbappending it at the same time as meta-oe also
shipping the same patch.

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

Re: [yocto] 2.2 release note material

[akuster808]

On 10/20/16 12:32 PM, Paul Eggleton wrote:
> Hi Armin,
> 
> On Thu, 20 Oct 2016 08:26:37 akuster808 wrote:
>> Regarding the CVE list. I see some info is based on what was in the
>> commit messages for package updates. I suspect the list would be bigger
>> because of general package updates. Should the release notes make note
>> of that?
>>   Should the community in general provide more info in the commits to
>> help with release notes if that is a source used for that process?
> 
> We really should include that - unfortunately I didn't have time to track 
> down 
> all of those, assembling this list took several days of grinding through the 
> commits as it was. 

This is why I bring it up. We tend to take the easy route when
submitting changes not understanding the work it may cause someone else
down stream. I appreciate your effort in this task.


I did check upstream for some of the upgrades where a CVE
> patch was removed just to verify that fix was indeed included in the upgrade, 
> and for those I collected any others that were listed as having been fixed, 
> but I wasn't really systematic about that.
> 
> Do you know if there's any central resource we can use to find out which 
> versions of upstream software included which CVE fixes, 

There are but I am not sure how complete they are. Its not uncommon for
the NVD to have "reserved" listed for something that has been out for a
while. Let me look into it.

or is it perhaps time
> we started gathering links to the changelogs for each recipe? (Maybe we 
> should 
> do the latter anyway.)

Some packages use a common link for all changes.

I think people just need to be aware we use the commit messages to help
with release notes. I am not proposing using a keyword in the commit
messages that we can suck in with a tool to help create the release
notes. That would just be silly.

- armin
> 
> Cheers,
> Paul
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

[Dinh Nguyen (dinhn)]

Thank you.  It works after removing the append in the meta-fsl-ppc*

Best,
  —Dinh

From: "Burton, Ross" mailto:ross.bur...@intel.com>>
Date: Thursday, October 20, 2016 at 1:18 PM
To: dinhn mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org" 
mailto:yocto@yoctoproject.org>>, "Srinivas Yedla 
(sryedla)" mailto:srye...@cisco.com>>
Subject: Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()


On 20 October 2016 at 19:41, Dinh Nguyen (dinhn) 
mailto:di...@cisco.com>> wrote:
I am trying to build the luajit_2.0.3.bb recipe on our 
Yocto-1.7 base.
It failed to path the ppc-fixplt.patch. Hers is my build configuration.

Looking back in history it's possible that both your BSP and meta-oe are both 
attempting to apply the same patch, so check that your BSP layer 
(meta-fsl-ppc-*) isn't bbappending it at the same time as meta-oe also shipping 
the same patch.

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

Re: [yocto] 2.2 release note material

[Paul Eggleton]

On Wed, 19 Oct 2016 23:54:59 Bruce Ashfield wrote:
> On 2016-10-19 10:25 PM, Paul Eggleton wrote:
> > I've been gathering material for the 2.2 release notes, here is what I
> > have at the moment. Things missing:
> > 
> > * Any new features/enhancements for the kernel tools - Bruce, is there
> > anything worth noting?
> 
> It is probably worth mentioning a few things on that front, I'll provide
> some raw bullets points here .. and they can be wordsmithed as needed:
> 
>   - kernel tools were streamlined, with patching/configuration overhead
> reduced or eliminated in most cases.
>   - kernel configuration audit was improved and runs as a standalone tool
>   - kernel configuration audit provides symbol resolution and dependency
> information to allow troubleshooting of missing/incorrect/invalid
> symbols
>   - kernel tools use upstream utilities directly, without local patches or
> wrappers.

Thanks Bruce, I pretty much included this verbatim.

Cheers,
Paul

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

Re: [yocto] 2.2 release note material

[Paul Eggleton]

On Thu, 20 Oct 2016 15:25:05 Paul Eggleton wrote:
> I've been gathering material for the 2.2 release notes, here is what I have
> at the moment. Things missing:
> 
> * Any new features/enhancements for the kernel tools - Bruce, is there
> anything worth noting?
> 
> * Known issues that are worth calling out
> 
> Note that I haven't included all of the bugfixes in this release since we
> haven't been recently and there are a lot of them. I do have a list of them
> if we want to include them but not only is it very long, it's not
> guaranteed to be devoid of fixes for regressions within the release and I
> also haven't tweaked any of the items to be more understandable out of
> context as I have with the features/enhancements.
> 
> Let me know if I've missed or misrepresented anything.

OK, updated content attached with additions from Bruce, and I made changes to 
address Khem's comments plus a few other minor tweaks.

We're still missing known issues, so someone will need to gather and record 
those.

Cheers,
Paul

-- 
Paul Eggleton
Intel Open Source Technology Centre
New Features / Enhancements


* Linux kernel 4.8 (and 4.4/4.1 LTS/LTSI)
* glibc 2.24
* gcc 6.2.0
* Migrated BitBake and python functions in the OE metadata to Python 3
* runqemu script has rewritten in Python and refactored to move 
machine-specific knowledge to the machine configuration, making it possible to 
extend it easily in each BSP layer
* Created pre-configured Docker containers for the build system, Toaster and 
the Extensible SDK (available at https://github.com/crops/)
* Add cve-check class to catch missing known CVE fixes for recipes
* Sato example UI moved to GTK+3 and refreshed with updated/replaced 
applications and Adwaita icon set
* Put deploy directory (including images, SDKs and other files) under shared 
state control. This effectively makes removal of old images and SDKs the 
default behaviour, and provides a way to trace files in that directory back to 
their originating recipes which is useful for scripts and UIs such as Toaster.
* Musl libc can now build world for all primary architectures, ppc64 is now 
also supported
* BitBake improvements:
* Basic support for multi-configuration builds. For example, this enables 
building for more than one MACHINE at a time, which may be useful if you have a 
board with two separate SoCs on it, each with their own OS, but you want to 
target both in the same build.
* Show more progress during operation - added real-time task progress 
reporting for do_fetch, image creation, cmake-based do_compile; also show 
progress for "Preparing RunQueue" and sstate object availability check.
* Show task elapsed time
* Added a -q/--quiet output mode switch that only shows basic progress
* Added an "unset VARNAME" syntax to clear a variable
* Implemented support for per-task variable exports
* Create a symlink to the latest console log
* Added BB_SETSCENE_ENFORCE to enable enforcing that tasks are restored 
from sstate
* Added LAYERRECOMMENDS to allow declaring recommended but not required 
layer dependencies in conf/layer.conf
* Ported depexp UI to GTK+3
* Output errors and warnings to stderr
* Implement server autostart feature to avoid constantly holding a lock on 
the metadata when resident
* Rework perforce fetcher to support SRCREV and P4CONFIG
* Add BBPRECONF and BBPOSTCONF environment variables
* Toaster web UI improvements:
* Improved image customisation
* Improved BitBake to Toaster process communication
* Upgraded Bootstrap UI framework to version 3 which provides a new look 
and more responsive design
* Improved performance and consistency of table views in build analysis
* Added visual feedback to the layerindex data fetcher
* Improved the ability to download artifacts created by builds such as SDK 
artifacts
* Added the ability to import a layer from a local directory and switch 
between local and git sources
* Added ability to configure and customise Toaster using fixtures at setup 
time
* Added layers to the backend admin interface
* Added the ability to delete objects from Toaster's database such as 
builds, layers, customised images and projects.
* Improved build progress reporting
* Improved help and notification messages
* Image construction improvements:
* Add variable FORCE_RO_REMOVE to force removal of unneeded packages 
specified by ROOTFS_RO_UNNEEDED even if rootfs is not read-only
* Add variable VM_ROOTFS_TYPE to allow filesystems other than ext4 to be 
used for VM images (vmdk, vdi, qcow2, hdddirect)
* Make the INITRD optional for "live" image type
* Add bmap generation option to produce files that can be used with 
bmap-tools for sparse images
* Add support for zip compression
* wic improvements:
* Produce wic images by default for beaglebone, edgerouter and 
genericx86/genericx86-

[yocto] Yocto on ECS GWS-QX board

[Sudhindra Deshpande]

Hi,

I have a newbee question.
We are thinking of installing Yocto linux on ECS board with Intel Quark SoC 
X1021 processor.
How do I make sure that Yocto will work on this board?
What are the questions I should ask?
The link to the board is below
http://www.ecs.com.tw/website2008/Product/Product_Overview.aspx?DetailID=1604&CategoryID=18&MenuID=205&LanID=0#Overview
It seems to support Wind River.

Thanks so much
-sv

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

[yocto] [meta-raspberrypi][PATCH 1/2] firmware: Update to latest

[Khem Raj]

Fixes issues with display not starting with weston

Signed-off-by: Khem Raj 
---
 recipes-bsp/common/firmware.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-bsp/common/firmware.inc b/recipes-bsp/common/firmware.inc
index 29f9c01..6ce89a5 100644
--- a/recipes-bsp/common/firmware.inc
+++ b/recipes-bsp/common/firmware.inc
@@ -1,5 +1,5 @@
-RPIFW_SRCREV ?= "ec63df146f454e8cab7080380f9138246d877013"
-RPIFW_DATE ?= "20161005"
+RPIFW_SRCREV ?= "ec5a517ed6051974a5a09f7b7811d21c443a7c74"
+RPIFW_DATE ?= "20161020"
 RPIFW_SRC_URI ?= 
"git://github.com/raspberrypi/firmware.git;protocol=git;branch=master"
 RPIFW_S ?= "${WORKDIR}/git"
 
-- 
2.10.0

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

[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi_4.8.bb: Update to 4.8.2

[Khem Raj]

Signed-off-by: Khem Raj 
---
 recipes-kernel/linux/linux-raspberrypi_4.8.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-kernel/linux/linux-raspberrypi_4.8.bb 
b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
index 02623f4..7934747 100644
--- a/recipes-kernel/linux/linux-raspberrypi_4.8.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_4.8.bb
@@ -1,8 +1,8 @@
 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
 
-LINUX_VERSION ?= "4.8.1"
+LINUX_VERSION ?= "4.8.2"
 
-SRCREV = "5b7970b19bbb2ea1620591bfb6517848696ed0b9"
+SRCREV = "0105b0ea92b1614ac00329a530da940053e64a4a"
 SRC_URI = 
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-4.8.y \
 "
 require linux-raspberrypi.inc
-- 
2.10.0

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