[OE-core] [PATCH] pinentry: update to 1.0.0

[Armin Kuster]

From: Armin Kuster 

add pkg-config support for libassuan and gpg-error
updated config options

Signed-off-by: Armin Kuster 
---
 .../pinentry/pinentry-1.0.0/gpg-error_pkconf.patch | 100 ++
 .../pinentry-1.0.0/libassuan_pkgconf.patch | 153 +
 .../{pinentry_0.9.2.bb => pinentry_1.0.0.bb}   |  22 +--
 3 files changed, 265 insertions(+), 10 deletions(-)
 create mode 100644 
meta/recipes-support/pinentry/pinentry-1.0.0/gpg-error_pkconf.patch
 create mode 100644 
meta/recipes-support/pinentry/pinentry-1.0.0/libassuan_pkgconf.patch
 rename meta/recipes-support/pinentry/{pinentry_0.9.2.bb => pinentry_1.0.0.bb} 
(63%)

diff --git 
a/meta/recipes-support/pinentry/pinentry-1.0.0/gpg-error_pkconf.patch 
b/meta/recipes-support/pinentry/pinentry-1.0.0/gpg-error_pkconf.patch
new file mode 100644
index 000..431edb0
--- /dev/null
+++ b/meta/recipes-support/pinentry/pinentry-1.0.0/gpg-error_pkconf.patch
@@ -0,0 +1,100 @@
+Convert to pkg-config support to match changes done to 
+the gpg-error recipe for gpg-error.pc  generation.
+
+Upstream-Status: Inappropriate [OE specific]
+
+Signed-off-by: Armin Kuster 
+
+Index: pinentry-1.0.0/m4/gpg-error.m4
+===
+--- pinentry-1.0.0.orig/m4/gpg-error.m4
 pinentry-1.0.0/m4/gpg-error.m4
+@@ -25,74 +25,12 @@ dnl config script does not match the hos
+ dnl is added to the gpg_config_script_warn variable.
+ dnl
+ AC_DEFUN([AM_PATH_GPG_ERROR],
+-[ AC_REQUIRE([AC_CANONICAL_HOST])
+-  gpg_error_config_prefix=""
+-  dnl --with-libgpg-error-prefix=PFX is the preferred name for this option,
+-  dnl since that is consistent with how our three siblings use the directory/
+-  dnl package name in --with-$dir_name-prefix=PFX.
+-  AC_ARG_WITH(libgpg-error-prefix,
+-  AC_HELP_STRING([--with-libgpg-error-prefix=PFX],
+- [prefix where GPG Error is installed 
(optional)]),
+-  [gpg_error_config_prefix="$withval"])
+-
+-  dnl Accept --with-gpg-error-prefix and make it work the same as
+-  dnl --with-libgpg-error-prefix above, for backwards compatibility,
+-  dnl but do not document this old, inconsistently-named option.
+-  AC_ARG_WITH(gpg-error-prefix,,
+-  [gpg_error_config_prefix="$withval"])
+-
+-  if test x"${GPG_ERROR_CONFIG}" = x ; then
+- if test x"${gpg_error_config_prefix}" != x ; then
+-GPG_ERROR_CONFIG="${gpg_error_config_prefix}/bin/gpg-error-config"
+- else
+-   case "${SYSROOT}" in
+- /*)
+-   if test -x "${SYSROOT}/bin/gpg-error-config" ; then
+- GPG_ERROR_CONFIG="${SYSROOT}/bin/gpg-error-config"
+-   fi
+-   ;;
+- '')
+-   ;;
+-  *)
+-   AC_MSG_WARN([Ignoring \$SYSROOT as it is not an absolute path.])
+-   ;;
+-   esac
+- fi
+-  fi
+-
+-  AC_PATH_PROG(GPG_ERROR_CONFIG, gpg-error-config, no)
++[
+   min_gpg_error_version=ifelse([$1], ,0.0,$1)
+-  AC_MSG_CHECKING(for GPG Error - version >= $min_gpg_error_version)
+-  ok=no
+-  if test "$GPG_ERROR_CONFIG" != "no" \
+- && test -f "$GPG_ERROR_CONFIG" ; then
+-req_major=`echo $min_gpg_error_version | \
+-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
+-req_minor=`echo $min_gpg_error_version | \
+-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
+-gpg_error_config_version=`$GPG_ERROR_CONFIG $gpg_error_config_args 
--version`
+-major=`echo $gpg_error_config_version | \
+-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
+-minor=`echo $gpg_error_config_version | \
+-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
+-if test "$major" -gt "$req_major"; then
+-ok=yes
+-else
+-if test "$major" -eq "$req_major"; then
+-if test "$minor" -ge "$req_minor"; then
+-   ok=yes
+-fi
+-fi
+-fi
+-  fi
++  PKG_CHECK_MODULES(GPG_ERROR, [gpg-error >= $min_gpg_error_version 
gpg-error], [ok=yes], [ok=no])
+   if test $ok = yes; then
+-GPG_ERROR_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --cflags`
+-GPG_ERROR_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --libs`
+-GPG_ERROR_MT_CFLAGS=`$GPG_ERROR_CONFIG $gpg_error_config_args --mt 
--cflags 2>/dev/null`
+-GPG_ERROR_MT_LIBS=`$GPG_ERROR_CONFIG $gpg_error_config_args --mt --libs 
2>/dev/null`
+-AC_MSG_RESULT([yes ($gpg_error_config_version)])
+ ifelse([$2], , :, [$2])
+-gpg_error_config_host=`$GPG_ERROR_CONFIG $gpg_error_config_args --host 
2>/dev/null || echo none`
++gpg_error_config_host=`$PKG_CONFIG --host gpg-error 2>/dev/null || echo 
none`
+ if test x"$gpg_error_config_host" != xnone ; then
+   if test x"$gpg_error_config_host" != x"$host" ; then
+   AC_MSG_WARN([[
+@@ -107,10 +45,6 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
+   fi
+ fi
+   else
+-GPG_ERROR_CFLAGS=""
+-GPG_ERROR_LIBS=""
+-

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

[Mark Hatle]

On 3/13/17 7:47 PM, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: den 13 mars 2017 17:50
>> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
>> recipes specifying static IDs
>>
>> On 3/13/17 11:11 AM, Peter Kjellerstedt wrote:
 -Original Message-
 From: Mark Hatle [mailto:mark.ha...@windriver.com]
 Sent: den 13 mars 2017 14:56
 To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
 recipes specifying static IDs

 On 3/10/17 11:27 PM, Peter Kjellerstedt wrote:
> If this bblcass is used and a recipe specifies a static ID for a
> user/group as part of the USERADD_PARAM_${PN} or
>> GROUPADD_PARAM_${PN},
> the build would fail with and error like this if there was no
> corresponding ID in the passwd/group files specified via
> USERADD_UID_TABLES/USERADD_GID_TABLES:

 If the system is set in warning mode, it should warn if this is done
 (but allow it).

 If the system is set to error mode, it should error.

 The useradd-staticids class is expecting the files (tables) to
>> contain
 all of the entries.  This is specifically to avoid the situation
>> where
 a new recipe is introduced that adds a new user or group (dynamic or
 static -- static because it could conflict with one of your existing
 static entries.)
>>>
>>> AFAICT, even before my rewrite of much of this code in 3149319a and
>>> subsequent correction in adc0f830, if a static ID was specified as
>> part
>>> of USERADD_PARAM_${PN} then no error would be issued. However, we can
>>> certainly change the code to always fail/warn if no ID is specified
>>> in any of the passwd/groups files. It should just be a matter of
>>> removing the if statements preceding the calls to handle_missing_id()
>>> below. (I will do some verification and send an updated patch
>>> tomorrow if this is the way the class should work.)
>>
>> The intention was always that the uname/gname had to be specified in
>> the useradd tables in some way, or a warning/error would occur.
>>
>> If the fields were blank in the tables, the system would use the
>> versions located in the recipe -- otherwise it would use the version in 
>> the table.  (At one point, but I don't think this was ever pushed in -- 
>> if a static ID was set in the recipe, there was a verification that the 
>> static version in both the recipe and the table files was the same -- 
>> otherwise it could indicate the package may not be built properly.)
>>
 I agree the error message below looks wrong, do the existing
 warning/error messages about it not being defined int he useradd 
 tables still occur with this patch?
>>>
>>> The error message below occurred because before my fix it forgot all
>>> the parameters that were specified in USERADD_PARAM_${PN} when it
>>> took the continue.
>>
>> Ok, we need to fix that bug first then.
>>
>> We should then verify the second issue and fix it in a subsequent
>> commit.  The key being that of the user/group was not in the table 
>> we warn them (or error) -- preventing unexpected users from showing up.
> 
> I have verified now that removing the if statements will get us the wanted 
> behavior that all users/group must have static IDs in the passwd/groups 
> files even if they have static IDs defined in the recipe. I had intended 
> to just squash that change with the first one, but I can do it as two 
> separate commits.
> 
>> The check both static IDs are the same could very well be a TODO item
>> (that is never done) -- but something that should be considered.
> 
> There is a warning if a static ID is specified in the recipe and it is 
> changed due to having a different value in the passwd file. I think that 
> is good enough.

Perfect!  Thank you for checking all of this.

--Mark

>> Thanks!
>> --Mark
> 
> //Peter
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

[Peter Kjellerstedt]

> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: den 13 mars 2017 17:50
> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
> recipes specifying static IDs
> 
> On 3/13/17 11:11 AM, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> >> Sent: den 13 mars 2017 14:56
> >> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> >> Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
> >> recipes specifying static IDs
> >>
> >> On 3/10/17 11:27 PM, Peter Kjellerstedt wrote:
> >>> If this bblcass is used and a recipe specifies a static ID for a
> >>> user/group as part of the USERADD_PARAM_${PN} or
> GROUPADD_PARAM_${PN},
> >>> the build would fail with and error like this if there was no
> >>> corresponding ID in the passwd/group files specified via
> >>> USERADD_UID_TABLES/USERADD_GID_TABLES:
> >>
> >> If the system is set in warning mode, it should warn if this is done
> >> (but allow it).
> >>
> >> If the system is set to error mode, it should error.
> >>
> >> The useradd-staticids class is expecting the files (tables) to
> contain
> >> all of the entries.  This is specifically to avoid the situation
> where
> >> a new recipe is introduced that adds a new user or group (dynamic or
> >> static -- static because it could conflict with one of your existing
> >> static entries.)
> >
> > AFAICT, even before my rewrite of much of this code in 3149319a and
> > subsequent correction in adc0f830, if a static ID was specified as
> part
> > of USERADD_PARAM_${PN} then no error would be issued. However, we can
> > certainly change the code to always fail/warn if no ID is specified
> > in any of the passwd/groups files. It should just be a matter of
> > removing the if statements preceding the calls to handle_missing_id()
> > below. (I will do some verification and send an updated patch
> > tomorrow if this is the way the class should work.)
> 
> The intention was always that the uname/gname had to be specified in
> the useradd tables in some way, or a warning/error would occur.
> 
> If the fields were blank in the tables, the system would use the
> versions located in the recipe -- otherwise it would use the version in 
> the table.  (At one point, but I don't think this was ever pushed in -- 
> if a static ID was set in the recipe, there was a verification that the 
> static version in both the recipe and the table files was the same -- 
> otherwise it could indicate the package may not be built properly.)
> 
> >> I agree the error message below looks wrong, do the existing
> >> warning/error messages about it not being defined int he useradd 
> >> tables still occur with this patch?
> >
> > The error message below occurred because before my fix it forgot all
> > the parameters that were specified in USERADD_PARAM_${PN} when it
> > took the continue.
> 
> Ok, we need to fix that bug first then.
> 
> We should then verify the second issue and fix it in a subsequent
> commit.  The key being that of the user/group was not in the table 
> we warn them (or error) -- preventing unexpected users from showing up.

I have verified now that removing the if statements will get us the wanted 
behavior that all users/group must have static IDs in the passwd/groups 
files even if they have static IDs defined in the recipe. I had intended 
to just squash that change with the first one, but I can do it as two 
separate commits.

> The check both static IDs are the same could very well be a TODO item
> (that is never done) -- but something that should be considered.

There is a warning if a static ID is specified in the recipe and it is 
changed due to having a different value in the passwd file. I think that 
is good enough.

> Thanks!
> --Mark

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [morty][PATCH 0/2] GDB: fix missing modules

[Juro Bystricky]

This is a backport of two patches by George McCollister needed to
fix GDB from complaining:

Python Exception  No module named 'imp':
...


[YOCTO#11134]


*** BLURB HERE ***

George McCollister (1):
  gdb-cross-canadian: Depend on nativesdk-python3-importlib

Juro Bystricky (1):
  python-3.5-manifest: Add imp to importlib

 meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 3 ++-
 meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [morty][PATCH 2/2] python-3.5-manifest: Add imp to importlib

[Juro Bystricky]

The imp python module is the forerunner of importlib. Include imp in
the importlib subpackage instead of the misc subpackage so that it can
be depended on without bringing in a bunch of unrelated, unused modules.

(Slightly modified backport of afd9de380dc04780da1eeb94a4c8c46529254231
by George McCollister )

[YOCTO#11134]

Signed-off-by: Juro Bystricky 
---
 meta/recipes-devtools/python/python-3.5-manifest.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python-3.5-manifest.inc 
b/meta/recipes-devtools/python/python-3.5-manifest.inc
index 3046114..6c690db 100644
--- a/meta/recipes-devtools/python/python-3.5-manifest.inc
+++ b/meta/recipes-devtools/python/python-3.5-manifest.inc
@@ -115,7 +115,7 @@ FILES_${PN}-image="${libdir}/python3.5/colorsys.* 
${libdir}/python3.5/imghdr.* $
 
 SUMMARY_${PN}-importlib="Python import implementation library"
 RDEPENDS_${PN}-importlib="${PN}-core ${PN}-lang"
-FILES_${PN}-importlib="${libdir}/python3.5/importlib "
+FILES_${PN}-importlib="${libdir}/python3.5/importlib ${libdir}/python3.5/imp.* 
"
 
 SUMMARY_${PN}-io="Python low-level I/O"
 RDEPENDS_${PN}-io="${PN}-core ${PN}-math"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [morty][PATCH 1/2] gdb-cross-canadian: Depend on nativesdk-python3-importlib

[Juro Bystricky]

From: George McCollister 

Add missing dependency on nativesdk-python3-importlib so the imp Python
module is installed.

Before this patch, running gdb from the sdk would give the following
error:

Python Exception  No module named 'imp':

(From OE-Core rev: ad00a31fbe93e073a2d83616efcd08c5a7ef37c9)

Signed-off-by: George McCollister 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gdb/gdb-cross-canadian.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc 
b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
index e53081d..3ff1989 100644
--- a/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
+++ b/meta/recipes-devtools/gdb/gdb-cross-canadian.inc
@@ -14,7 +14,8 @@ GDBPROPREFIX = "--program-prefix='${TARGET_PREFIX}'"
 PACKAGECONFIG ??= "python readline"
 PACKAGECONFIG[python] = 
"--with-python=${WORKDIR}/python,--without-python,nativesdk-python3, \
  nativesdk-python3-core nativesdk-python3-lang 
nativesdk-python3-re \
- nativesdk-python3-codecs nativesdk-python3-netclient"
+ nativesdk-python3-codecs nativesdk-python3-netclient \
+ nativesdk-python3-importlib"
 PACKAGECONFIG[readline] = 
"--with-system-readline,--without-system-readline,nativesdk-readline"
 
 SSTATE_DUPWHITELIST += "${STAGING_DATADIR}/gdb"
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/3] python3-setuptools: Remove pth file creation at recipe level

[Jose Lamego]

Ping.

On 02/08/2017 04:31 PM, Jose Lamego wrote:
> Ping.
> 
> On 01/17/2017 09:42 AM, Jose Lamego wrote:
>> Handling of installed eggs is now performed at the distutils3 bbclass.
>>
>> This change removes the pth file creation at recipe level.
>>
>> [YOCTO #8673]
>>
>> Signed-off-by: Jose Lamego 
>> ---
>>  meta/recipes-devtools/python/python3-setuptools_31.0.0.bb | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb 
>> b/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
>> index 65af6f0..b37b381 100644
>> --- a/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
>> +++ b/meta/recipes-devtools/python/python3-setuptools_31.0.0.bb
>> @@ -7,11 +7,8 @@ inherit distutils3
>>  
>>  DISTUTILS_INSTALL_ARGS += "--install-lib=${D}${PYTHON_SITEPACKAGES_DIR}"
>>  
>> -# The installer puts the wrong path in the setuptools.pth file.  Correct it.
>>  do_install_append() {
>> -rm ${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
>>  mv ${D}${bindir}/easy_install ${D}${bindir}/easy3_install
>> -echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
>> ${D}${PYTHON_SITEPACKAGES_DIR}/setuptools.pth
>>  }
>>  
>>  RDEPENDS_${PN} = "\
>>
> 
> 
> 

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/3] python3-pip: Remove pth file creation at recipe level

[Jose Lamego]

Ping.

On 02/08/2017 04:31 PM, Jose Lamego wrote:
> Ping.
> 
> On 01/17/2017 09:42 AM, Jose Lamego wrote:
>> Handling of installed eggs is now performed at the distutils3 bbclass.
>>
>> This change removes the pth file creation at recipe level.
>>
>> [YOCTO #8673]
>>
>> Signed-off-by: Jose Lamego 
>> ---
>>  meta/recipes-devtools/python/python3-pip_9.0.1.bb | 3 ---
>>  1 file changed, 3 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/python/python3-pip_9.0.1.bb 
>> b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
>> index 6ac94bb..9dce107 100644
>> --- a/meta/recipes-devtools/python/python3-pip_9.0.1.bb
>> +++ b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
>> @@ -31,9 +31,6 @@ do_install_append() {
>>  
>>  # Install as pip3 and leave pip2 as default
>>  rm ${D}/${bindir}/pip
>> -
>> -# Installed eggs need to be passed directly to the interpreter via a 
>> pth file
>> -echo "./${SRCNAME}-${PV}-py${PYTHON_BASEVERSION}.egg" > 
>> ${D}${PYTHON_SITEPACKAGES_DIR}/${SRCNAME}-${PV}.pth
>>  }
>>  
>>  RDEPENDS_${PN} = "\
>>
> 
> 
> 

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] distutils3.bbclass: add egg files/directories to python path

[Jose Lamego]

Ping

On 02/08/2017 04:30 PM, Jose Lamego wrote:
> Ping.
> 
> On 01/17/2017 09:42 AM, Jose Lamego wrote:
>> Packages that use .egg files or directories for installation may
>> not be found when imported at the python3 interpreter.
>> .egg files/directories path must be included in a .pth file to
>> be appropriately included in python path.
>>
>> This change looks for .egg files/directories in sitepackages
>> and adds its path to a .pth file during package installation.
>> It ensures that any new package that uses .egg files/recipes
>> will be appropriately added to path by performing the check from
>> the distutils3 class.
>>
>> [YOCTO #8673]
>>
>> Signed-off-by: Jose Lamego 
>> ---
>>  meta/classes/distutils3.bbclass | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/meta/classes/distutils3.bbclass 
>> b/meta/classes/distutils3.bbclass
>> index a6720c5..f8e2e2e 100644
>> --- a/meta/classes/distutils3.bbclass
>> +++ b/meta/classes/distutils3.bbclass
>> @@ -68,6 +68,16 @@ distutils3_do_install() {
>>  mv -f ${D}${datadir}/share/* ${D}${datadir}/
>>  rmdir ${D}${datadir}/share
>>  fi
>> +
>> +# detect if .egg files/directories were created and add their
>> +# path to a .pth file
>> +SHORT_PN=$(echo "${PN}" | sed 's/${PYTHON_PN}-//g')
>> +if test -e ${D}${PYTHON_SITEPACKAGES_DIR}/${SHORT_PN}*.egg; then
>> +EGG_NAME=$(basename $(find ${D}${PYTHON_SITEPACKAGES_DIR}/ \
>> +-name ${SHORT_PN}\*.egg))
>> +echo "./${EGG_NAME}" > ${D}${PYTHON_SITEPACKAGES_DIR}/\
>> +${SHORT_PN}.pth
>> +fi
>>  }
>>  distutils3_do_install[vardepsexclude] = "MACHINE"
>>  
>>
> 
> 
> 

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



signature.asc
Description: OpenPGP digital signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] terminal: Use original PATH for terminals

[Khem Raj]

On Mon, Mar 13, 2017 at 2:41 AM, Richard Purdie
 wrote:
> Now that we filter out PATH to only the utilities we rely upon, the devshel
> terminal was broken since it can no longer find the terminals. Even if
> we fix that, the user couldn't access any of their commands within
> devshell which somewhat defeats its purpose.
>
> Add the original PATH back to the environment to restore that behaviour
> since this is more in line with user expectations and it wouldn't be possible
> (or desireable) to whitelist all the commands a user might want to use from
> the shell.
>

will this also mean that it will now, inject original PATH into builds done
using seashell ?

> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/terminal.bbclass | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
> index 62409c0..a27e10c 100644
> --- a/meta/classes/terminal.bbclass
> +++ b/meta/classes/terminal.bbclass
> @@ -66,6 +66,11 @@ def oe_terminal(command, title, d):
>  envdata.setVar(key, str(value))
>  envdata.setVarFlag(key, 'export', '1')
>
> +# Use original PATH as a fallback
> +path = d.getVar('PATH') + ":" + origbbenv.getVar('PATH')
> +os.environ['PATH'] = path
> +envdata.setVar('PATH', path)
> +
>  # A complex PS1 might need more escaping of chars.
>  # Lets not export PS1 instead.
>  envdata.delVar("PS1")
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] go: add native recipes for 1.8

[Khem Raj]

Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb  |  3 +++
 meta/recipes-devtools/go/go-native.inc   | 16 +---
 .../go/{go-native_1.4.bb => go-native_1.8.bb}|  1 +
 meta/recipes-devtools/go/go.inc  |  4 ++--
 4 files changed, 15 insertions(+), 9 deletions(-)
 create mode 100644 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
 rename meta/recipes-devtools/go/{go-native_1.4.bb => go-native_1.8.bb} (54%)

diff --git a/meta/recipes-devtools/go/go-bootstrap-native_1.4.bb 
b/meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
new file mode 100644
index 00..3d4141e879
--- /dev/null
+++ b/meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
@@ -0,0 +1,3 @@
+BOOTSTRAP = "1.4"
+require go-native.inc
+require go-${PV}.inc
diff --git a/meta/recipes-devtools/go/go-native.inc 
b/meta/recipes-devtools/go/go-native.inc
index 89bc63459d..c1ada5121a 100644
--- a/meta/recipes-devtools/go/go-native.inc
+++ b/meta/recipes-devtools/go/go-native.inc
@@ -1,8 +1,10 @@
 inherit native
 
+BOOTSTRAP ?= ""
 export GOOS = "${BUILD_GOOS}"
 export GOARCH = "${BUILD_GOARCH}"
-export GOROOT_FINAL = "${STAGING_LIBDIR_NATIVE}/go"
+export GOROOT_FINAL = "${STAGING_LIBDIR_NATIVE}/go${BOOTSTRAP}"
+export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go1.4"
 export CGO_ENABLED = "1"
 
 do_configure[noexec] = "1"
@@ -31,18 +33,18 @@ END
 }
 
 do_install() {
-   install -d ${D}${libdir}/go
-   cp -a ${B}/pkg ${D}${libdir}/go/
-   install -d ${D}${libdir}/go/src
+   install -d ${D}${libdir}/go${BOOTSTRAP}
+   cp -a ${B}/pkg ${D}${libdir}/go${BOOTSTRAP}/
+   install -d ${D}${libdir}/go${BOOTSTRAP}/src
(cd ${S}/src; for d in *; do \
-   [ -d $d ] && cp -a ${S}/src/$d ${D}${libdir}/go/src/; \
+   [ -d $d ] && cp -a ${S}/src/$d 
${D}${libdir}/go${BOOTSTRAP}/src/; \
done)
 
-   install -d ${D}${bindir} ${D}${libdir}/go/bin
+   install -d ${D}${bindir} ${D}${libdir}/go${BOOTSTRAP}/bin
for f in ${B}/bin/*
do
base=`basename $f`
-   install -m755 $f ${D}${libdir}/go/bin
+   install -m755 $f ${D}${libdir}/go${BOOTSTRAP}/bin
make_wrapper $base $base
done
 }
diff --git a/meta/recipes-devtools/go/go-native_1.4.bb 
b/meta/recipes-devtools/go/go-native_1.8.bb
similarity index 54%
rename from meta/recipes-devtools/go/go-native_1.4.bb
rename to meta/recipes-devtools/go/go-native_1.8.bb
index bbf3c0dd73..182fca27a0 100644
--- a/meta/recipes-devtools/go/go-native_1.4.bb
+++ b/meta/recipes-devtools/go/go-native_1.8.bb
@@ -1,2 +1,3 @@
 require ${PN}.inc
 require go-${PV}.inc
+DEPENDS += "go-bootstrap-native"
diff --git a/meta/recipes-devtools/go/go.inc b/meta/recipes-devtools/go/go.inc
index 1c94fc9c34..0b0cbf19ad 100644
--- a/meta/recipes-devtools/go/go.inc
+++ b/meta/recipes-devtools/go/go.inc
@@ -1,6 +1,6 @@
 inherit goarch
 # libgcc is required for the target specific libraries to build properly
-DEPENDS += " go-native libgcc"
+DEPENDS += "go-bootstrap-native libgcc"
 # Prevent runstrip from running because you get errors when the host arch != 
target arch
 INHIBIT_PACKAGE_STRIP = "1"
 INHIBIT_SYSROOT_STRIP = "1"
@@ -15,7 +15,7 @@ export GOHOSTARCH = "${BUILD_GOARCH}"
 export GOOS = "${TARGET_GOOS}"
 export GOARCH = "${TARGET_GOARCH}"
 export GOARM = "${TARGET_GOARM}"
-export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go"
+export GOROOT_BOOTSTRAP = "${STAGING_LIBDIR_NATIVE}/go1.4"
 export GOROOT_FINAL = "${libdir}/go"
 export CGO_ENABLED = "1"
 export CC_FOR_TARGET = "${CC}"
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] go: Enable on musl

[Khem Raj]

Working fine for musl targets now

Signed-off-by: Khem Raj 
---
 meta/classes/go.bbclass   | 2 --
 meta/recipes-devtools/go/go-cross.inc | 2 --
 meta/recipes-devtools/go/go.inc   | 2 --
 3 files changed, 6 deletions(-)

diff --git a/meta/classes/go.bbclass b/meta/classes/go.bbclass
index f1984604b0..42bbd73cf8 100644
--- a/meta/classes/go.bbclass
+++ b/meta/classes/go.bbclass
@@ -1,7 +1,5 @@
 inherit goarch
 
-# Incompatible with musl, at least for now
-COMPATIBLE_HOST_libc-musl_class-target = "null"
 # x32 ABI is not supported on go compiler so far
 COMPATIBLE_HOST_linux-gnux32 = "null"
 # ppc32 is not supported in go compilers
diff --git a/meta/recipes-devtools/go/go-cross.inc 
b/meta/recipes-devtools/go/go-cross.inc
index 054ce501bd..68f5efd6c0 100644
--- a/meta/recipes-devtools/go/go-cross.inc
+++ b/meta/recipes-devtools/go/go-cross.inc
@@ -9,8 +9,6 @@ FILESEXTRAPATHS =. "${FILE_DIRNAME}/go-cross:"
 GOROOT_FINAL = "${libdir}/go"
 export GOROOT_FINAL
 
-# Incompatible with musl, at least for now
-COMPATIBLE_HOST_libc-musl_class-target = "null"
 # x32 ABI is not supported on go compiler so far
 COMPATIBLE_HOST_linux-gnux32 = "null"
 # ppc32 is not supported in go compilers
diff --git a/meta/recipes-devtools/go/go.inc b/meta/recipes-devtools/go/go.inc
index 0c315afe06..1c94fc9c34 100644
--- a/meta/recipes-devtools/go/go.inc
+++ b/meta/recipes-devtools/go/go.inc
@@ -5,8 +5,6 @@ DEPENDS += " go-native libgcc"
 INHIBIT_PACKAGE_STRIP = "1"
 INHIBIT_SYSROOT_STRIP = "1"
 
-# Incompatible with musl, at least for now
-COMPATIBLE_HOST_libc-musl_class-target = "null"
 # x32 ABI is not supported on go compiler so far
 COMPATIBLE_HOST_linux-gnux32 = "null"
 # ppc32 is not supported in go compilers
-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] Enable go on musl and add native version for 1.8

[Khem Raj]

The following changes since commit 86b09a7ed67a43a45c805f44778bed0bfdf57361:

  u-boot: add option to specify FDT argument in extlinux.conf (2017-03-13 
09:43:08 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib kraj/go
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=kraj/go

Khem Raj (2):
  go: Enable on musl
  go: add native recipes for 1.8

 meta/classes/go.bbclass  |  2 --
 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb  |  3 +++
 meta/recipes-devtools/go/go-cross.inc|  2 --
 meta/recipes-devtools/go/go-native.inc   | 16 +---
 .../go/{go-native_1.4.bb => go-native_1.8.bb}|  1 +
 meta/recipes-devtools/go/go.inc  |  6 ++
 6 files changed, 15 insertions(+), 15 deletions(-)
 create mode 100644 meta/recipes-devtools/go/go-bootstrap-native_1.4.bb
 rename meta/recipes-devtools/go/{go-native_1.4.bb => go-native_1.8.bb} (54%)

-- 
2.12.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V4] go: Add recipes for golang compilers and tools

[Maciej Borzęcki]

On Mon, Mar 13, 2017 at 6:58 PM, Otavio Salvador
 wrote:
> On Fri, Mar 3, 2017 at 7:19 PM, Khem Raj  wrote:
>> * This is converging the recipes for go from
>>   meta-virtualization and oe-meta-go
>>
>> * Add recipes for go 1.7
>
> Go 1.8 is out so I believe we ought to move to it. Also one thing
> which need discussion is regarding the upgrade process of Go recipes.
> The 1.8 release is the last one supporting ARMv5 and this means some
> reference BSP won't work with Go 1.9 (QEMU ARM) without some hackery.
>

As usual in Go community, the things are in a state of flux. The final
decision about removing ARMv5 has not been reached yet. While the
original proposal was to deprecate ARMv5, members of community have
emerged, providing build systems and general argumentation in favor of
keeping this target supported (at least for the time being). Right
now, the discussion has evolved in the direction of figuring out a
general policy for deprecating legacy architectures. Still, there's no
guarantee that come 1.9 ARMv5E will be no more.

Interested parties can track the progress here:
https://github.com/golang/go/issues/17082 and here:
https://github.com/golang/go/issues/19075

-- 
Maciej Borzecki
RnDity
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V4] go: Add recipes for golang compilers and tools

[Otavio Salvador]

On Fri, Mar 3, 2017 at 7:19 PM, Khem Raj  wrote:
> * This is converging the recipes for go from
>   meta-virtualization and oe-meta-go
>
> * Add recipes for go 1.7

Go 1.8 is out so I believe we ought to move to it. Also one thing
which need discussion is regarding the upgrade process of Go recipes.
The 1.8 release is the last one supporting ARMv5 and this means some
reference BSP won't work with Go 1.9 (QEMU ARM) without some hackery.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] python*-git: Upgrade to version 2.1.3

[Jose Lamego]

Both python-git and python3-git need to be upgraded to latest
upstream
version.
This change was tested using qemux86 with core-image-sato.

Signed-off-by: Jose Lamego 
---
 meta/recipes-devtools/python/python-git.inc   | 4 ++--
 .../python/{python-git_2.1.1.bb => python-git_2.1.3.bb}   | 0
 .../python/{python3-git_2.1.1.bb => python3-git_2.1.3.bb} | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python-git_2.1.1.bb => 
python-git_2.1.3.bb} (100%)
 rename meta/recipes-devtools/python/{python3-git_2.1.1.bb => 
python3-git_2.1.3.bb} (100%)

diff --git a/meta/recipes-devtools/python/python-git.inc 
b/meta/recipes-devtools/python/python-git.inc
index feddf27..825e795d9 100644
--- a/meta/recipes-devtools/python/python-git.inc
+++ b/meta/recipes-devtools/python/python-git.inc
@@ -10,8 +10,8 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=8b8d26c37c1d5a04f9b0186edbebc183"
 
 SRC_URI = 
"https://files.pythonhosted.org/packages/source/G/GitPython/GitPython-${PV}.tar.gz;
 
-SRC_URI[md5sum] = "77f8339e68dedb6d7c4e26371a588ed9"
-SRC_URI[sha256sum] = 
"e96f8e953cf9fee0a7599fc587667591328760b6341a0081ef311a942fc96204"
+SRC_URI[md5sum] = "6cd18008c03a767740f3bf6d89ef79bc"
+SRC_URI[sha256sum] = 
"3826185b11e1fc372e7d31251e9b65e11ccb7c27f82c771d619048bdb5b66c81"
 
 UPSTREAM_CHECK_URI = "https://pypi.python.org/pypi/GitPython/;
 UPSTREAM_CHECK_REGEX = "/GitPython/(?P(\d+[\.\-_]*)+)"
diff --git a/meta/recipes-devtools/python/python-git_2.1.1.bb 
b/meta/recipes-devtools/python/python-git_2.1.3.bb
similarity index 100%
rename from meta/recipes-devtools/python/python-git_2.1.1.bb
rename to meta/recipes-devtools/python/python-git_2.1.3.bb
diff --git a/meta/recipes-devtools/python/python3-git_2.1.1.bb 
b/meta/recipes-devtools/python/python3-git_2.1.3.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-git_2.1.1.bb
rename to meta/recipes-devtools/python/python3-git_2.1.3.bb
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

[Mark Hatle]

On 3/13/17 11:11 AM, Peter Kjellerstedt wrote:
>> -Original Message-
>> From: Mark Hatle [mailto:mark.ha...@windriver.com]
>> Sent: den 13 mars 2017 14:56
>> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
>> recipes specifying static IDs
>>
>> On 3/10/17 11:27 PM, Peter Kjellerstedt wrote:
>>> If this bblcass is used and a recipe specifies a static ID for a
>>> user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN},
>>> the build would fail with and error like this if there was no
>>> corresponding ID in the passwd/group files specified via
>>> USERADD_UID_TABLES/USERADD_GID_TABLES:
>>
>> If the system is set in warning mode, it should warn if this is done
>> (but allow it).
>>
>> If the system is set to error mode, it should error.
>>
>> The useradd-staticids class is expecting the files (tables) to contain
>> all of the entries.  This is specifically to avoid the situation where 
>> a new recipe is introduced that adds a new user or group (dynamic or 
>> static -- static because it could conflict with one of your existing 
>> static entries.)
> 
> AFAICT, even before my rewrite of much of this code in 3149319a and 
> subsequent correction in adc0f830, if a static ID was specified as part 
> of USERADD_PARAM_${PN} then no error would be issued. However, we can 
> certainly change the code to always fail/warn if no ID is specified 
> in any of the passwd/groups files. It should just be a matter of 
> removing the if statements preceding the calls to handle_missing_id() 
> below. (I will do some verification and send an updated patch tomorrow 
> if this is the way the class should work.)

The intention was always that the uname/gname had to be specified in the useradd
tables in some way, or a warning/error would occur.

If the fields were blank in the tables, the system would use the versions
located in the recipe -- otherwise it would use the version in the table.  (At
one point, but I don't think this was ever pushed in -- if a static ID was set
in the recipe, there was a verification that the static version in both the
recipe and the table files was the same -- otherwise it could indicate the
package may not be built properly.)

>> I agree the error message below looks wrong, do the existing warning/
>> error messages about it not being defined int he useradd tables still 
>> occur with this patch?
> 
> The error message below occurred because before my fix it forgot all 
> the parameters that were specified in USERADD_PARAM_${PN} when it took 
> the continue.

Ok, we need to fix that bug first then.

We should then verify the second issue and fix it in a subsequent commit.  The
key being that of the user/group was not in the table we warn them (or error) --
preventing unexpected users from showing up.

The check both static IDs are the same could very well be a TODO item (that is
never done) -- but something that should be considered.

Thanks!
--Mark

>> --Mark
>>
>>>   ERROR: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb:
>>>   meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb inherits
>>>   useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or
>>>   GROUPMEMS_PARAM for package postgresql
>>>
>>> Signed-off-by: Peter Kjellerstedt 
>>> ---
>>>  meta/classes/useradd-staticids.bbclass | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/classes/useradd-staticids.bbclass
>> b/meta/classes/useradd-staticids.bbclass
>>> index a65c3f69cb..9b194df490 100644
>>> --- a/meta/classes/useradd-staticids.bbclass
>>> +++ b/meta/classes/useradd-staticids.bbclass
>>> @@ -125,6 +125,7 @@ def update_useradd_static_config(d):
>>>  if uaargs.LOGIN not in users:
>>>  if not uaargs.uid or not uaargs.uid.isdigit() or not 
>>> uaargs.gid:
>>>  handle_missing_id(uaargs.LOGIN, 'user', pkg)
>>> +newparams.append(param)
>>>  continue
>>>
>>>  field = users[uaargs.LOGIN]
>>> @@ -260,6 +261,7 @@ def update_useradd_static_config(d):
>>>  if gaargs.GROUP not in groups:
>>>  if not gaargs.gid or not gaargs.gid.isdigit():
>>>  handle_missing_id(gaargs.GROUP, 'group', pkg)
>>> +newparams.append(param)
>>>  continue
>>>
>>>  field = groups[gaargs.GROUP]
>>>
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] gzip: add ptest

[Denys Zagorui]

'zless' don't work with less from busybox. In this case test 'help-version'
fails. First of all 'zless' tries to figure out version of 'less' launching
'less -V', 'less' from busybox don't understand key -V. So 'zless' needs
to be fixed so that it can use 'less' from busybox.

'zdiff' test fixed so that it can use 'diff' from busybox
('diff' from busybox and 'diff' from diffutils has different output)

Signed-off-by: Denys Zagorui 
---
 ...zdiff-add-diff-from-busybox-compatibility.patch | 40 ++
 meta/recipes-extended/gzip/files/run-ptest |  6 
 meta/recipes-extended/gzip/gzip_1.8.bb | 19 +-
 3 files changed, 64 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/gzip/files/0001-tests-zdiff-add-diff-from-busybox-compatibility.patch
 create mode 100644 meta/recipes-extended/gzip/files/run-ptest

diff --git 
a/meta/recipes-extended/gzip/files/0001-tests-zdiff-add-diff-from-busybox-compatibility.patch
 
b/meta/recipes-extended/gzip/files/0001-tests-zdiff-add-diff-from-busybox-compatibility.patch
new file mode 100644
index 000..e64bf82
--- /dev/null
+++ 
b/meta/recipes-extended/gzip/files/0001-tests-zdiff-add-diff-from-busybox-compatibility.patch
@@ -0,0 +1,40 @@
+From 93673d1bc2af38dec512b05bc6d9262c6b45b5ad Mon Sep 17 00:00:00 2001
+From: Denys Zagorui 
+Date: Fri, 10 Mar 2017 22:59:48 +0200
+Subject: [PATCH] tests/zdiff: add diff from busybox compatibility.
+
+Diff from busybox has another output than diff from diffutils
+
+Signed-off-by: Denys Zagorui 
+Upstream-Status: Pending
+---
+ tests/zdiff | 13 +++--
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/tests/zdiff b/tests/zdiff
+index 7ed2f34..2567d1a 100755
+--- a/tests/zdiff
 b/tests/zdiff
+@@ -24,12 +24,13 @@ echo a > a || framework_failure_
+ echo b > b || framework_failure_
+ gzip a b || framework_failure_
+
+-cat < exp
+-1c1
+-< a
+
+-> b
+-EOF
++diff -v 2>&1 > /dev/null | grep BusyBox
++
++if [ $? == 0 ];then
++echo -e '--- /dev/fd/5\n+++ -\n@@ -1 +1 @@\n-a\n+b' > exp
++else
++echo -e '1c1\n< a\n---\n> b' >exp
++fi
+
+ fail=0
+ returns_ 1 zdiff a.gz b.gz > out 2>&1 || fail=1
+--
+1.9.1
+
diff --git a/meta/recipes-extended/gzip/files/run-ptest 
b/meta/recipes-extended/gzip/files/run-ptest
new file mode 100644
index 000..cf7c649
--- /dev/null
+++ b/meta/recipes-extended/gzip/files/run-ptest
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+cd src/tests
+
+make check
+
diff --git a/meta/recipes-extended/gzip/gzip_1.8.bb 
b/meta/recipes-extended/gzip/gzip_1.8.bb
index 11be846..a4a39a6 100644
--- a/meta/recipes-extended/gzip/gzip_1.8.bb
+++ b/meta/recipes-extended/gzip/gzip_1.8.bb
@@ -2,7 +2,9 @@ require gzip.inc
 
 LICENSE = "GPLv3+"
 
-SRC_URI = "${GNU_MIRROR}/gzip/${BP}.tar.gz"
+SRC_URI = "${GNU_MIRROR}/gzip/${BP}.tar.gz \
+file://0001-tests-zdiff-add-diff-from-busybox-compatibility.patch \
+file://run-ptest"
 SRC_URI_append_class-target = " file://wrong-path-fix.patch"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
@@ -12,6 +14,21 @@ PROVIDES_append_class-native = " gzip-replacement-native"
 
 BBCLASSEXTEND = "native"
 
+inherit ptest
+
+do_install_ptest() {
+   mkdir -p ${D}${PTEST_PATH}/src/build-aux
+   cp ${S}/build-aux/test-driver ${D}${PTEST_PATH}/src/build-aux/
+   mkdir -p ${D}${PTEST_PATH}/src/tests
+   cp -r ${S}/tests/* ${D}${PTEST_PATH}/src/tests
+   sed -e 's/^abs_srcdir = ..*/abs_srcdir = \.\./' \
+-e 's/^top_srcdir = ..*/top_srcdir = \.\./' \
+-e 's/^AWK = ..*/AWK = awk/'\
+-e 's/^srcdir = ..*/srcdir = \./'   \
+-e 's/^Makefile: ..*/Makefile: /'   \
+${B}/tests/Makefile > ${D}${PTEST_PATH}/src/tests/Makefile
+}
+
 SRC_URI[md5sum] = "732553152814b22dc35aa0267df5286c"
 SRC_URI[sha256sum] = 
"1ff7aedb3d66a0d73f442f6261e4b3860df6fd6c94025c2cb31a202c9c60fe0e"
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Create more than one image with WIC

[Daniel Schultz]

Am 08.03.2017 um 14:43 schrieb Ed Bartosh:

On Wed, Mar 08, 2017 at 02:41:10PM +0100, Gary Thomas wrote:

On 2017-03-08 11:57, Ed Bartosh wrote:

On Wed, Mar 08, 2017 at 10:44:21AM +0100, Daniel Schultz wrote:

Hi,

I created two kickstart files (am335x-sdimage.wks, am335x-emmc.wks)
and added them to the local.conf.

When I build the image only the first wks in WKS_FILES will be used
by WIC and the second will be ignored. Is it possible to build two
images in one build?



I don't think it's possible to build more than one image for the same
type. wic is not an exception here.


Includes of the wks files in local.conf:
WKS_FILES_ti33x = "am335x-sdimage.wks am335x-emmc.wks "


WKS_FILES variable is to provide possible wks files to use. First one found will
be used to produce an image.


Would it work to add/define this variable in the corresponding *image*.bb recipe
rather than local.conf?


Yes, it would if image recipe is unique, i.e. images of the same type
can be produced for different recipes.

But isn't wic different to other images like e.g. ext? I agree that 
there are other images that need only build once, but wic images can 
contain these and therefore act as a wrapper.


Do I have misunderstood the design of wic?

I mean MMC and EMMC are very similar, but different in the bootloader 
and it would be a overhead to create an extra image for all EMMC images.


--
Mit freundlichen Grüßen,
With best regards,
  Daniel Schultz


WKS_FILES makes sense to set only if there are multiple wks files that
can be used to produce an image. The most obvious use case is using
multiple layers with different wks files in each and specifying all of
them in WKS_FILES.

If this is not the case then setting WKS_FILE is enough.

--
Regards,
Ed




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

[Peter Kjellerstedt]

> -Original Message-
> From: Mark Hatle [mailto:mark.ha...@windriver.com]
> Sent: den 13 mars 2017 14:56
> To: Peter Kjellerstedt; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support
> recipes specifying static IDs
> 
> On 3/10/17 11:27 PM, Peter Kjellerstedt wrote:
> > If this bblcass is used and a recipe specifies a static ID for a
> > user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN},
> > the build would fail with and error like this if there was no
> > corresponding ID in the passwd/group files specified via
> > USERADD_UID_TABLES/USERADD_GID_TABLES:
> 
> If the system is set in warning mode, it should warn if this is done
> (but allow it).
> 
> If the system is set to error mode, it should error.
> 
> The useradd-staticids class is expecting the files (tables) to contain
> all of the entries.  This is specifically to avoid the situation where 
> a new recipe is introduced that adds a new user or group (dynamic or 
> static -- static because it could conflict with one of your existing 
> static entries.)

AFAICT, even before my rewrite of much of this code in 3149319a and 
subsequent correction in adc0f830, if a static ID was specified as part 
of USERADD_PARAM_${PN} then no error would be issued. However, we can 
certainly change the code to always fail/warn if no ID is specified 
in any of the passwd/groups files. It should just be a matter of 
removing the if statements preceding the calls to handle_missing_id() 
below. (I will do some verification and send an updated patch tomorrow 
if this is the way the class should work.)

> I agree the error message below looks wrong, do the existing warning/
> error messages about it not being defined int he useradd tables still 
> occur with this patch?

The error message below occurred because before my fix it forgot all 
the parameters that were specified in USERADD_PARAM_${PN} when it took 
the continue.

> --Mark
> 
> >   ERROR: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb:
> >   meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb inherits
> >   useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or
> >   GROUPMEMS_PARAM for package postgresql
> >
> > Signed-off-by: Peter Kjellerstedt 
> > ---
> >  meta/classes/useradd-staticids.bbclass | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/classes/useradd-staticids.bbclass
> b/meta/classes/useradd-staticids.bbclass
> > index a65c3f69cb..9b194df490 100644
> > --- a/meta/classes/useradd-staticids.bbclass
> > +++ b/meta/classes/useradd-staticids.bbclass
> > @@ -125,6 +125,7 @@ def update_useradd_static_config(d):
> >  if uaargs.LOGIN not in users:
> >  if not uaargs.uid or not uaargs.uid.isdigit() or not 
> > uaargs.gid:
> >  handle_missing_id(uaargs.LOGIN, 'user', pkg)
> > +newparams.append(param)
> >  continue
> >
> >  field = users[uaargs.LOGIN]
> > @@ -260,6 +261,7 @@ def update_useradd_static_config(d):
> >  if gaargs.GROUP not in groups:
> >  if not gaargs.gid or not gaargs.gid.isdigit():
> >  handle_missing_id(gaargs.GROUP, 'group', pkg)
> > +newparams.append(param)
> >  continue
> >
> >  field = groups[gaargs.GROUP]
> >

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/44] rootfs_rpm.bbclass: migrate image creation to dnf

[Alexander Kanavin]

On 03/13/2017 05:04 PM, Alexander Kanavin wrote:


Forgot to add - I'll try to fix both of these this week, with
corresponding tests of course.


Oh, and: Markus Lehtonen is looking into package feed signing, which is 
a separate thing from rpm signing. Also Fedora does not sign their 
feeds, and so the feature has apparently bitrotted somewhat and will be 
more difficult to get working.


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/44] rootfs_rpm.bbclass: migrate image creation to dnf

[Alexander Kanavin]

On 03/13/2017 04:52 PM, Alexander Kanavin wrote:

On 03/13/2017 04:25 PM, Burton, Ross wrote:



+raise NotImplementedError("Adding remote dnf feeds not yet
supported.")


I think this is a 2.4M4 blocker if the series merges into M3.


Yes. There is no runtime/selftest test for this, and I didn't want to
implement things that are not enabled by default and cannot be
automatically tested. I don't want to take the risk of unnoticed
regressions in code that was tested only once when it was initially
written.

Creating an image from signed rpms is currently not supported for the
same reason (but signing rpms in the first place *is* supported, because
it actually is tested in oe-selftest, and I can use that to verify that
it works and keeps working).


Forgot to add - I'll try to fix both of these this week, with 
corresponding tests of course.


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW11’17

[Jolley, Stephen K]

Current Dev Position: YP 2.3 M3

Next Deadline: YP 2.3 M3 by Feb. 27, 2017


*** FEATURE FREEZE for 2.3 is now in effect. ***


SWAT team rotation: Tracy -> Alejandro on Mar. 11, 2017.

SWAT team rotation: Alejandro -> Jussi on Mar. 18, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·The focus for the past week has been patch merging. Details follow but 
the plan is to build M3 early this week. We’ve focused on getting the right 
pieces in rather than forcing to specific date deadlines.

·Of particular note is a late change to filter out the contents of PATH 
and symlink only to utilities in a specific whitelist. There was a real risk 
that had we not done this, the project’s reputation on determinism and 
reproducibility would have been damaged. This change may cause some pain for 
people as we make sure the dependency metadata is correct but I believe the 
longer term benefit is worth it, as is ensuring we have a reputation for 
deterministic and reproducible builds.

·The GPLv2 recipes where the upstream had switched to GPLv3 licenses 
have been separated out into a separate layer: 
http://git.yoctoproject.org/cgit.cgi/meta-gplv2

·The go patches have also merged. There may be need of subsequent fixes 
from some of the other layers and I’d like to see some better automated tests 
but this provides a starting point to work around.

·The multilib issues with the smart -> dnf transition have been 
resolved. Given that and that M3 hasn’t built yet, I’m now thinking we should 
take this change (and the corresponding rpm v5 -> v4) since I prefer that and 
potentially taking slightly longer in M4 rather than delaying the switch six 
months.

·The smart/dnf question is the one real remaining decision to be made 
about M3 and the build will commence after that is made. We’ve test built with 
and without the patchset with green builds.

·Since we’re into the stabilization phase of 2.3, planning for 2.4 will 
be beginning soon and we’re starting to plan out 2.4 in the bugzilla. If you 
have suggestions for 2.4, please ensure they are in bugzilla.


Proposed upcoming dot releases:

YP 2.1.3 Cut off May 15, 2017

YP 2.1.3 Release by May 26, 2017

YP 2.2.2 Cut off May 29, 2017

YP 2.2.2 Release by June 9, 2017


Key YP 2.3 Dates:

YP 2.3 M3 Release is Mar. 10, 2017 (Will be a few weeks late.)

YP 2.3 M4 Cutoff is April 10, 2017

YP 2.3 M4 Release is May 5, 2017


Tracking Metrics:

WDD 2715 (last week 2737)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.3_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.3_Features

[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]

Thanks,

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

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/44] rootfs_rpm.bbclass: migrate image creation to dnf

[Alexander Kanavin]

On 03/13/2017 04:25 PM, Burton, Ross wrote:



+raise NotImplementedError("Adding remote dnf feeds not yet
supported.")


I think this is a 2.4M4 blocker if the series merges into M3.


Yes. There is no runtime/selftest test for this, and I didn't want to 
implement things that are not enabled by default and cannot be 
automatically tested. I don't want to take the risk of unnoticed 
regressions in code that was tested only once when it was initially written.


Creating an image from signed rpms is currently not supported for the 
same reason (but signing rpms in the first place *is* supported, because 
it actually is tested in oe-selftest, and I can use that to verify that 
it works and keeps working).



Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 41/44] bash: package bashbug separately

[Alexander Kanavin]

On 03/10/2017 07:13 PM, Mark Hatle wrote:

On 3/10/17 5:24 AM, Alexander Kanavin wrote:

It's a machine-specific script, which is causing conflicts
when multiple versions of bash are installed in multilib setting,
and it also does not really make sense for embedded systems anyway.


Out of curiosity what is machine specific here?


--- 
./tmp/work/x86_64-pokymllib64-linux/lib64-bash/4.3.30-r0/packages-split/lib64-bash-bashbug/usr/bin/bashbug 
2017-03-09 16:10:27.0 +0200
+++ 
./tmp/work/i586-poky-linux/bash/4.3.30-r0/packages-split/bash-bashbug/usr/bin/bashbug 
2017-03-09 16:03:49.0 +0200

@@ -26,14 +26,14 @@
 # configuration section:
 #  these variables are filled in by the make target in Makefile
 #
-MACHINE="x86_64"
+MACHINE="i586"
 OS="linux-gnu"
-CC="x86_64-pokymllib64-linux-gcc  -m64 "
-CFLAGS=" -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pokymllib64-linux-gnu' 
-DCONF_VENDOR='pokymllib64' -DLOCALEDIR='/usr/share/locale' 
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I../bash-4.3.30 
-I../bash-4.3.30/include -I../bash-4.3.30/lib   -O2 -pipe -g 
-feliminate-unused-debug-types 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-bash/4.3.30-r0=/usr/src/debug/lib64-bash/4.3.30-r0 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-bash/4.3.30-r0/recipe-sysroot-native= 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-bash/4.3.30-r0/lib64-recipe-sysroot= 
 -DNON_INTERACTIVE_LOGIN_SHELLS"

+CC="i586-poky-linux-gcc  -m32 -march=i586 "
+CFLAGS=" -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-poky-linux-gnu' 
-DCONF_VENDOR='poky' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash-4.3.30 -I../bash-4.3.30/include 
-I../bash-4.3.30/lib   -O2 -pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/i586-poky-linux/bash/4.3.30-r0=/usr/src/debug/bash/4.3.30-r0 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/i586-poky-linux/bash/4.3.30-r0/recipe-sysroot-native= 
-fdebug-prefix-map=/home/ak/development/poky/build-multilib/tmp/work/i586-poky-linux/bash/4.3.30-r0/recipe-sysroot= 
 -DNON_INTERACTIVE_LOGIN_SHELLS"

 RELEASE="4.3"
 PATCHLEVEL="46"
 RELSTATUS="release"
-MACHTYPE="x86_64-pokymllib64-linux-gnu"
+MACHTYPE="i586-poky-linux-gnu"

 PATH=/bin:/usr/bin:/usr/local/bin:$PATH
 export PATH


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 38/44] package_rpm.bbclass: do not strip multilib prefixes from package names, do not add multilib prefix to package arch

[Alexander Kanavin]

On 03/10/2017 07:04 PM, Mark Hatle wrote:

On 3/10/17 5:24 AM, Alexander Kanavin wrote:

This is done for reasons I cannot establish, and greatly complicates the code
that installs packages into rootfs.


RPM internally resolves ELF dependencies through a resolution system.

If you look at a typical Fedora, SuSe, etc system you will often see:

glibc-x.y.i386.rpm
glibc-x.y.x86-64.rpm

When a package asks for 'glibc', the system will go out and match the one for
the arch that is being requested.


I don't know the core reason for it, but it actually does not happen, 
and I saw it firsthand. When a package needs a library, the resolver 
will pick the library package with the architecture that has the higher 
priority in the list of architectures, not the architecture that would 
match the package correctly.



When using smart, there seems to be a similar issue:

# Pull in multilib requires since rpm may not pull in them
# correctly, for example,
# lib32-packagegroup-core-standalone-sdk-target requires
# lib32-libc6, but rpm may pull in libc6 rather than lib32-libc6
# since it doesn't know mlprefix (lib32-), bitbake knows it and
# can handle it well, find out the RDEPENDS on the chain will
# fix the problem. Both do_rootfs and do_populate_sdk have this
# issue.
# The attempt_only packages don't need this since they are
# based on the installed ones.
#
# Separate pkgs into two lists, one is multilib, the other one
# is non-multilib.

... which is then followed by the most hackish, impementrable code that 
recursively walks RDEPENDS and massages that into a list that is given 
to smart, effectively subverting smart's own dependency resolution. I do 
not want to carry this into rpm4/dnf (or even spend time understanding 
it), and so I dropped both the multilib prefix stripping, and the code 
that works around it.


By the way, I don't know about Fedora, but SuSE does use -32bit suffixes 
in package names.



Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/44] package_rpm.bbclass: do not set the OS dynamically when building rpms

[Mark Hatle]

On 3/13/17 9:24 AM, Alexander Kanavin wrote:
> On 03/10/2017 06:57 PM, Mark Hatle wrote:
>> On 3/10/17 5:24 AM, Alexander Kanavin wrote:
>>> Packages need to contain just one value for the os field, otherwise
>>> rpm will refuse to install them if they don't match what is in
>>> /etc/rpm/platform.
>>
>> How will this work with nativesdk for things like targeting mingw (windows),
>> darwin, or even alternative OS like Zephyr?
>>
>> I'm thinking if 'linux-gnu' is invalid, then a simple conversion to 'linux'
>> would be better then hard coding everything to 'linux'.
> 
> I don't believe that the OS name embedded into packages is actually used 
> anywhere to make decisions about which package to install. It's just 
> that some packages have one value for it, others have another, and rpm 4 
> does not allow that (rpm 5 does, and so several OS values gets written 
> into /etc). So I bring them all to a common value.

In the past there was both a (Smart/YUM/DNF) and RPM check for OS to prevent
packages for one OS to be installed onto another OS.

While out mingw SDK does not contain RPM (not IMHO should it ever), I'd hate to
accidentally try to install one of the mingw packages onto a Linux system.

Darwin (OS X) as well.

This is likely something we need to look into and understand.

--Mark

> Alex
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 34/44] package_rpm.bbclass: add a /bin/sh Provides for nativesdk- packages

[Mark Hatle]

On 3/13/17 9:21 AM, Alexander Kanavin wrote:
> On 03/10/2017 06:54 PM, Mark Hatle wrote:
>> On 3/10/17 5:24 AM, Alexander Kanavin wrote:
>>> nativesdk-* rpm packages all require /bin/sh because postinst scriptlets
>>> are run with it. We can either teach rpm4 and dnf to ignore that dependency
>>> (a lot of non-upstreamable work), or add auto-satisfy the dependency
>>> in each package. I've chosen to do the latter.
> 
>>>  print_deps(srcrrecommends, "Recommends", spec_preamble_top, d)
>>>  print_deps(srcrsuggests, "Suggests", spec_preamble_top, d)
>>> -print_deps(srcrprovides, "Provides", spec_preamble_top, d)
>>> +print_deps(srcrprovides + (" /bin/sh" if 
>>> srcname.startswith("nativesdk-") else ""), "Provides", spec_preamble_top, d)
>>>  print_deps(srcrobsoletes, "Obsoletes", spec_preamble_top, d)
>>
>> I'm confused as to what this is doing...   I see this is only affecting the
>> virtual 'src package' (or the one built for archiving?)..
> 
> The variable name is misleading. That line up there is printing the 
> Provides list into the top section of the .spec file which is then given 
> to rpm so it can create binary packages.
> 
>> But providing /bin/sh as any type of provide seems wrong.  Either --nodeps to
>> the rpmbuild or there should be a configuration file that the (host/cross) 
>> rpm
>> can use to say "yes I really just have /bin/sh.
> 
>> (rpm5 has a single file you could put arbitrary file provides into, at one 
>> point
>> rpm4 did as well -- but I don't know if it's still there.)
> 
> I checked - rpm 4 does not have that feature now, or I couldn't find it.

We may need to add this feature.  It really is useful to deal with situations
like this.

>> Doing this runs the risk of someone asking for '/bin/sh' and getting a source
>> package (a random one) as part of their build process using the DNF sources
>> option and such.  Definitely not what is expected.
> 
> This only affects nativesdk- packages, which are well isolated from all 
> other packages during installation time. I haven't seen any issues with 
> it either in my local testing or in the autobuilder run. If it pops up 
> somehow, we can do more to isolate the package sets.
> 

Thank you.  I understand now.

--Mark

> Alex
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 36/44] package_rpm.bbclass: do not set the OS dynamically when building rpms

[Alexander Kanavin]

On 03/10/2017 06:57 PM, Mark Hatle wrote:

On 3/10/17 5:24 AM, Alexander Kanavin wrote:

Packages need to contain just one value for the os field, otherwise
rpm will refuse to install them if they don't match what is in
/etc/rpm/platform.


How will this work with nativesdk for things like targeting mingw (windows),
darwin, or even alternative OS like Zephyr?

I'm thinking if 'linux-gnu' is invalid, then a simple conversion to 'linux'
would be better then hard coding everything to 'linux'.


I don't believe that the OS name embedded into packages is actually used 
anywhere to make decisions about which package to install. It's just 
that some packages have one value for it, others have another, and rpm 4 
does not allow that (rpm 5 does, and so several OS values gets written 
into /etc). So I bring them all to a common value.


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 21/44] rootfs_rpm.bbclass: migrate image creation to dnf

[Burton, Ross]

On 10 March 2017 at 11:24, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> +raise NotImplementedError("Adding remote dnf feeds not yet
> supported.")
>

I think this is a 2.4M4 blocker if the series merges into M3.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 34/44] package_rpm.bbclass: add a /bin/sh Provides for nativesdk- packages

[Alexander Kanavin]

On 03/10/2017 06:54 PM, Mark Hatle wrote:

On 3/10/17 5:24 AM, Alexander Kanavin wrote:

nativesdk-* rpm packages all require /bin/sh because postinst scriptlets
are run with it. We can either teach rpm4 and dnf to ignore that dependency
(a lot of non-upstreamable work), or add auto-satisfy the dependency
in each package. I've chosen to do the latter.



 print_deps(srcrrecommends, "Recommends", spec_preamble_top, d)
 print_deps(srcrsuggests, "Suggests", spec_preamble_top, d)
-print_deps(srcrprovides, "Provides", spec_preamble_top, d)
+print_deps(srcrprovides + (" /bin/sh" if srcname.startswith("nativesdk-") else ""), 
"Provides", spec_preamble_top, d)
 print_deps(srcrobsoletes, "Obsoletes", spec_preamble_top, d)


I'm confused as to what this is doing...   I see this is only affecting the
virtual 'src package' (or the one built for archiving?)..


The variable name is misleading. That line up there is printing the 
Provides list into the top section of the .spec file which is then given 
to rpm so it can create binary packages.



But providing /bin/sh as any type of provide seems wrong.  Either --nodeps to
the rpmbuild or there should be a configuration file that the (host/cross) rpm
can use to say "yes I really just have /bin/sh.



(rpm5 has a single file you could put arbitrary file provides into, at one point
rpm4 did as well -- but I don't know if it's still there.)


I checked - rpm 4 does not have that feature now, or I couldn't find it.


Doing this runs the risk of someone asking for '/bin/sh' and getting a source
package (a random one) as part of their build process using the DNF sources
option and such.  Definitely not what is expected.


This only affects nativesdk- packages, which are well isolated from all 
other packages during installation time. I haven't seen any issues with 
it either in my local testing or in the autobuilder run. If it pops up 
somehow, we can do more to isolate the package sets.



Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 30/44] byacc: remove the recipe

[Mark Hatle]

On 3/13/17 8:18 AM, Alexander Kanavin wrote:
> On 03/10/2017 06:37 PM, Mark Hatle wrote:
>> byacc, until recently, was required by the LSB / LSB Test Suite.
>>
>> So I'd rather is be kept in oe-core through the 2.3 release.
> 
> I couldn't find it in the LSB 5 standard. Is it something from earlier 
> versions?

It is in the instructions for the LSB Test Suite.  Byacc was required until
fairly recently.  From what I've found it was needed up until about September of
last year.  (There may be people doing CGL certification and such that still
need to use older versions of the LSB Test Suite for the time being.)

I have no objections (at this time) to remove it in 2.4, but I think it's too
later in 2.3 to remove/move it on someone.

--Mark

> Alex
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] how does files/fs-perms.txt affect building base-files rpm?

[Mark Hatle]

On 3/11/17 3:57 AM, Robert P. J. Day wrote:
> On Sat, 11 Mar 2017, Khem Raj wrote:
> 
>> On 3/11/17 12:30 AM, Robert P. J. Day wrote:
>>>
>>>   potentially a dumb question, but do the settings in
>>> files/fs-perms.txt affect the building of the base-files rpm just
>>> as they would affect the building of any other rpm?
>>
>> it should be executing fixup_perms() in PKGD before splitting the
>> package, so yes it should run for all recipes.
> 
>   so it is possible that, despite the manual settings in the
> base-files do_install() task, fs-perms.txt might override some of
> those settings. i'm not saying i've seen anything like that, just
> clarifying the possibility.

Yes, same for all packages.

At one point I thought there was a comment in both the base-files and
fs-perms.txt files reminding people they should be kept in sync.  I am not
finding that comment.

--Mark

> rday
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] useradd-staticids.bbclass: Support recipes specifying static IDs

[Mark Hatle]

On 3/10/17 11:27 PM, Peter Kjellerstedt wrote:
> If this bblcass is used and a recipe specifies a static ID for a
> user/group as part of the USERADD_PARAM_${PN} or GROUPADD_PARAM_${PN},
> the build would fail with and error like this if there was no
> corresponding ID in the passwd/group files specified via
> USERADD_UID_TABLES/USERADD_GID_TABLES:

If the system is set in warning mode, it should warn if this is done (but allow 
it).

If the system is set to error mode, it should error.

The useradd-staticids class is expecting the files (tables) to contain all of
the entries.  This is specifically to avoid the situation where a new recipe is
introduced that adds a new user or group (dynamic or static -- static because it
could conflict with one of your existing static entries.)

I agree the error message below looks wrong, do the existing warning/error
messages about it not being defined int he useradd tables still occur with this
patch?

--Mark

>   ERROR: meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb:
>   meta-oe/recipes-support/postgresql/postgresql_9.4.11.bb inherits
>   useradd but doesn't set USERADD_PARAM, GROUPADD_PARAM or
>   GROUPMEMS_PARAM for package postgresql
> 
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/classes/useradd-staticids.bbclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/classes/useradd-staticids.bbclass 
> b/meta/classes/useradd-staticids.bbclass
> index a65c3f69cb..9b194df490 100644
> --- a/meta/classes/useradd-staticids.bbclass
> +++ b/meta/classes/useradd-staticids.bbclass
> @@ -125,6 +125,7 @@ def update_useradd_static_config(d):
>  if uaargs.LOGIN not in users:
>  if not uaargs.uid or not uaargs.uid.isdigit() or not 
> uaargs.gid:
>  handle_missing_id(uaargs.LOGIN, 'user', pkg)
> +newparams.append(param)
>  continue
>  
>  field = users[uaargs.LOGIN]
> @@ -260,6 +261,7 @@ def update_useradd_static_config(d):
>  if gaargs.GROUP not in groups:
>  if not gaargs.gid or not gaargs.gid.isdigit():
>  handle_missing_id(gaargs.GROUP, 'group', pkg)
> +newparams.append(param)
>  continue
>  
>  field = groups[gaargs.GROUP]
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

On Monday 13 March 2017 at 13:33:27 +, Burton, Ross wrote:
> On 11 March 2017 at 16:54, Mike Crowe  wrote:
> 
> > ccache apparently does this so that paths in the debug information will
> > always be correct. In an OE world these paths may already be missing or
> > incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> > seem as if we're losing much by disabling this feature.
> >
> 
> In an OE world we tell GCC to rewrite them to be target paths anyway, so
> this isn't a problem.  Maybe worth rewriting the commit message?
> 
> (see bitbake.conf, -fdebug-prefix-map)

I wasn't aware of that.

ccache does have some technology to detect this situation:

  Exception: The CWD will not be included in the hash if *base_dir* is set
  (and matches the CWD) and the compiler option *-fdebug-prefix-map* is
  used.

I think this means that if CCACHE_BASEDIR is set appropriately then it
wouldn't be necessary to set CCACHE_NOHASHDIR. (Looking at the ccache code,
I think that "matches the CWD" means "CWD is under *base_dir*" rather than
the two needing to be identical.)

I shall investigate why things weren't working correctly for us. In the
meantime I don't think my patch is yet proven to be doing the right thing.

Thanks.

Mike.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V7] go: Add recipes for golang compilers and tools

[Kristian Amlie]

On 09/03/17 08:27, Khem Raj wrote:
> On Wed, Mar 8, 2017 at 11:03 PM, Kristian Amlie
>  wrote:
>> On 08/03/17 23:19, Khem Raj wrote:
 ...
 For the following go-1.4 recipes:

 I wouldn't recommend fixing go-native at version 1.4, which is now
 postiviely ancient.
 Instead, add go1.4.3's SRC_URI into the go-native recipe, loading it
 in the right place so
 that make.bash finds it.  This way, you can have all the go toolchain
 recipes build at the
 same version.  The go team only supports go1.4 for bootstrapping the
 compiler build now
 anyway, IIRC.
>>>
>>> since we do not use go-native for anything other than bootstrapping
>>> right now, thats why it is there. there is no intent of providing a
>>> go-native version for general consumption
>>
>> Just FYI, in Mender we use the latest go-native, provided by
>> github.com/mem/oe-meta-go, to compile some build tools. The layer has a
>> separate go-bootstrap recipe, which is locked to 1.4, for the purpose of
>> creating go-native and go-cross.
> 
> Thanks for info. we should add it here as well.

What work is going on in this regard right now? We will need this fixed
rather soon, since currently it conflicts with the existing, external layer.

I could take a look at this myself, but I'm no Go toolchain expert, more
on the consumption side, so my solution may not be the optimal one.

-- 
Kristian
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Burton, Ross]

On 11 March 2017 at 16:54, Mike Crowe  wrote:

> ccache apparently does this so that paths in the debug information will
> always be correct. In an OE world these paths may already be missing or
> incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> seem as if we're losing much by disabling this feature.
>

In an OE world we tell GCC to rewrite them to be target paths anyway, so
this isn't a problem.  Maybe worth rewriting the commit message?

(see bitbake.conf, -fdebug-prefix-map)

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 30/44] byacc: remove the recipe

[Alexander Kanavin]

On 03/10/2017 06:37 PM, Mark Hatle wrote:

byacc, until recently, was required by the LSB / LSB Test Suite.

So I'd rather is be kept in oe-core through the 2.3 release.


I couldn't find it in the LSB 5 standard. Is it something from earlier 
versions?


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] bitbake.conf: whitelist socat as non-fatal host tool

[Mikko Ylinen]

oe-git-proxy depends on socat host tool but it's not
whitelisted and triggers a 'binary not in PATH' error.

Whitelist socat but make it a HOSTTOOLS_NONFATAL since
it's not a hard dependency.

Signed-off-by: Mikko Ylinen 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index bc115117c9..ea5309462f 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -469,7 +469,7 @@ HOSTTOOLS += " \
 HOSTTOOLS += "ps stty ip ssh scp ping vi"
 
 # Link to these if present
-HOSTTOOLS_NONFATAL += "ccache pip3 ld.bfd ld.gold gcc-ar gpg sftp"
+HOSTTOOLS_NONFATAL += "ccache pip3 ld.bfd ld.gold gcc-ar gpg sftp socat"
 
 CCACHE ??= ""
 # Disable ccache explicitly if CCACHE is null since gcc may be a symlink
-- 
2.11.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes: Fix "U-boot", use proper spelling of "U-Boot".

[Robert P. J. Day]

U-Boot people are amazingly pedantic in their insistence on proper
spelling of "U-Boot", so humour them.

Signed-off-by: Robert P. J. Day 

---

diff --git a/meta/classes/kernel-fitimage.bbclass 
b/meta/classes/kernel-fitimage.bbclass
index 1c3b4b7..f9702f8 100644
--- a/meta/classes/kernel-fitimage.bbclass
+++ b/meta/classes/kernel-fitimage.bbclass
@@ -24,7 +24,7 @@ python __anonymous () {
 d.appendVarFlag('do_assemble_fitimage_initramfs', 'depends', ' 
${INITRAMFS_IMAGE}:do_image_complete')

 # Verified boot will sign the fitImage and append the public key to
-# U-boot dtb. We ensure the U-Boot dtb is deployed before assembling
+# U-Boot dtb. We ensure the U-Boot dtb is deployed before assembling
 # the fitImage:
 if d.getVar('UBOOT_SIGN_ENABLE') == "1":
 uboot_pn = d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 65a8c49..8ee904e 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -25,7 +25,7 @@
 #   u-boot:do_concat_dtb
 #   u-boot:do_install
 #
-# For more details on signature process, please refer to U-boot documentation.
+# For more details on signature process, please refer to U-Boot documentation.

 # Signature activation.
 UBOOT_SIGN_ENABLE ?= "0"

-- 


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

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


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] wic: selftest: account for occasional newline in debugfs file names

[Kristian Amlie]

On 13/03/17 11:19, Maciej Borzecki wrote:
> Debugfs output may contain a newline in file names in 'ls -p' output. Make 
> sure
> that output is correctly split into lines by matching '/\n' and newlines are
> removed from file names.
> 
> Fixes the following error appearing in AB tests:
> 
>Traceback (most recent call last):
>  File 
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/wic.py",
>  line 388, in test_exclude_path
>files = [line.split('/')[5] for line in res.output.split('\n')]
>  File 
> "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/wic.py",
>  line 388, in 
>files = [line.split('/')[5] for line in res.output.split('\n')]
>IndexError: list index out of range
> 
> Signed-off-by: Maciej Borzecki 
> ---
>  meta/lib/oeqa/selftest/wic.py | 25 +
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
> index 
> dcb88bacad13a2da4c725abf1c986b39ea70f0fc..825312e5a55639129d88246e7335174484260fc1
>  100644
> --- a/meta/lib/oeqa/selftest/wic.py
> +++ b/meta/lib/oeqa/selftest/wic.py
> @@ -381,11 +381,28 @@ part /etc --source rootfs --ondisk mmcblk0 
> --fstype=ext4 --exclude-path bin/ --r
>  self.assertEqual(0, runCmd("dd if=%s of=%s skip=%d count=%d" 
> %
> (wicimg, part_file, start, 
> length)).status)
>  
> +def extract_files(debugfs_output):
> +# extract file names from the output of debugfs -R 'ls -p',
> +# which looks like this:
> +#
> +# /2/040755/0/0/.//\n
> +# /2/040755/0/0/..//\n
> +# /11/040700/0/0/lost+found^M//\n
> +# /12/040755/1002/1002/run//\n
> +# /13/040755/1002/1002/sys//\n
> +# /14/040755/1002/1002/bin//\n
> +# /80/040755/1002/1002/var//\n
> +# /92/040755/1002/1002/tmp//\n
> +#
> +# NOTE the occasional ^M in file names
> +return [line.split('/')[5].strip() for line in \
> +debugfs_output.strip().split('/\n')]
> +
>  # Test partition 1, should contain the normal root directories, 
> except
>  # /usr.
>  res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
> os.path.join(self.resultdir, "selftest_img.part1"))
>  self.assertEqual(0, res.status)
> -files = [line.split('/')[5] for line in res.output.split('\n')]
> +files = extract_files(res.output)
>  self.assertIn("etc", files)
>  self.assertNotIn("usr", files)
>  
> @@ -393,7 +410,7 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
> --exclude-path bin/ --r
>  # directories.
>  res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
> os.path.join(self.resultdir, "selftest_img.part2"))
>  self.assertEqual(0, res.status)
> -files = [line.split('/')[5] for line in res.output.split('\n')]
> +files = extract_files(res.output)
>  self.assertNotIn("etc", files)
>  self.assertNotIn("usr", files)
>  self.assertIn("share", files)
> @@ -402,14 +419,14 @@ part /etc --source rootfs --ondisk mmcblk0 
> --fstype=ext4 --exclude-path bin/ --r
>  # directory, but not the files inside it.
>  res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
> os.path.join(self.resultdir, "selftest_img.part3"))
>  self.assertEqual(0, res.status)
> -files = [line.split('/')[5] for line in res.output.split('\n')]
> +files = extract_files(res.output)
>  self.assertNotIn("etc", files)
>  self.assertNotIn("usr", files)
>  self.assertIn("share", files)
>  self.assertIn("bin", files)
>  res = runCmd("debugfs -R 'ls -p bin' %s 2>/dev/null" % 
> os.path.join(self.resultdir, "selftest_img.part3"))
>  self.assertEqual(0, res.status)
> -files = [line.split('/')[5] for line in res.output.split('\n')]
> +files = extract_files(res.output)
>  self.assertIn(".", files)
>  self.assertIn("..", files)
>  self.assertEqual(2, len(files))

Looks good to me.

-- 
Kristian
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] wic: selftest: account for occasional newline in debugfs file names

[Maciej Borzecki]

Debugfs output may contain a newline in file names in 'ls -p' output. Make sure
that output is correctly split into lines by matching '/\n' and newlines are
removed from file names.

Fixes the following error appearing in AB tests:

   Traceback (most recent call last):
 File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/wic.py",
 line 388, in test_exclude_path
   files = [line.split('/')[5] for line in res.output.split('\n')]
 File 
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/lib/oeqa/selftest/wic.py",
 line 388, in 
   files = [line.split('/')[5] for line in res.output.split('\n')]
   IndexError: list index out of range

Signed-off-by: Maciej Borzecki 
---
 meta/lib/oeqa/selftest/wic.py | 25 +
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index 
dcb88bacad13a2da4c725abf1c986b39ea70f0fc..825312e5a55639129d88246e7335174484260fc1
 100644
--- a/meta/lib/oeqa/selftest/wic.py
+++ b/meta/lib/oeqa/selftest/wic.py
@@ -381,11 +381,28 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 self.assertEqual(0, runCmd("dd if=%s of=%s skip=%d count=%d" %
(wicimg, part_file, start, 
length)).status)
 
+def extract_files(debugfs_output):
+# extract file names from the output of debugfs -R 'ls -p',
+# which looks like this:
+#
+# /2/040755/0/0/.//\n
+# /2/040755/0/0/..//\n
+# /11/040700/0/0/lost+found^M//\n
+# /12/040755/1002/1002/run//\n
+# /13/040755/1002/1002/sys//\n
+# /14/040755/1002/1002/bin//\n
+# /80/040755/1002/1002/var//\n
+# /92/040755/1002/1002/tmp//\n
+#
+# NOTE the occasional ^M in file names
+return [line.split('/')[5].strip() for line in \
+debugfs_output.strip().split('/\n')]
+
 # Test partition 1, should contain the normal root directories, 
except
 # /usr.
 res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
os.path.join(self.resultdir, "selftest_img.part1"))
 self.assertEqual(0, res.status)
-files = [line.split('/')[5] for line in res.output.split('\n')]
+files = extract_files(res.output)
 self.assertIn("etc", files)
 self.assertNotIn("usr", files)
 
@@ -393,7 +410,7 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 # directories.
 res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
os.path.join(self.resultdir, "selftest_img.part2"))
 self.assertEqual(0, res.status)
-files = [line.split('/')[5] for line in res.output.split('\n')]
+files = extract_files(res.output)
 self.assertNotIn("etc", files)
 self.assertNotIn("usr", files)
 self.assertIn("share", files)
@@ -402,14 +419,14 @@ part /etc --source rootfs --ondisk mmcblk0 --fstype=ext4 
--exclude-path bin/ --r
 # directory, but not the files inside it.
 res = runCmd("debugfs -R 'ls -p' %s 2>/dev/null" % 
os.path.join(self.resultdir, "selftest_img.part3"))
 self.assertEqual(0, res.status)
-files = [line.split('/')[5] for line in res.output.split('\n')]
+files = extract_files(res.output)
 self.assertNotIn("etc", files)
 self.assertNotIn("usr", files)
 self.assertIn("share", files)
 self.assertIn("bin", files)
 res = runCmd("debugfs -R 'ls -p bin' %s 2>/dev/null" % 
os.path.join(self.resultdir, "selftest_img.part3"))
 self.assertEqual(0, res.status)
-files = [line.split('/')[5] for line in res.output.split('\n')]
+files = extract_files(res.output)
 self.assertIn(".", files)
 self.assertIn("..", files)
 self.assertEqual(2, len(files))
-- 
2.5.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [v2][PATCH] license class: try alt encoding when copying license file

[akuster808]

On 03/13/2017 02:42 AM, Burton, Ross wrote:


On 12 March 2017 at 15:27, Armin Kuster > wrote:


Try another encoding if utf-8 fails in file read.

hl
I sent a patch for this last week (just taking bytes instead of 
guessing encodings, which will still fail if the encoding isn't UTF-8 
or 8859-1)

Your patch works great in this case. I was working in a old tree.
- armin


Ross


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/2] classes/npm: allow installation of devDependencies

[Anders Darander]

Often, eg when using angular2, there's a need to install also
the devDependencies.

The default is to keep the old behaviour, to not install
devDependencies.

Signed-off-by: Anders Darander 
---
 meta/classes/npm.bbclass | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index c538040..a69bedb 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -14,6 +14,7 @@ def npm_oe_arch_map(target_arch, d):
 return target_arch
 
 NPM_ARCH ?= "${@npm_oe_arch_map(d.getVar('TARGET_ARCH'), d)}"
+NPM_INSTALL_DEV = "0"
 
 npm_do_compile() {
# Copy in any additionally fetched modules
@@ -23,12 +24,20 @@ npm_do_compile() {
# changing the home directory to the working directory, the .npmrc will
# be created in this directory
export HOME=${WORKDIR}
-   npm config set dev false
+   if [  "${NPM_INSTALL_DEV}" = "1" ]; then
+   npm config set dev true
+   else
+   npm config set dev false
+   fi
npm set cache ${WORKDIR}/npm_cache
# clear cache before every build
npm cache clear
# Install pkg into ${S} without going to the registry
-   npm --arch=${NPM_ARCH} --target_arch=${NPM_ARCH} --production 
--no-registry install
+   if [  "${NPM_INSTALL_DEV}" = "1" ]; then
+   npm --arch=${NPM_ARCH} --target_arch=${NPM_ARCH} --no-registry 
install
+   else
+   npm --arch=${NPM_ARCH} --target_arch=${NPM_ARCH} --production 
--no-registry install
+   fi
 }
 
 npm_do_install() {
-- 
2.10.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 1/2] devtool/recipetill: npm install of devDependencies

[Anders Darander]

Web applications built using e.g. angular2, usually requires that the
packages in devDependencies are available.

Thus, add an option '--fetch-dev' to both devtool add and recipetool, to
add npm packages in devDependencies to DEPENDS.

Signed-off-by: Anders Darander 
---
 scripts/lib/devtool/standard.py  |  3 +++
 scripts/lib/recipetool/create.py |  6 ++
 scripts/lib/recipetool/create_npm.py | 23 ++-
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index 5bd498c..07c1400 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -150,6 +150,8 @@ def add(args, config, basepath, workspace):
 extracmdopts += ' --src-subdir "%s"' % args.src_subdir
 if args.autorev:
 extracmdopts += ' -a'
+if args.fetch_dev:
+extracmdopts += ' --fetch-dev'
 
 tempdir = tempfile.mkdtemp(prefix='devtool')
 try:
@@ -1823,6 +1825,7 @@ def register_commands(subparsers, context):
 group.add_argument('--same-dir', '-s', help='Build in same directory as 
source', action="store_true")
 group.add_argument('--no-same-dir', help='Force build in a separate build 
directory', action="store_true")
 parser_add.add_argument('--fetch', '-f', help='Fetch the specified URI and 
extract it to create the source tree (deprecated - pass as positional argument 
instead)', metavar='URI')
+parser_add.add_argument('--fetch-dev', help='For npm, also fetch 
devDependencies', action="store_true")
 parser_add.add_argument('--version', '-V', help='Version to use within 
recipe (PV)')
 parser_add.add_argument('--no-git', '-g', help='If fetching source, do not 
set up source tree as a git repository', action="store_true")
 parser_add.add_argument('--autorev', '-a', help='When fetching from a git 
repository, set SRCREV in the recipe to a floating revision instead of fixed', 
action="store_true")
diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 1be3f14..648f2d6 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -599,6 +599,11 @@ def create_recipe(args):
 lines_after.append('INSANE_SKIP_${PN} += "already-stripped"')
 lines_after.append('')
 
+if args.fetch_dev:
+extravalues['fetchdev'] = True
+else:
+extravalues['fetchdev'] = None
+
 # Find all plugins that want to register handlers
 logger.debug('Loading recipe handlers')
 raw_handlers = []
@@ -1134,6 +1139,7 @@ def register_commands(subparsers):
 parser_create.add_argument('--src-subdir', help='Specify subdirectory 
within source tree to use', metavar='SUBDIR')
 parser_create.add_argument('-a', '--autorev', help='When fetching from a 
git repository, set SRCREV in the recipe to a floating revision instead of 
fixed', action="store_true")
 parser_create.add_argument('--keep-temp', action="store_true", help='Keep 
temporary directory (for debugging)')
+parser_create.add_argument('--fetch-dev', action="store_true", help='For 
npm, also fetch devDependencies')
 parser_create.add_argument('--devtool', action="store_true", 
help=argparse.SUPPRESS)
 parser_create.set_defaults(func=create_recipe)
 
diff --git a/scripts/lib/recipetool/create_npm.py 
b/scripts/lib/recipetool/create_npm.py
index 158029f..a215026 100644
--- a/scripts/lib/recipetool/create_npm.py
+++ b/scripts/lib/recipetool/create_npm.py
@@ -101,7 +101,7 @@ class NpmRecipeHandler(RecipeHandler):
 extravalues['extrafiles']['lockdown.json'] = tmpfile
 lines_before.append('NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"')
 
-def _handle_dependencies(self, d, deps, optdeps, lines_before, srctree):
+def _handle_dependencies(self, d, deps, optdeps, devdeps, lines_before, 
srctree):
 import scriptutils
 # If this isn't a single module we need to get the dependencies
 # and add them to SRC_URI
@@ -115,6 +115,10 @@ class NpmRecipeHandler(RecipeHandler):
 depdata = self.get_npm_data(dep, depver, d)
 if self.check_npm_optional_dependency(depdata):
 deplist[dep] = depdata
+for dep, depver in devdeps.items():
+depdata = self.get_npm_data(dep, depver, d)
+if self.check_npm_optional_dependency(depdata):
+deplist[dep] = depdata
 for dep, depver in deps.items():
 depdata = self.get_npm_data(dep, depver, d)
 deplist[dep] = depdata
@@ -197,8 +201,9 @@ class NpmRecipeHandler(RecipeHandler):
 if 'homepage' in data:
 extravalues['HOMEPAGE'] = data['homepage']
 
-deps, optdeps = self.get_npm_package_dependencies(data)
-updated = 

[OE-core] [PATCH v2 0/2] devtool/recipetool: allow installation of devDependencies

[Anders Darander]

This allows the conditional addition of devDependencies to DEPENDS, as well asi
installation to the recipes WORKDIR.

changes from v1:

* A number of patches was merged.

* Make the addition of devDependencies from package.json optional in 
create_npm.py
from recipetool.

The following changes since commit a47e64d985a610535449730806651f5bfd75d9ec:

  libcomps: add a recipe (2017-03-11 16:08:50 +)

are available in the git repository at:

  git://github.com/darander/openembedded-core npm
  https://github.com/darander/openembedded-core/tree/npm

Anders Darander (2):
  devtool/recipetill: npm install of devDependencies
  classes/npm: allow installation of devDependencies

 meta/classes/npm.bbclass | 13 +++--
 scripts/lib/devtool/standard.py  |  3 +++
 scripts/lib/recipetool/create.py |  6 ++
 scripts/lib/recipetool/create_npm.py | 23 ++-
 4 files changed, 38 insertions(+), 7 deletions(-)

-- 
2.10.2

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

[jobol]

From: José Bollo 

The copy of extended attributes is interesting for
Smack systems because it allows to set the security
template of the user's home directories without
modifying the tools (useradd here). But the version
of useradd that copies the extended attributes doesn't
copy the extended attributes of the root. This can make
use of homes impossible! This patch corrects the issue
by copying the extended attributes of the root directory:
/home/user will get the extended attributes of /etc/skel.

The patch is submitted upstream (see
http://lists.alioth.debian.org/pipermail/pkg-shadow-commits/2017-March/003804.html)

The existing patch specific to open-embedded is updated:
  0001-useradd.c-create-parent-directories-when-necessary.patch

Also, attr are activated for native tools.
This is needed when users are created during image creation.

Signed-off-by: José Bollo 
---
 ...-useradd-copy-extended-attributes-of-home.patch | 47 ++
 ...-create-parent-directories-when-necessary.patch | 10 -
 .../allow-for-setting-password-in-clear-text.patch |  8 ++--
 meta/recipes-extended/shadow/shadow.inc|  3 +-
 4 files changed, 61 insertions(+), 7 deletions(-)
 create mode 100644 
meta/recipes-extended/shadow/files/0001-useradd-copy-extended-attributes-of-home.patch

diff --git 
a/meta/recipes-extended/shadow/files/0001-useradd-copy-extended-attributes-of-home.patch
 
b/meta/recipes-extended/shadow/files/0001-useradd-copy-extended-attributes-of-home.patch
new file mode 100644
index 000..60a46e1
--- /dev/null
+++ 
b/meta/recipes-extended/shadow/files/0001-useradd-copy-extended-attributes-of-home.patch
@@ -0,0 +1,47 @@
+From acec93540eba6899661c607408498ac72ab07a47 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Jos=C3=A9=20Bollo?= 
+Date: Tue, 7 Mar 2017 16:03:03 +0100
+Subject: [PATCH] useradd: copy extended attributes of home
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The Home directory wasn't getting the extended attributes
+of /etc/skel. This patch fixes that issue and adds the copy
+of the extended attributes of the root of the home directory.
+
+Upstream-Status: Submitted 
[http://lists.alioth.debian.org/pipermail/pkg-shadow-commits/2017-March/003804.html]
+
+Change-Id: Icd633f7c6c494efd2a30cb8f04c306f749ad0c3b
+Signed-off-by: José Bollo 
+---
+ src/useradd.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/src/useradd.c b/src/useradd.c
+index a8a1f76..8aefb9c 100644
+--- a/src/useradd.c
 b/src/useradd.c
+@@ -52,6 +52,9 @@
+ #include 
+ #include 
+ #include 
++#ifdef WITH_ATTR
++#include 
++#endif
+ #include "chkname.h"
+ #include "defines.h"
+ #include "faillog.h"
+@@ -1915,6 +1918,9 @@ static void create_home (void)
+   chown (user_home, user_id, user_gid);
+   chmod (user_home,
+  0777 & ~getdef_num ("UMASK", GETDEF_DEFAULT_UMASK));
++#ifdef WITH_ATTR
++  attr_copy_file (def_template, user_home, NULL, NULL);
++#endif
+   home_added = true;
+ #ifdef WITH_AUDIT
+   audit_logger (AUDIT_ADD_USER, Prog,
+-- 
+2.9.3
+
diff --git 
a/meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
 
b/meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
index 85dde8e..2f084b4 100644
--- 
a/meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
+++ 
b/meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
@@ -11,7 +11,7 @@ diff --git a/src/useradd.c b/src/useradd.c
 index 4bd969d..cb5dd6c 100644
 --- a/src/useradd.c
 +++ b/src/useradd.c
-@@ -1893,6 +1893,35 @@ static void usr_update (void)
+@@ -1896,6 +1896,35 @@ static void usr_update (void)
  }
  
  /*
@@ -47,7 +47,7 @@ index 4bd969d..cb5dd6c 100644
   * create_home - create the user's home directory
   *
   *create_home() creates the user's home directory if it does not
-@@ -1907,36 +1936,33 @@ static void create_home (void)
+@@ -1910,39 +1939,36 @@ static void create_home (void)
fail_exit (E_HOMEDIR);
}
  #endif
@@ -67,6 +67,9 @@ index 4bd969d..cb5dd6c 100644
 -  chown (user_home, user_id, user_gid);
 -  chmod (user_home,
 - 0777 & ~getdef_num ("UMASK", GETDEF_DEFAULT_UMASK));
+-#ifdef WITH_ATTR
+-  attr_copy_file (def_template, user_home, NULL, NULL);
+-#endif
 -  home_added = true;
 +  mkdir_p(user_home);
 +  }
@@ -88,6 +91,9 @@ index 4bd969d..cb5dd6c 100644
 +  chown (user_home, user_id, user_gid);
 +  chmod (user_home,
 + 0777 & ~getdef_num ("UMASK", GETDEF_DEFAULT_UMASK));
++#ifdef WITH_ATTR
++  attr_copy_file (def_template, user_home, NULL, NULL);
++#endif
 +  home_added = true;
 +#ifdef 

[OE-core] [PATCH] u-boot: Update patch to match upstream

[Richard Purdie]

After discussions with upstream this version of the patch was proposed
and is being submitted to upstream u-boot. Update to that version
(which is better than my workaround).

Signed-off-by: Richard Purdie 
---
 meta/recipes-bsp/u-boot/files/default-gcc.patch   | 42 +++
 meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb |  2 +-
 2 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/meta/recipes-bsp/u-boot/files/default-gcc.patch 
b/meta/recipes-bsp/u-boot/files/default-gcc.patch
index 76d192e..04184df 100644
--- a/meta/recipes-bsp/u-boot/files/default-gcc.patch
+++ b/meta/recipes-bsp/u-boot/files/default-gcc.patch
@@ -3,23 +3,37 @@ through the make command, it overwrites not only this setting 
but also the
 setting in tools/Makefile wrapped in ifneq ($(CROSS_BUILD_TOOLS),) which 
 breaks the build.
 
-We therefore add a way of changing the default in the top level Makefile 
-without interfering with the other setting.
+We therefore use override to ensure the value of HOSTCC is overwritten when
+needed.
+
+RP: Updated the patch to the version being submitted to upstream u-boot
 
 Upstream-Status: Submitted [emailed to Masahiro Yamada for discussion]
 RP 2017/3/11
 
-Index: git/Makefile
+Index: git/tools/Makefile
+===
+--- git.orig/tools/Makefile
 git/tools/Makefile
+@@ -262,7 +262,7 @@ $(LICENSE_H): $(obj)/bin2header $(srctre
+ subdir- += env
+ 
+ ifneq ($(CROSS_BUILD_TOOLS),)
+-HOSTCC = $(CC)
++override HOSTCC = $(CC)
+ 
+ quiet_cmd_crosstools_strip = STRIP   $^
+   cmd_crosstools_strip = $(STRIP) $^; touch $@
+Index: git/tools/env/Makefile
 ===
 git.orig/Makefile
-+++ git/Makefile
-@@ -254,7 +254,8 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH"
- else if [ -x /bin/bash ]; then echo /bin/bash; \
- else echo sh; fi ; fi)
+--- git.orig/tools/env/Makefile
 git/tools/env/Makefile
+@@ -8,7 +8,7 @@
+ # fw_printenv is supposed to run on the target system, which means it should 
be
+ # built with cross tools. Although it may look weird, we only replace "HOSTCC"
+ # with "CC" here for the maximum code reuse of scripts/Makefile.host.
+-HOSTCC = $(CC)
++override HOSTCC = $(CC)
  
--HOSTCC   = cc
-+DEFAULTHOSTCC = cc
-+HOSTCC   = $(DEFAULTHOSTCC)
- HOSTCXX  = c++
- HOSTCFLAGS   = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer \
-   $(if $(CONFIG_TOOLS_DEBUG),-g)
+ # Compile for a hosted environment on the target
+ HOST_EXTRACFLAGS  = $(patsubst -I%,-idirafter%, $(filter -I%, 
$(UBOOTINCLUDE))) \
diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb 
b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
index 9b5772e..1aa95e7 100644
--- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
+++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.01.bb
@@ -5,7 +5,7 @@ SRC_URI += "file://default-gcc.patch"
 SUMMARY = "U-Boot bootloader image creation tool"
 DEPENDS = "openssl"
 
-EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} 
${CFLAGS} ${LDFLAGS}" DEFAULTHOSTCC="${BUILD_CC}" STRIP=true V=1'
+EXTRA_OEMAKE_class-target = 'CROSS_COMPILE="${TARGET_PREFIX}" CC="${CC} 
${CFLAGS} ${LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
STRIP=true V=1'
 EXTRA_OEMAKE_class-native = 'CC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" STRIP=true V=1'
 EXTRA_OEMAKE_class-nativesdk = 'CC="${BUILD_CC} ${BUILD_CFLAGS} 
${BUILD_LDFLAGS}" HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
STRIP=true V=1'
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [v2][PATCH] license class: try alt encoding when copying license file

[Burton, Ross]

On 12 March 2017 at 15:27, Armin Kuster  wrote:

> Try another encoding if utf-8 fails in file read.
>

I sent a patch for this last week (just taking bytes instead of guessing
encodings, which will still fail if the encoding isn't UTF-8 or 8859-1)

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] terminal: Use original PATH for terminals

[Richard Purdie]

Now that we filter out PATH to only the utilities we rely upon, the devshel
terminal was broken since it can no longer find the terminals. Even if
we fix that, the user couldn't access any of their commands within
devshell which somewhat defeats its purpose.

Add the original PATH back to the environment to restore that behaviour
since this is more in line with user expectations and it wouldn't be possible
(or desireable) to whitelist all the commands a user might want to use from
the shell.

Signed-off-by: Richard Purdie 
---
 meta/classes/terminal.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index 62409c0..a27e10c 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -66,6 +66,11 @@ def oe_terminal(command, title, d):
 envdata.setVar(key, str(value))
 envdata.setVarFlag(key, 'export', '1')
 
+# Use original PATH as a fallback
+path = d.getVar('PATH') + ":" + origbbenv.getVar('PATH')
+os.environ['PATH'] = path
+envdata.setVar('PATH', path)
+
 # A complex PS1 might need more escaping of chars.
 # Lets not export PS1 instead.
 envdata.delVar("PS1")
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] terminal.bbclass: add tools for terminal

[Anders Darander]

* Robert Yang  [170313 08:47]:


> +# Tools needed by terminal
> +HOSTTOOLS_NONFATAL += "tmux tmux xfce4-terminal konsole gnome-terminal \
> +terminology mate-terminal rxvt xterm tmux screen \
> +"

Why are you adding tmxu 3 times?

Cheers,
Anders

-- 
Anders Darander, Senior System Architect
ChargeStorm AB / eStorm AB
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] devshell.bbclass: add editors for devshell

[Robert Yang]

On 03/13/2017 04:24 PM, Richard Purdie wrote:

On Mon, 2017-03-13 at 00:46 -0700, Robert Yang wrote:

* The vi, vim, emacs and nano can be used in devshell.

* The groups, lesspipe and dircolors are required by
/etc/skel/.bashrc on
  Ubuntu 14.04, otherwise, there would be warnings when start
devshell:
bash: groups: command not found
bash: lesspipe: command not found
bash: dircolors: command not found

Signed-off-by: Robert Yang 
---
 meta/classes/devshell.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/devshell.bbclass
b/meta/classes/devshell.bbclass
index 4de7ea6fce..055d21ba50 100644
--- a/meta/classes/devshell.bbclass
+++ b/meta/classes/devshell.bbclass
@@ -2,6 +2,12 @@ inherit terminal

 DEVSHELL = "${SHELL}"

+# Tools used in devshell
+HOSTTOOLS_NONFATAL += "vi vim emacs nano"


Thinking about this further, I think we need to restore PATH for the
devshell. We can't really go down the road of trying to add in links
for any tool the developer may want to use...


Yes, that would be great.

// Robert



Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] devshell.bbclass: add editors for devshell

[Richard Purdie]

On Mon, 2017-03-13 at 00:46 -0700, Robert Yang wrote:
> * The vi, vim, emacs and nano can be used in devshell.
> 
> * The groups, lesspipe and dircolors are required by
> /etc/skel/.bashrc on
>   Ubuntu 14.04, otherwise, there would be warnings when start
> devshell:
> bash: groups: command not found
> bash: lesspipe: command not found
> bash: dircolors: command not found
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/classes/devshell.bbclass | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/classes/devshell.bbclass
> b/meta/classes/devshell.bbclass
> index 4de7ea6fce..055d21ba50 100644
> --- a/meta/classes/devshell.bbclass
> +++ b/meta/classes/devshell.bbclass
> @@ -2,6 +2,12 @@ inherit terminal
>  
>  DEVSHELL = "${SHELL}"
>  
> +# Tools used in devshell
> +HOSTTOOLS_NONFATAL += "vi vim emacs nano"

Thinking about this further, I think we need to restore PATH for the
devshell. We can't really go down the road of trying to add in links
for any tool the developer may want to use...

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] devshell.bbclass: add editors for devshell

[akuster808]

On 03/13/2017 12:46 AM, Robert Yang wrote:

* The vi, vim, emacs and nano can be used in devshell.


thanks
- armin

* The groups, lesspipe and dircolors are required by /etc/skel/.bashrc on
   Ubuntu 14.04, otherwise, there would be warnings when start devshell:
 bash: groups: command not found
 bash: lesspipe: command not found
 bash: dircolors: command not found

Signed-off-by: Robert Yang 
---
  meta/classes/devshell.bbclass | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/classes/devshell.bbclass b/meta/classes/devshell.bbclass
index 4de7ea6fce..055d21ba50 100644
--- a/meta/classes/devshell.bbclass
+++ b/meta/classes/devshell.bbclass
@@ -2,6 +2,12 @@ inherit terminal
  
  DEVSHELL = "${SHELL}"
  
+# Tools used in devshell

+HOSTTOOLS_NONFATAL += "vi vim emacs nano"
+
+# Tools needed by bash
+HOSTTOOLS_NONFATAL += "groups lesspipe dircolors"
+
  python do_devshell () {
  if d.getVarFlag("do_devshell", "manualfakeroot"):
 d.prependVar("DEVSHELL", "pseudo ")


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] devshell.bbclass: add editors for devshell

[Robert Yang]

* The vi, vim, emacs and nano can be used in devshell.

* The groups, lesspipe and dircolors are required by /etc/skel/.bashrc on
  Ubuntu 14.04, otherwise, there would be warnings when start devshell:
bash: groups: command not found
bash: lesspipe: command not found
bash: dircolors: command not found

Signed-off-by: Robert Yang 
---
 meta/classes/devshell.bbclass | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/classes/devshell.bbclass b/meta/classes/devshell.bbclass
index 4de7ea6fce..055d21ba50 100644
--- a/meta/classes/devshell.bbclass
+++ b/meta/classes/devshell.bbclass
@@ -2,6 +2,12 @@ inherit terminal
 
 DEVSHELL = "${SHELL}"
 
+# Tools used in devshell
+HOSTTOOLS_NONFATAL += "vi vim emacs nano"
+
+# Tools needed by bash
+HOSTTOOLS_NONFATAL += "groups lesspipe dircolors"
+
 python do_devshell () {
 if d.getVarFlag("do_devshell", "manualfakeroot"):
d.prependVar("DEVSHELL", "pseudo ")
-- 
2.11.0.rc2.dirty

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/2] add tools for terminal and devshell

[Robert Yang]

The following changes since commit a47e64d985a610535449730806651f5bfd75d9ec:

  libcomps: add a recipe (2017-03-11 16:08:50 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/tools
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/tools

Robert Yang (2):
  terminal.bbclass: add tools for terminal
  devshell.bbclass: add editors for devshell

 meta/classes/devshell.bbclass | 6 ++
 meta/classes/terminal.bbclass | 5 +
 2 files changed, 11 insertions(+)

-- 
2.11.0.rc2.dirty

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] terminal.bbclass: add tools for terminal

[Robert Yang]

Otherwise the -cdevshell doesn't work.

Signed-off-by: Robert Yang 
---
 meta/classes/terminal.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/terminal.bbclass b/meta/classes/terminal.bbclass
index 62409c0815..b68e5733c7 100644
--- a/meta/classes/terminal.bbclass
+++ b/meta/classes/terminal.bbclass
@@ -9,6 +9,11 @@ OE_TERMINAL_EXPORTS[type] = 'list'
 XAUTHORITY ?= "${HOME}/.Xauthority"
 SHELL ?= "bash"
 
+# Tools needed by terminal
+HOSTTOOLS_NONFATAL += "tmux tmux xfce4-terminal konsole gnome-terminal \
+terminology mate-terminal rxvt xterm tmux screen \
+"
+
 def oe_terminal_prioritized():
 import oe.terminal
 return " ".join(o.name for o in oe.terminal.prioritized())
-- 
2.11.0.rc2.dirty

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] devshell not working after pulling latest oe-core changes

[Robert Yang]

On 03/13/2017 03:37 PM, akuster808 wrote:



On 03/13/2017 12:19 AM, Richard Purdie wrote:

On Mon, 2017-03-13 at 00:09 -0700, akuster808 wrote:

 tmux split-window "do_terminal"
  tmux new-window -n "OpenEmbedded Developer Shell" "do_terminal"
  terminology -T="OpenEmbedded Developer Shell" -e do_terminal
  gnome-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
  mate-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
  konsole --separate --workdir . -p tabtitle="OpenEmbedded
Developer
Shell" -e do_terminal
  xfce4-terminal -T "OpenEmbedded Developer Shell" -e
"do_terminal"
  xterm -T "OpenEmbedded Developer Shell" -e do_terminal
  rxvt -T "OpenEmbedded Developer Shell" -e do_terminal
  tmux new -d -s devshell -n devshell "do_terminal"
  screen -D -m

I suspect we need a:

HOSTTOOLS_NONFATAL += "xterm rxvt tmux screen xfce4-terminal mate-
terminal konsole terminology gnome-terminal"

That worked to get remove the above errors.

please add:

HOSTTOOLS_NONFATAL += "dircolors lesspipe"

devshell comes up clean.


I met the same errors today, I have a patch now, will send it soon.

// Robert



kind regards,
Armin

into terminal.bbclass.

Cheers,

Richard



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] devshell not working after pulling latest oe-core changes

[akuster808]

On 03/13/2017 12:19 AM, Richard Purdie wrote:

On Mon, 2017-03-13 at 00:09 -0700, akuster808 wrote:

 tmux split-window "do_terminal"
  tmux new-window -n "OpenEmbedded Developer Shell" "do_terminal"
  terminology -T="OpenEmbedded Developer Shell" -e do_terminal
  gnome-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
  mate-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
  konsole --separate --workdir . -p tabtitle="OpenEmbedded
Developer
Shell" -e do_terminal
  xfce4-terminal -T "OpenEmbedded Developer Shell" -e
"do_terminal"
  xterm -T "OpenEmbedded Developer Shell" -e do_terminal
  rxvt -T "OpenEmbedded Developer Shell" -e do_terminal
  tmux new -d -s devshell -n devshell "do_terminal"
  screen -D -m

I suspect we need a:

HOSTTOOLS_NONFATAL += "xterm rxvt tmux screen xfce4-terminal mate-
terminal konsole terminology gnome-terminal"

That worked to get remove the above errors.

please add:

HOSTTOOLS_NONFATAL += "dircolors lesspipe"

devshell comes up clean.

kind regards,
Armin

into terminal.bbclass.

Cheers,

Richard


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] devshell not working after pulling latest oe-core changes

[Richard Purdie]

On Mon, 2017-03-13 at 00:09 -0700, akuster808 wrote:
>     tmux split-window "do_terminal"
>  tmux new-window -n "OpenEmbedded Developer Shell" "do_terminal"
>  terminology -T="OpenEmbedded Developer Shell" -e do_terminal
>  gnome-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
>  mate-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
>  konsole --separate --workdir . -p tabtitle="OpenEmbedded
> Developer 
> Shell" -e do_terminal
>  xfce4-terminal -T "OpenEmbedded Developer Shell" -e
> "do_terminal"
>  xterm -T "OpenEmbedded Developer Shell" -e do_terminal
>  rxvt -T "OpenEmbedded Developer Shell" -e do_terminal
>  tmux new -d -s devshell -n devshell "do_terminal"
>  screen -D -m

I suspect we need a:

HOSTTOOLS_NONFATAL += "xterm rxvt tmux screen xfce4-terminal mate-
terminal konsole terminology gnome-terminal"

into terminal.bbclass.

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] devshell not working after pulling latest oe-core changes

[akuster808]

Hello,


I am seeing the following error with devshell after pulling in the 
latest master ( a47e64d985a610535449730806651f5bfd75d9ec) ? Running on 
"Ubuntu 16.04.2 LTS


ERROR: bind-9.10.3-P3-r0 do_devshell: No valid terminal found, unable to 
open devshell.

Tried the following commands:
tmux split-window "do_terminal"
tmux new-window -n "OpenEmbedded Developer Shell" "do_terminal"
terminology -T="OpenEmbedded Developer Shell" -e do_terminal
gnome-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
mate-terminal -t "OpenEmbedded Developer Shell" -x do_terminal
konsole --separate --workdir . -p tabtitle="OpenEmbedded Developer 
Shell" -e do_terminal

xfce4-terminal -T "OpenEmbedded Developer Shell" -e "do_terminal"
xterm -T "OpenEmbedded Developer Shell" -e do_terminal
rxvt -T "OpenEmbedded Developer Shell" -e do_terminal
tmux new -d -s devshell -n devshell "do_terminal"
screen -D -m -t "OpenEmbedded Developer Shell" -S devshell do_terminal
ERROR: bind-9.10.3-P3-r0 do_devshell: Function failed: do_devshell
ERROR: Logfile of failure stored in: 
/home/akuster/oss/maint/openembedded-core/build/tmp-glibc/work/aarch64-oe-linux/bind/9.10.3-P3-r0/temp/log.do_devshell.6445
ERROR: Task 
(/home/akuster/oss/maint/openembedded-core/meta/recipes-connectivity/bind/bind_9.10.3-P3.bb:do_devshell) 
failed with exit code '1'



if I remove fa764a403da34bb0ca9fa3767a9e9dba8d685965 , devshell starts 
working again.


commit fa764a403da34bb0ca9fa3767a9e9dba8d685965
Author: Richard Purdie 
Date:   Thu Mar 9 00:14:38 2017 +

base/bitbake.conf: Filter contents of PATH to only allow 
whitelisted tools


is there something I am missing?

regards,

Armin


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core