Re: [oe] [meta-oe][zeus][PATCH 1/1] php: fix CVE-2019-11043

2019-11-12 Thread Slater, Joseph 
Oops, the patch is only part of commit ab061f95ca.  I could document this, or 
just leave it.Joe

-Original Message-
From: Joe Slater  
Sent: Tuesday, November 12, 2019 1:23 PM
To: openembedded-devel@lists.openembedded.org
Cc: Slater, Joseph ; MacLeod, Randy 

Subject: [meta-oe][zeus][PATCH 1/1] php: fix CVE-2019-11043

Backport unmodified patch from git.php.net.  Fixed in php 7.3.11.

Signed-off-by: Joe Slater 
---
 .../recipes-devtools/php/php/CVE-2019-11043.patch  | 38 ++
 meta-oe/recipes-devtools/php/php_7.3.9.bb  |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 meta-oe/recipes-devtools/php/php/CVE-2019-11043.patch

diff --git a/meta-oe/recipes-devtools/php/php/CVE-2019-11043.patch 
b/meta-oe/recipes-devtools/php/php/CVE-2019-11043.patch
new file mode 100644
index 000..7e20063
--- /dev/null
+++ b/meta-oe/recipes-devtools/php/php/CVE-2019-11043.patch
@@ -0,0 +1,38 @@
+From ab061f95ca966731b1c84cf5b7b20155c0a1c06a Mon Sep 17 00:00:00 2001
+From: Jakub Zelenka 
+Date: Sat, 12 Oct 2019 15:56:16 +0100
+Subject: [PATCH] Fix bug #78599 (env_path_info underflow can lead to 
+RCE)
+
+CVE: CVE-2019-11043
+
+Fixed in php version 7.3.11.
+
+Upstream-Status: Backport [https://git.php.net/repository/php-src.git]
+
+Signed-off-by: Joe Slater 
+---
+ NEWS  |  4 +-
+ sapi/fpm/fpm/fpm_main.c   |  4 +-
+ .../tests/bug78599-path-info-underflow.phpt   | 61 +++
+ sapi/fpm/tests/tester.inc | 11 +++-
+ 4 files changed, 75 insertions(+), 5 deletions(-)  create mode 100644 
+sapi/fpm/tests/bug78599-path-info-underflow.phpt
+
+diff --git a/sapi/fpm/fpm/fpm_main.c b/sapi/fpm/fpm/fpm_main.c index 
+24a7e5d56a..50f92981f1 100644
+--- a/sapi/fpm/fpm/fpm_main.c
 b/sapi/fpm/fpm/fpm_main.c
+@@ -1209,8 +1209,8 @@ static void init_request_info(void)
+   path_info = 
script_path_translated + ptlen;
+   tflag = (slen 
!= 0 && (!orig_path_info || strcmp(orig_path_info, path_info) != 0));
+   } else {
+-  path_info = 
env_path_info ? env_path_info + pilen - slen : NULL;
+-  tflag = 
(orig_path_info != path_info);
++  path_info = 
(env_path_info && pilen > slen) ? env_path_info + pilen - slen : NULL;
++  tflag = 
path_info && (orig_path_info != path_info);
+   }
+ 
+   if (tflag) {
+--
+2.17.1
+
diff --git a/meta-oe/recipes-devtools/php/php_7.3.9.bb 
b/meta-oe/recipes-devtools/php/php_7.3.9.bb
index a5c7b9b..e886cb1 100644
--- a/meta-oe/recipes-devtools/php/php_7.3.9.bb
+++ b/meta-oe/recipes-devtools/php/php_7.3.9.bb
@@ -8,6 +8,7 @@ SRC_URI += 
"file://0001-acinclude.m4-don-t-unset-cache-variables.patch \
 file://0001-Use-pkg-config-for-libxml2-detection.patch \
 file://debian-php-fixheader.patch \
 file://CVE-2019-6978.patch \
+file://CVE-2019-11043.patch \
"
 SRC_URI_append_class-target = " \
 file://pear-makefile.patch \
--
2.7.4

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

Re: [oe] [meta-oe][V2][PATCH 1/1] php: zlib and zip support

2019-08-15 Thread Slater, Joseph 
I think the current config does not enable either zlib or zip.  It defines 
--with-libzip, but does not enable it with --enable-zip.  It also does not 
define --with-zlib, so we lose that.

The original concern was that phoronix-test-suite would put out a message at 
runtime that it needed php zip.  I think this message is wrong and all it needs 
is zlib.  So, I decided to bring both back but not enable zip because it needs 
an extra package.  The "old" way of supporting php zip used a bundled library.  
That way has been deprecated, so if we want zip, we need libzip.

This patch is aimed at helping phoronix-test-suite and easing php zip support 
should someone desire to add that via PACKAGECONFIG.  I would be happy to put 
zip into the default config, but who really needs it?

Joe

-Original Message-
From: MacLeod, Randy  
Sent: Thursday, August 15, 2019 4:01 PM
To: Slater, Joseph ; 
openembedded-devel@lists.openembedded.org
Subject: Re: [meta-oe][V2][PATCH 1/1] php: zlib and zip support

On 8/15/19 5:26 PM, Joe Slater wrote:
> Add back zlib support.  Define zip support but do not enable it.

Can you explain what that achieves.
 From the change it looks like you have duplicated the default config and added 
a PACKAGECONFIG. Why do you need both?

../Randy
> 
> Signed-off-by: Joe Slater 
> ---
>   meta-oe/recipes-devtools/php/php.inc | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta-oe/recipes-devtools/php/php.inc 
> b/meta-oe/recipes-devtools/php/php.inc
> index 33bcf12..b63ed4c 100644
> --- a/meta-oe/recipes-devtools/php/php.inc
> +++ b/meta-oe/recipes-devtools/php/php.inc
> @@ -59,7 +59,7 @@ EXTRA_OECONF = "--enable-mbstring \
>   --enable-fpm \
>   --with-libdir=${baselib} \
>   --with-gettext=${STAGING_LIBDIR}/.. \
> ---with-libzip=${STAGING_LIBDIR}/.. \
> +--with-zlib=${STAGING_LIBDIR}/.. \
>   --with-iconv=${STAGING_LIBDIR}/.. \
>   --with-bz2=${STAGING_DIR_TARGET}${exec_prefix} \
>   
> --with-config-file-path=${sysconfdir}/php/apache2-php${PHP_MAJOR_VERSION} \ 
> @@ -81,6 +81,8 @@ PACKAGECONFIG ??= "mysql sqlite3 imap opcache openssl \
>   "
>   PACKAGECONFIG_class-native = ""
>   
> +PACKAGECONFIG[zip] = "--enable-zip 
> --with-libzip=${STAGING_EXECPREFIXDIR},,libzip"
> +
>   PACKAGECONFIG[mysql] = "--with-mysql=${STAGING_DIR_TARGET}${prefix} \
>   --with-mysqli=${STAGING_BINDIR_CROSS}/mysql_config \
>   
> --with-pdo-mysql=${STAGING_BINDIR_CROSS}/mysql_config \
> 


--
# Randy MacLeod
# Wind River Linux
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 1/1] php: zlib and zip support

2019-08-13 Thread Slater, Joseph 
That's probably best.  The bundled way won't be supported at some future date, 
anyway.  Joe

-Original Message-
From: Adrian Bunk  
Sent: Monday, August 12, 2019 9:50 PM
To: Slater, Joseph 
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [meta-oe][PATCH 1/1] php: zlib and zip support

On Mon, Aug 12, 2019 at 12:22:20PM -0700, Joe Slater wrote:
> Add back zlib support.  Define zip support but do not enable it.
>...
> +# For zip, select one or none.  oldzip uses a bundled library and is 
> deprecated.
> +#
> +PACKAGECONFIG[newzip] = "--enable-zip 
> --with-libzip=${STAGING_EXECPREFIXDIR},,libzip"
> +PACKAGECONFIG[oldzip] = "--enable-zip --without-libzip,"
>...

Any reason why this can't be PACKAGECONFIG[zip] for the external libzip only 
without any option for the bundled library?

Bundled libraries are usually behind on security fixes, and php is a software 
where this tends to matter.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[oe] Recipe local variables

2019-08-12 Thread Slater, Joseph 
Is there a naming convention?  I have seen some defined which look confusingly 
like externally defined variables.  How about lcl_, or something like 
that.  All "global" variables start with an upper case segment, right?  Or, 
maybe just say recipe local variables are all lower case.

Joe

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

Re: [oe] [meta-oe][PATCH 1/1] php: zlib and zip support

2019-08-12 Thread Slater, Joseph 
Maybe the names are confusing.  It's really use_libzip_zip vs use_bundled_zip.  
 Joe

-Original Message-
From: akuster808  
Sent: Monday, August 12, 2019 12:34 PM
To: Slater, Joseph ; 
openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [meta-oe][PATCH 1/1] php: zlib and zip support



On 8/12/19 12:22 PM, Joe Slater wrote:
> Add back zlib support.  Define zip support but do not enable it.
>
> Signed-off-by: Joe Slater 
> ---
>  meta-oe/recipes-devtools/php/php.inc | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-devtools/php/php.inc 
> b/meta-oe/recipes-devtools/php/php.inc
> index 33bcf12..08173ea 100644
> --- a/meta-oe/recipes-devtools/php/php.inc
> +++ b/meta-oe/recipes-devtools/php/php.inc
> @@ -59,7 +59,7 @@ EXTRA_OECONF = "--enable-mbstring \
>  --enable-fpm \
>  --with-libdir=${baselib} \
>  --with-gettext=${STAGING_LIBDIR}/.. \
> ---with-libzip=${STAGING_LIBDIR}/.. \
> +--with-zlib=${STAGING_LIBDIR}/.. \
>  --with-iconv=${STAGING_LIBDIR}/.. \
>  --with-bz2=${STAGING_DIR_TARGET}${exec_prefix} \
>  
> --with-config-file-path=${sysconfdir}/php/apache2-php${PHP_MAJOR_VERSI
> ON} \ @@ -81,6 +81,11 @@ PACKAGECONFIG ??= "mysql sqlite3 imap opcache 
> openssl \  "
>  PACKAGECONFIG_class-native = ""
>  
> +# For zip, select one or none.  oldzip uses a bundled library and is 
> deprecated.
> +#

How would I know which is old or new? is there a version ref we can mention? is 
it a gplv2 or gplv3 thing?

-armin
> +PACKAGECONFIG[newzip] = "--enable-zip 
> --with-libzip=${STAGING_EXECPREFIXDIR},,libzip"
> +PACKAGECONFIG[oldzip] = "--enable-zip --without-libzip,"
> +
>  PACKAGECONFIG[mysql] = "--with-mysql=${STAGING_DIR_TARGET}${prefix} \
>  --with-mysqli=${STAGING_BINDIR_CROSS}/mysql_config \
>  
> --with-pdo-mysql=${STAGING_BINDIR_CROSS}/mysql_config \

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

Re: [oe] [meta-networking][PATCH 1/1] drbd-utils: enable reproducible_build awareness

2019-07-11 Thread Slater, Joseph 



> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Thursday, July 11, 2019 12:33 AM
> To: Slater, Joseph
> Cc: openembeded-devel
> Subject: Re: [oe] [meta-networking][PATCH 1/1] drbd-utils: enable
> reproducible_build awareness
> 
> On Wed, Jul 10, 2019 at 4:57 PM Joe Slater 
> wrote:
> >
> > Enable use of SOURCE_DATE_EPOCH from the reproducible_build bbclass.
> >
> > Signed-off-by: Joe Slater 
> > ---
> >  meta-networking/recipes-support/drbd/drbd-utils_9.10.0.bb | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta-networking/recipes-support/drbd/drbd-utils_9.10.0.bb
> b/meta-networking/recipes-support/drbd/drbd-utils_9.10.0.bb
> > index 70e04b9..7fd3090 100644
> > --- a/meta-networking/recipes-support/drbd/drbd-utils_9.10.0.bb
> > +++ b/meta-networking/recipes-support/drbd/drbd-utils_9.10.0.bb
> > @@ -35,6 +35,9 @@ EXTRA_OECONF = " \
> >  --without-manual \
> > "
> >
> > +# If we have inherited reproducible_build, we want to use it.
> > +export WANT_DRBD_REPRODUCIBLE_BUILD = "yes"
> 
> should this be set after checking for inherit 

[Joe Slater] This variable is always queried and the code checks for a 
reproducible_build environment, so we don't need to test here.

> > +
> >  do_configure_prepend() {
> >  # move the the file under folder /lib/drbd/ to /usr/lib/drbd when
> usrmerge enabled
> >  if ${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', 'true', 
> > 'false', d)};
> then
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips with DEFAULTTUNE mips

2019-03-06 Thread Slater, Joseph 
The particular failure we see might be a Wind River thing.  For our distro's we 
set the DEFAULTTUNE's in an include file under layers/wrlinux/wrlinux-distro 
and the multilib bbclass forces it to that.  It should probably be mips32r2 
instead of mips32.

Joe

From: Khem Raj [raj.k...@gmail.com]
Sent: Wednesday, March 06, 2019 9:21 AM
To: Slater, Joseph
Cc: Kang, Kai; openembeded-devel
Subject: Re: [oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips with 
DEFAULTTUNE mips

On Wed, Mar 6, 2019 at 8:38 AM Slater, Joseph  wrote:
>
> If we assume we do not really have "sync" for the failing case here, 
> lib32-leveldb, shouldn't we apply the no-sync patch with something like
>
> SRC_URI_pn-lib32-leveldb_mipsarcho32 += "..."
>

my problem is that we have mips32r2 which is also mipsarcho32
and does have sync, I would rather suggest that you switch the
defaulttune for multilib to use mips32r2 since thats more or less
whats out there

> Joe
> 
> From: openembedded-devel-boun...@lists.openembedded.org 
> [openembedded-devel-boun...@lists.openembedded.org] on behalf of Kang Kai 
> [kai.k...@windriver.com]
> Sent: Tuesday, March 05, 2019 9:44 PM
> To: Khem Raj
> Cc: openembeded-devel
> Subject: Re: [oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips 
> with DEFAULTTUNE mips
>
> On 2019/3/6 下午1:31, Khem Raj wrote:
> > On Tue, Mar 5, 2019 at 9:16 PM Kang Kai  wrote:
> >> On 2019/3/6 上午11:49, Khem Raj wrote:
> >>>
> >>> On 3/5/19 7:39 PM, kai.k...@windriver.com wrote:
> >>>> From: Kai Kang 
> >>>>
> >>>> It fails to compile leveldb for qemumips with DEFAULTTUNE 'mips':
> >>>>
> >>>> | {standard input}: Assembler messages:
> >>>> | {standard input}:8004: Error: opcode not supported on this processor:
> >>>> mips1 (mips1) `sync'
> >>>> | {standard input}:10296: Error: opcode not supported on this processor:
> >>>> mips1 (mips1) `sync'
> >>>> | make: *** [out-shared/db/db_bench.o] Error 1
> >>>>
> >>>> Asm instruction 'sync' is called in platform-specific function
> >>>> MemoryBarrier() which is used by AtomicPointer(). Comment out the
> >>>> definition of MemoryBarrier() for mips to avoid the errors. And turn to
> >>>> use AtomicPointer() based on C++11 .
> >>>>
> >>>> Signed-off-by: Kai Kang 
> >>>> ---
> >>>>...fine-function-MemoryBarrier-for-mips.patch | 43 +++
> >>>>meta-oe/recipes-dbs/leveldb/leveldb_git.bb|  1 +
> >>>>2 files changed, 44 insertions(+)
> >>>>create mode 100644
> >>>> meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
> >>>>
> >>>> diff --git
> >>>> a/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
> >>>> b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
> >>>>
> >>>> new file mode 100644
> >>>> index 0..fc7743030
> >>>> --- /dev/null
> >>>> +++
> >>>> b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
> >>>> @@ -0,0 +1,43 @@
> >>>> +It fails to compile leveldb for qemumips with default tune 'mips':
> >>>> +
> >>>> +| {standard input}: Assembler messages:
> >>>> +| {standard input}:8004: Error: opcode not supported on this processor:
> >>>> +  mips1 (mips1) `sync'
> >>>> +| {standard input}:10296: Error: opcode not supported on this
> >>>> processor:
> >>>> +  mips1 (mips1) `sync'
> >>>> +| make: *** [out-shared/db/db_bench.o] Error 1
> >>>> +
> >>>> +Asm instruction 'sync' is called in platform-specific function
> >>>> +MemoryBarrier() which is used by AtomicPointer(). Comment out the
> >>>> +definition of MemoryBarrier() for mips to avoid the errors. And turn to
> >>>> +use AtomicPointer() based on C++11 .
> >>>> +
> >>>> +Upstream-Status: Inappropriate [oe specific]
> >>>> +
> >>>> +Signed-off-by: Kai Kang 
> >>>> +
> >>>> +---
> >>>> + port/atomic_pointer.h | 10 +-
> >>>> + 1 file changed, 5 insertions(+), 5 deletions(-)
> >>>> +
&g

Re: [oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips with DEFAULTTUNE mips

2019-03-06 Thread Slater, Joseph 
If we assume we do not really have "sync" for the failing case here, 
lib32-leveldb, shouldn't we apply the no-sync patch with something like

SRC_URI_pn-lib32-leveldb_mipsarcho32 += "..."

Joe

From: openembedded-devel-boun...@lists.openembedded.org 
[openembedded-devel-boun...@lists.openembedded.org] on behalf of Kang Kai 
[kai.k...@windriver.com]
Sent: Tuesday, March 05, 2019 9:44 PM
To: Khem Raj
Cc: openembeded-devel
Subject: Re: [oe] [meta-oe][PATCH v2] leveldb: fix compile errors for mips with 
DEFAULTTUNE mips

On 2019/3/6 下午1:31, Khem Raj wrote:
> On Tue, Mar 5, 2019 at 9:16 PM Kang Kai  wrote:
>> On 2019/3/6 上午11:49, Khem Raj wrote:
>>>
>>> On 3/5/19 7:39 PM, kai.k...@windriver.com wrote:
 From: Kai Kang 

 It fails to compile leveldb for qemumips with DEFAULTTUNE 'mips':

 | {standard input}: Assembler messages:
 | {standard input}:8004: Error: opcode not supported on this processor:
 mips1 (mips1) `sync'
 | {standard input}:10296: Error: opcode not supported on this processor:
 mips1 (mips1) `sync'
 | make: *** [out-shared/db/db_bench.o] Error 1

 Asm instruction 'sync' is called in platform-specific function
 MemoryBarrier() which is used by AtomicPointer(). Comment out the
 definition of MemoryBarrier() for mips to avoid the errors. And turn to
 use AtomicPointer() based on C++11 .

 Signed-off-by: Kai Kang 
 ---
...fine-function-MemoryBarrier-for-mips.patch | 43 +++
meta-oe/recipes-dbs/leveldb/leveldb_git.bb|  1 +
2 files changed, 44 insertions(+)
create mode 100644
 meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch

 diff --git
 a/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
 b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch

 new file mode 100644
 index 0..fc7743030
 --- /dev/null
 +++
 b/meta-oe/recipes-dbs/leveldb/leveldb/do-not-define-function-MemoryBarrier-for-mips.patch
 @@ -0,0 +1,43 @@
 +It fails to compile leveldb for qemumips with default tune 'mips':
 +
 +| {standard input}: Assembler messages:
 +| {standard input}:8004: Error: opcode not supported on this processor:
 +  mips1 (mips1) `sync'
 +| {standard input}:10296: Error: opcode not supported on this
 processor:
 +  mips1 (mips1) `sync'
 +| make: *** [out-shared/db/db_bench.o] Error 1
 +
 +Asm instruction 'sync' is called in platform-specific function
 +MemoryBarrier() which is used by AtomicPointer(). Comment out the
 +definition of MemoryBarrier() for mips to avoid the errors. And turn to
 +use AtomicPointer() based on C++11 .
 +
 +Upstream-Status: Inappropriate [oe specific]
 +
 +Signed-off-by: Kai Kang 
 +
 +---
 + port/atomic_pointer.h | 10 +-
 + 1 file changed, 5 insertions(+), 5 deletions(-)
 +
 +diff --git a/port/atomic_pointer.h b/port/atomic_pointer.h
 +index 1c4c7aa..7025ac3 100644
 +--- a/port/atomic_pointer.h
  b/port/atomic_pointer.h
 +@@ -113,11 +113,11 @@ inline void MemoryBarrier() {
 + #define LEVELDB_HAVE_MEMORY_BARRIER
 +
 + // MIPS
 +-#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(__GNUC__)
 +-inline void MemoryBarrier() {
 +-  __asm__ __volatile__("sync" : : : "memory");
 +-}
 +-#define LEVELDB_HAVE_MEMORY_BARRIER
 ++//#elif defined(ARCH_CPU_MIPS_FAMILY) && defined(__GNUC__)
 ++//inline void MemoryBarrier() {
 ++//  __asm__ __volatile__("sync" : : : "memory");
 ++//}
 ++//#define LEVELDB_HAVE_MEMORY_BARRIER
 +
>>> this is punishing all mips o32 variants.
>> How about only apply the patch when DEFAULTTUNE is 'mips', such as
>> something looks like:
>>
>> python ()  {
>>
>>   if d.getVar('DEFAULTTUNE') == 'mips':
>>
>>   d.appendVar('SRC_URI', '
>> file://do-not-define-function-MemoryBarrier-for-mips.patch')
>>
>> }
>
> None of these are as good as first patch. Ideally you should change
> the defaulttune


But defaulttune could be overridden by user configure. Even could
configure qemumips64 with defaulttune 'mips'.
I'll try to fix it from oe side based on first patch.

Kai


>

--
Kai Kang

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

Re: [oe] [meta-oe][PATCH 1/1] leveldb: restrict building for mips64

2019-03-05 Thread Slater, Joseph 
Yes, it only fails for multilib.  An unaupported instruction ("sync").  Kai 
Kang is sending a different patch, that is, I assume it is different.

Joe

From: Khem Raj [raj.k...@gmail.com]
Sent: Monday, March 04, 2019 6:36 PM
To: Slater, Joseph
Cc: openembeded-devel
Subject: Re: [oe] [meta-oe][PATCH 1/1] leveldb: restrict building for mips64

On Mon, Mar 4, 2019 at 3:51 PM Joe Slater  wrote:
>
> Do not try to build lib32-leveldb.  libn32-leveldb will build.
>
> Signed-off-by: Joe Slater 
> ---
>  meta-oe/recipes-dbs/leveldb/leveldb_git.bb | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta-oe/recipes-dbs/leveldb/leveldb_git.bb 
> b/meta-oe/recipes-dbs/leveldb/leveldb_git.bb
> index 8fec89c..908ad3e 100644
> --- a/meta-oe/recipes-dbs/leveldb/leveldb_git.bb
> +++ b/meta-oe/recipes-dbs/leveldb/leveldb_git.bb
> @@ -35,3 +35,7 @@ do_install() {
>
>  PACKAGES =+ "${PN}-ptest"
>  FILES_${PN}-ptest = "${bindir}"
> +
> +# Do not try to build lib32-leveldb for mips64, but allow libn32-leveldb.
> +#
> +COMPATIBLE_HOST_mipsarcho32_pn-lib32-leveldb = "null"

does it fail just in multilib situation ?

> --
> 2.7.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH 1/1] php: specify no valgrind

2018-08-27 Thread Slater, Joseph 
Yes, although that is an enhancement.Joe

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Friday, August 24, 2018 1:22 PM
To: Slater, Joseph
Cc: openembeded-devel
Subject: Re: [oe] [meta-oe][PATCH 1/1] php: specify no valgrind

On Fri, Aug 24, 2018 at 12:35 PM Joe Slater  wrote:
>
> configure will look by default for valgrind.h in some host directories.
> We override this by setting --with-valgrind=no.
>
> Signed-off-by: Joe Slater 
> ---
>  meta-oe/recipes-devtools/php/php.inc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta-oe/recipes-devtools/php/php.inc 
> b/meta-oe/recipes-devtools/php/php.inc
> index 4231fcc..ef03e66 100644
> --- a/meta-oe/recipes-devtools/php/php.inc
> +++ b/meta-oe/recipes-devtools/php/php.inc
> @@ -47,6 +47,7 @@ EXTRA_OECONF = "--enable-mbstring \
>  --enable-wddx \
>  --enable-fpm \
>  --enable-zip \
> +--with-valgrind=no \

perhaps turning it into a packageconfig is better.

>  --with-libdir=${baselib} \
>  --with-gettext=${STAGING_LIBDIR}/.. \
>  --with-zlib=${STAGING_LIBDIR}/.. \
> --
> 2.7.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-gnome][PATCH 1/1] metacity: allow for warnings during compilation

2018-06-25 Thread Slater, Joseph 
I think it is better to have to take an action to cover up an issue rather than 
need
to do something to expose it, but either way gives you a choice.

Joe

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Saturday, June 23, 2018 5:31 PM
To: Slater, Joseph
Cc: openembeded-devel
Subject: Re: [oe] [meta-gnome][PATCH 1/1] metacity: allow for warnings during 
compilation

On Sat, Jun 23, 2018 at 4:56 PM Joe Slater  wrote:
>
> Add a PACKAGECONFIG option which lets us permit warnings during
> compilation until warnings from new compiler versions are
> dealt with.
>
> Signed-off-by: Joe Slater 
> ---
>  meta-gnome/recipes-gnome/metacity/metacity_3.28.0.bb | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/meta-gnome/recipes-gnome/metacity/metacity_3.28.0.bb 
> b/meta-gnome/recipes-gnome/metacity/metacity_3.28.0.bb
> index ce97a80..948c2f1 100644
> --- a/meta-gnome/recipes-gnome/metacity/metacity_3.28.0.bb
> +++ b/meta-gnome/recipes-gnome/metacity/metacity_3.28.0.bb
> @@ -23,6 +23,11 @@ SRCREV = "c0d4b2fc0fcd6f2d3c37da935923f9e9ed5eb99f"
>
>  EXTRA_OECONF += "--disable-xinerama"
>
> +PACKAGECONFIG ?= ""
> +

since we defaulted to gcc8 in oe-core, perhaps its better to turn it on
by default.

> +# enable as neccessary until new warnings are dealt with
> +PACKAGECONFIG[noWerror] = "--disable-Werror,,,"
> +
>  do_configure_prepend() {
>  cd ${S}
>  aclocal --install || exit 1
> --
> 2.7.4
>
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] geoip versions

2018-03-29 Thread Slater, Joseph 
The SRC_URIs for geoip source from maxmind are not versioned and are not a 
reliable source of the version you are trying to build.  I think the sources 
are mirrored on a yocto site, but, once again, lack version info, so they might 
or might not match what you want.

It would be easy enough to add a yocto(?) PREMIRROR with version info to the 
recipe, but I have no idea how to establish the physical mirror.  Also, the 
recipe versions and the versions of the source may well not be in sync because 
the source changes frequently, and I think, without notice.  I realize this is 
an odd case, but it would be nice to have some solution to this maintenance 
issue.

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

Re: [oe] [meta-networking][PATCH 1/1] postfix: move running newaliases back to pkg_postinst

2018-02-01 Thread Slater, Joseph 
The one you reference fixes several things.  Best to merge that one.  However, 
if newaliases fails during pkg_postinst(), I believe the system will not know 
to schedule the script at first boot unless we ‘exit 1’.   We also need to 
create the sendmail link before this or do it someplace else.

Joe

From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Thursday, February 01, 2018 1:39 PM
To: Slater, Joseph
Cc: openembedded-devel
Subject: Re: [oe] [meta-networking][PATCH 1/1] postfix: move running newaliases 
back to pkg_postinst

How is this one related to:
https://patchwork.openembedded.org/patch/147161/
?

On Thu, Feb 1, 2018 at 10:26 PM, Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>> wrote:
newaliases, when run on the host, will fail if /var/spool/postfix
does not exist.  Run it during pkg_postinst() so that we can defer
it to first boot.

Signed-off-by: Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>>
---
 meta-networking/recipes-daemons/postfix/postfix.inc | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/meta-networking/recipes-daemons/postfix/postfix.inc 
b/meta-networking/recipes-daemons/postfix/postfix.inc
index e48fc39..d5d0789 100644
--- a/meta-networking/recipes-daemons/postfix/postfix.inc
+++ b/meta-networking/recipes-daemons/postfix/postfix.inc
@@ -217,12 +217,6 @@ do_install_append_class-native() {
 do_install_append_class-target() {
 # Remove references to buildmachine paths in target makedefs.out
 sed -i 's:-fdebug-prefix-map[^ ]*::g; 
s:--sysroot=${STAGING_DIR_TARGET}::g' ${D}/etc/postfix/makedefs.out
-# Since we are building recipe postfix, newaliases and postmap come from 
our sysroot_native.
-touch ${D}/etc/aliases
-newaliases -C ${D}/etc/postfix/main.cf<http://main.cf> -oA${D}/etc/aliases
-touch ${D}/etc/postfix/virtual_alias
-postmap -c ${D}/etc/postfix ${D}/etc/postfix/virtual_alias
-
 }

 ALTERNATIVE_${PN} = "sendmail"
@@ -235,6 +229,7 @@ ALTERNATIVE_LINK_NAME[mailq.1] = "${mandir}/man1/mailq.1"
 ALTERNATIVE_LINK_NAME[newaliases.1] = "${mandir}/man1/newaliases.1"
 ALTERNATIVE_LINK_NAME[sendmail.1] = "${mandir}/man1/sendmail.1"

+PACKAGE_WRITE_DEPS += "postfix-native"
 pkg_postinst_${PN} () {
 if [ "x$D" = "x" ]; then
 touch /etc/aliases
@@ -248,6 +243,12 @@ pkg_postinst_${PN} () {
 # /usr/lib/sendmail is required by LSB core test
 [ ! -L $D/usr/lib/sendmail ] && ln -sf ${sbindir}/sendmail 
$D/usr/lib/
 fi
+
+touch $D/etc/aliases
+# fails if /var/spool/postfix is not on host
+newaliases -C $D/etc/postfix/main.cf<http://main.cf> -oA$D/etc/aliases 
 ||  exit 1
+touch $D/etc/postfix/virtual_alias
+postmap -c $D/etc/postfix $D/etc/postfix/virtual_alias
 fi
 }

--
2.7.4

--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org<mailto:Openembedded-devel@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

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

[oe] samba 4.7.0

2017-11-07 Thread Slater, Joseph 
I would like to move us to 4.7.0 which requires updating libtalloc, libtevent, 
libtdb and libldb.  Updating the last breaks the build for samba 4.6.7.  If 
this is where we would like to go, please hold off on patches for these recipes 
or send them to me for inclusion in my submissions.

Joe

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

Re: [oe] [php5.6.26]error during build

2017-08-18 Thread Slater, Joseph 
There is a patch on master, 6cd2492, that you can cherry-pick.  It addresses 
more than just this issue, though.

Joe


From: openembedded-devel-boun...@lists.openembedded.org 
[openembedded-devel-boun...@lists.openembedded.org] on behalf of Randy MacLeod 
[randy.macl...@windriver.com]
Sent: Friday, August 18, 2017 11:15 AM
To: idealsim; openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [php5.6.26]error during build

On 2017-08-17 06:32 AM, idealsim wrote:
> Hi try to build an image with php5.6.26 in pyro branch. I have this
> error during the build :
>
> /| ERROR: oe_runmake failed//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/usr/lib/../lib/libc-client.a(osdep.o):
> In function `ssl_onceonlyinit'://
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/uw-imap/2007f-r0/imap-2007f/c-client/osdep.c:302:
> warning: the use of `tmpnam' is dangerous, better use `mkstemp'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
> TSRM/.libs/TSRM.o: undefined reference to symbol
> 'pthread_getspecific@@GLIBC_2.4'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libpthread.so.0:
> error adding symbols: DSO missing from command line//
> //| collect2: error: ld returned 1 exit status//
> //| Makefile:270: recipe for target 'sapi/cli/php' failed//
> //| make: *** [sapi/cli/php] Error 1//
> //| make: *** Waiting for unfinished jobs//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/usr/lib/../lib/libc-client.a(osdep.o):
> In function `ssl_onceonlyinit'://
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/uw-imap/2007f-r0/imap-2007f/c-client/osdep.c:302:
> warning: the use of `tmpnam' is dangerous, better use `mkstemp'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
> TSRM/.libs/TSRM.o: undefined reference to symbol
> 'pthread_getspecific@@GLIBC_2.4'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libpthread.so.0:
> error adding symbols: DSO missing from command line//
> //| collect2: error: ld returned 1 exit status//
> //| Makefile:306: recipe for target 'sapi/cgi/php-cgi' failed//
> //| make: *** [sapi/cgi/php-cgi] Error 1//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/usr/lib/../lib/libc-client.a(osdep.o):
> In function `ssl_onceonlyinit'://
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/uw-imap/2007f-r0/imap-2007f/c-client/osdep.c:302:
> warning: the use of `tmpnam' is dangerous, better use `mkstemp'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/6.3.0/ld:
> TSRM/.libs/TSRM.o: undefined reference to symbol
> 'pthread_getspecific@@GLIBC_2.4'//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/lib/libpthread.so.0:
> error adding symbols: DSO missing from command line//
> //| collect2: error: ld returned 1 exit status//
> //| Makefile:283: recipe for target 'sapi/fpm/php-fpm' failed//
> //| make: *** [sapi/fpm/php-fpm] Error 1//
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/recipe-sysroot/usr/lib/../lib/libc-client.a(osdep.o):
> In function `ssl_onceonlyinit'://
> //|
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/uw-imap/2007f-r0/imap-2007f/c-client/osdep.c:302:
> warning: the use of `tmpnam' is dangerous, better use `mkstemp'//
> //| WARNING: exit code 1 from a shell command.//
> //| ERROR: Function failed: do_compile (log file is located at
> /media/modjo/data1TO/yocto/pyro/quadBuild/tmp/work/udooqdl-poky-linux-gnueabi/php/5.6.26-r0/temp/log.do_compile.15528)//
>
> //ERROR: Task
> (/media/modjo/data1TO/yocto/pyro/sources/meta-openembedded/meta-oe/recipes-devtools/php/php_5.6.26.bb:do_compile)
> failed with exit code '1'//
> //NOTE: Tasks Summary: Attempted 6275 tasks of which 6269 didn't need to
> be rerun and 1 failed.//
> //
> //Summary: 1 task failed://
> ///media/modjo/data1TO/yocto/pyro/sources/meta-openembedded/meta-oe/recipes-devtools/php/php_5.6.26.bb:do_compile//
>
> //Summary: There was 1 WARNING message shown.//
> //Summary: There

Re: [oe] [meta-networking][PATCH 1/1] yp-tools: fix compile errors

2016-08-18 Thread Slater, Joseph 


> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org 
> [mailto:openembedded-devel-
> boun...@lists.openembedded.org] On Behalf Of Khem Raj
> Sent: Wednesday, August 17, 2016 4:20 PM
> To: openembedded-devel@lists.openembedded.org
> Subject: Re: [oe] [meta-networking][PATCH 1/1] yp-tools: fix compile errors
> 
> 
> > On Aug 17, 2016, at 1:22 PM, Joe Slater  wrote:
> >
> > Fix two fatal warnings.  The cast error only
> > occurs for some architectures.
> >
> > Signed-off-by: Joe Slater 
> > ---
> > .../nis/yp-tools/alignment-cheat.patch |   58 
> > 
> > .../recipes-support/nis/yp-tools_3.3.bb|3 +-
> > 2 files changed, 59 insertions(+), 2 deletions(-)
> > create mode 100644 
> > meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> >
> > diff --git 
> > a/meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch b/meta-
> networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> > new file mode 100644
> > index 000..856e42e
> > --- /dev/null
> > +++ b/meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> > @@ -0,0 +1,58 @@
> > +yp-tools: avoid fatal cast warning
> > +
> > +The way casting is done, we will get a fatal alignment warning on some
> > +architectures.  This patch cheats our way around this.
> > +
> 
> These changes look fine, however you should run it by the upstream.

Version 4.2 of the tools seems to bear little resemblance to 3.3.  The code and
structures patched here no longer exist.

> 
> > +We also eliminate an unused constant which causes a fatal warning.
> > +
> > +Upstream-status: Pending
> > +
> > +Signed-off-by: Joe Slater 
> > +
> > +
> > +--- a/lib/do_ypcall.c
> >  b/lib/do_ypcall.c
> > +@@ -44,7 +44,9 @@ struct dom_binding
> > + typedef struct dom_binding dom_binding;
> > +
> > + static const struct timeval RPCTIMEOUT = {25, 0};
> > ++#if 0
> > + static const struct timeval UDPTIMEOUT = {5, 0};
> > ++#endif
> 
> perhaps its better to remove the unused code instead of making preprocessor
> work even more.

Probably.  I think RPCTIMEOUT made it to 4.2, but UDPTIMEOUT did not.

> 
> > + static int const MAXTRIES = 2;
> > + static pthread_mutex_t ypbindlist_lock = PTHREAD_MUTEX_INITIALIZER;
> > + static dom_binding *ypbindlist = NULL;
> > +@@ -381,7 +383,7 @@ __ypclnt_call (u_long prog, xdrproc_t xa
> > +
> > + int
> > + do_ypcall (const char *domain, u_long prog, xdrproc_t xargs,
> > +- caddr_t req, xdrproc_t xres, caddr_t resp)
> > ++ caddr_t req, xdrproc_t xres, void *resp)
> > + {
> > +   dom_binding *ydb;
> > +   int status;
> > +@@ -450,9 +452,9 @@ do_ypcall (const char *domain, u_long pr
> > + /* Like do_ypcall, but translate the status value if necessary.  */
> > + int
> > + do_ypcall_tr (const char *domain, u_long prog, xdrproc_t xargs,
> > +-caddr_t req, xdrproc_t xres, caddr_t resp)
> > ++caddr_t req, xdrproc_t xres, void *resp)
> > + {
> > +-  int status = do_ypcall (domain, prog, xargs, req, xres, resp);
> > ++  int status = do_ypcall (domain, prog, xargs, req, xres, (void *) resp);
> 
> resp is already a void pointer why is this typecast needed ?

I put it in someplace along the line in trying to fix the problem and forgot
to take it out.

V2 or leave it?  This code does not look like it's going anywhere beyond here.

Joe


> 
> > +   if (status == YPERR_SUCCESS)
> > + /* We cast to ypresp_val although the pointer could also be of
> > +type ypresp_key_val or ypresp_master or ypresp_order or
> > +--- a/lib/internal.h
> >  b/lib/internal.h
> > +@@ -17,8 +17,8 @@
> > + #define _INTERNAL_H_
> > +
> > + extern int do_ypcall (const char *domain, u_long prog, xdrproc_t xargs,
> > +-caddr_t req, xdrproc_t xres, caddr_t resp);
> > ++caddr_t req, xdrproc_t xres, void *resp);
> > + extern int do_ypcall_tr (const char *domain, u_long prog, xdrproc_t xargs,
> > +-   caddr_t req, xdrproc_t xres, caddr_t resp);
> > ++   caddr_t req, xdrproc_t xres, void *resp);
> > + extern int yp_maplist (const char *, struct ypmaplist **);
> > + #endif
> > diff --git a/meta-networking/recipes-support/nis/yp-tools_3.3.bb b/meta-
> networking/recipes-support/nis/yp-tools_3.3.bb
> > index b89f0b8..69217fa 100644
> > --- a/meta-networking/recipes-support/nis/yp-tools_3.3.bb
> > +++ b/meta-networking/recipes-support/nis/yp-tools_3.3.bb
> > @@ -11,11 +11,10 @@ ypwhich, yppasswd, domainname, nisdomainname \
> > and ypdomainname. \
> > "
> >
> > -PNBLACKLIST[yp-tools] ?= "BROKEN: fails to build for qemuarm."
> > -
> > SRC_URI = "http://www.linux-nis.org/download/yp-tools/${BP}.tar.bz2 \
> >file://domainname.service \
> >
> > file://yp-tools-ipv4-ipv6-Provide-an-in-place-version-of-mapv4v6addr.patch \
> > +   file://alignment-cheat.patch \
> > "
> > SRC_URI[md5sum] =

Re: [oe] [meta-networking][PATCH 1/1] openconnect: PACKAGECONFIG certain dependencies

2016-07-01 Thread Slater, Joseph 


> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org 
> [mailto:openembedded-devel-
> boun...@lists.openembedded.org] On Behalf Of Christopher Larson
> Sent: Thursday, June 30, 2016 10:13 PM
> To: Openembedded Discussion
> Subject: Re: [oe] [meta-networking][PATCH 1/1] openconnect: PACKAGECONFIG 
> certain
> dependencies
> 
> On Thu, Jun 30, 2016 at 12:46 PM, Joe Slater  wrote:
> 
> > +PACKAGECONFIG ??= "gnutls lz4 libproxy"
> > +
> > +# config defaults
> > +PACKAGECONFIG[gnutls] = ",--without-gnutls,gnutls,"
> > +PACKAGECONFIG[lz4] = ",--without-lz4,lz4,"
> > +PACKAGECONFIG[libproxy] = ",--without-libproxy,libproxy,"
> > +
> > +# not config defaults
> > +PACKAGECONFIG[pcsc-lite] = ",--without-libpcsclite,pcsc-lite,"
> >
> 
> Why are the options not being passed for the enabled case, here? We prefer
> to be explicit, rather than relying on defaults.

I can easily add them.  I left them out because configure help only mentions 
the --without
options to override the defaults.

Joe


> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> --
> ___
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-initramfs][PATCH 1/1] dracut: RDEPEND on util-linux

2015-10-19 Thread Slater, Joseph 


> -Original Message-
> From: openembedded-devel-boun...@lists.openembedded.org 
> [mailto:openembedded-devel-
> boun...@lists.openembedded.org] On Behalf Of Khem Raj
> Sent: Friday, October 16, 2015 1:05 PM
> To: openembeded-devel
> Subject: Re: [oe] [meta-initramfs][PATCH 1/1] dracut: RDEPEND on util-linux
> 
> On Fri, Oct 16, 2015 at 10:57 AM, Joe Slater  wrote:
> > We might need findmnt and setsid, which are in the
> > util-linux package.
> 
> would it make sense to put them in a independent package ?

If we do, I think we should make util-linux RDEPEND on it (them), so we won't 
break other
stuff that assumes that's where they are.

Joe


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

Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as broken

2015-07-30 Thread Slater, Joseph 


 -Original Message-
 From: Joe MacDonald [mailto:joe_macdon...@mentor.com]
 Sent: Thursday, July 30, 2015 8:41 AM
 To: Slater, Joseph
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but 
 keep as
 broken
 
 [Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as 
 broken] On
 15.07.28 (Tue 19:39) Slater, Joseph wrote:
 
 
   -Original Message-
   From: openembedded-devel-boun...@lists.openembedded.org 
   [mailto:openembedded-devel-
   boun...@lists.openembedded.org] On Behalf Of Joe MacDonald
   Sent: Wednesday, July 22, 2015 1:31 PM
   To: openembedded-devel@lists.openembedded.org
   Subject: Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency 
   but keep as
   broken
  
   [[oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as 
   broken] On
   15.07.22 (Wed 11:54) Joe Slater wrote:
  
We will need the conditional dependency on systemd.  It is
not a good idea to use PNBLACKLIST in a recipe, and the
  
   It isn't a good idea to have a recipe that needs to be blacklisted.  :-)
  
   That said, it's here and there's still an argument for supporting it, so
   why remove PNBLACKLIST and replace it with something less obvious?
 
  Blacklisting oneself is esthetically unpleasing.
 
 I won't argue there.  But it happens because it's a less violent option
 than kicking the recipe to the curb and waiting for pick-up day.  It
 does allow someone using the recipe to come along and still use it for
 their scenario if they need it and they know the reason for the
 blacklisting doesn't apply to them.
 
  But, beyond that, it doesn't work for multilib variants, and for some
  reason PNBLACKLIST[${PN}] does not parse.
 
 I don't know about that, but maybe a patch to poky is appropriate
 instead.  It's nothing to be proud of, but there are dozens of recipes
 in meta-openembedded/ right now that are blacklisted, unless you're
 planning on submitting the same construct to replace all of them, I
 don't think there's much more to discuss on it.
 
 I'm marking this 'changes requested'.  Do you think you could re-submit
 with just the dependency change?

Sure.  I'll check, though, if maybe PNBLACKLIST[${PN}] parses, in which
case I'll use that for the blacklisting.

Joe

 
 Thanks,
 -J.
 
 
  Joe
 
 
  
   No objection to a conditional dependency on systemd.
  
   -J.
  
version here does not suppress lib32-ypbind-mt.
   
Signed-off-by: Joe Slater jsla...@windriver.com
---
 recipes-support/nis/ypbind-mt_2.2.bb |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
   
diff --git a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb 
b/meta-
   networking/recipes-support/nis/ypbind-mt_2.2.bb
index 4f8bf48..359b020 100644
--- a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
+++ b/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
@@ -15,10 +15,12 @@ of known secure NIS server (/etc/yp.conf) Binds to \
 the server which answered as first. \
 
 HOMEPAGE = http://www.linux-nis.org/nis/ypbind-mt/index.html;
-DEPENDS = yp-tools
+DEPENDS = yp-tools ${@base_contains('DISTRO_FEATURES', 'systemd', 
'systemd', '',
 d)}
 PROVIDES += ypbind
   
-PNBLACKLIST[ypbind-mt] ?= BROKEN: Depends on broken yp-tools
+python () {
+raise bb.parse.SkipPackage(BROKEN: Depends on broken yp-tools)
+}
   
 SRC_URI = http://www.linux-nis.org/download/ypbind-mt/${BP}.tar.bz2 \
file://ypbind-yocto.init \
--
1.7.9.5
   
   --
   -Joe MacDonald.
   :wq
 --
 -Joe MacDonald.
 :wq
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as broken

2015-07-28 Thread Slater, Joseph 


 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org 
 [mailto:openembedded-devel-
 boun...@lists.openembedded.org] On Behalf Of Joe MacDonald
 Sent: Wednesday, July 22, 2015 1:31 PM
 To: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but 
 keep as
 broken
 
 [[oe] [meta-networking][PATCH 1/1] ypbind-mt: add dependency but keep as 
 broken] On
 15.07.22 (Wed 11:54) Joe Slater wrote:
 
  We will need the conditional dependency on systemd.  It is
  not a good idea to use PNBLACKLIST in a recipe, and the
 
 It isn't a good idea to have a recipe that needs to be blacklisted.  :-)
 
 That said, it's here and there's still an argument for supporting it, so
 why remove PNBLACKLIST and replace it with something less obvious?

Blacklisting oneself is esthetically unpleasing.  But, beyond that, it doesn't 
work
for multilib variants, and for some reason PNBLACKLIST[${PN}] does not parse.

Joe


 
 No objection to a conditional dependency on systemd.
 
 -J.
 
  version here does not suppress lib32-ypbind-mt.
 
  Signed-off-by: Joe Slater jsla...@windriver.com
  ---
   recipes-support/nis/ypbind-mt_2.2.bb |6 --
   1 file changed, 4 insertions(+), 2 deletions(-)
 
  diff --git a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb b/meta-
 networking/recipes-support/nis/ypbind-mt_2.2.bb
  index 4f8bf48..359b020 100644
  --- a/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
  +++ b/meta-networking/recipes-support/nis/ypbind-mt_2.2.bb
  @@ -15,10 +15,12 @@ of known secure NIS server (/etc/yp.conf) Binds to \
   the server which answered as first. \
   
   HOMEPAGE = http://www.linux-nis.org/nis/ypbind-mt/index.html;
  -DEPENDS = yp-tools
  +DEPENDS = yp-tools ${@base_contains('DISTRO_FEATURES', 'systemd', 
  'systemd', '', d)}
   PROVIDES += ypbind
 
  -PNBLACKLIST[ypbind-mt] ?= BROKEN: Depends on broken yp-tools
  +python () {
  +raise bb.parse.SkipPackage(BROKEN: Depends on broken yp-tools)
  +}
 
   SRC_URI = http://www.linux-nis.org/download/ypbind-mt/${BP}.tar.bz2 \
  file://ypbind-yocto.init \
  --
  1.7.9.5
 
 --
 -Joe MacDonald.
 :wq
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH] arptables: defeat multi-job for install

2013-02-17 Thread Slater, Joseph 
Hi Paul,

I apologize for the patch path.  I applied it to a repository for 
meta-networking,
not meta-openembedded.  I should have guessed that the subject qualifier should
be more specific than [oe].

As to PARALLEL_MAKEINST, I did note that usually it is , but I think that
-j1 makes it very clear what the form of this variable is and doesn't cost 
all that
much, so that's what I went for.

Joe


From: Paul Eggleton [paul.eggle...@linux.intel.com]
Sent: Saturday, February 16, 2013 12:31 PM
To: Slater, Joseph
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] [PATCH] arptables: defeat multi-job for install

Hi Joe,

On Thursday 14 February 2013 13:40:04 Joe Slater wrote:
 CQID: 399299

 The make install target is not parallel job
 safe, but doesn't do all that much, so we
 limit make to one job for that.

 The make target is of the form

 install: x y z

 Unfortunately, z depends on y, so if z is started
 before y (almost) completes, we will fail.

 Signed-off-by: Joe Slater jsla...@windriver.com
 ---
  recipes-support/arptables/arptables_0.0.3-4.bb |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

 diff --git a/recipes-support/arptables/arptables_0.0.3-4.bb
 b/recipes-support/arptables/arptables_0.0.3-4.bb index 2faccec..de3f62d
 100644
 --- a/recipes-support/arptables/arptables_0.0.3-4.bb
 +++ b/recipes-support/arptables/arptables_0.0.3-4.bb
 @@ -3,6 +3,8 @@ PRIORITY = optional
  LICENSE = GPL-2.0
  SECTION = console/network

 +PR = r2
 +
  RDEPENDS_${PN} += perl

  LIC_FILES_CHKSUM =
 file://${COREBASE}/meta/files/common-licenses/GPL-2.0;md5=801f80980d171dd6
 425610833a22dbe6 @@ -20,6 +22,11 @@ do_compile () {
   oe_runmake
  }

 +# the install target is not multi-job safe, but it doesn't do much
 +# so we just install seriatim
 +#

I hope I don't expose my ignorance too much by saying I just learned a new
word thanks to the above comment... ;)

 +PARALLEL_MAKEINST = -j1

Of course this will work but typically we would just set PARALLEL_MAKEINST =
 to accomplish this.

More importantly, this appears to be a patch for the meta-networking layer and
should therefore have [meta-networking] in the subject and use the meta-
networking/ path.

Cheers,
Paul
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel