Re: [yocto] Extended SDK installation fails during git fetch of kernel source hosted on private repo

[Gabriele Favalessa]

An update (and a workaround.)

What's happening is that during the execution of the install script for the
extended SDK, the env of the original shell is ignored. If your SDK refers
to private git repos (on github for example) and you normally authenticate
to github using ssh and ssh-agent, the SSH_AUTH_SOCK env variables needed
won't be set by the time git is invoked. The workaround is configuring the
authentication to github in .ssh/config and avoid the ssh-agent. (Yes, I
checked and SSH_AUTH_SOCK is exported by the shell :)

But the underlying problem is that env of the shell is ignored during
install, so potentially other useful variables could be ignored. Is that
intentional? Is there a way to prevent it?

Gabriele

On Wed, Aug 29, 2018 at 3:55 PM Gabriele Favalessa <
gabri...@analyticsfire.com> wrote:

> Hi,
>
> I'm trying to install on ubuntu 17.04 an Extensible SDK that I have built,
> and it stops with an error:
>
> ---
> sdk@sdk:~$ ./
> acme-linux-glibc-x86_64-acme-image-datalogger-cortexa7hf-neon-toolchain-ext-2.5.1.sh
> -D
> …
> + sh -c . buildtools/environment-setup* >
> /home/sdk/acme-linux_sdk/preparing_build_system.log && cd
> /home/sdk/acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && .
> /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env
> /home/sdk/acme-linux_sdk >>
> /home/sdk/acme-linux_sdk/preparing_build_system.log && python
> /home/sdk/acme-linux_sdk/ext-sdk-prepare.py
> /home/sdk/acme-linux_sdk/preparing_build_system.log 'acme-image-datalogger
> meta-extsdk-toolchain:do_populate_sysroot'
> WARNING:
> /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/
> linux-imx_4.9.11.bb: Exception during build_dependencies for AUTOREV
> WARNING:
> /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/
> linux-imx_4.9.11.bb: Error during finalise of
> /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/
> linux-imx_4.9.11.bb
> ERROR: ExpansionError during parsing
> /home/sdk/acme-linux_sdk/layers/poky/meta-myboard/recipes-kernel/linux/
> linux-imx_4.9.11.bb
> Traceback (most recent call last):
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
> Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export
> GIT_SSL_CAINFO="/home/sdk/acme-linux_sdk/buildtools/sysroots/x86_64-acmesdk-linux/etc/ssl/certs/ca-certificates.crt";
> export
> PATH="/home/sdk/acme-linux_sdk/layers/poky/scripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin/arm-acme-linux-gnueabi:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot/usr/bin/crossscripts:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/usr/bin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/sbin:/home/sdk/acme-linux_sdk/tmp/work/myboard-acme-linux-gnueabi/linux-imx/4.9.11-r0/recipe-sysroot-native/bin:/home/sdk/acme-linux_sdk/layers/poky/bitbake/bin:/home/sdk/acme-linux_sdk/tmp/hosttools";
> export HOME="/home/sdk"; git -c core.fsyncobjectfiles=0 ls-remote ssh://
> g...@github.com/Acme/linux-imx.git  failed with exit code 128, output:
> Permission denied (publickey).
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
>
> ERROR: SDK preparation failed: error log written to
> /home/sdk/acme-linux_sdk/preparing_build_system.log
> ---
>
> I tested the failing git command `git -c ls-remote ssh://
> g...@github.com/Acme/linux-imx.git`
>  directly from the command line
> and it succeeds without errors. I do have the ssh key in ssh-agent, so
> that's not surprise.
>
> It looks like during the SDK installation the ssh key is needed but for
> some reason the ssh-agent is not reachable (maybe the SSH_* env variables
> are not propagated by the script?)
>
> Is it unavoidable for the SDK to fetch from git during the installation?
> If it is unavoidable, how can I make the script fetch from a private github
> repo, given that the ssh-agent seems to be ignored?
>
> Just out of curiosity, I copy&pasted the failing command in the shell, and
> this time it ran without errors (again confirming that the ssh key is
> present.)
>
> ---
> sdk@sdk:~$ sh -c . buildtools/environment-setup* >
> /home/sdk/acme-linux_sdk/preparing_build_system.log && cd /home/sdk/
> acme-linux_sdk/layers/poky && set /home/sdk/acme-linux_sdk && .
> /home/sdk/acme-linux_sdk/layers/poky/oe-init-build-env
> /home/sdk/acme-linux_sdk >>
> /ho

[yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Måns Zigher]

Hi,

I have a cmake project that is making use of ExternalProject_Add. The
external project will make use of git clone to pull down the project. The
problem that I am seeing is that the do_configure will fail because it
cannot find git which is not part of the sysroot the reason for git not
being part the sysroot is that git-native is included in ASSUME_PROVIDED
which prevent me from getting it into the sysroot and when running
do_configure it will only look for it in the sysroot and not on the host if
I am not mistaken? What would the best way be to proceed to solve this
problem?

BR
Måns Zigher
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Alexander Kanavin]

Sadly, Yocto is not well equippped to deal with projects that download
stuff from the internet as a part of the build process. I'd say if
it's just one project, write a separate recipe for it, and build it
via that. Then install into the original recipe's sysroot or build dir
as needed, and make sure the project doesn't attempt to download it
anymore.

Alex

2018-09-06 13:05 GMT+02:00 Måns Zigher :
> Hi,
>
> I have a cmake project that is making use of ExternalProject_Add. The
> external project will make use of git clone to pull down the project. The
> problem that I am seeing is that the do_configure will fail because it
> cannot find git which is not part of the sysroot the reason for git not
> being part the sysroot is that git-native is included in ASSUME_PROVIDED
> which prevent me from getting it into the sysroot and when running
> do_configure it will only look for it in the sysroot and not on the host if
> I am not mistaken? What would the best way be to proceed to solve this
> problem?
>
> BR
> Måns Zigher
>
> --
> ___
> 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] Determine revision of meta-layer within a recipe

[Matthias Schoepfer]

Hi!

Is there a standard way of determining the git revision of the *layer*
the recipe lives in from within the recipe itself? I know that
image-buildinfo class does something like it, but I wonder how this
could be used within a recipe.

Thanks and Regards,

   Matthias



pEpkey.asc
Description: application/pgp-keys
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: No manifest generated

[Ravikiran J]

On Thu, Sep 6, 2018 at 1:47 AM, Khem Raj  wrote:

>
>
> On 9/4/18 10:39 PM, Ravikiran J wrote:
> > Dear Yocto team,
> >
> > We have developed some recipe file to install  the firmware binary in
> > the file system of Yocto.
> > Recipe file is working fine in *Yocto morty* version but when we tried
> > the same in the *Yocto sumo* version we got the following error for
> > *bitbake core-image-minimal*.
> >
> > *ERROR: core-image-minimal-1.0-r0 do_rootfs: No manifest generated from:
> > rtl-firmware in
> > /home/graco_sm/1.4.4/GRACO_SM_REL_V1.1/Software/U-Boot-and-L
> inux/sumo/poky/meta-graco/recipes-graco/firmware/rtl-firmware.bb
> > *
> > ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
> > ERROR: Logfile of failure stored in:
> > /home/graco_sm/1.4.4/GRACO_SM_REL_V1.1/Software/U-Boot-and-L
> inux/sumo/poky/build/tmp/work/rzn1d400_graco-poky-linux-gnue
> abi/core-image-minimal/1.0-r0/temp/log.do_rootfs.28035
> > ERROR: Task
> > (/home/graco_sm/1.4.4/GRACO_SM_REL_V1.1/Software/U-Boot-and-
> Linux/sumo/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs)
> > failed with exit code '1'
> >
> >
>
> which version of yocto project release is in use here ?
>
*Yocto version 2.5*

>
> > Recipe file*rtl-firmware.bb  *content*
> > *
> > *
> > *
> > DESCRIPTION = "RTL 8723BU BT firmware"
> >
> > LICENSE = "MIT"
> > LIC_FILES_CHKSUM =
> > "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
> >
> > PACKAGE_ARCH = "all"
>
> perhaps using inherit allarch  is better here.
>
> >
> > SRC_URI += " \
> > file://rtl8723b_fw.bin \
> > "
> >
> > do_install () {
> > install -d ${D}${base_libdir}/firmware/
> > install -m 755 ${WORKDIR}/rtl8723b_fw.bin
> ${D}${base_libdir}/firmware/
> > }
> >
> > FILES_${PN} += " \
> > ${base_libdir}/firmware/rtl8723b_fw.bin \
> > "*
> > *
> >
> > What needs to be done for to avoiding manifest error  ?
> > Kindly help us to resolve this issue.s
> >
> >
> > Thanks and Regards,
> > Ravikiran J J
> >
> >
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Weekly Triage Meeting

[Jolley, Stephen K]

Attendees: Armin, Stephen, Amanda, Randy, Richard, Joshua, Ross

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

AR: Richard – File bugs to update Bitbake warnings.

Thanks,

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

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

[yocto] curl package config

[Antonio Santagiuliana]

Hello
I am trying to enable the SMB protocol when building curl library by Yocto
the original recipe is under meta/recipes-support/curl

in my image's local.conf I have
IMAGE_INSTALL_append += "curl-dev"

curl is built correctly, but SMB is disabled

So I tried to add a .bbappend file with same name as the recipe's name,
with this line only :
PACKAGECONFIG = "--enable-smb"

but I still have SMB disaabled on curl.

Which is the right way to enable it with PACKAGECONFIG?
or another way ?
thank you
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] curl package config

[Erik Botö]

Hi,

On Thu, Sep 6, 2018 at 8:01 PM Antonio Santagiuliana <
santantonios...@gmail.com> wrote:

> Hello
> I am trying to enable the SMB protocol when building curl library by Yocto
> the original recipe is under meta/recipes-support/curl
>
> in my image's local.conf I have
> IMAGE_INSTALL_append += "curl-dev"
>
> curl is built correctly, but SMB is disabled
>
> So I tried to add a .bbappend file with same name as the recipe's name,
> with this line only :
> PACKAGECONFIG = "--enable-smb"
>
> but I still have SMB disaabled on curl.
>
> Which is the right way to enable it with PACKAGECONFIG?
> or another way ?
>

You just want to add "smb" to the variable PACKAGECONFIG in the bbappend.
But since the original recipe uses ??= to assign the default PACKAGECONFIG
value you probably want to either redefine the whole variable as the
original recipe, but adding "smb"
PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
libidn proxy threaded-resolver verbose zlib smb"

I think it could work if you use _append as well, since I think that's
added after the ??= operator is evaluated. So you can also try (note the
space before smb):
PACKAGECONFIG_append = " smb"

Cheers,
Erik

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

Re: [yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Måns Zigher]

Hi,

Thanks for your reply. A colleague found

OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH"

and it seems to work. Do you have any comment using this?

Br
Måns Zigher

On Thu, Sep 6, 2018, 13:52 Alexander Kanavin  wrote:

> Sadly, Yocto is not well equippped to deal with projects that download
> stuff from the internet as a part of the build process. I'd say if
> it's just one project, write a separate recipe for it, and build it
> via that. Then install into the original recipe's sysroot or build dir
> as needed, and make sure the project doesn't attempt to download it
> anymore.
>
> Alex
>
> 2018-09-06 13:05 GMT+02:00 Måns Zigher :
> > Hi,
> >
> > I have a cmake project that is making use of ExternalProject_Add. The
> > external project will make use of git clone to pull down the project. The
> > problem that I am seeing is that the do_configure will fail because it
> > cannot find git which is not part of the sysroot the reason for git not
> > being part the sysroot is that git-native is included in ASSUME_PROVIDED
> > which prevent me from getting it into the sysroot and when running
> > do_configure it will only look for it in the sysroot and not on the host
> if
> > I am not mistaken? What would the best way be to proceed to solve this
> > problem?
> >
> > BR
> > Måns Zigher
> >
> > --
> > ___
> > 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] curl package config

[Andre McCurdy]

On Thu, Sep 6, 2018 at 12:10 PM, Erik Botö  wrote:
> Hi,
>
> On Thu, Sep 6, 2018 at 8:01 PM Antonio Santagiuliana
>  wrote:
>>
>> Hello
>> I am trying to enable the SMB protocol when building curl library by Yocto
>> the original recipe is under meta/recipes-support/curl
>>
>> in my image's local.conf I have
>> IMAGE_INSTALL_append += "curl-dev"
>>
>> curl is built correctly, but SMB is disabled
>>
>> So I tried to add a .bbappend file with same name as the recipe's name,
>> with this line only :
>> PACKAGECONFIG = "--enable-smb"

This is just the wrong syntax. PACKAGECONFIG is not a list of
configure options. It's a list of "features" to enable, which are then
translated into appropriate configure options (and dependencies) based
on rules defined in the recipe. Maybe look through some existing
recipes in oe-core to get some idea of how the process works.

>> but I still have SMB disaabled on curl.
>>
>> Which is the right way to enable it with PACKAGECONFIG?
>> or another way ?
>
>
> You just want to add "smb" to the variable PACKAGECONFIG in the bbappend.
> But since the original recipe uses ??= to assign the default PACKAGECONFIG
> value you probably want to either redefine the whole variable as the
> original recipe, but adding "smb"
> PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
> libidn proxy threaded-resolver verbose zlib smb"
>
> I think it could work if you use _append as well, since I think that's added
> after the ??= operator is evaluated. So you can also try (note the space
> before smb):
> PACKAGECONFIG_append = " smb"

Using _append like this to add values to PACKAGECONFIG is the
recommended way (ie don't try to use +=) for the reasons mentioned.

Redefining the entire variable isn't necessary or recommended (it
requires more maintenance to keep the .bbappend value in sync with any
changes in the base recipe).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH 00/16] selinux: upgrade 2.7 -> 2.8

[Yi Zhao]

Ping


//Yi


在 2018年09月05日 08:18, Yi Zhao 写道:


Yi Zhao (16):
   selinux: uprev inc files to 2.8 (20180524)
   libsepol: uprev to 2.8 (20180524)
   libselinux: uprev to 2.8 (20180524)
   libsemanage: uprev to 2.8 (20180524)
   checkpolicy: uprev to 2.8 (20180524)
   secilc: uprev to 2.8 (20180524)
   policycoreutils: uprev to 2.8 (20180524)
   mcstrans: uprev to 2.8 (20180524)
   restorecond: uprev to 2.8 (20180524)
   selinux-sandbox: uprev to 2.8 (20180524)
   selinux-python: uprev to 2.8 (20180524)
   semodule-utils: uprev to 2.8 (20180524)
   selinux-dbus: uprev to 2.8 (20180524)
   selinux-gui: uprev to 2.8 (20180524)
   packagegroup-selinux-policycoreutils: remove
 semodule-utils-semodule-deps
   audit: uprev to 2.8.4

  .../audit/{audit_2.7.6.bb => audit_2.8.4.bb}   | 18 +++---
  .../packagegroup-selinux-policycoreutils.bb|  1 -
  recipes-security/selinux/checkpolicy.inc   |  1 -
  recipes-security/selinux/checkpolicy_2.7.bb|  7 --
  recipes-security/selinux/checkpolicy_2.8.bb|  7 ++
  recipes-security/selinux/libselinux.inc|  2 +-
  ...-Makefile-fix-includedir-in-libselinux.pc.patch | 20 ---
  .../{libselinux_2.7.bb => libselinux_2.8.bb}   |  6 ++---
  recipes-security/selinux/libsemanage.inc   | 12 ++---
  ...-Makefile-fix-includedir-in-libselinux.pc.patch | 20 ---
  .../{libsemanage_2.7.bb => libsemanage_2.8.bb} |  6 ++---
  ...rc-Makefile-fix-includedir-in-libsepol.pc.patch | 13 +-
  recipes-security/selinux/libsepol_2.7.bb   |  9 ---
  recipes-security/selinux/libsepol_2.8.bb   |  9 +++
  recipes-security/selinux/mcstrans.inc  |  1 -
  recipes-security/selinux/mcstrans_2.7.bb   |  7 --
  recipes-security/selinux/mcstrans_2.8.bb   |  7 ++
  recipes-security/selinux/policycoreutils.inc   |  8 +++---
  ...policycoreutils-fix-fixfiles-install-path.patch | 29 ++
  ...icycoreutils-fix-load_policy-install-path.patch | 29 ++
  .../policycoreutils-loadpolicy-symlink.patch   | 19 --
  recipes-security/selinux/policycoreutils_2.7.bb|  8 --
  recipes-security/selinux/policycoreutils_2.8.bb|  8 ++
  recipes-security/selinux/restorecond.inc   |  4 ---
  recipes-security/selinux/restorecond_2.7.bb|  7 --
  recipes-security/selinux/restorecond_2.8.bb|  7 ++
  recipes-security/selinux/secilc_2.7.bb |  7 --
  recipes-security/selinux/secilc_2.8.bb |  7 ++
  recipes-security/selinux/selinux-dbus_2.7.bb   |  7 --
  recipes-security/selinux/selinux-dbus_2.8.bb   |  7 ++
  recipes-security/selinux/selinux-gui_2.7.bb|  7 --
  recipes-security/selinux/selinux-gui_2.8.bb|  7 ++
  recipes-security/selinux/selinux-python.inc|  2 +-
  .../selinux-python/fix-sepolicy-install-path.patch | 23 +
  recipes-security/selinux/selinux-python_2.7.bb |  7 --
  recipes-security/selinux/selinux-python_2.8.bb |  7 ++
  recipes-security/selinux/selinux-sandbox_2.7.bb|  7 --
  recipes-security/selinux/selinux-sandbox_2.8.bb|  7 ++
  .../{selinux_20170804.inc => selinux_20180524.inc} |  2 +-
  recipes-security/selinux/selinux_common.inc|  9 ---
  recipes-security/selinux/semodule-utils.inc|  2 --
  recipes-security/selinux/semodule-utils_2.7.bb |  7 --
  recipes-security/selinux/semodule-utils_2.8.bb |  7 ++
  43 files changed, 209 insertions(+), 178 deletions(-)
  rename recipes-security/audit/{audit_2.7.6.bb => audit_2.8.4.bb} (91%)
  delete mode 100644 recipes-security/selinux/checkpolicy_2.7.bb
  create mode 100644 recipes-security/selinux/checkpolicy_2.8.bb
  rename recipes-security/selinux/{libselinux_2.7.bb => libselinux_2.8.bb} (72%)
  rename recipes-security/selinux/{libsemanage_2.7.bb => libsemanage_2.8.bb} 
(76%)
  delete mode 100644 recipes-security/selinux/libsepol_2.7.bb
  create mode 100644 recipes-security/selinux/libsepol_2.8.bb
  delete mode 100644 recipes-security/selinux/mcstrans_2.7.bb
  create mode 100644 recipes-security/selinux/mcstrans_2.8.bb
  create mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-fix-fixfiles-install-path.patch
  create mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-fix-load_policy-install-path.patch
  delete mode 100644 
recipes-security/selinux/policycoreutils/policycoreutils-loadpolicy-symlink.patch
  delete mode 100644 recipes-security/selinux/policycoreutils_2.7.bb
  create mode 100644 recipes-security/selinux/policycoreutils_2.8.bb
  delete mode 100644 recipes-security/selinux/restorecond_2.7.bb
  create mode 100644 recipes-security/selinux/restorecond_2.8.bb
  delete mode 100644 recipes-security/selinux/secilc_2.7.bb
  create mode 100644 recipes-security/selinux/secilc_2.8.bb
  delete mode 100644 re