[yocto] [meta-security][PATCH 2/2] scap-security-guide: update recipe

[Yi Zhao]

* Set B="${S}/build" to fix the build failure for out of source
  directory
* Remove do_complile and do_install. Use the default functions from
  cmake.bbclass.
* Install the artifacts to /usr/share rather than /usr/local/share

Signed-off-by: Yi Zhao 
---
 .../scap-security-guide/scap-security-guide.inc| 28 +-
 .../scap-security-guide/scap-security-guide_git.bb |  6 +
 2 files changed, 7 insertions(+), 27 deletions(-)

diff --git 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
index ed70c18..d123561 100644
--- 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
+++ 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide.inc
@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=97662e4486d9a1d09f358851d9f41a1a"
 LICENSE = "LGPL-2.1"
 
 DEPENDS = "openscap-native python3 python3-pyyaml-native python3-jinja2-native 
libxml2-native"
+RDEPNEDS_${PN} = "openscap"
 
 S = "${WORKDIR}/git"
 
@@ -20,28 +21,11 @@ OECMAKE_GENERATOR = "Unix Makefiles"
 
 EXTRA_OECMAKE += "-DENABLE_PYTHON_COVERAGE=OFF"
 
-do_configure_prepend () {
-   sed -i -e 's:NAMES\ sed:NAMES\ ${HOSTTOOLS_DIR}/sed:g'   
${S}/CMakeLists.txt
-sed -i 
's:/usr/share/openscap/:${STAGING_OSCAP_BUILDDIR}${datadir_native}/openscap/:g' 
${S}/cmake/SSGCommon.cmake
-}
-
-do_compile () {
-   cd ${S}/build
-   cmake ../
-   # oddly rhel7 needs to build first
-   make rhel7
-}
+B = "${S}/build"
 
-do_install () {
-   cd ${S}/build
-   make DESTDIR=${D} install
+do_configure_prepend () {
+sed -i -e 's:NAMES\ sed:NAMES\ ${HOSTTOOLS_DIR}/sed:g' ${S}/CMakeLists.txt
+sed -i -e 's:NAMES\ grep:NAMES\ ${HOSTTOOLS_DIR}/grep:g' 
${S}/CMakeLists.txt
 }
 
-localdatadir = "${prefix}/local/share"
-localmandir = "${localdatadir}/man"
-localdocdir = "${localdatadir}/doc"
-localxmldir = "${localdatadir}/xml"
-
-FILES_${PN} += "${localdatadir} ${localxmldir}"
-FILES_${PN}-doc += "${localmandir} ${localdocdir}"
-RDEPNEDS_${PN} = "openscap"
+FILES_${PN} += "${datadir}/xml"
diff --git 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
index cb21fed..d9238c0 100644
--- 
a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
+++ 
b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
@@ -2,12 +2,8 @@ SUMARRY = "SCAP content for various platforms, OE changes"
 
 SRCREV = "5fdfdcb2e95afbd86ace555beca5d20cbf1043ed"
 SRC_URI = "git://github.com/akuster/scap-security-guide.git;branch=oe-0.1.44;"
-PV = "v0.1.44+git${SRCPV}"
+PV = "0.1.44+git${SRCPV}"
 
 require scap-security-guide.inc
 
-do_compile_append () {
-make openembedded
-}
-
 EXTRA_OECMAKE += "-DSSG_PRODUCT_OPENEMBEDDED=ON"
-- 
2.7.4

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

[yocto] [meta-security][PATCH 1/2] openscap: update recipe

[Yi Zhao]

* Add PACKAGECONFIG for gcrypt, nss3 and selinux
* Use EXTRA_OECMAKE rather than EXTRA_OECONF
* Set CMAKE_SKIP_RPATH and CMAKE_SKIP_INSTALL_RPATH instead of chrpath
* Remove ptest since there are many host contamination issues on target.
  We will add it back when these issues are solved.
* Drop the unused patch
* Add PV

Signed-off-by: Yi Zhao 
---
 .../openscap/files/probe_dir_fixup.patch   | 17 -
 .../recipes-openscap/openscap/files/run-ptest  |  3 -
 .../recipes-openscap/openscap/openscap.inc | 77 --
 .../recipes-openscap/openscap/openscap_1.3.1.bb|  1 -
 .../recipes-openscap/openscap/openscap_git.bb  |  3 +-
 5 files changed, 30 insertions(+), 71 deletions(-)
 delete mode 100644 
meta-security-compliance/recipes-openscap/openscap/files/probe_dir_fixup.patch
 delete mode 100644 
meta-security-compliance/recipes-openscap/openscap/files/run-ptest

diff --git 
a/meta-security-compliance/recipes-openscap/openscap/files/probe_dir_fixup.patch
 
b/meta-security-compliance/recipes-openscap/openscap/files/probe_dir_fixup.patch
deleted file mode 100644
index ecbe602..000
--- 
a/meta-security-compliance/recipes-openscap/openscap/files/probe_dir_fixup.patch
+++ /dev/null
@@ -1,17 +0,0 @@
-Index: git/configure.ac
-===
 git.orig/configure.ac
-+++ git/configure.ac
-@@ -1109,11 +1109,7 @@ AC_ARG_WITH([crypto],
-  [],
-  [crypto=gcrypt])
- 
--if test "x${libexecdir}" = xNONE; then
--  probe_dir="/usr/local/libexec/openscap"
--else
--  EXPAND_DIR(probe_dir,"${libexecdir}/openscap")
--fi
-+probe_dir="/usr/local/libexec/openscap"
- 
- AC_SUBST(probe_dir)
- 
diff --git a/meta-security-compliance/recipes-openscap/openscap/files/run-ptest 
b/meta-security-compliance/recipes-openscap/openscap/files/run-ptest
deleted file mode 100644
index 454a6a3..000
--- a/meta-security-compliance/recipes-openscap/openscap/files/run-ptest
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-cd tests
-make -k check
diff --git a/meta-security-compliance/recipes-openscap/openscap/openscap.inc 
b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
index e5daaf8..f23ea99 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap.inc
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap.inc
@@ -6,71 +6,50 @@ HOME_URL = "https://www.open-scap.org/tools/openscap-base/";
 LIC_FILES_CHKSUM = "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
 LICENSE = "LGPL-2.1"
 
-DEPENDS = "autoconf-archive dbus acl bzip2 pkgconfig gconf procps curl libxml2 
libxslt libcap swig libgcrypt chrpath-replacement-native "
-
-DEPENDS_class-native = "autoconf-archive-native pkgconfig-native swig-native 
curl-native libxml2-native libxslt-native dpkg-native libgcrypt-native 
nss-native"
+DEPENDS = "autoconf-archive dbus acl bzip2 pkgconfig gconf procps curl libxml2 
libxslt libcap swig"
+DEPENDS_class-native = "autoconf-archive-native pkgconfig-native swig-native 
curl-native libxml2-native libxslt-native libcap-native dpkg-native"
 
 S = "${WORKDIR}/git"
 
-inherit cmake pkgconfig python3native perlnative ptest
-
-PACKAGECONFIG ?= "python3 rpm perl"
-PACKAGECONFIG[python3] = "-DENABLE_PYTHON3=True, , python3, python3"
-PACKAGECONFIG[perl] = "-DENABLE_PERL=True,, perl, perl"
-PACKAGECONFIG[rpm] = "-DENABLE_OSCAP_UTIL_AS_RPM=True, ,rpm, rpm"
-
-EXTRA_OECONF += "-DENABLE_PROBES_INDEPENDENT=yes -DENABLE_PROBES_LINUX=yes 
-DWITH_CRYPTO=gcrypt\
-   -DENABLE_PROBES_SOLARIS=yes -DENABLE_PROBES_UNIX=yes  
-DENABLE_TESTS=no \
-   -DENABLE_OSCAP_UTIL_SSH=yes -DENABLE_OSCAP_UTIL=yes 
-DENABLE_SCE=yes \
--DENABLE_OSCAP_UTIL_DOCKER=no \
-"
-
+inherit cmake pkgconfig python3native perlnative
+
+PACKAGECONFIG ?= "python3 rpm perl gcrypt 
${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux', '', d)}"
+PACKAGECONFIG[python3] = "-DENABLE_PYTHON3=ON, ,python3, python3"
+PACKAGECONFIG[perl] = "-DENABLE_PERL=ON, ,perl, perl"
+PACKAGECONFIG[rpm] = "-DENABLE_OSCAP_UTIL_AS_RPM=ON, ,rpm, rpm"
+PACKAGECONFIG[gcrypt] = "-DWITH_CRYPTO=gcrypt, ,libgcrypt"
+PACKAGECONFIG[nss3] = "-DWITH_CRYPTO=nss3, ,nss"
+PACKAGECONFIG[selinux] = ", ,libselinux"
+
+EXTRA_OECMAKE += "-DENABLE_PROBES_LINUX=ON -DENABLE_PROBES_UNIX=ON \
+  -DENABLE_PROBES_SOLARIS=OFF -DENABLE_PROBES_INDEPENDENT=ON \
+  -DENABLE_OSCAP_UTIL=ON -DENABLE_OSCAP_UTIL_SSH=ON \
+  -DENABLE_OSCAP_UTIL_DOCKER=OFF 
-DENABLE_OSCAP_UTIL_CHROOT=OFF \
+  -DENABLE_OSCAP_UTIL_PODMAN=OFF -DENABLE_OSCAP_UTIL_VM=OFF \
+  -DENABLE_PROBES_WINDOWS=OFF -DENABLE_VALGRIND=OFF \
+  -DENABLE_SCE=ON -DENABLE_MITRE=OFF -DENABLE_TESTS=OFF \
+  -DCMAKE_SKIP_INSTALL_RPATH=ON -DCMAKE_SKIP_RPATH=ON \
+ "
 
 STAGING_OSCAP_DIR = "${TMPDIR}/work-shared/${MACHINE}/oscap-source"
 STAGING_OSCAP_BUILDDIR = "${TMPDIR}/work

Re: [yocto] How to fix SSH interfactive promotion for Yocto Linux embedded system

[Burton, Ross]

You're using busybox's scp, which is limited compared to openssh.  If
you want to use openssh's binaries install openssh-clients, otherwise
adapt your options to work with busybox's scp.

Ross

On Thu, 25 Jul 2019 at 02:10, JH  wrote:
>
> Hi,
>
> I am running busybox in imx6 using ssh and scp in shell scripts, but I
> troubled to run the scripts to run ssh and scp, it did not have ssh
> options stopped at following:
>
> scp  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o
> ServerAliveCountMax=3 -o StrictHostKeyChecking=no -o
> UserKnownHostsFile=/dev/null ...
>
> ECDSA key fingerprint is SHA256:rAS+4gVqPJj7yfVDHlhG1g5bQP+VgMczooGifv+H9vk.
> Are you sure you want to continue connecting (yes/no)
>
> cp: can't stat '-o': No such file or directory
> cp: can't stat 'ServerAliveInterval=60': No such file or directory
> cp: can't stat '-o': No such file or directory
> cp: can't stat 'ExitOnForwardFailure=yes': No such file or directory
> cp: can't stat '-o': No such file or directory
> cp: can't stat 'ServerAliveCountMax=3': No such file or directory
> cp: can't stat '-o': No such file or directory
> cp: can't stat 'StrictHostKeyChecking=no': No such file or directory
> cp: can't stat '-o': No such file or directory
> cp: can't stat 'UserKnownHostsFile=/dev/null': No such file or directory
> root@solar:/tmp# ssh-keyscan SaController >> /home/root/.ssh/known_hosts
>
> What will be effective and simple solution in Yocto?
>
> - Replace busybox by bash recipe.
>
> - Install openssh-client to run ssh-keyscan to write the target to
> .ssh/known_hosts
>
> Appreciate your advice for Yocto Linux embedded system.
>
> Thank you.
>
> Kind regards,
>
> - jupiter
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] btrfs: Fix build error while LIBCRC32C is module

[zhe.he]

From: YueHaibing 

If CONFIG_BTRFS_FS is y and CONFIG_LIBCRC32C is m,
building fails:

  fs/btrfs/super.o: In function `btrfs_mount_root':
  super.c:(.text+0xb7f9): undefined reference to `crc32c_impl'
  fs/btrfs/super.o: In function `init_btrfs_fs':
  super.c:(.init.text+0x3465): undefined reference to `crc32c_impl'
  fs/btrfs/extent-tree.o: In function `hash_extent_data_ref':
  extent-tree.c:(.text+0xe60): undefined reference to `crc32c'
  extent-tree.c:(.text+0xe78): undefined reference to `crc32c'
  extent-tree.c:(.text+0xe8b): undefined reference to `crc32c'
  fs/btrfs/dir-item.o: In function `btrfs_insert_xattr_item':
  dir-item.c:(.text+0x291): undefined reference to `crc32c'
  fs/btrfs/dir-item.o: In function `btrfs_insert_dir_item':
  dir-item.c:(.text+0x429): undefined reference to `crc32c'

Select LIBCRC32C to fix it.

Reported-by: Hulk Robot 
Fixes: d5178578bcd4 ("btrfs: directly call into crypto framework for 
checksumming")
Reviewed-by: Johannes Thumshirn 
Signed-off-by: YueHaibing 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 

commit 314c4cd6d9e60b9412dcd1b1783a66532f91ea2d upstream

Signed-off-by: He Zhe 
---
 fs/btrfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 212b4a8..38651fa 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -4,6 +4,7 @@ config BTRFS_FS
tristate "Btrfs filesystem support"
select CRYPTO
select CRYPTO_CRC32C
+   select LIBCRC32C
select ZLIB_INFLATE
select ZLIB_DEFLATE
select LZO_COMPRESS
-- 
2.7.4

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

[yocto] [PATCH V2 3/3] intel-graphics-compiler: skip it if clang is not ready

[Hongxu Jia]

Since intel-graphics-compiler depends on clang, skip it if clang is not ready

Issue: LIN1019-1846
(LOCAL REV: NOT UPSTREAM) -- Sent to Yocto on 20190724

Signed-off-by: Hongxu Jia 
---
 recipes-opencl/igc/intel-graphics-compiler_1.0.6.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/recipes-opencl/igc/intel-graphics-compiler_1.0.6.bb 
b/recipes-opencl/igc/intel-graphics-compiler_1.0.6.bb
index f64b97f..2c33b12 100644
--- a/recipes-opencl/igc/intel-graphics-compiler_1.0.6.bb
+++ b/recipes-opencl/igc/intel-graphics-compiler_1.0.6.bb
@@ -25,3 +25,11 @@ DEPENDS_class-target = " flex-native bison-native clang 
clang-cross-x86_64"
 
 EXTRA_OECMAKE = "-DIGC_PREFERRED_LLVM_VERSION=8.0.0 
-DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python2"
 EXTRA_OECMAKE += "-DCOMMON_CLANG_LIBRARY_NAME=common_clang"
+
+python __anonymous() {
+toolchain = d.getVar('TOOLCHAIN')
+if toolchain != "clang" or 'clang-layer' not in 
d.getVar('BBFILE_COLLECTIONS').split():
+msg = "Add 'TOOLCHAIN = \"clang\"' in local.conf\n"
+msg += "And meta-clang should be present"
+raise bb.parse.SkipRecipe(msg)
+}
-- 
2.7.4

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

Re: [yocto] How to fix SSH interfactive promotion for Yocto Linux embedded system

[JH]

Thanks Zoran and Burton.

- jupiter

On 7/25/19, Zoran Stojsavljevic  wrote:
> And, YES, since BysuBox supplies very reduced set of commands...
>
> You should put these options
>> -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o
>> ServerAliveCountMax=3 -o StrictHostKeyChecking=no -o
>> UserKnownHostsFile=/dev/null ...
>
> in the following file:/etc/ssh/ssh_config
>
> Hope this helps.
>
> Zoran
> ___
>
> On Thu, Jul 25, 2019 at 5:00 AM Zoran Stojsavljevic
>  wrote:
>>
>> > scp  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o
>> > ServerAliveCountMax=3 -o StrictHostKeyChecking=no -o
>> > UserKnownHostsFile=/dev/null ...
>>
>> Format of your command is wrong... scp assumes your options as files
>> to be transferred.
>>
>> You need to compile better command, something like:
>> scp  user_name@host_IP_address:/directory path>
>> https://www.youtube.com/watch?v=fmMg6cyww14
>>
>> Zoran
>> ___
>>
>> On Thu, Jul 25, 2019 at 3:10 AM JH  wrote:
>> >
>> > Hi,
>> >
>> > I am running busybox in imx6 using ssh and scp in shell scripts, but I
>> > troubled to run the scripts to run ssh and scp, it did not have ssh
>> > options stopped at following:
>> >
>> > scp  -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o
>> > ServerAliveCountMax=3 -o StrictHostKeyChecking=no -o
>> > UserKnownHostsFile=/dev/null ...
>> >
>> > ECDSA key fingerprint is
>> > SHA256:rAS+4gVqPJj7yfVDHlhG1g5bQP+VgMczooGifv+H9vk.
>> > Are you sure you want to continue connecting (yes/no)
>> >
>> > cp: can't stat '-o': No such file or directory
>> > cp: can't stat 'ServerAliveInterval=60': No such file or directory
>> > cp: can't stat '-o': No such file or directory
>> > cp: can't stat 'ExitOnForwardFailure=yes': No such file or directory
>> > cp: can't stat '-o': No such file or directory
>> > cp: can't stat 'ServerAliveCountMax=3': No such file or directory
>> > cp: can't stat '-o': No such file or directory
>> > cp: can't stat 'StrictHostKeyChecking=no': No such file or directory
>> > cp: can't stat '-o': No such file or directory
>> > cp: can't stat 'UserKnownHostsFile=/dev/null': No such file or
>> > directory
>> > root@solar:/tmp# ssh-keyscan SaController >>
>> > /home/root/.ssh/known_hosts
>> >
>> > What will be effective and simple solution in Yocto?
>> >
>> > - Replace busybox by bash recipe.
>> >
>> > - Install openssh-client to run ssh-keyscan to write the target to
>> > .ssh/known_hosts
>> >
>> > Appreciate your advice for Yocto Linux embedded system.
>> >
>> > Thank you.
>> >
>> > Kind regards,
>> >
>> > - jupiter
>> > --
>> > ___
>> > 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] how to stop applying patches in yocto project

[Tg, Harish]

Hi,
 I have requirement that I shall not apply patches to the yocto project 
and then build u-boot, kernel and the images. Can u please help me? Basically I 
need to revert back to PSDKLA-3.02 Release and without patches. Please guide me.


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

[yocto] nostamp is not working as expected

[Aravindhlal G . S . S]

Hi Yocto Experts,

I wanted to run do_compile task every time and should not fetch from the sstate 
cache for the incremental builds. In the correspond recipe, I had set 
do_compile[nostamp] = "1"  and still it does not run every time. It is re-run 
only after clean sstate.

Am I missing something ? can you please help ?

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

Re: [yocto] PREMIRROR

[Russell Peterson]

I think I have a somewhat better understanding of what is going on.

First off, I was confused by the fact that the original error message I saw
from do_unpack referenced the file (URL) at
DL_DIR/git2/original_github_url.  What I didn't understand at the time was
that while that file existed,* it was actually a link* to
DL_DIR/git2/local_url.  So, do_unpack wasn't looking at the wrong bare
repository as I thought.  It was unhappy because it didn't see the git
commit in the local repo that it was looking for.  I use AUTOREV for
SRCREV.  Apparently, even with PREMIRROR set and matched, bitbake will
still fetch the git HEAD commit hash from the original URL in the recipe.
The local git repo doesn't contain that commit.  When I sync the local git
repo to the github repo things work as expected.

Here is my problem.  What I am ultimately trying to do here is have 2 git
repos.  1 public, 1 private.  For internal development we use the private
git repo (a local gerrit server).  Just before we ship we update the public
github repo.  The recipe always points to the github (public) repo so we
don't need to mess with that before a release.  This way we can do nightly
builds (I'm just talking nightly builds done by Jenkins... not developers
using eSDK and devtool) and test.  Customers using yocto will be given a
recipe that points to github and, importantly, those customers that do NOT
use yocto simply fetch the project from github and manually build it in
their own environment with their own tools.

I can't be the only one doing this.  Is there a best practices here
(private vs. public repo)?

--Russ


On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif 
wrote:

> Russell,
>
> That is exactly what devtool and the externalsrc class do. PREMIRROR is
> the wrong approach for that.
>
> :rjs
> On 7/24/19 12:53 PM, Russell Peterson wrote:
>
> Hi, Rudolf.
>
> I apologize for not being clear.  The idea here is that my recipe points
> to github while, for my local development environment, I set a premirror to
> match a specific github repository and translate it to a local directory.
> That works.  The fetch matches the PREMIRROR and places a copy of the LOCAL
> git repo in my DL_DIR.  The problem is, the do_unpack task is looking for
> the git repo in the DL_DIR (git2/etc...)... but it's looking for the git
> repo from github, not my local repo that the fetch task just put in DL_DIR.
>
> There are numerous reasons I'm doing this including the fact that I cannot
> put a reference to my local repo in the bb file since I ship that recipe to
> my customers and a local pathname is meaningless to them.  I prefer to
> simply modify my local.conf with a PREMIRROR value that has a specific
> regular expression that matches this particular github repo (and hence does
> NOT effect all recipes).  This is why I wanted to use the PREMIRROR
> function.  Unfortunately, it does not appear to work or at least not work
> as I expected.
>
> --Russ
>
>
>
>
> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif 
> wrote:
>
>> Hi Russell,
>>
>> devtool and eSDK are different things. The purpose of PREMIRRORS is to
>> set a mirror for all recipes. It's a way for organizations to control where
>> their YP builds download sources from. It's not intended to be used for a
>> single recipe. There is no need for that. You simply set SRC_URI in your
>> recipe to your local git repo. That is what devtool does after downloading
>> the sources from a remote repo. If you already have the remote repo cloned
>> locally you can just point devtool to it.
>>
>> You can do it manually by creating your recipe and setting SRC_URI like
>> this:
>>
>> SRC_URI = "git:///local/path/${PN};protocol=file"
>>
>> SRCREV = "${AUTOREV}"
>>
>> S = "${WORKDIR}/git"
>>
>> PREMIRRORS is only relevant for do_fetch not for do_unpack.
>>
>> :rjs
>>
>>
>> On 7/24/19 11:28 AM, Russell Peterson wrote:
>>
>> Hi, Rudolf.
>>
>> Thanks for the reply.  Yes, I am aware of the eSDK functionality,
>> however, I have some unique requirements that I am trying to work around.
>> Regardless... what I am doing should work, no?  I simply want to use a
>> local git repo (the directory itself hence protocol=file) instead of what
>> the recipe specifies.  Looks like the fetch is working but the do_unpack
>> task is ignoring PREMIRRORS (or at least the localpath variable seems
>> wrong).
>>
>> --Russ
>>
>>
>> On Wed, Jul 24, 2019 at 12:19 PM Rudolf J Streif <
>> rudolf.str...@ibeeto.com> wrote:
>>
>>> Russell,
>>>
>>> You don't need PREMIRROR for this functionality. It's not exactly
>>> intended for that use.
>>>
>>> The simplest way to achieve what you are looking for is to use devtool.
>>> If I understand you correctly you are downloading sources from a remote
>>> repo on GitHub but want to have them locally to make modifications? If so
>>> use:
>>>
>>> devtool add myrecipe localsrc fetchuri
>>>
>>> from your build environment (you have to source oe-init-build-env
>>> first). devtool then fetches the source from

Re: [yocto] Building for AM335x with meta-ti and meta-qt5

[Andy Pont]

I wrote about trying to compile the SGX kernel modules giving up with 
the following error:



| *** Multiarch build: no
| *** Primary arch:target_armel
| *** Secondary arch:  none
| ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild 
may fail.
| eurasiacon/build/linux2/toplevel.mk:230: 
eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or 
directory


This gets pulled from 
https://git.ti.com/graphics/omap5-sgx-ddk-linux/commits/ti-img-sgx/1.17.4948957/k4.19 
and the files in the …/eurasiacon/build/linux2/moduledefs/ directory 
are:


host_i386.mk
target_aarch64.mk
target_i686.mk
target_neutral.mk
host_x86_64.mk
target_armhf.mk
target_mips32r2el.mk
target_x86_64.mk

I’m guessing it is supposed to be using target_armhf.mk but I can’t 
figure out why it is making the incorrect decision and trying to use a 
file that doesn’t exist.


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

Re: [yocto] PREMIRROR

[Rudolf J Streif]

Inlining below.

On 7/25/19 8:14 AM, Russell Peterson wrote:
> I think I have a somewhat better understanding of what is going on.
>
> First off, I was confused by the fact that the original error message
> I saw from do_unpack referenced the file (URL) at
> DL_DIR/git2/original_github_url.  What I didn't understand at the time
> was that while that file existed,/it was actually a link/ to
> DL_DIR/git2/local_url.  So, do_unpack wasn't looking at the wrong bare
> repository as I thought.  It was unhappy because it didn't see the git
> commit in the local repo that it was looking for.  I use AUTOREV for
> SRCREV.  Apparently, even with PREMIRROR set and matched, bitbake will
> still fetch the git HEAD commit hash from the original URL in the
> recipe.  The local git repo doesn't contain that commit.  When I sync
> the local git repo to the github repo things work as expected.
Correct. If the source repo or the correct commit cannot be found from
the PREMIRROR, bitbake will use SRC_URI from the recipe. You can block
that behavior by setting BB_NO_NETWORK = "1" in which case bitbake will
not be able to connect to any remote server. However, that does not help
if your PREMIRROR is a network server. In this case use BB_ALLOWED_HOSTS
to allow access to only the servers you want.
>
> Here is my problem.  What I am ultimately trying to do here is have 2
> git repos.  1 public, 1 private.  For internal development we use the
> private git repo (a local gerrit server).  Just before we ship we
> update the public github repo.  The recipe always points to the github
> (public) repo so we don't need to mess with that before a release. 
> This way we can do nightly builds (I'm just talking nightly builds
> done by Jenkins... not developers using eSDK and devtool) and test. 
> Customers using yocto will be given a recipe that points to github
> and, importantly, those customers that do NOT use yocto simply fetch
> the project from github and manually build it in their own environment
> with their own tools.
>
That is a common problem. I do this all the time. To do this add to your
conf/local.conf file:

INHERIT += "externalsrc"
EXTERNALSRC_pn-myrecipe = "/path/to/source/tree"

Alternatively, you could use a bbappend file for you recipe in a
development layer, myrecipe.bbappend:

inherit externalsrc
EXTERNALSRC = "/path/to/source/tree"

Now, that is exactly what devtool does for you but you can of course do
it manually.

:rjs



> I can't be the only one doing this.  Is there a best practices here
> (private vs. public repo)?
>
> --Russ
>
>
> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif
> mailto:rudolf.str...@ibeeto.com>> wrote:
>
> Russell,
>
> That is exactly what devtool and the externalsrc class do.
> PREMIRROR is the wrong approach for that.
>
> :rjs
>
> On 7/24/19 12:53 PM, Russell Peterson wrote:
>> Hi, Rudolf.
>>
>> I apologize for not being clear.  The idea here is that my recipe
>> points to github while, for my local development environment, I
>> set a premirror to match a specific github repository and
>> translate it to a local directory.  That works.  The fetch
>> matches the PREMIRROR and places a copy of the LOCAL git repo in
>> my DL_DIR.  The problem is, the do_unpack task is looking for the
>> git repo in the DL_DIR (git2/etc...)... but it's looking for the
>> git repo from github, not my local repo that the fetch task just
>> put in DL_DIR.
>>
>> There are numerous reasons I'm doing this including the fact that
>> I cannot put a reference to my local repo in the bb file since I
>> ship that recipe to my customers and a local pathname is
>> meaningless to them.  I prefer to simply modify my local.conf
>> with a PREMIRROR value that has a specific regular expression
>> that matches this particular github repo (and hence does NOT
>> effect all recipes).  This is why I wanted to use the PREMIRROR
>> function.  Unfortunately, it does not appear to work or at least
>> not work as I expected.
>>
>> --Russ
>>
>>
>>
>>
>> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif
>> mailto:rudolf.str...@ibeeto.com>> wrote:
>>
>> Hi Russell,
>>
>> devtool and eSDK are different things. The purpose of
>> PREMIRRORS is to set a mirror for all recipes. It's a way for
>> organizations to control where their YP builds download
>> sources from. It's not intended to be used for a single
>> recipe. There is no need for that. You simply set SRC_URI in
>> your recipe to your local git repo. That is what devtool does
>> after downloading the sources from a remote repo. If you
>> already have the remote repo cloned locally you can just
>> point devtool to it.
>>
>> You can do it manually by creating your recipe and setting
>> SRC_URI like this:
>>
>> SRC_URI = "git:///local/path/${PN};protocol=file"
>>
>> SRCREV = "

[yocto] Recurrent service file

[JH]

Hi,

I am running Yocto distroI am building a service file like a cron job
to run every 10 minutes, I searched from Internet, there was tips to
use Restart=always and RestartSec=10min, but that seems not quite
right, the document said that RestartSec is for delaying 10min, any
tips how to fix following format?

[Unit]
Description=Cron job

[Service]
Type=simple
Restart=always
RestartSec=10min
ExecStart=/usr/sbin/sa_cron_job.sh

[Install]
WantedBy=multi-user.target

Thank you.

Kind regards,

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

Re: [yocto] Recurrent service file

[Anders Montonen]

On 26 Jul 2019, at 1:45, JH  wrote:
> 
> Hi,
> 
> I am running Yocto distroI am building a service file like a cron job
> to run every 10 minutes, I searched from Internet, there was tips to
> use Restart=always and RestartSec=10min, but that seems not quite
> right, the document said that RestartSec is for delaying 10min, any
> tips how to fix following format?

You probably want a timer unit that triggers the service unit: 
>

Regards,
Anders 

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

Re: [yocto] PREMIRROR

[Russell Peterson]

Just tried the externalsrc feature.  Works perfectly.  Exactly what I was
looking for.  Thanks so much, Rudolf!

--Russ


On Thu, Jul 25, 2019 at 4:59 PM Rudolf J Streif 
wrote:

> Inlining below.
> On 7/25/19 8:14 AM, Russell Peterson wrote:
>
> I think I have a somewhat better understanding of what is going on.
>
> First off, I was confused by the fact that the original error message I
> saw from do_unpack referenced the file (URL) at
> DL_DIR/git2/original_github_url.  What I didn't understand at the time was
> that while that file existed,* it was actually a link* to
> DL_DIR/git2/local_url.  So, do_unpack wasn't looking at the wrong bare
> repository as I thought.  It was unhappy because it didn't see the git
> commit in the local repo that it was looking for.  I use AUTOREV for
> SRCREV.  Apparently, even with PREMIRROR set and matched, bitbake will
> still fetch the git HEAD commit hash from the original URL in the recipe.
> The local git repo doesn't contain that commit.  When I sync the local git
> repo to the github repo things work as expected.
>
> Correct. If the source repo or the correct commit cannot be found from the
> PREMIRROR, bitbake will use SRC_URI from the recipe. You can block that
> behavior by setting BB_NO_NETWORK = "1" in which case bitbake will not be
> able to connect to any remote server. However, that does not help if your
> PREMIRROR is a network server. In this case use BB_ALLOWED_HOSTS to allow
> access to only the servers you want.
>
>
> Here is my problem.  What I am ultimately trying to do here is have 2 git
> repos.  1 public, 1 private.  For internal development we use the private
> git repo (a local gerrit server).  Just before we ship we update the public
> github repo.  The recipe always points to the github (public) repo so we
> don't need to mess with that before a release.  This way we can do nightly
> builds (I'm just talking nightly builds done by Jenkins... not developers
> using eSDK and devtool) and test.  Customers using yocto will be given a
> recipe that points to github and, importantly, those customers that do NOT
> use yocto simply fetch the project from github and manually build it in
> their own environment with their own tools.
>
> That is a common problem. I do this all the time. To do this add to your
> conf/local.conf file:
>
> INHERIT += "externalsrc"
> EXTERNALSRC_pn-myrecipe = "/path/to/source/tree"
>
> Alternatively, you could use a bbappend file for you recipe in a
> development layer, myrecipe.bbappend:
>
> inherit externalsrc
> EXTERNALSRC = "/path/to/source/tree"
>
> Now, that is exactly what devtool does for you but you can of course do it
> manually.
>
> :rjs
>
>
>
> I can't be the only one doing this.  Is there a best practices here
> (private vs. public repo)?
>
> --Russ
>
>
> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif 
> wrote:
>
>> Russell,
>>
>> That is exactly what devtool and the externalsrc class do. PREMIRROR is
>> the wrong approach for that.
>>
>> :rjs
>> On 7/24/19 12:53 PM, Russell Peterson wrote:
>>
>> Hi, Rudolf.
>>
>> I apologize for not being clear.  The idea here is that my recipe points
>> to github while, for my local development environment, I set a premirror to
>> match a specific github repository and translate it to a local directory.
>> That works.  The fetch matches the PREMIRROR and places a copy of the LOCAL
>> git repo in my DL_DIR.  The problem is, the do_unpack task is looking for
>> the git repo in the DL_DIR (git2/etc...)... but it's looking for the git
>> repo from github, not my local repo that the fetch task just put in DL_DIR.
>>
>> There are numerous reasons I'm doing this including the fact that I
>> cannot put a reference to my local repo in the bb file since I ship that
>> recipe to my customers and a local pathname is meaningless to them.  I
>> prefer to simply modify my local.conf with a PREMIRROR value that has a
>> specific regular expression that matches this particular github repo (and
>> hence does NOT effect all recipes).  This is why I wanted to use the
>> PREMIRROR function.  Unfortunately, it does not appear to work or at least
>> not work as I expected.
>>
>> --Russ
>>
>>
>>
>>
>> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif 
>> wrote:
>>
>>> Hi Russell,
>>>
>>> devtool and eSDK are different things. The purpose of PREMIRRORS is to
>>> set a mirror for all recipes. It's a way for organizations to control where
>>> their YP builds download sources from. It's not intended to be used for a
>>> single recipe. There is no need for that. You simply set SRC_URI in your
>>> recipe to your local git repo. That is what devtool does after downloading
>>> the sources from a remote repo. If you already have the remote repo cloned
>>> locally you can just point devtool to it.
>>>
>>> You can do it manually by creating your recipe and setting SRC_URI like
>>> this:
>>>
>>> SRC_URI = "git:///local/path/${PN};protocol=file"
>>>
>>> SRCREV = "${AUTOREV}"
>>>
>>> S = "${WORKDIR}/git"
>>>
>>> P

Re: [yocto] QA notification for completed autobuilder build (yocto-2.8_M2.rc1)

[Yeoh, Ee Peng]

Hello All,

Intel and WR YP QA is planning for QA execution for YP build yocto-2.8_M2.rc1.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
3. BSP-Qemu

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is next Wednesday, July 31.

-Original Message-
From: pokybuild@centos7-ty-3.localdomain 
[mailto:pokybuild@centos7-ty-3.localdomain] 
Sent: Wednesday, July 24, 2019 11:21 AM
To: yocto@yoctoproject.org
Cc: ota...@ossystems.com.br; yi.z...@windriver.com; Sangal, Apoorv 
; Yeoh, Ee Peng ; Chan, Aaron 
Chun Yew ; Ang, Chin Huat 
; richard.pur...@linuxfoundation.org; 
akuster...@gmail.com; sjolley.yp...@gmail.com; Jain, Sangeeta 

Subject: QA notification for completed autobuilder build (yocto-2.8_M2.rc1)


A build flagged for QA (yocto-2.8_M2.rc1) was completed on the autobuilder and 
is available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.8_M2.rc1


Build hash information: 

bitbake: f5ea06fc2b6713c9f8e85ecf7cb981ae9a84d896
meta-gplv2: 1e2480e50f34e55bdfd5e06f98441e03a3752d5a
meta-intel: 3227874941bb8f9b706d6057b1de3997881bdffd
meta-mingw: 3fa43aa92f1a1c90304f6f4f49270915d1392cce
oecore: e0c3436241afca93f107e325d1b9ffcdebf706cd
poky: 835f7eac0610325e906591cd81890bebe8627580



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.pur...@linuxfoundation.org


 

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

Re: [yocto] how to stop applying patches in yocto project

[Randy MacLeod]

On 7/25/19 7:19 AM, Tg, Harish wrote:

Hi,

  I have requirement that I shall not apply patches to the yocto 
project and then build u-boot, kernel and the images. Can u please help 
me? Basically I need to revert back to PSDKLA-3.02 Release and without 
patches. Please guide me.


PSDKLA-3.02 seems to be a TI distro that is apparently based on oe-core:

http://processors.wiki.ti.com/index.php/Category:Processor_SDK_Linux_Automotive

You should contact who ever your vendor or support organization is.

If you can formulated and explain your question in fairly generic
oe-core/yocto terms ideally with links to public git repos, then
perhaps someone will help you out here.

Good luck,
../Randy



Thanks,

Harish.





--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [layerindex-web][PATCH v2 000/129] Docker setup / misc fixes (cover letter only)

[Paul Eggleton]

The Clear Linux* Dissector [1] is a special-purpose fork of the OE Layer
Index codebase. During development a number of general-purpose fixes have
been made, so I am now sending a slightly reworked set of these back to be
merged into the layer index. Highlights:

* Enhanced docker/docker-compose setup with script for one-command
  installation - this is now the preferred method of installation for
  uses other than development, so the README documentation has been
  updated accordingly.
* User-selectable security questions for password resets
* Fixes for spec file importing
* Various minor security fixes

[1] https://github.com/intel/clear-linux-dissector-web

Changes since v1:

* Add a few more fixes:
  import_otherdistro: handle non-UTF8 encoded spec files
  import_otherdistro: try-specfile: handle files in current dir
  dockersetup: fix error when printing URL with https enabled



The following changes since commit dba1fbe5d1c5d8714d7ca3ca86c42972ebde128e:

  RRS: add missing migration (2019-05-28 09:57:58 +1200)

are available in the Git repository at:

  git://git.yoctoproject.org/layerindex-web paule/dissector-backports
  
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=paule/dissector-backports

Amber Elliot (6):
  docker: add setup script
  admin.py: Add custom SiteAdmin model.
  Upgrade django-registration to version 3.0.
  Add user security questions
  layerindex/urls.py: improve formatting
  requirements.txt: Require secure version of Django.

Paul Eggleton (122):
  Add ability to hide branches
  Split out recipe dependency handling to its own function
  docker: Add docker-compose file
  update_classic_status: recognise pythonhosted.org as python
  update_classic_status: set category for KDE packages
  update_classic_status: categorise perl packages
  import_otherdistro: add description option
  import_otherdistro: improve display of deleted items
  dockersetup: formatting fixes
  dockersetup: add some error checking to the setup script
  dockersetup: tweak portmapping option and display port
  docker/nginx*.conf: fix up indentation
  docker: use quoted values
  dockersetup: add HTTPS support and use by default
  dockersetup: Show intro message
  dockersetup: add letsencrypt support
  nginx: set some limits for DDOS protection
  docker: set mariadb wait_timeout to upstream default
  dockerignore: add docker files and tests
  docker: enable user/password for RabbitMQ server
  dockersetup: move HTTPS code to its own function
  dockersetup: support update/reinstall mode
  dockersetup: fix auto-generated passwords
  dockersetup: warn if http proxy specified without https
  dockersetup: use separate db account with lower privileges
  dockersetup: use with open in readfile/writefile
  .gitignore: add some more files/dirs
  dockersetup: support importing gzip compressed database dumps
  docker: pass through options for migrate script
  docker: restart services automatically unless stopped
  Update TableSorter to latest version of active fork
  Disable caching on auth views
  docker: enable SECURE_BROWSER_XSS_FILTER
  Use shell=False where possible with utils.runcmd()
  dockersetup: import database dump before running migrations
  dockersetup: move superuser account creation to the end
  dockersetup: set site info and email host
  Rework README documents
  import_layers: fix URL construction
  Add a script to create initial db dump
  dockersetup: add option to skip database migrations
  dockersetup: enable error report emails
  Disable autocomplete on sensitive fields
  docker: Increase nginx max upload size
  docker: increase gunicorn worker timeout to handle large images
  ClassicRecipeDetailView does not need a form
  Add ability to disposition comparison patches
  Add access controls to PatchDispositionAdmin
  import_otherdistro: refactor spec file import
  import_otherdistro.py: avoid deleting all records if no spec files found
  import_otherdistro.py: create layer/branch if they don't exist
  Add sha256sum to Source model
  Record sha256sum of other distro source files
  dockersetup: require email address
  import_otherdistro: optionally store local path
  import_otherdistro: fix handling of garbage in description values
  Determine if spec file patches are actually applied and striplevel
  docker-compose: fix missing DATABASE_USER for layerscelery service
  docker: add dependencies for derivative import
  tasks: support running non-shell commands
  tasks: fix incorrect closing tag on button
  Enable task log/progress to work within docker
  tasks: handle carriage returns in task output
  Record configure options
  Fix erroneously importing package fields from spec files
  docker: use python3 in migrate script
  docker: improve nginx https configuration security
  docker: Increase max packet size to 128M
  tasks: disable broker heartbeat to workaround connection issues
  dockersetup: 'easy' subprocess conversions to not use shell=True
  dockersetup: require python 3.4.3 or later
  More