Re: [yocto] Create uncompressed rootfs

[Anders Darander]

* Andre McCurdy  [151102 20:35]:

> See the "IMAGE_TYPES" variable for a list of rootfs types which are
> supported. There's support for creating an uncompressed .tar file, but
> I don't see any support for creating a rootfs directory under
> tmp/deploy.

No, the usual workflow here is to unpack the tar'ed rootfs at a suitable
location.

> Depending on your work flow there are a few different solutions
> though. You could extend
> openembedded-core/meta/classes/image_types.bbclass to do what you want
> (e.g. define a new image type or hack "IMAGE_CMD_tar" so that it also
> untars rootfs.tar right after creating it). 

Well, there's some issues with this approach. In order to uncompress the
tarball and be able to set owner, group, and permissions on all files,
you need to untar the rootfs with root privileges. The same is true when
it comes to creating device nodes.

Thus, I think it really do make a lot more sense to untar the rootfs in
an external step, which very well could be scripted.

> Or you could ignore OE's
> image creation and manually copy or rsync your image's rootfs ( under
> tmp/work/...//.../rootfs ) to the directory exported
> by your NFS server. Note that you probably shouldn't export
> tmp/work/.../rootfs directly since when the target boots it will
> create files owned by root, which will cause problems later if you try
> to rebuild or modify the rootfs.

No, avoid doing this. The reasons are the same as why you shouldn't
unpack the tarball using a new image type; you're not allowed to set the
correct owner, group, and permissions on files, nor are you allowed to
create device nodes.

Cheers,
Anders

-- 
Anders Darander
ChargeStorm AB / eStorm AB
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Reminder: Yocto Project Technical Team Meeting - Tuesday, Nov. 3, 2015 8:00 AM US Pacific Time

[Jolley, Stephen K]

Tuesday, Nov. 3, 2015 8:00 AM US Pacific Time



Agenda:



* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features

* Opens - 10 min

* Team Sharing - 10 min





We encourage people attending the meeting to logon the Yocto Project IRC 
chancel during the meeting (optional):



Yocto IRC: http://webchat.freenode.net/?channels=#yocto

IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html



Conference Details:

Company:   WIND RIVER SYS

Ready-Access Number: 8007302996/9139049836

Access Code: 2705751


For International numbers see: 
https://www.yoctoproject.org/tools-resources/community/monthly-technical-call


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

[yocto] How to install only a subset of the packages listed in a packagegroup?

[Roberto]

Hi,

 

I have written the following packagegroup called packagegroup-amatek.bb for
testing purposes :

 

# Copyright (C) 2012-2013 Freescale Semiconductor

# Released under the MIT license (see COPYING.MIT for the terms)

 

DESCRIPTION = "Example package group"

LICENSE = "MIT"

LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58 \

 
file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"

 

PR = "r5"

 

inherit packagegroup

 

PROVIDES = "${PACKAGES}"

PACKAGES += " \

   ${PN}-package1 \

${PN}-package2 \

"

 

 

RDEPENDS_${PN}-package1 = " \

   package1-depend1 \

"

 

RDEPENDS_${PN}-package2 = " \

   package2-depend2 \

"

 

 

PACKAGE_ARCH = "${MACHINE_ARCH}"

 

If in my custom image file (amatek-image) I include only
packagegroup-amatek-package1:

 

IMAGE_INSTALL = "packagegroup-amatek-package1"

 

I would expect that package2-depend2 is not installed because it is a
dependency of the package packagegroup-amatek-package2 which is not
installed.

 

However, bitbake amatek-image -g -u depexp shows that package2-depend2 is
installed as well:

 

  enter image description here

 

Is this the expected behaviour?

Regards,

Roberto

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

[yocto] Release Candidate Build for yocto-2.0.rc3.rc3 now available.

[Poky Build User]

-e 
A release candidate build for yocto-2.0.rc3 is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.rc3


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 42cd81d2058e957b0dd223f6017687e134f6c21f 
meta-fsl-arm : 2f78ef1230481e0da690296a6a41330d7ffc4c13 
meta-minnow : 9c965ef5252e383843d796cd8b50c61b3034b6ae 
meta-qt3 : 5233565c80db869f6f539f37f26ea6662d9dc5f6 
meta-fsl-ppc : 84263d57fcada761a350015ce4d77fb91af54bf8 
poky : e1aa897beb33171bc902207b98c8f666b9e97ad3 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] COPY_LIC_DIRS, COPY_LIC_MANIFEST and firmware upgrades

[Bryan Evenson]

Martin,

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Monday, November 02, 2015 3:32 PM
> To: Bryan Evenson 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] COPY_LIC_DIRS, COPY_LIC_MANIFEST and firmware
> upgrades
> 
> On Mon, Nov 02, 2015 at 05:13:48PM +, Bryan Evenson wrote:
> > All,
> >
> > I'm on poky/dizzy-1.7.2 and I've been using COPY_LIC_DIRS and
> COPY_LIC_MANIFEST to include the license text on my image.  I noticed
> something about the way it operates and I'm wondering if it's a problem
> when it comes to Free and Open Source Software compliance.
> >
> > If I build an image with COPY_LIC_MANIFEST and COPY_LIC_DIRS both set
> to 1, then the image is generated with the directory /usr/share/common-
> licenses that include all the licenses for all the packages in the image.  
> There is
> also /usr/share/common-licenses/license.manifest which summarizes all the
> licenses in the directory.  Let's call this starting point image version A.
> >
> > Later on in development I add package "foo-extra" to the image.  I add
> "foo-extra" to the RDEPENDS list for package "foo" which now needs the
> new package for proper operation.  The built image now includes in
> /usr/share/common-licenses/foo-extra the license for the new package.
> We'll call this image version B.
> >
> > If I ship a product that was burned with image verison A then it has all the
> licenses for all the packages that were installed in the image.  Likewise, if 
> I
> ship a product that was burned with image version B then it has all the
> licenses for all the packages that were installed in the image.  However, if a
> product ships with image version A and then is upgraded to image version B
> then package "foo-extra" is installed due to dependencies but the license for
> "foo-extra" is not included in the upgrade.  The /usr/share/common-licenses
> directory is not tied to any package, so firmware upgrade does not add,
> modify or remove any of the licenses in /usr/share/common-licenses.
> >
> > Is this a problem when it comes to FOSS compliance?  If so, is there a
> suggested way of including the new licenses for firmware upgrades?
> 
> You can also enable LICENSE_CREATE_PACKAGE which should create -
> lic packages rrecommended from  so they should get installed together
> with image upgrade, see:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=3743

Thanks for the information, I'll give this a try.  I noticed I don't see any 
reference to LICENSE_CREATE_PACKAGE in the Yocto documentation.  Should I add a 
bug in Bugzilla to add documentation for this variable?

Regards,
Bryan

> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] should layers define BB_DANGLINGAPPENDS_WARNONLY ?= "1"?

[Khem Raj]

On Mon, Nov 2, 2015 at 9:54 AM, Robert P. J. Day  wrote:
>
>   perusing the meta-musl layer, and noticed in layer.conf the line:
>
> BB_DANGLINGAPPENDS_WARNONLY ?= "1"

should be avoided although meta-musl is a bit core in nature.
this is so that it can interface with several different compilers
coming from different layers and also different oe-core releases can
work with same branch of meta-musl.
 one may not have same layers attached to it. Ideally, those patches
should now become part
of the original layers as they have been accepted in gcc upstream and
so on. Hopefully as I will take
this into oe-core in coming months this should disappear.

>
> i thought this was a bit odd since (at least to me) it seems like the
> sort of thing a *developer* might set in their local.conf to
> temporarily deal with a dangling .bbappend file -- it never occurred
> to me that it would be appropriate for a layer to define that value
> itself as an inherent part of its own ... layerness.
>
>   a quick grep of the couple dozen layers i have checked out revealed
> two layers that do that:
>
> ./meta-musl/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY ?= "1"
> ./meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY
> ?= "true"
>
>   i'm curious what others think of this approach.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
> --
> ___
> 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] COPY_LIC_DIRS, COPY_LIC_MANIFEST and firmware upgrades

[Martin Jansa]

On Mon, Nov 02, 2015 at 05:13:48PM +, Bryan Evenson wrote:
> All,
> 
> I'm on poky/dizzy-1.7.2 and I've been using COPY_LIC_DIRS and 
> COPY_LIC_MANIFEST to include the license text on my image.  I noticed 
> something about the way it operates and I'm wondering if it's a problem when 
> it comes to Free and Open Source Software compliance.
> 
> If I build an image with COPY_LIC_MANIFEST and COPY_LIC_DIRS both set to 1, 
> then the image is generated with the directory /usr/share/common-licenses 
> that include all the licenses for all the packages in the image.  There is 
> also /usr/share/common-licenses/license.manifest which summarizes all the 
> licenses in the directory.  Let's call this starting point image version A.
> 
> Later on in development I add package "foo-extra" to the image.  I add 
> "foo-extra" to the RDEPENDS list for package "foo" which now needs the new 
> package for proper operation.  The built image now includes in 
> /usr/share/common-licenses/foo-extra the license for the new package.  We'll 
> call this image version B.
> 
> If I ship a product that was burned with image verison A then it has all the 
> licenses for all the packages that were installed in the image.  Likewise, if 
> I ship a product that was burned with image version B then it has all the 
> licenses for all the packages that were installed in the image.  However, if 
> a product ships with image version A and then is upgraded to image version B 
> then package "foo-extra" is installed due to dependencies but the license for 
> "foo-extra" is not included in the upgrade.  The /usr/share/common-licenses 
> directory is not tied to any package, so firmware upgrade does not add, 
> modify or remove any of the licenses in /usr/share/common-licenses.
> 
> Is this a problem when it comes to FOSS compliance?  If so, is there a 
> suggested way of including the new licenses for firmware upgrades?

You can also enable LICENSE_CREATE_PACKAGE which should create -lic
packages rrecommended from  so they should get installed together
with image upgrade, see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3743

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] COPY_LIC_DIRS, COPY_LIC_MANIFEST and firmware upgrades

[Bryan Evenson]

All,

I'm on poky/dizzy-1.7.2 and I've been using COPY_LIC_DIRS and COPY_LIC_MANIFEST 
to include the license text on my image.  I noticed something about the way it 
operates and I'm wondering if it's a problem when it comes to Free and Open 
Source Software compliance.

If I build an image with COPY_LIC_MANIFEST and COPY_LIC_DIRS both set to 1, 
then the image is generated with the directory /usr/share/common-licenses that 
include all the licenses for all the packages in the image.  There is also 
/usr/share/common-licenses/license.manifest which summarizes all the licenses 
in the directory.  Let's call this starting point image version A.

Later on in development I add package "foo-extra" to the image.  I add 
"foo-extra" to the RDEPENDS list for package "foo" which now needs the new 
package for proper operation.  The built image now includes in 
/usr/share/common-licenses/foo-extra the license for the new package.  We'll 
call this image version B.

If I ship a product that was burned with image verison A then it has all the 
licenses for all the packages that were installed in the image.  Likewise, if I 
ship a product that was burned with image version B then it has all the 
licenses for all the packages that were installed in the image.  However, if a 
product ships with image version A and then is upgraded to image version B then 
package "foo-extra" is installed due to dependencies but the license for 
"foo-extra" is not included in the upgrade.  The /usr/share/common-licenses 
directory is not tied to any package, so firmware upgrade does not add, modify 
or remove any of the licenses in /usr/share/common-licenses.

Is this a problem when it comes to FOSS compliance?  If so, is there a 
suggested way of including the new licenses for firmware upgrades?

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

Re: [yocto] Create uncompressed rootfs

[Andre McCurdy]

On Sun, Nov 1, 2015 at 9:20 PM, Roberto  wrote:
> Hi,
>

Hi Roberto,

>
> I apologise if this is not the right channel for asking the following
> question. If so, please advise me on a more appropriate support channel.
>
>
>
> I am looking for the quickest workflow for debugging a recipe. I basically
> need to modify a recipe, deploy the entire distribution to the target board
> and test it.
>
>
>
> have come to the conclusion that the quickest way is to boot the target
> board through TFTP for the kernel and then mount the rootfs via NFS.
>
>
>
> In my view, the only issue of this workflow is that when I bitbake the image
> it creates a compressed rootfs that then I have to uncompress in order to
> provide the rootfs to the target board via NFS.
>
>
>
> Is there any way to avoid bitbake compressing the rootfs but rather having
> it uncompressed in some folders under tmp/deploy ?

See the "IMAGE_TYPES" variable for a list of rootfs types which are
supported. There's support for creating an uncompressed .tar file, but
I don't see any support for creating a rootfs directory under
tmp/deploy.

Depending on your work flow there are a few different solutions
though. You could extend
openembedded-core/meta/classes/image_types.bbclass to do what you want
(e.g. define a new image type or hack "IMAGE_CMD_tar" so that it also
untars rootfs.tar right after creating it). Or you could ignore OE's
image creation and manually copy or rsync your image's rootfs ( under
tmp/work/...//.../rootfs ) to the directory exported
by your NFS server. Note that you probably shouldn't export
tmp/work/.../rootfs directly since when the target boots it will
create files owned by root, which will cause problems later if you try
to rebuild or modify the rootfs.

>
> Regards,
>
>
>
> Roberto
>
>
> --
> ___
> 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] populate_sdk and debian packages problem

[Martin Townsend]

Hi,

I've just moved everything to fido and everything builds fine.  One of the
reasons for moving to Fido was to use the built toolchain and create an SDK
using populate_sdk but it is failing with the following message:
ERROR: Unable to install packages. Command
'/home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/sysroots/x86_64-linux/usr/bin/apt-get
install --force-yes --allow-unauthenticated nativesdk-packagegroup-sdk-host
packagegroup-cross-canadian-am43-devboard-aquila' returned 100:
Reading package lists...
Building dependency tree...
Reading state information...
W: Unable to read
/home/martin/ws_poweroasis/build/am43-devboard-aquila/bia-tmp-glibc/work/am43_devboard_aquila-oe-linux-gnueabi/bia-image/1.0-r0/apt-sdk/preferences.d/
- DirectoryExists (2: No such file or directory)
E: Unable to locate package nativesdk-packagegroup-sdk-host

I checked the nativesdk-packagegroup-sdk-host build and it's empty.

After a bit of searching I found that a similar problem exists in Daisy and
it was down to debian packages which I am using so I chaged to use the
default IPK and the error message disappears.

Is this a regression? or are Debian packages not supported for SDK?

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

Re: [yocto] should layers define BB_DANGLINGAPPENDS_WARNONLY ?= "1"?

[Gary Thomas]

On 2015-11-02 10:54, Robert P. J. Day wrote:


   perusing the meta-musl layer, and noticed in layer.conf the line:

BB_DANGLINGAPPENDS_WARNONLY ?= "1"

i thought this was a bit odd since (at least to me) it seems like the
sort of thing a *developer* might set in their local.conf to
temporarily deal with a dangling .bbappend file -- it never occurred
to me that it would be appropriate for a layer to define that value
itself as an inherent part of its own ... layerness.

   a quick grep of the couple dozen layers i have checked out revealed
two layers that do that:

./meta-musl/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY ?= "1"
./meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY
?= "true"

   i'm curious what others think of this approach.


Sounds dangerous, bordering on incorrect (or irresponsible) to me.
This could easily mask a problem and is not layer specific, i.e.
the warning would then apply to all layers, not just meta-musl.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] should layers define BB_DANGLINGAPPENDS_WARNONLY ?= "1"?

[Paul Eggleton]

Hi Robert,

On Monday 02 November 2015 12:54:33 Robert P. J. Day wrote:
>   perusing the meta-musl layer, and noticed in layer.conf the line:
> 
> BB_DANGLINGAPPENDS_WARNONLY ?= "1"
> 
> i thought this was a bit odd since (at least to me) it seems like the
> sort of thing a *developer* might set in their local.conf to
> temporarily deal with a dangling .bbappend file -- it never occurred
> to me that it would be appropriate for a layer to define that value
> itself as an inherent part of its own ... layerness.
> 
>   a quick grep of the couple dozen layers i have checked out revealed
> two layers that do that:
> 
> ./meta-musl/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY ?= "1"
> ./meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf:BB_DANGLINGAPPEND
> S_WARNONLY ?= "true"
> 
>   i'm curious what others think of this approach.

I'd say no, they shouldn't really. As a user of the layer you might not 
realise that it's making this change to your configuration.

Cheers,
Paul

-- 

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

[yocto] should layers define BB_DANGLINGAPPENDS_WARNONLY ?= "1"?

[Robert P. J. Day]

  perusing the meta-musl layer, and noticed in layer.conf the line:

BB_DANGLINGAPPENDS_WARNONLY ?= "1"

i thought this was a bit odd since (at least to me) it seems like the
sort of thing a *developer* might set in their local.conf to
temporarily deal with a dangling .bbappend file -- it never occurred
to me that it would be appropriate for a layer to define that value
itself as an inherent part of its own ... layerness.

  a quick grep of the couple dozen layers i have checked out revealed
two layers that do that:

./meta-musl/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY ?= "1"
./meta-yocto-kernel-extras/meta-kernel-dev/conf/layer.conf:BB_DANGLINGAPPENDS_WARNONLY
?= "true"

  i'm curious what others think of this approach.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[yocto] what are the currently-supported beaglebone-flavoured layers?

[Robert P. J. Day]

  just checking which layers out there still have value WRT the
beaglebone black, and while meta-yocto-bsp and the meta-ti layer
clearly(?) are still being updated, the "meta-beagleboard" layer:

git://github.com/beagleboard/meta-beagleboard.git

listed at layers.openembedded.org apparently hasn't been updated in
just over two years, so is it safe to conclude it's not getting any
more care?

  are there any other BBB-related layers worth perusing?

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [yocto] openjpeg on github

[Burton, Ross]

On 2 November 2015 at 16:42, Edward Vidal  wrote:

> When a project is using git instead of tar file which branch is used?
> Is best to be using git or tar file with yocto?
>

I prefer tarballs if there is a choice as they're theoretically immutable
and we can checksum them, but many upstreams are only using git and tags so
you have no choice.

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

[yocto] openjpeg on github

[Edward Vidal]

Hello All,When a project is using git instead of tar file which branch is 
used?Is best to be using git or tar file with yocto?
Openjepeg is now on github.   The openjpeg 2.1.0 was at SRC_URI = 
"${SOURCEFORGE_MIRROR}/project/${BPN}.mirror/${PV}/${BPN}-${PV}.tar.gz".   I 
did the following to create a new recipe.
recipetool create  -o 
/home/vidal/wkg/yocto/RaspberryPi2/poky/meta-oe/recipes-graphics/openjpeg/openjpeg_git.bb
 https://github.com/uclouvain/openjpeg.git
 # Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be 
fully functional.
# (Feel free to remove these comments when editing.)
#
# Unable to find any files that looked like license statements. Check the 
accompanying
# documentation and source headers and set LICENSE and LIC_FILES_CHKSUM 
accordingly.
#
# NOTE: LICENSE is being set to "CLOSED" to allow you to at least start 
building - if
# this is not accurate with respect to the licensing of the software being 
built (it
# will not be in most cases) you must specify the correct value before using 
this
# recipe for anything other than initial testing/development!
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

SRC_URI = "https://github.com/uclouvain/openjpeg.git";
SRC_URI[md5sum] = "9ad2bb8d9e833bfd74b4885a0f1d3882"
SRC_URI[sha256sum] = 
"af9d33bcc1485f1938ceb13464e66041dc4538dccc8edf02320141b0da9f95c6"
inherit cmake

DEPENDS = "libpng tiff lcms"
# NOTE: no Makefile found, unable to determine what needs to be done

do_configure () {
    # Specify any needed configure commands here
    mkdir build
}

do_compile () {
    # Specify compilation commands here
    cd build
    cmake ../
}

do_install () {
    # Specify install commands here
}
When I try bitbake openjpeg I get several errors.
The INSTALL file Using cmake (see www.cmake.org)

Type:
  cmake .
  makeOn my system I created a buildcd build 
cmake ../makeThis builds okay.
Any and all help  is appreaciated.Cheers
 Edward Vidal Jr. e-mail devel...@sbcglobal.net 915-595-1613-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH] update.py: fix splitting on _ when getting class inheritance

[Paul Eggleton]

The code to populate the inherits information was using a function
designed to get the recipe name from a file path, but unlike recipe
filenames, the underscore isn't treated as special in class filenames
and in fact it's quite common to use underscores there; we were ending
up with items in the inherit list such as "populate" and "rootfs". Use
the standard python os.path functions to do the splitting instead and
avoid this.

Signed-off-by: Paul Eggleton 
---
 layerindex/update.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/layerindex/update.py b/layerindex/update.py
index 1e96da6..7497743 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -68,7 +68,7 @@ def update_recipe_file(data, path, recipe, layerdir_start, 
repodir):
 # Handle recipe inherits for this recipe
 gr = set(data.getVar("__inherit_cache", True) or [])
 lr = set(envdata.getVar("__inherit_cache", True) or [])
-recipe.inherits = ' '.join(sorted({split_recipe_fn(r)[0] for r in lr 
if r not in gr}))
+recipe.inherits = ' 
'.join(sorted({os.path.splitext(os.path.basename(r))[0] for r in lr if r not in 
gr}))
 recipe.save()
 
 # Get file dependencies within this layer
-- 
2.1.0

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

Re: [yocto] opkg 0.3.0 or rootfs task

[Alejandro del Castillo]

On 11/02/2015 09:31 AM, Christopher Larson wrote:
> 
> On Mon, Nov 2, 2015 at 8:25 AM, Nicolas Dechesne  > wrote:
> 
> On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson  > wrote:
> 
> 
> I've just posted patches to the opkg-devel list which should fix 
> this. I had
> intended to give them a bit more testing before I sent them but a 
> quick fix is
> needed.
> 
> 
> Thanks for your quick work on this, Paul, it's much appreciated. From 
> some initial testing, builds are completing now. We'll keep testing it out.
> 
> 
> 
> I just hit the same issue. I was pointed out to this thread on IRC today. 
> I found the patches on the 0.3.x branch in the opkg git tree. Apart from 
> applying these patches, do i need to do anything in any OE variables to use 
> the newly added options? I am not entirely sure after reading this thread and 
> looking at the patches..
> 
> 
> No, there's nothing else you need to do. The patches fromPaul change the opkg 
> download cache to use checksums rather than the entire url as the filename, 
> which avoids the file name length problem.

The patches are under review on the opkg mailing list: 
https://groups.google.com/forum/#!topic/opkg-devel/UzDigiuKBcs. I asked Paul 
for a small modification on one of the patches, once that's done, I will pull 
them into the opkg repo (and we'll need to update the opkg recipe).

> I would not apply the first patch in the series, however, since that's not 
> related to this. The first patch (memory leak fix) caused double-free 
> failures in glibc in our testing.

yes, the first patch needs to be dropped

-- 
Cheers,

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

Re: [yocto] Create uncompressed rootfs

[Marco Cavallini]

You could mount the .ext3 image on a partition using -o loop
or find/customize a different solution using IMAGE_TYPES
(i.e. when IMAGE_FSTYPES contains "live")
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html
--
Marco Cavallini | KOAN sas | Bergamo - Italia
embedded and real-time software engineering
http://www.KoanSoftware.com

2015-11-02 6:20 GMT+01:00 Roberto :
> Hi,
>
>
>
> I apologise if this is not the right channel for asking the following
> question. If so, please advise me on a more appropriate support channel.
>
>
>
> I am looking for the quickest workflow for debugging a recipe. I basically
> need to modify a recipe, deploy the entire distribution to the target board
> and test it.
>
>
>
> have come to the conclusion that the quickest way is to boot the target
> board through TFTP for the kernel and then mount the rootfs via NFS.
>
>
>
> In my view, the only issue of this workflow is that when I bitbake the image
> it creates a compressed rootfs that then I have to uncompress in order to
> provide the rootfs to the target board via NFS.
>
>
>
> Is there any way to avoid bitbake compressing the rootfs but rather having
> it uncompressed in some folders under tmp/deploy ?
>
>
>
> Regards,
>
>
>
> Roberto
>
>
> --
> ___
> 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] New prelink version

[Mark Hatle]

I just wanted to updated people on the prelinker, and send out news of a new
release, but first some project announcements.

As some of you may be aware, the previous upstream to the Cross Prelinker has
effectively been abandoned.  This work was being done by Jakub Jelinek at Red
Hat.  However, there have not been any updates since October of 2013.  I have
tried to reach out to him a few times and have not gotten a response.

So effectively immediately, I am planning on supporting both a standalone
prelink and cross prelinker.  In order to do this, there are now two 'release'
branches in the git://git.yoctoproject.org/prelink-cross, 'master' and
'cross_prelink'.

The 'master' branch is intended to replace the former prelink that was created
and managed by Jakub.  It is a standalone project that does not provide any of
the cross compilation helper items, such as the prelink-rtld and sysroot
(--root=) processing.  It will contain all of the latest patches for
architecture functionality and bug fixes.

The 'cross_prelink' branch, as it has been, is the home for the cross
compilation version of the prelinker.  It will be functionally identical to the
'master' branch -- but contain prelink-rtld and the sysroot functions.

In addition, I intend to do regular date-based tags to indicate stable release
points.  This is similar to how Jakub did releases for the prelinker.

Two tags will be generated, both with the same date, and one ending in '_cross'.
 The _cross indicates it contains the cross compilation functionality.

...and now... the first release

20151030 and 20151030_cross

Common changes:

* Add additional debugging in certain places
* Take over full maintainership of the project
* general: Update type_class values to sync w/ glibc-2.22
* MIPS: Add SHT_MIPS_ABIFLAGS support
* ARM: Fix ARM IFUNC implementation (bad patch merge)

Cross changes:
* Rebase the prelink-rtld on glibc-2.22
* Add NIOS2 support to the prelink-rtld

Notes:

If you are using the standalone prelinker with glibc-2.22 on IA32 or ARM, due to
a bug in glibc-2.22, you -must- have the following patch applied to glibc:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=cadaf1336332ca7bcdfe4a400776e5782a20e26d

for more info see:

https://sourceware.org/bugzilla/show_bug.cgi?id=19178

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

Re: [yocto] opkg 0.3.0 or rootfs task

[Christopher Larson]

On Mon, Nov 2, 2015 at 8:25 AM, Nicolas Dechesne <
nicolas.deche...@linaro.org> wrote:

> On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson 
> wrote:
>
>>
>>> I've just posted patches to the opkg-devel list which should fix this. I
>>> had
>>> intended to give them a bit more testing before I sent them but a quick
>>> fix is
>>> needed.
>>
>>
>> Thanks for your quick work on this, Paul, it's much appreciated. From
>> some initial testing, builds are completing now. We'll keep testing it out.
>
>
>
> I just hit the same issue. I was pointed out to this thread on IRC today.
> I found the patches on the 0.3.x branch in the opkg git tree. Apart from
> applying these patches, do i need to do anything in any OE variables to use
> the newly added options? I am not entirely sure after reading this thread
> and looking at the patches..
>

No, there's nothing else you need to do. The patches fromPaul change the
opkg download cache to use checksums rather than the entire url as the
filename, which avoids the file name length problem.

I would not apply the first patch in the series, however, since that's not
related to this. The first patch (memory leak fix) caused double-free
failures in glibc in our testing.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] opkg 0.3.0 or rootfs task

[Nicolas Dechesne]

On Mon, Oct 26, 2015 at 12:46 AM, Christopher Larson 
wrote:

>
>> I've just posted patches to the opkg-devel list which should fix this. I
>> had
>> intended to give them a bit more testing before I sent them but a quick
>> fix is
>> needed.
>
>
> Thanks for your quick work on this, Paul, it's much appreciated. From some
> initial testing, builds are completing now. We'll keep testing it out.



I just hit the same issue. I was pointed out to this thread on IRC today. I
found the patches on the 0.3.x branch in the opkg git tree. Apart from
applying these patches, do i need to do anything in any OE variables to use
the newly added options? I am not entirely sure after reading this thread
and looking at the patches..

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

Re: [yocto] gcc LIBRARY_PATH sstate-cache issue

[Jérôme OLIVIER]

Hi Andre,

Thanks a lot for this big hint that allowed me to find the cause of this 
problem.

The problem came from the CMakeLists.txt of libB. It was overriding 
CMAKE_C_FLAGS cmake variable defined in the Yocto generated toolchain.cmake.
CMAKE_C_FLGAS contains the "--sysroot" flag for gcc command.


I don't know how it could work before and what in image/machine configurations' 
changes triggered this bug to show up.

I don't know also how, when it was bugged, the build system populated the gcc's 
LIBRARY_PATH variable with sysroots path from the mirrored reference build's 
sstate-cache (build-machineA's sstate-cache).

The most important is that state sharing cache is working fine.


Thanks everyone for the help,

Cheers
-- 
Jérôme OLIVIER
TEL : +337 52 46 29 25
@ : jerome.oliv...@outlook.com

> Date: Wed, 21 Oct 2015 13:58:53 -0700
> Subject: Re: [yocto] gcc LIBRARY_PATH sstate-cache issue
> From: armccu...@gmail.com
> To: jerome.oliv...@outlook.com
> CC: paul.eggle...@linux.intel.com; yocto@yoctoproject.org
> 
> On Wed, Oct 21, 2015 at 5:10 AM, Jérôme OLIVIER
>  wrote:
> >
> > My situation is I have two machines:
> > * machineA
> > * machineB: inherits from machine B (only PREFERRED_VERSION for libxml2
> > added)
> >
> > two images:
> > * imageA
> > * imageB: inherits from image A
> >
> > I have one build directory for each machine:
> > * build-machineA
> > * build-machineB (only new packages added), two of the package are shared
> > libraries : libA and libB. libA is linked to libB. libB depends on libA.
> > libA and libB are cmake recipes
> >
> > First I build the imageA in build-machineA for machineA
> >
> > In the build-machineB directory I build imageB for machineB. Moreover I
> > point SSTATE_DIR or SSTATE_MIRRORS of build-machineB/conf/local.conf to
> > build-machineA's sstate-cache directory.
> >
> > libA is built with success but libB's do_compile fails:
> >
> > /.../build-machineB$ bitbake libB
> > [...]
> >
> > /.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/arm-opensdk-linux-gnueabi-gcc
> > -fPIC -g -O2 -W -Werror -Wall -Wextra -Wuninitialized -Wstrict-prototypes
> > -Wcast-align -Wmissing-prototypes -Wchar-subscripts -Wpointer-arith -Winline
> > -Wno-conversion -Wshadow  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
> > -shared -Wl,-soname,libsys.so.1 -o libsys.so.1
> > CMakeFiles/sys.dir/src/crc.c.o CMakeFiles/sys.dir/src/fast_32k_utils.c.o
> > CMakeFiles/sys.dir/src/filemap.c.o CMakeFiles/sys.dir/src/hash_tables.c.o
> > CMakeFiles/sys.dir/src/hash_tables_2.c.o
> > CMakeFiles/sys.dir/src/ipcs_keys.c.o CMakeFiles/sys.dir/src/log.c.o
> > CMakeFiles/sys.dir/src/MM.c.o CMakeFiles/sys.dir/src/MM_no_mutex.c.o
> > CMakeFiles/sys.dir/src/random.c.o CMakeFiles/sys.dir/src/registry.c.o
> > CMakeFiles/sys.dir/src/time.c.o CMakeFiles/sys.dir/src/watchdog_timer.c.o
> > CMakeFiles/sys.dir/src/watchdog_client.c.o
> > CMakeFiles/sys.dir/src/watchdog_server.c.o
> > CMakeFiles/sys.dir/src/state_machine.c.o
> > CMakeFiles/sys.dir/src/thread_manager.c.o
> > CMakeFiles/sys.dir/src/sg_log_eina.c.o -lpthread -leina -lpthread -leina
> >
> > /.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/../../libexec/arm-opensdk-linux-gnueabi/gcc/arm-opensdk-linux-gnueabi/4.9.1/ld:
> > cannot find -llibA
> >
> > collect2: error: ld returned 1 exit status
> >
> > ERROR: Function failed: do_compile (log file is located at
> > /.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/temp/log.do_compile.2284)
> >
> >
> > At this moment I had to find why ld cannot find libA.so in sysroots so I
> > launched a devshell on libB. In the devshell I cd-ed to the B dir of libB
> > and run the cross-gcc command with the verbose "-v" option.
> >
> > /.../build-machineB$ bitbake libB -c devshell
> >
> > [devshell]
> > /.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/git
> > $ cd ../build
> >
> > [devshell]
> > /.../build-machineB/tmp-glibc/work/cortexa9t2hf-vfp-neon-opensdk-linux-gnueabi/libB/1.0.0/build$
> > /.../build-machineB/tmp-glibc/sysroots/i686-linux/usr/bin/arm-opensdk-linux-gnueabi/arm-opensdk-linux-gnueabi-gcc
> > -fPIC -g -O2 -W -Werror -Wall -Wextra -Wuninitialized -Wstrict-prototypes
> > -Wcast-align -Wmissing-prototypes -Wchar-subscripts -Wpointer-arith -Winline
> > -Wno-conversion -Wshadow  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
> > -shared -Wl,-soname,libsys.so.1 -o libsys.so.1
> > CMakeFiles/sys.dir/src/crc.c.o CMakeFiles/sys.dir/src/fast_32k_utils.c.o
> > CMakeFiles/sys.dir/src/filemap.c.o CMakeFiles/sys.dir/src/hash_tables.c.o
> > CMakeFiles/sys.dir/src/hash_tables_2.c.o
> > CMakeFiles/sys.dir/src/ipcs_keys.c.o CMakeFiles/sys.dir/src/log.c.o
> > CMakeFiles/sys.dir/src/MM.c.o CMakeFiles/sys.dir/src/MM_no_mutex.c.o
> > CMakeFiles/sys.dir/src/random.c.o CMakeFiles/sys.dir/src/registry.c.o
> > CMakeFiles/sys.dir/src/time.c.o CMakeFiles/sys.dir/src/watchdog_timer.c.o
> > CMakeF

Re: [yocto] [PATCH][yocto-autobuilder] buildset-config.controller: Workaround module dependency issue

[Flanagan, Elizabeth]

On 2 November 2015 at 11:57, Burton, Ross  wrote:
> Acked-by: Ross Burton 
>
> Beth, please merge before the RC3 build.
>

Pulled into master and pushed into production. Thanks.

> Ross
>
> On 2 November 2015 at 11:58, Jussi Kukkonen 
> wrote:
>>
>> Dynamically loaded modules are a problem for multilib builds: 32-bit
>> Pango and Gdk-Pixbuf modules in particular do not get included in the
>> image when 32-bit versions of the libraries get included.
>>
>> Proper fix may require extensive changes to dependency handling:
>> Include the required modules manually in the test configuration as a
>> workaround for 2.0.
>>
>> Fixes [YOCTO #8624].
>> The underlying issue is [YOCTO #8570]
>>
>> Signed-off-by: Jussi Kukkonen 
>> ---
>>  buildset-config.controller/nightly-multilib.conf | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/buildset-config.controller/nightly-multilib.conf
>> b/buildset-config.controller/nightly-multilib.conf
>> index 7cf75c3..bc63c39 100644
>> --- a/buildset-config.controller/nightly-multilib.conf
>> +++ b/buildset-config.controller/nightly-multilib.conf
>> @@ -24,13 +24,13 @@ steps: [{'SetDest':{}},
>>  {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' :
>> 'x86_64',
>>  'buildhistory' : False, 'multilib': 'lib32',
>>  'distro': 'poky',
>> -'atextappend' : '\nRPM_PREFER_ELF_ARCH =
>> "1"\nIMAGE_INSTALL_append = " lib32-connman-gnome"\n'}},
>> +'atextappend' : '\nRPM_PREFER_ELF_ARCH =
>> "1"\nIMAGE_INSTALL_append = " lib32-connman-gnome gdk-pixbuf-loader-jpeg
>> lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
>> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
>> lib32-pango-module-basic-fc"\n'}},
>>  {'BuildImages': {'images': 'core-image-sato'}},
>>  {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' :
>> 'multilib'}},
>>  {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' :
>> 'x86_64',
>>  'buildhistory' : False, 'multilib': 'lib32',
>>  'distro': 'poky', 'packages' : 'ipk',
>> -'atextappend' : '\nIMAGE_INSTALL_append = "
>> lib32-connman-gnome"\n'}},
>> +'atextappend' : '\nIMAGE_INSTALL_append = "
>> lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg
>> gdk-pixbuf-loader-png  lib32-gdk-pixbuf-loader-png pango-module-basic-fc
>> lib32-pango-module-basic-fc"\n'}},
>>  {'BuildImages': {'images': 'core-image-sato'}},
>>  {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' :
>> 'multilib'}},
>>  {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
>> --
>> 2.1.4
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.



-- 
Elizabeth Flanagan
Yocto Project
Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH][yocto-autobuilder] buildset-config.controller: Workaround module dependency issue

[Burton, Ross]

Acked-by: Ross Burton 

Beth, please merge before the RC3 build.

Ross

On 2 November 2015 at 11:58, Jussi Kukkonen 
wrote:

> Dynamically loaded modules are a problem for multilib builds: 32-bit
> Pango and Gdk-Pixbuf modules in particular do not get included in the
> image when 32-bit versions of the libraries get included.
>
> Proper fix may require extensive changes to dependency handling:
> Include the required modules manually in the test configuration as a
> workaround for 2.0.
>
> Fixes [YOCTO #8624].
> The underlying issue is [YOCTO #8570]
>
> Signed-off-by: Jussi Kukkonen 
> ---
>  buildset-config.controller/nightly-multilib.conf | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/buildset-config.controller/nightly-multilib.conf
> b/buildset-config.controller/nightly-multilib.conf
> index 7cf75c3..bc63c39 100644
> --- a/buildset-config.controller/nightly-multilib.conf
> +++ b/buildset-config.controller/nightly-multilib.conf
> @@ -24,13 +24,13 @@ steps: [{'SetDest':{}},
>  {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' :
> 'x86_64',
>  'buildhistory' : False, 'multilib': 'lib32',
>  'distro': 'poky',
> -'atextappend' : '\nRPM_PREFER_ELF_ARCH =
> "1"\nIMAGE_INSTALL_append = " lib32-connman-gnome"\n'}},
> +'atextappend' : '\nRPM_PREFER_ELF_ARCH =
> "1"\nIMAGE_INSTALL_append = " lib32-connman-gnome gdk-pixbuf-loader-jpeg
> lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png
> lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc"\n'}},
>  {'BuildImages': {'images': 'core-image-sato'}},
>  {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' :
> 'multilib'}},
>  {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' :
> 'x86_64',
>  'buildhistory' : False, 'multilib': 'lib32',
>  'distro': 'poky', 'packages' : 'ipk',
> -'atextappend' : '\nIMAGE_INSTALL_append = "
> lib32-connman-gnome"\n'}},
> +'atextappend' : '\nIMAGE_INSTALL_append = "
> lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg
> gdk-pixbuf-loader-png  lib32-gdk-pixbuf-loader-png pango-module-basic-fc
> lib32-pango-module-basic-fc"\n'}},
>  {'BuildImages': {'images': 'core-image-sato'}},
>  {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' :
> 'multilib'}},
>  {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
> --
> 2.1.4
>
> --
> ___
> 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] [PATCH][yocto-autobuilder] buildset-config.controller: Workaround module dependency issue

[Jussi Kukkonen]

Dynamically loaded modules are a problem for multilib builds: 32-bit
Pango and Gdk-Pixbuf modules in particular do not get included in the
image when 32-bit versions of the libraries get included.

Proper fix may require extensive changes to dependency handling:
Include the required modules manually in the test configuration as a
workaround for 2.0.

Fixes [YOCTO #8624].
The underlying issue is [YOCTO #8570]

Signed-off-by: Jussi Kukkonen 
---
 buildset-config.controller/nightly-multilib.conf | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/buildset-config.controller/nightly-multilib.conf 
b/buildset-config.controller/nightly-multilib.conf
index 7cf75c3..bc63c39 100644
--- a/buildset-config.controller/nightly-multilib.conf
+++ b/buildset-config.controller/nightly-multilib.conf
@@ -24,13 +24,13 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64',
 'buildhistory' : False, 'multilib': 'lib32',
 'distro': 'poky',
-'atextappend' : '\nRPM_PREFER_ELF_ARCH = 
"1"\nIMAGE_INSTALL_append = " lib32-connman-gnome"\n'}},
+'atextappend' : '\nRPM_PREFER_ELF_ARCH = 
"1"\nIMAGE_INSTALL_append = " lib32-connman-gnome gdk-pixbuf-loader-jpeg 
lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png  lib32-gdk-pixbuf-loader-png 
pango-module-basic-fc lib32-pango-module-basic-fc"\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'multilib'}},
 {'CreateAutoConf': {'machine': 'qemux86-64', 'SDKMACHINE' : 'x86_64',
 'buildhistory' : False, 'multilib': 'lib32',
 'distro': 'poky', 'packages' : 'ipk',
-'atextappend' : '\nIMAGE_INSTALL_append = " 
lib32-connman-gnome"\n'}},
+'atextappend' : '\nIMAGE_INSTALL_append = " 
lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg 
gdk-pixbuf-loader-png  lib32-gdk-pixbuf-loader-png pango-module-basic-fc 
lib32-pango-module-basic-fc"\n'}},
 {'BuildImages': {'images': 'core-image-sato'}},
 {'RunSanityTests': {'images': 'core-image-sato', 'suitesappend' : 
'multilib'}},
 {'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
-- 
2.1.4

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

[yocto] Yocto 1.7.3.rc1 Full Pass test report

[Georgescu, Alexandru C]

Hello,
Here is the Full Pass test report for YP 1.7.3.rc1 release. No blockers have 
been found during the test campaign.

The full test report can be accessed 
here.



 Test type:  Full Pass Release Test

 Branch: master

 Build name: 1.7.3.rc1

 poky commit: b38454c2e3a7a58f5397bb16d59e2b0aa71c4a94

 Autobuilder images repository: 
http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.3.rc1

 Distributions tested: Ubuntu 15.04 64bit, Fedora 22 64bit, Fedora 22 32bit, 
Opensuse 13.2 64bit, CentOS 7 64 bit

Summary Report
Testing Summary Report

Test Run

Test Plan

Environment

Passed

Other issues

Failed

Failing bugs

Blocked

Blocking bugs

Complete

4850

ADT: dizzy branch

Fedora 22 i686

100.0%

none

0.0%

none

0.0%

none

100.0%

4849

ADT: dizzy branch

Ubuntu 14.04 x86_64

100.0%

none

0.0%

none

0.0%

none

100.0%

4847

BSP/QEMU: dizzy branch

Beaglebone Black

100.0%

none

0.0%

none

0.0%

none

100.0%

4853

BSP/QEMU: dizzy branch

EdgeRouter

100.0%

none

0.0%

none

0.0%

none

100.0%

47734842

BSP/QEMU: dizzy branch

genericx86 - on MMAX32bit

94.7%

none

5.3%

6584789785268473

0.0%

none

100.0%

4844

BSP/QEMU: dizzy branch

genericx86-64 on MMAX64

95.1%

none

4.9%

65847897

0.0%

none

100.0%

47724843

BSP/QEMU: dizzy branch

genericx86-64 on NUC

96.8%

none

3.2%

65848473

0.0%

none

100.0%

4854

BSP/QEMU: dizzy branch

MPC8315e-rdb

100.0%

none

0.0%

none

0.0%

none

100.0%

4848

BSP/QEMU: dizzy branch

P1022ds

100.0%

none

0.0%

none

0.0%

none

100.0%

4774

BSP/QEMU: dizzy branch

qemu-x86

100.0%

none

0.0%

none

0.0%

none

100.0%

4776

BSP/QEMU: dizzy branch

qemuarm

100.0%

none

0.0%

none

0.0%

none

100.0%

4777

BSP/QEMU: dizzy branch

qemumips

100.0%

none

0.0%

none

0.0%

none

100.0%

4778

BSP/QEMU: dizzy branch

qemuppc

100.0%

none

0.0%

none

0.0%

none

100.0%

4775

BSP/QEMU: dizzy branch

qemux86-64

100.0%

none

0.0%

none

0.0%

none

100.0%

48514852

Meta-yocto: dizzy branch

Ubuntu 14.04 x86_64

100.0%

6156

0.0%

none

0.0%

none

100.0%

47454746

HOB: dizzy branch

Fedora 22

100.0%

none

0.0%

none

0.0%

none

100.0%

4845

OE-Core: dizzy branch

Multiple environments

100.0%

none

0.0%

none

0.0%

none

100.0%

4846

BitBake: dizzy branch

Ubuntu 14.10 x86_64

100.0%

none

0.0%

none

0.0%

none

100.0%

4924

Automated Build Testing: master branch

CentOS 7 x86_64

100.0%

none

0.0%

none

0.0%

none

100.0%

4923

Automated Build Testing: master branch

Fedora 22 x86-64

100.0%

none

0.0%

none

0.0%

none

100.0%

4922

Automated Build Testing: master branch

OpenSuse 13.2 x86_64

100.0%

none

0.0%

none

0.0%

none

100.0%

4921

Automated Build Testing: master branch

Ubuntu 15.04 x86_64

100.0%

none

0.0%

none

0.0%

non