[yocto] [meta-security][PATCH] swtpm: update to latest tip

[Amarnath Valluri]

Pull in changes to support passing client control sockets(--ctrl
type=unixio,clientfd=), that allows to fork swtpm and communicate using
socketpair.

Signed-off-by: Amarnath Valluri 
---
 recipes-tpm/swtpm/swtpm_1.0.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-tpm/swtpm/swtpm_1.0.bb b/recipes-tpm/swtpm/swtpm_1.0.bb
index 99c6fdc..14f668b 100644
--- a/recipes-tpm/swtpm/swtpm_1.0.bb
+++ b/recipes-tpm/swtpm/swtpm_1.0.bb
@@ -10,7 +10,7 @@ DEPENDS = "libtasn1 fuse expect socat glib-2.0 libtpm 
libtpm-native"
 DEPENDS += "tpm-tools-native expect-native socat-native"
 RDEPENDS_${PN} += "tpm-tools"
 
-SRCREV = "d7bbe3de5cc58c1dca41149df89cfdc08019a722"
+SRCREV = "073e71f99eaa7a0ff9499339176af1af62c090b2"
 SRC_URI = " \
git://github.com/stefanberger/swtpm.git \
file://fix_signed_issue.patch \
-- 
2.7.4

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

Re: [yocto] Sub-directories from Git in SRC-URI

[Eswaran Vinothkumar (BEG/PJ-IOT-EL)]

Hi,

Thanks for your answer. I had thought about using this solution initially. In 
my case I have a common git repo for some 20 different applications and 
planning to write an individual recipe for each application.

If I plan to use in this way, I have 20 copies in my disk which I don't want to 
have.

Mit freundlichen Grüßen / Best regards

Vinothkumar Eswaran
BEG-PT/PJ-IOT1

Von: Esponde, Joel [mailto:joel.espo...@honeywell.com]
Gesendet: Dienstag, 11. April 2017 09:58
An: Eswaran Vinothkumar (BEG/PJ-IOT-EL) ; 
yocto@yoctoproject.org
Betreff: RE: Sub-directories from Git in SRC-URI

Hi,

Here is one way to manage this use case.
In the SRC_URI variable, you set the git repo access.
Now let's say that your sub-directory relative path is "src/myapp".
Son now you just have to add to your recipe this line:

S = "${WORKDIR}/git/src/myapp"

It is not optimized from a disk usage point of view (a full copy of the repo 
files is in ${WORKDIR}/git) but it works.

Regards,

Joël Esponde
Honeywell | Safety and Productivity Solutions

De : yocto-boun...@yoctoproject.org 
[mailto:yocto-boun...@yoctoproject.org] De la part de Eswaran Vinothkumar 
(BEG/PJ-IOT-EL)
Envoyé : mardi 11 avril 2017 08:25
À : yocto@yoctoproject.org
Objet : [yocto] Sub-directories from Git in SRC-URI

Hallo,

May I now is it possible to include a sub-directory from git repo in the 
SRC_URI of bitbake recipe.

Also in SRC_URI is it possible to include a directory instead of a single file?

I know I could create a tar file of a directory and include it , but I would 
like to know is it possible to include directory as a SRC_URI.


Mit freundlichen Grüßen / Best regards

Vinothkumar Eswaran
BEG-PT/PJ-IOT1


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

Re: [yocto] Sub-directories from Git in SRC-URI

[Miguel Aveiro]

Hi,

You might want to take a look at bitbake's documentation:

https://www.yoctoproject.org/docs/2.0/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher

It actually has a git submodules fetcher (gitsm://). I haven't used it, but
it should be straightforward.

Regards,
Miguel Aveiro

On 11 April 2017 at 09:04, Eswaran Vinothkumar (BEG/PJ-IOT-EL) <
vinothkumar.eswa...@de.bosch.com> wrote:

> Hi,
>
>
>
> Thanks for your answer. I had thought about using this solution initially.
> In my case I have a common git repo for some 20 different applications and
> planning to write an individual recipe for each application.
>
>
>
> If I plan to use in this way, I have 20 copies in my disk which I don’t
> want to have.
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
>
>
> *Vinothkumar Eswaran BEG-PT/PJ-IOT1 *
>
> *Von:* Esponde, Joel [mailto:joel.espo...@honeywell.com]
> *Gesendet:* Dienstag, 11. April 2017 09:58
> *An:* Eswaran Vinothkumar (BEG/PJ-IOT-EL)  com>; yocto@yoctoproject.org
> *Betreff:* RE: Sub-directories from Git in SRC-URI
>
>
>
> Hi,
>
>
>
> Here is one way to manage this use case.
>
> In the SRC_URI variable, you set the git repo access.
>
> Now let’s say that your sub-directory relative path is “src/myapp”.
>
> Son now you just have to add to your recipe this line:
>
>
>
> S = "${WORKDIR}/git/src/myapp"
>
>
>
> It is not optimized from a disk usage point of view (a full copy of the
> repo files is in ${WORKDIR}/git) but it works.
>
>
>
> Regards,
>
>
>
> *Joël Esponde*
>
> *Honeywell* | Safety and Productivity Solutions
>
>
>
> *De :* yocto-boun...@yoctoproject.org [mailto:yocto-bounces@
> yoctoproject.org ] *De la part de*
> Eswaran Vinothkumar (BEG/PJ-IOT-EL)
> *Envoyé :* mardi 11 avril 2017 08:25
> *À :* yocto@yoctoproject.org
> *Objet :* [yocto] Sub-directories from Git in SRC-URI
>
>
>
> Hallo,
>
>
>
> May I now is it possible to include a sub-directory from git repo in the
> SRC_URI of bitbake recipe.
>
>
>
> Also in SRC_URI is it possible to include a directory instead of a single
> file?
>
>
>
> I know I could create a tar file of a directory and include it , but I
> would like to know is it possible to include directory as a SRC_URI.
>
>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Vinothkumar Eswaran BEG-PT/PJ-IOT1*
>
>
>
> --
> ___
> 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] Porting a middleware to Yocto

[Alexander Kanavin]

On 04/11/2017 09:20 AM, Eswaran Vinothkumar (BEG/PJ-IOT-EL) wrote:

We are internally using a middleware which acts as an abstraction to
underlying operating system and provides APIs to application layers. Now
the task is to port the middleware to Yocto. The middleware contains lot
of make files and folders which are interdependent and I am at lost on
how to start.

I have some 20 directories which contains makefiles and autotool
configure.ac files to generate lib files.


Without seeing the source code, it is difficult to provide useful help.

If the 20 different things are all set up through a common autoconf 
configuration file, it's probably best to write one recipe for the whole 
thing, and then split it into sub-packages after it has been built.


How does the configuration/compilation/insallation procedure look like? 
What are the commands you need to type?


Alex

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

Re: [yocto] Porting a middleware to Yocto

[Jussi Kukkonen]

On 11 April 2017 at 09:20, Eswaran Vinothkumar (BEG/PJ-IOT-EL) <
vinothkumar.eswa...@de.bosch.com> wrote:

> Hallo,
>
>
>
> For our new project we are planning to use Yocto as a build system to
> build customized Linux distribution. I have already created a BSP for our
> customized hardware with Linux kernel, U-boot and UBIFS rootfs image.
>
>
>
> We are internally using a middleware which acts as an abstraction to
> underlying operating system and provides APIs to application layers. Now
> the task is to port the middleware to Yocto. The middleware contains lot of
> make files and folders which are interdependent and I am at lost on how to
> start.
>
> I have some 20 directories which contains makefiles and autotool
> configure.ac files to generate lib files.
>
>
>
> As of now I have planned to create a new Yocto layer called
> meta-middleware and a recipe file for individual folders. I then create a
> package group which will include all these recipes and can include this
> package group as dependency in the recipes of meta-application layer. I am
> facing a problem like I have to include headers from other recipes. In this
> case to include the headers , is it enough to add “DEPENDS = recipename” ?
>

Yes, a DEPENDS should be all that's needed in the normal case. The
assumption is that the recipe you depend on installs the headers and
libraries like it should -- these will then be made available in the
sysroot of the recipe you are compiling (the location and nature of this
sysroot depends on the version of yocto). If your autotools setup is well
behaving the recipes should be fairly straight forward to write.

If you have issues with not finding headers, start by making sure that the
recipe you depend on installs things correctly: see e.g.
$WORKDIR/sysroot-destdir/ to see files that should become available in the
sysroot of a anyone depending on this recipe. If that looks fine, make sure
the depending project is doing something sane to find the headers (like
using pkg-config): see e.g. $WORKDIR/temp/log.do_configure.

Better advice probably requires you to actually show a problem case and
mention the version of Yocto you are using.

HTH,
  Jussi


> I know my question is relatively vague, but anybody who ported middleware
> from another build systems like ptxdist would have faced similar issues.
> Any input on how you planned to port these source files to Yocto would be
> helpful.
>
>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Vinothkumar Eswaran BEG-PT/PJ-IOT1*
>
>
> --
> ___
> 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] Sub-directories from Git in SRC-URI

[Esponde, Joel]

Hi,

Here is one way to manage this use case.
In the SRC_URI variable, you set the git repo access.
Now let's say that your sub-directory relative path is "src/myapp".
Son now you just have to add to your recipe this line:

S = "${WORKDIR}/git/src/myapp"

It is not optimized from a disk usage point of view (a full copy of the repo 
files is in ${WORKDIR}/git) but it works.

Regards,

Joël Esponde
Honeywell | Safety and Productivity Solutions

De : yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] De 
la part de Eswaran Vinothkumar (BEG/PJ-IOT-EL)
Envoyé : mardi 11 avril 2017 08:25
À : yocto@yoctoproject.org
Objet : [yocto] Sub-directories from Git in SRC-URI

Hallo,

May I now is it possible to include a sub-directory from git repo in the 
SRC_URI of bitbake recipe.

Also in SRC_URI is it possible to include a directory instead of a single file?

I know I could create a tar file of a directory and include it , but I would 
like to know is it possible to include directory as a SRC_URI.


Mit freundlichen Grüßen / Best regards

Vinothkumar Eswaran
BEG-PT/PJ-IOT1

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

[yocto] Modifying CFLAGS in .bbappend

[Mark T]

Hi,

If I add an include path to CFLAGS in a .bbappend  is it only applied for
that recipe or is it present in CFLAGS for all recipes built after that ?

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

[yocto] Getting recipe variables into config.m4 files

[Mark T]

Hi,

I'm building a PHP extension.  In the config.m4 file for the extension I
can add include and library paths as follows -

  PHP_ADD_INCLUDE(../../../../../../../sources/inc)  - works
  PHP_ADD_INCLUDE($PROJ_ROOT/sources/inc)  ** does not work
  PHP_ADD_INCLUDE(${PROJ_ROOT}/sources/inc)  ** does not work
  PHP_ADD_LIBRARY(stdc++, 1, MY_TEST_SHARED_LIBADD)

where $PROJ_ROOT is define in my .bbappend.  for the php recipe.

Its the include path that is not working with the variable - I just get
"-I/sources/inc" in the compile line. The relative path works but I'd like
to be able to tie the path to a variable I have control over.

Any ideas on how to achieve this ?

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

Re: [yocto] Modifying CFLAGS in .bbappend

[Patrick Ohly]

On Tue, 2017-04-11 at 11:45 +0100, Mark T wrote:

> If I add an include path to CFLAGS in a .bbappend  is it only applied
> for that recipe or is it present in CFLAGS for all recipes built after
> that ?

Just for that recipe. You can check that with "bitbake -e ".


-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [yocto] [OE-core] [PATCH 1/2] logrotate: Bump to 3.11.0

[Romain Perier]

ping,


Le 06/04/2017 à 14:20, Romain Perier a écrit :
> Hello,
>
>
> Le 06/04/2017 à 13:38, Richard Purdie a écrit :
>> On Wed, 2017-04-05 at 17:05 +0200, Romain Perier wrote:
>>> This commit updates the recipe to the last upstream tag. Then, as the
>>> tarball no longer contains the pre-generated Makefile, inherit from
>>> autotools
>>>
>>> [...]
>>> -PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl
>>> selinux', d)}"
>>> +PACKAGECONFIG ?= "\
>>> +${@bb.utils.contains('DISTRO_FEATURES', 'acl', 'acl', '', d)} \
>>> +${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux',
>>> '', d)} \
>>> +"
> Correct, I probably did something wrong during rebase.
>
>> I'm not sure the above should be there, it reverts someone else's
>> change?
>>
>> I am a little nervous of taking this at this point in the release
>> too...
> What do you think if we backport the systemd service and the systemd
> timer from upstream into 3.9.1 and then add support for systemd in the
> recipe ? (In the original patches, I have written systemd services
> myself) The code of logrotate would be unchanged.
>
> Regards,
> Romain
What do we do for this ? this is possible or I have to propose this
feature for master-next ? (I mean post 2.3)

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

Re: [yocto] Install rootfs.tar.bz2 to ${D}/home/root/

[Josef Holzmayr]

On 11.04.2017 08:48, Maier, Chris wrote:
> Hi,
>  The usual question 
>
> Chris
>

*sigh*

I've tried to get in touch via non-list email (as for overly aggressive 
mail servers), and even called the company but you didn't pick up the 
phone. So Chris - if you ever read this: I really tried. Obviously 
there's no other choice than bluntly ignoring this topic.


Greetz,
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

[yocto] opkg behavior

[Gary Thomas]

I'm using opkg (IPK) packaging with my Yocto builds (using recent
master 633ad6c9f).  For the most part, this seems to work well,
but occasionally I'll rebuild a recipe along with the packaging
indexes on my build machine only to find that opkg doesn't want
to upgrade to the changes.  Here's an example:

* Update the package databases on the target board
  root@teton-p7621:~# opkg update
  Downloading http://192.168.1.12/teton-p7621-feeds/all/Packages.gz.
  Updated source 'poky_am-all'.
  Downloading http://192.168.1.12/teton-p7621-feeds/cortexa7hf-neon/Packages.gz.
  Updated source 'poky_am-cortexa7hf-neon'.
  Downloading http://192.168.1.12/teton-p7621-feeds/teton_p7621/Packages.gz.
  Updated source 'poky_am-teton_p7621'.

* Try to update the package I just rebuilt.  Normally, this does the right thing
  root@teton-p7621:~# opkg install production-tests
  No packages installed or removed.

* Odd, check the packaging
  root@teton-p7621:~# opkg list-installed | grep prod
  production-tests - 1.0-r0.74

* Force the install by removing the existing package, etc
  root@teton-p7621:~# opkg remove production-tests
  Removing production-tests (1.0) from root...
  root@teton-p7621:~# opkg install production-tests
  Installing production-tests (1.0) on root
  Downloading 
http://192.168.1.12/teton-p7621-feeds/teton_p7621/production-tests_1.0-r0.76_teton_p7621.ipk.
  Configuring production-tests.

So from this you can see that the package has been rebuilt (using
the PR server) and that I can indeed install the new version.  That
said, why did opkg not "upgrade" as expected.  Note: I often use
the 'opkg upgrade' command but I recently updated my Poky/Yocto
repository which caused nearly every package to be rebuilt and I
didn't want to have to download everything (none of which affected
my current program which is just a python script), so I chose the
'opkg install ...' method instead, which does seem to work sometimes.

Any ideas what I can look at or tweak to get this to work the way
I expect?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Remove/prevent a package's installed files if another package present

[Colin Helliwell]

> On 07 April 2017 at 12:57 Alexander Kanavin 
>  wrote:
> 
> On 04/07/2017 02:53 PM, colin.helliw...@ln-systems.com wrote:
> 
> > I'd like to do a mod to my ppp recipe such that ip-up & ip-down aren't
> > installed if another package is in the image recipe i.e. set in
> > CORE_IMAGE_EXTRA_INSTALL.
> > 
> > I guess I could do a do_install_append() or a pkg_postinst_(), but is there
> > a way to detect the other package within the recipe? E.g. along the lines of
> > what PACKAGE_CONF can do for configuration.
> > 
> > Oh, and it needs to work after an update (e.g. rpm/deb) - don't want the
> > files (re)installed by the update. (So I don't believe
> > ROOTFS_POSTPROCESS_COMMAND is an option)
> 
> Maybe you should do this at runtime, and modify ip-up/down themselves
> (or the thing that utilizes them) so that they do the right thing in
> both scenarios.
> 

Worried about complexities of runtime mods (esp. across two other packages). 
What seems may be a 'simple' (if not weakness-less) method is to add my own 
DISTRO_FEATURE, and switch on that in my ppp_.bbappend.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Sub-directories from Git in SRC-URI

[Esponde, Joel]

Following Miguel Aveiro's link, I noticed a parameter called subpath that I had 
never see:
https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#git-fetcher
This parameter may provide you the feature you are looking for.

Joël Esponde
Honeywell | Safety and Productivity Solutions

De : Eswaran Vinothkumar (BEG/PJ-IOT-EL) 
[mailto:vinothkumar.eswa...@de.bosch.com]
Envoyé : mardi 11 avril 2017 10:04
À : Esponde, Joel ; yocto@yoctoproject.org
Objet : AW: Sub-directories from Git in SRC-URI

Hi,

Thanks for your answer. I had thought about using this solution initially. In 
my case I have a common git repo for some 20 different applications and 
planning to write an individual recipe for each application.

If I plan to use in this way, I have 20 copies in my disk which I don't want to 
have.

Mit freundlichen Grüßen / Best regards

Vinothkumar Eswaran
BEG-PT/PJ-IOT1
Von: Esponde, Joel [mailto:joel.espo...@honeywell.com]
Gesendet: Dienstag, 11. April 2017 09:58
An: Eswaran Vinothkumar (BEG/PJ-IOT-EL) 
mailto:vinothkumar.eswa...@de.bosch.com>>; 
yocto@yoctoproject.org
Betreff: RE: Sub-directories from Git in SRC-URI

Hi,

Here is one way to manage this use case.
In the SRC_URI variable, you set the git repo access.
Now let's say that your sub-directory relative path is "src/myapp".
Son now you just have to add to your recipe this line:

S = "${WORKDIR}/git/src/myapp"

It is not optimized from a disk usage point of view (a full copy of the repo 
files is in ${WORKDIR}/git) but it works.

Regards,

Joël Esponde
Honeywell | Safety and Productivity Solutions

De : yocto-boun...@yoctoproject.org 
[mailto:yocto-boun...@yoctoproject.org] De la part de Eswaran Vinothkumar 
(BEG/PJ-IOT-EL)
Envoyé : mardi 11 avril 2017 08:25
À : yocto@yoctoproject.org
Objet : [yocto] Sub-directories from Git in SRC-URI

Hallo,

May I now is it possible to include a sub-directory from git repo in the 
SRC_URI of bitbake recipe.

Also in SRC_URI is it possible to include a directory instead of a single file?

I know I could create a tar file of a directory and include it , but I would 
like to know is it possible to include directory as a SRC_URI.


Mit freundlichen Grüßen / Best regards

Vinothkumar Eswaran
BEG-PT/PJ-IOT1

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

[yocto] Fw: yocto Digest, Vol 79, Issue 23

[Natalia Theologou]

From: Natalia Theologou 
Sent: Tuesday, April 11, 2017 9:38 AM
To: Paul Eggleton
Subject: Re: [yocto] yocto Digest, Vol 79, Issue 23


Hello Paul,

Thank you for your answer.


My error is this:


ERROR: Task 1570
(virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 106
tasks of which 102 didn't need to be rerun and 2 failed. Waiting for 0
 running tasks to finish:


After this, I get also this message:


Summary: 2 tasks failed:
virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb,
do_compile
virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
do_compile


My whole message was this:


Well I am running Ubuntu 16 and trying to install yocto for a board.

When I run


bitbake core-image-x11

I get this error:



ERROR: Task 1570 
(virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb, 
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 106 tasks of which 102 didn't need to be rerun 
and 2 failed.
Waiting for 0 running tasks to finish:

Summary: 2 tasks failed:
  virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb, 
do_compile
  virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb, 
do_compile


gmp_5.1.1.bb has this code inside:


require gmp.inc
LICENSE="LGPLv3&GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"

SRC_URI_append = " file://use-includedir.patch \
   file://append_user_provided_flags.patch \
   "

SRC_URI[md5sum] = "2fa018a7cd193c78494525f236d02dd6"
SRC_URI[sha256sum] = 
"a0d4779f48b36519dfaceb5f987a7c76fcac223258bebea3bb2244310970afad"


and when I run the  bitbake fsl-image-x11 I also have an error in ncurses.bb 
which has this code inside:


require ncurses.inc

PR = "${INC_PR}.1"

SRC_URI += "file://tic-hang.patch \
file://config.cache \
"

SRC_URI[md5sum] = "8cb9c412e5f2d96bc6f459aa8c6282a1"
SRC_URI[sha256sum] = 
"9046298fb440324c9d4135ecea7879ffed8546dd1b58e59430ea07a4633f563b"

Best regards and thanks,
Theologou Natalia






From: Paul Eggleton 
Sent: Tuesday, April 11, 2017 4:59 AM
To: Natalia Theologou
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] yocto Digest, Vol 79, Issue 23

Hi Natalia,

On Tuesday, 11 April 2017 2:11:15 AM NZST Natalia Theologou wrote:
> Well I am running Ubuntu 16 and trying to install yocto for a board.
>
> When I run
>
> bitbake core-image-x11
>
> I get this error:
>
> ERROR: Task 1570
> (virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
> do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 106
> tasks of which 102 didn't need to be rerun and 2 failed. Waiting for 0
> running tasks to finish:
>
> Summary: 2 tasks failed:
>   virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb,
> do_compile
> virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
> do_compile

This doesn't look like the complete message - it should be preceded by the
specific error that occurred, can you please paste that in?

Thanks,
Paul

--

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

Re: [yocto] Porting a middleware to Yocto

[Khem Raj]

On Mon, Apr 10, 2017 at 11:20 PM, Eswaran Vinothkumar (BEG/PJ-IOT-EL)
 wrote:
> Hallo,
>
>
>
> For our new project we are planning to use Yocto as a build system to build
> customized Linux distribution. I have already created a BSP for our
> customized hardware with Linux kernel, U-boot and UBIFS rootfs image.
>
>
>
> We are internally using a middleware which acts as an abstraction to
> underlying operating system and provides APIs to application layers. Now the
> task is to port the middleware to Yocto. The middleware contains lot of make
> files and folders which are interdependent and I am at lost on how to start.
>
> I have some 20 directories which contains makefiles and autotool
> configure.ac files to generate lib files.
>
>
>
> As of now I have planned to create a new Yocto layer called meta-middleware
> and a recipe file for individual folders. I then create a package group
> which will include all these recipes and can include this package group as
> dependency in the recipes of meta-application layer. I am facing a problem
> like I have to include headers from other recipes. In this case to include
> the headers , is it enough to add “DEPENDS = recipename” ?
>
> I know my question is relatively vague, but anybody who ported middleware
> from another build systems like ptxdist would have faced similar issues. Any
> input on how you planned to port these source files to Yocto would be
> helpful.
>

This is a common usecase I have faced multiple times, where people are
coming from monolithic build systems. So
task 1:
segregate this monolith into components which have their own life or
you can treat the whole monolith as one component. Choice is yours.

task 2: if you want to componentize it then choose a component build
system e.g. autoconf, cmake or if nothing just plain make and convert
your components to be able to ask for external dependencies for other
components without needing to cross reference them. E.g. let it expect
a given lib or header is coming from standard sysroot

Task3: Let a component be able to generate .so or binaries using its
own component build system. It should also be able to stage the
headers and libs for APIs its exposing for other components to
interact with it.

Task4: Write recipes and express the dependencies as you might have
then well known by now.

Task5: Write logical package groups

Task6: Expose the middleware via SDKs for application developers.

>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
> Vinothkumar Eswaran
> BEG-PT/PJ-IOT1
>
>
> --
> ___
> 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] Sub-directories from Git in SRC-URI

[Khem Raj]

On Mon, Apr 10, 2017 at 11:24 PM, Eswaran Vinothkumar (BEG/PJ-IOT-EL)
 wrote:
> Hallo,
>
>
>
> May I now is it possible to include a sub-directory from git repo in the
> SRC_URI of bitbake recipe.
>
>
>
> Also in SRC_URI is it possible to include a directory instead of a single
> file?
>
>
>
> I know I could create a tar file of a directory and include it , but I would
> like to know is it possible to include directory as a SRC_URI.
>

if you have a setup where you checkout this component yourself e.g.
using android repo or gitsm to manage your yocto setup then you can
simply point your recipes to use file:// fetcher or even resort to
externalsrc to build in recipes where you point S to this common
directory for multiple recipes. I for one however like to defer the
fetching to bitbake in that case it will really fetch your component
once but will make copies locally for each component it builds. It may
not be as bad now a days with shared state and if the components are
not built so often its only a occasional thing.

>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
> Vinothkumar Eswaran
> BEG-PT/PJ-IOT1
>
>
>
> --
> ___
> 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] opkg behavior

[Alejandro del Castillo]

On 04/11/2017 08:03 AM, Gary Thomas wrote:
> I'm using opkg (IPK) packaging with my Yocto builds (using recent
> master 633ad6c9f).  For the most part, this seems to work well,
> but occasionally I'll rebuild a recipe along with the packaging
> indexes on my build machine only to find that opkg doesn't want
> to upgrade to the changes.  Here's an example:
> 
> * Update the package databases on the target board
>   root@teton-p7621:~# opkg update
>   Downloading http://192.168.1.12/teton-p7621-feeds/all/Packages.gz.
>   Updated source 'poky_am-all'.
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/cortexa7hf-neon/Packages.gz.
>   Updated source 'poky_am-cortexa7hf-neon'.
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/teton_p7621/Packages.gz.
>   Updated source 'poky_am-teton_p7621'.
> 
> * Try to update the package I just rebuilt.  Normally, this does the
> right thing
>   root@teton-p7621:~# opkg install production-tests
>   No packages installed or removed.
> 
> * Odd, check the packaging
>   root@teton-p7621:~# opkg list-installed | grep prod
>   production-tests - 1.0-r0.74
> 
> * Force the install by removing the existing package, etc
>   root@teton-p7621:~# opkg remove production-tests
>   Removing production-tests (1.0) from root...
>   root@teton-p7621:~# opkg install production-tests
>   Installing production-tests (1.0) on root
>   Downloading
> http://192.168.1.12/teton-p7621-feeds/teton_p7621/production-tests_1.0-r0.76_teton_p7621.ipk.
> 
>   Configuring production-tests.
> 
> So from this you can see that the package has been rebuilt (using
> the PR server) and that I can indeed install the new version.  That
> said, why did opkg not "upgrade" as expected.  Note: I often use
> the 'opkg upgrade' command but I recently updated my Poky/Yocto
> repository which caused nearly every package to be rebuilt and I
> didn't want to have to download everything (none of which affected
> my current program which is just a python script), so I chose the
> 'opkg install ...' method instead, which does seem to work sometimes.
> 
> Any ideas what I can look at or tweak to get this to work the way
> I expect?

Opkg uses libsolv as it's solver backend. When you say 'opkg install
production-tests', the solver doesn't do anything since package
'production-tests' is already installed.

What you want is a targeted upgrade, which can be done by calling 'opkg
upgrade production-tests'. Another option is to do a by version install,
which can be done by calling 'opkg install production-tests=1.0-r0.76'


-- 
Cheers,

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

[yocto] Relicensing an Apache-licensed recipe as MIT

[Martin Kelly]

Hi,

I'm thinking about integrating the open-vm-tools recipe from 
openswitch[1] into openembedded (it massively improves the performance 
of VMWare guests) but first I have a question about licensing. The 
openswitch repository is Apache-licensed while the openembedded layers 
are all MIT licensed. I'm not a lawyer, but my understanding is that the 
Apache license is a superset of the MIT license (it includes a patent 
clause that the MIT license lacks), and therefore MIT code can be 
relicensed as Apache but not the other way around. If that's the case, 
then there's two options here:


(1) - Include this recipe in openembedded with an Apache license, while 
the rest of the recipes are MIT-licensed. This sounds complicated, 
messy, and probably not feasible.


(2) - Ask openswitch for permission to relicense that one recipe as MIT 
with attributions.


I'm wondering if someone with a better understanding than I have could 
provide me me advice about the best way to proceed.


Thanks,
Martin

[1]: 
https://github.com/open-switch/ops-build/tree/master/yocto/openswitch/meta-foss-openswitch/recipes-extended/open-vm-tools

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

[yocto] Fw: yocto Digest, Vol 79, Issue 23

[Natalia Theologou]

From: Natalia Theologou 
Sent: Tuesday, April 11, 2017 9:39 AM
To: paul.eggle...@linux.intel.com
Cc: yocto@yoctoproject.org
Subject: Fw: [yocto] yocto Digest, Vol 79, Issue 23





From: Natalia Theologou 
Sent: Tuesday, April 11, 2017 9:38 AM
To: Paul Eggleton
Subject: Re: [yocto] yocto Digest, Vol 79, Issue 23


Hello Paul,

Thank you for your answer.


My error is this:


 ERROR: oe_runmake failed
| WARNING: 
/~/build_directory/tmp/work/x86_64-linux/gmp-native/5.1.1-r0/temp/run.do_compile.16521:1
 exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at 
/~/build_directory/tmp/work/x86_64-linux/gmp-native/5.1.1-r0/temp/log.do_compile.16521)

ERROR: Task 1570
(virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 106
tasks of which 102 didn't need to be rerun and 2 failed. Waiting for 0
 running tasks to finish:


After this, I get also this message:


Summary: 2 tasks failed:
virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb,
do_compile
virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
do_compile


My whole message was this:


Well I am running Ubuntu 16 and trying to install yocto for a board.

When I run


bitbake core-image-x11

I get this error:

 ERROR: oe_runmake failed
| WARNING: 
/~/build_directory/tmp/work/x86_64-linux/gmp-native/5.1.1-r0/temp/run.do_compile.16521:1
 exit 1 from
|   exit 1
| ERROR: Function failed: do_compile (log file is located at 
/~/build_directory/tmp/work/x86_64-linux/gmp-native/5.1.1-r0/temp/log.do_compile.16521)


ERROR: Task 1570 
(virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb, 
do_compile) failed with exit code '1'
NOTE: Tasks Summary: Attempted 106 tasks of which 102 didn't need to be rerun 
and 2 failed.
Waiting for 0 running tasks to finish:

Summary: 2 tasks failed:
  virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb, 
do_compile
  virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb, 
do_compile


gmp_5.1.1.bb has this code inside:


require gmp.inc
LICENSE="LGPLv3&GPLv3"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
file://version.c;endline=18;md5=d8c56b52b9092346b9f93b4da65ef790"

SRC_URI_append = " file://use-includedir.patch \
   file://append_user_provided_flags.patch \
   "

SRC_URI[md5sum] = "2fa018a7cd193c78494525f236d02dd6"
SRC_URI[sha256sum] = 
"a0d4779f48b36519dfaceb5f987a7c76fcac223258bebea3bb2244310970afad"


and when I run the  bitbake fsl-image-x11 I also have an error in ncurses.bb 
which has this code inside:


require ncurses.inc

PR = "${INC_PR}.1"

SRC_URI += "file://tic-hang.patch \
file://config.cache \
"

SRC_URI[md5sum] = "8cb9c412e5f2d96bc6f459aa8c6282a1"
SRC_URI[sha256sum] = 
"9046298fb440324c9d4135ecea7879ffed8546dd1b58e59430ea07a4633f563b"

Best regards and thanks,
Theologou Natalia






From: Paul Eggleton 
Sent: Tuesday, April 11, 2017 4:59 AM
To: Natalia Theologou
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] yocto Digest, Vol 79, Issue 23

Hi Natalia,

On Tuesday, 11 April 2017 2:11:15 AM NZST Natalia Theologou wrote:
> Well I am running Ubuntu 16 and trying to install yocto for a board.
>
> When I run
>
> bitbake core-image-x11
>
> I get this error:
>
> ERROR: Task 1570
> (virtual:native:/~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
> do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 106
> tasks of which 102 didn't need to be rerun and 2 failed. Waiting for 0
> running tasks to finish:
>
> Summary: 2 tasks failed:
>   virtual:native:/~/sources/poky/meta/recipes-core/ncurses/ncurses_5.9.bb,
> do_compile
> virtual:native:~/sources/poky/meta/recipes-support/gmp/gmp_5.1.1.bb,
> do_compile

This doesn't look like the complete message - it should be preceded by the
specific error that occurred, can you please paste that in?

Thanks,
Paul

--

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

Re: [yocto] [meta-security][PATCH] swtpm: update to latest tip

[akuster808]

On 04/11/2017 12:08 AM, Amarnath Valluri wrote:

Pull in changes to support passing client control sockets(--ctrl
type=unixio,clientfd=), that allows to fork swtpm and communicate using
socketpair.

Signed-off-by: Amarnath Valluri 


merge to master-next

thanks


---
  recipes-tpm/swtpm/swtpm_1.0.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-tpm/swtpm/swtpm_1.0.bb b/recipes-tpm/swtpm/swtpm_1.0.bb
index 99c6fdc..14f668b 100644
--- a/recipes-tpm/swtpm/swtpm_1.0.bb
+++ b/recipes-tpm/swtpm/swtpm_1.0.bb
@@ -10,7 +10,7 @@ DEPENDS = "libtasn1 fuse expect socat glib-2.0 libtpm 
libtpm-native"
  DEPENDS += "tpm-tools-native expect-native socat-native"
  RDEPENDS_${PN} += "tpm-tools"
  
-SRCREV = "d7bbe3de5cc58c1dca41149df89cfdc08019a722"

+SRCREV = "073e71f99eaa7a0ff9499339176af1af62c090b2"
  SRC_URI = " \
git://github.com/stefanberger/swtpm.git \
file://fix_signed_issue.patch \


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

[yocto] [meta-security][PATCH 1/2] samhain: update to 4.2.1

[Armin Kuster]

remove patch integrated into update

Signed-off-by: Armin Kuster 
---
 recipes-security/samhain/files/c99_dnmalloc.patch  | 18 --
 ...samhain-client_4.2.0.bb => samhain-client_4.2.1.bb} |  0
 ...samhain-server_4.2.0.bb => samhain-server_4.2.1.bb} |  0
 recipes-security/samhain/samhain.inc   |  5 ++---
 4 files changed, 2 insertions(+), 21 deletions(-)
 delete mode 100644 recipes-security/samhain/files/c99_dnmalloc.patch
 rename recipes-security/samhain/{samhain-client_4.2.0.bb => 
samhain-client_4.2.1.bb} (100%)
 rename recipes-security/samhain/{samhain-server_4.2.0.bb => 
samhain-server_4.2.1.bb} (100%)

diff --git a/recipes-security/samhain/files/c99_dnmalloc.patch 
b/recipes-security/samhain/files/c99_dnmalloc.patch
deleted file mode 100644
index 2216564..000
--- a/recipes-security/samhain/files/c99_dnmalloc.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-samhain: musl build fix c99
-
-Upstream-Status: Submitted
-Signed-off-by: Armin Kuster 
-
-Index: samhain-4.2.0/src/dnmalloc.c
-===
 samhain-4.2.0.orig/src/dnmalloc.c
-+++ samhain-4.2.0/src/dnmalloc.c
-@@ -5524,7 +5524,7 @@ arc4_stir(void)
- struct {
- struct timeval tv1;
- struct timeval tv2;
--u_int rnd[(128 - 2*sizeof(struct timeval)) / sizeof(u_int)];
-+unsigned char rnd[(128 - 2*sizeof(struct timeval)) / 
sizeof(unsigned char)];
- } rdat;
- #if !defined(__FreeBSD__) && !defined(__OpenBSD__) && !defined(__NetBSD__)
- ssize_t sz = 0;
diff --git a/recipes-security/samhain/samhain-client_4.2.0.bb 
b/recipes-security/samhain/samhain-client_4.2.1.bb
similarity index 100%
rename from recipes-security/samhain/samhain-client_4.2.0.bb
rename to recipes-security/samhain/samhain-client_4.2.1.bb
diff --git a/recipes-security/samhain/samhain-server_4.2.0.bb 
b/recipes-security/samhain/samhain-server_4.2.1.bb
similarity index 100%
rename from recipes-security/samhain/samhain-server_4.2.0.bb
rename to recipes-security/samhain/samhain-server_4.2.1.bb
diff --git a/recipes-security/samhain/samhain.inc 
b/recipes-security/samhain/samhain.inc
index d558e6b..007264d 100644
--- a/recipes-security/samhain/samhain.inc
+++ b/recipes-security/samhain/samhain.inc
@@ -7,11 +7,10 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=8ca43cbc842c2336e835926c2166c28b"
 SRC_URI = "http://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
   file://${INITSCRIPT_NAME}.init \
   file://${INITSCRIPT_NAME}.default \
-   file://c99_dnmalloc.patch \
  "
 
-SRC_URI[md5sum] = "d98a55646b14f9419fcedde909d1bf02"
-SRC_URI[sha256sum] = 
"6b2db91fc92b3a9fc2edcc6ee16438156753c05f69c114856289e9f25ba0e50a"
+SRC_URI[md5sum] = "6de1060d6e79c4893d8d89d5cbd3c1b0"
+SRC_URI[sha256sum] = 
"93beabb19ac68fb5336a3d8f6b5414de05a460ff6982c41a4e3fb2082e769791"
 
 S = "${WORKDIR}/samhain-${PV}"
 
-- 
2.7.4

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

[yocto] [meta-security][PATCH 2/2] tpm2.0-tss: update to tip.

[Armin Kuster]

remove merged patch now in tip

Signed-off-by: Armin Kuster 
---
 .../tpm2.0-tss/tpm2.0-tss/musl_header_fix.patch| 27 --
 recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb   |  3 +--
 2 files changed, 1 insertion(+), 29 deletions(-)
 delete mode 100644 recipes-tpm/tpm2.0-tss/tpm2.0-tss/musl_header_fix.patch

diff --git a/recipes-tpm/tpm2.0-tss/tpm2.0-tss/musl_header_fix.patch 
b/recipes-tpm/tpm2.0-tss/tpm2.0-tss/musl_header_fix.patch
deleted file mode 100644
index b1e0aaa..000
--- a/recipes-tpm/tpm2.0-tss/tpm2.0-tss/musl_header_fix.patch
+++ /dev/null
@@ -1,27 +0,0 @@
-Add missing header to avoid:
-
-../TPM2.0-TSS/tcti/tcti_socket.c: In function 'SocketReceiveTpmResponse':
-| ../TPM2.0-TSS/tcti/tcti_socket.c:286:5: error: unknown type name 'fd_set'
-|  fd_set readFds;
-|  ^~
-| ../TPM2.0-TSS/tcti/tcti_socket.c:287:20: error: storage size of 'tv' isn't 
known
-|  struct timeval tv, *tvPtr;
-| ^~
-
-Upstream-Status: Submitted
-tcti_socket: fix musl build issue do to missing header #393 
-
-Signed-off-by: Armin Kuster 
-
-Index: TPM2.0-TSS/tcti/tcti_socket.c
-===
 TPM2.0-TSS.orig/tcti/tcti_socket.c
-+++ TPM2.0-TSS/tcti/tcti_socket.c
-@@ -27,6 +27,7 @@
- 
- #include 
- #include// Needed for _wtoi
-+#include 
- 
- #include "sapi/tpm20.h"
- #include "sapi/marshal.h"
diff --git a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb 
b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
index 6f9ce67..14ec0ab 100644
--- a/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
+++ b/recipes-tpm/tpm2.0-tss/tpm2.0-tss_git.bb
@@ -6,12 +6,11 @@ SECTION = "tpm"
 
 DEPENDS = "autoconf-archive pkgconfig"
 
-SRCREV = "d1bd1fe175d233c7c5adbe1b9f3d256c41721001"
+SRCREV = "30794affab01598bbacfe1f167be7c068a0c0476"
 
 SRC_URI = " \
 
git://github.com/01org/TPM2.0-TSS.git;protocol=git;branch=master;name=TPM2.0-TSS;destsuffix=TPM2.0-TSS
 \
 file://ax_pthread.m4 \
-file://musl_header_fix.patch \
 "
 
 inherit autotools pkgconfig systemd
-- 
2.7.4

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

[yocto] Bug 11307 - sstate.bbclass tries to modify mirror files

[Paulo Neves]

Commit 51edde653707e7a3cd2186082458f01f32cd1996 makes a wrong
assumption that SSTATE_MIRRORS have write permissions.

A mirror is by definition outside of it's user control. In my use case
it happens I does not have permissions to update the access time of
the dereferenced symbolic-link file.

If we had the possibility to modify the sstate-mirror we would have
set SSTATE_DIR instead. There are 3 possible fixes:

* Revert this patch. It seems tailored to a very special use case
which breaks the definition of mirror.
* Only touch the file if the file access time is writeable.
* Set (yet) another option to touch SSTATE_MIRROR files.

I also can imagine this raising sever performance issues if the mirror
is used by several users at the same time. The server will need to
update the file meta data every time

This patch fixes the bug with minimal impact on the original
functionality. Option 2


Related to (https://bugzilla.yoctoproject.org/show_bug.cgi?id=10857)

>From aa8cab9660744c8d5277f8e82f10a844884aff78 Mon Sep 17 00:00:00 2001
From: Paulo Neves 
Date: Tue, 11 Apr 2017 10:57:47 +0300
Subject: [PATCH] Added test for write ability of sstate-mirror .siginfo

---
 meta/classes/sstate.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 
af588548c2ef85d966787df7ae1432e1744bdba6..36cbbd151aa1c93f4ca377b3a23c011a527389d8
100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -753,7 +753,7 @@ python sstate_sign_package () {
 sstate_unpack_package () {
  tar -xvzf ${SSTATE_PKG}
  # update .siginfo atime on local/NFS mirror
- [ -h ${SSTATE_PKG}.siginfo ] && touch -a ${SSTATE_PKG}.siginfo
+ [ -w ${SSTATE_PKG}.siginfo ] && [ -h ${SSTATE_PKG}.siginfo ] &&
touch -a ${SSTATE_PKG}.siginfo
  # Use "! -w ||" to return true for read only files
  [ ! -w ${SSTATE_PKG} ] || touch --no-dereference ${SSTATE_PKG}
  [ ! -w ${SSTATE_PKG}.sig ] || [ ! -e ${SSTATE_PKG}.sig ] || touch
--no-dereference ${SSTATE_PKG}.sig
-- 
2.6.2



Best regards
Paulo Neves
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] multiconfig samples not put in the build dir.

[Paulo Neves]

Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:

>From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001
From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 
ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)
+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat 

Re: [yocto] multiconfig samples not put in the build dir.

[Gary Thomas]

On 2017-04-12 08:48, Paulo Neves wrote:

Hello,

I thought it would be consistent to have the multiconfig samples to
also be populated just like the local.conf.

I produced a patch accordingly:


From 6091978f666463c46093203b74f28b82a9bf4d47 Mon Sep 17 00:00:00 2001

From: Paulo Neves 
Date: Mon, 3 Apr 2017 11:23:12 +0200
Subject: [PATCH 1/2] multiconfig samples are now put in the build dir.

The users of multiconfig which use the templateconf
mechanism may also want the multiconfig samples to
be retrieved from the template configuration
directories. This patch allows for that.

It only copies the .conf.sample files. It does not
create the multiconfig directory if the templateconf
directory does not exist or have any sample files.
---
 scripts/oe-setup-builddir | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 
ef495517aaafd8150313ac1f8f5eb5079c90d09b..783ed20dd49d23fe38fa28d6a105918200a54610
100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -77,11 +77,11 @@ if [ -n "$TEMPLATECONF" ]; then
 OECORELOCALCONF="$TEMPLATECONF/local.conf.sample"
 OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt"
 fi
-
 unset SHOWYPDOC
 if [ -z "$OECORELOCALCONF" ]; then
 OECORELOCALCONF="$OEROOT/meta/conf/local.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/local.conf" ]; then
 cat <&1 >  /dev/null ); then
+   mkdir -p "$BUILDDIR/conf/multiconfig/"
+cp -fa "$TEMPLATECONF/multiconfig" "$BUILDDIR/conf/"
+(cd "$BUILDDIR/conf/multiconfig/" &&
+rename .conf.sample .conf *.conf.sample)


This doesn't look right to me - what are you expecting the 'rename' command to 
do?


+echo "Multiconfig samples detected copying them also.\n"
+fi
 SHOWYPDOC=yes
 fi

 if [ -z "$OECORELAYERCONF" ]; then
 OECORELAYERCONF="$OEROOT/meta/conf/bblayers.conf.sample"
 fi
+
 if [ ! -r "$BUILDDIR/conf/bblayers.conf" ]; then
 cat <


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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