Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

Sent a patch that works around this issue.

Then I get the exact same failure as in gatesgarth, the "unrecognized 
command line option ‘-fmacro-prefix-map" bug.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 24-03-2021 08:28, Mike Looijmans via lists.openembedded.org wrote:
Been digging into this, something weird is going on with the TOPDIR 
environment.


recipes-core/openjdk/openjdk-8-common.inc:
do_configure_prepend () {
    export TOPDIR=${S}
}

So TOPDIR should be set okay, but in the logging one can see that the 
autoconf tools do not expand it.


Bluntly adding the following line:
    mkdir $TOPDIR/common/autoconf/build-aux

Errors out with an error that this path already exists.

So it's something askew in the shell environment handling, but I 
cannot figure out what is going on here.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 23-03-2021 16:09, Mike Looijmans via lists.openembedded.org wrote:
In a desperate attempt to get openjre-8 to build, I just went to the 
current master, and that failed to build with lots of warnings about 
"inherit native". I noticed that those were fixed in master-next, so 
I switched to that instead. Still fails to build after a long 
time. (I replaced some private path details with '...')


These are the GIT hashes are reported by OE.

meta = "HEAD:69f8f3e21324223c8e68a34db156e4472acfba6d"
meta-oe
meta-python
meta-multimedia
meta-networking  = "HEAD:589aa162cead42acdd7e8dbd7c0243b95e341f19"
meta-java    = "HEAD:db9a58bb71fffdb74eb9850978a643a98ff13323"
meta-qt5 = "HEAD:324843cb1a2feb5f5c7b0064ca33edaa605cb749"
meta-raspberrypi = "HEAD:a3cda589508a9b56ea803cdd31e870481fc27132"
meta-swupdate    = "HEAD:065aafa41cff44985170b9ff6170ff9f87007b7f"


Log data follows:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 
'bit-64', 'x86_64-linux', 'common']

| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are 
['virtual:native:/home/.../oe-core/meta/recipes-support/libxslt/libxslt_1.1.34.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/glib-2.0/glib-2.0_2.66.7.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/fontconfig/fontconfig_2.13.1.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/jpeg/libjpeg-turbo_2.0.6.bb:do_populate_sysroot', 
'virtual:native:/home/.../meta-oe/meta-oe/recipes-devtools/giflib/giflib_5.1.4.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-support/ca-certificates/ca-certificates_20210119.bb:do_populate_sysroot', 
'/home/.../meta-java/recipes-core/icedtea/icedtea7-native_2.1.3.bb:do_populate_sysroot', 
'/home/.../meta-java/recipes-core/ant/ant-native_1.8.1.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-core/gettext/gettext-minimal-native_0.21.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-multimedia/libpng/libpng_1.6.37.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/make/make_4.3.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/zlib/zlib_1.2.11.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/automake/automake_1.16.2.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/autoconf/autoconf_2.71.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/freetype/freetype_2.10.4.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-extended/zip/zip_3.0.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/coreutils/coreutils_8.32.bb:do_populate_sy

[oe] [PATCH][meta-java][master] openjdk-8: Workaround TOPDIR not getting expanded in configure.ac

[Mike Looijmans]

Somehow the TOPDIR environment doesn't get expanded in configure.ac. Suspecting
a clash with OE's internal TOPDIR variable, I tried replacing it with JDKTOPDIR
but that resulted in the same error.

| autoreconf: configure.ac: creating directory $TOPDIR/common/autoconf/build-aux
| autoreconf: error: cannot create $TOPDIR/common/autoconf/build-aux: No such 
file or directory

The workaround implemented here is to replace $TOPDIR in the file by its 
assigned
value ${S}. This makes the error go away and the native build succeed.

Signed-off-by: Mike Looijmans 
---
 recipes-core/openjdk/openjdk-8-common.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-core/openjdk/openjdk-8-common.inc 
b/recipes-core/openjdk/openjdk-8-common.inc
index 70585a6..7d45585 100644
--- a/recipes-core/openjdk/openjdk-8-common.inc
+++ b/recipes-core/openjdk/openjdk-8-common.inc
@@ -28,6 +28,7 @@ SRC_URI = "\
 
 do_configure_prepend () {
 export TOPDIR=${S}
+sed -i 's#\$TOPDIR#${S}#g' ${S}/common/autoconf/configure.ac
 }
 
 do_unpack_extract_submodules () {
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#90291): 
https://lists.openembedded.org/g/openembedded-devel/message/90291
Mute This Topic: https://lists.openembedded.org/mt/81571977/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

Been digging into this, something weird is going on with the TOPDIR 
environment.


recipes-core/openjdk/openjdk-8-common.inc:
do_configure_prepend () {
    export TOPDIR=${S}
}

So TOPDIR should be set okay, but in the logging one can see that the 
autoconf tools do not expand it.


Bluntly adding the following line:
    mkdir $TOPDIR/common/autoconf/build-aux

Errors out with an error that this path already exists.

So it's something askew in the shell environment handling, but I cannot 
figure out what is going on here.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 23-03-2021 16:09, Mike Looijmans via lists.openembedded.org wrote:
In a desperate attempt to get openjre-8 to build, I just went to the 
current master, and that failed to build with lots of warnings about 
"inherit native". I noticed that those were fixed in master-next, so I 
switched to that instead. Still fails to build after a long time. 
(I replaced some private path details with '...')


These are the GIT hashes are reported by OE.

meta = "HEAD:69f8f3e21324223c8e68a34db156e4472acfba6d"
meta-oe
meta-python
meta-multimedia
meta-networking  = "HEAD:589aa162cead42acdd7e8dbd7c0243b95e341f19"
meta-java    = "HEAD:db9a58bb71fffdb74eb9850978a643a98ff13323"
meta-qt5 = "HEAD:324843cb1a2feb5f5c7b0064ca33edaa605cb749"
meta-raspberrypi = "HEAD:a3cda589508a9b56ea803cdd31e870481fc27132"
meta-swupdate    = "HEAD:065aafa41cff44985170b9ff6170ff9f87007b7f"


Log data follows:
| DEBUG: Executing shell function autotools_preconfigure
| DEBUG: Shell function autotools_preconfigure finished
| DEBUG: Executing python function autotools_aclocals
| DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 
'bit-64', 'x86_64-linux', 'common']

| DEBUG: Python function autotools_aclocals finished
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are 
['virtual:native:/home/.../oe-core/meta/recipes-support/libxslt/libxslt_1.1.34.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-connectivity/openssl/openssl_1.1.1j.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/glib-2.0/glib-2.0_2.66.7.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-devtools/libtool/libtool-native_2.4.6.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/fontconfig/fontconfig_2.13.1.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/jpeg/libjpeg-turbo_2.0.6.bb:do_populate_sysroot', 
'virtual:native:/home/.../meta-oe/meta-oe/recipes-devtools/giflib/giflib_5.1.4.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-support/ca-certificates/ca-certificates_20210119.bb:do_populate_sysroot', 
'/home/.../meta-java/recipes-core/icedtea/icedtea7-native_2.1.3.bb:do_populate_sysroot', 
'/home/.../meta-java/recipes-core/ant/ant-native_1.8.1.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-core/gettext/gettext-minimal-native_0.21.bb:do_populate_sysroot', 
'/home/.../oe-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-multimedia/libpng/libpng_1.6.37.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/make/make_4.3.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/zlib/zlib_1.2.11.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/automake/automake_1.16.2.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-devtools/autoconf/autoconf_2.71.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-graphics/freetype/freetype_2.10.4.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-extended/unzip/unzip_6.0.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-extended/zip/zip_3.0.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-core/coreutils/coreutils_8.32.bb:do_populate_sysroot', 
'virtual:native:/home/.../oe-core/meta/recipes-support/attr/attr_2.4.48.bb:do_populate_sysroot'] 


| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['libxslt-native', 
'openssl-native', 'glib-2.0-native', 'libtool-native', 
'pkgconfig-native', 'fontconfig-native', 'libjpeg-turbo-native', 
'giflib-native', 'ca-certificates-native', 'icedtea7-native', 
'ant-native', 'gettext-minimal-native', 'quilt-native', 
'libpng-native', 'make-native', 'zlib-native', 'automake-native', 
'autoconf

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

e free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
|
| Written by Tom Tromey 
|    and Alexandre Duret-Lutz .
| AUTOV is 1.16
| autoreconf: export WARNINGS=cross,no-obsolete
| autoreconf: Entering directory '.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal 
--system-acdir=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/recipe-sysroot-native/usr/share/aclocal/ 
--automake-acdir=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/recipe-sysroot-native/usr/share/aclocal-1.16 
-I 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/ 
-I 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/build-aux/ 
--force

| autoreconf: configure.ac: tracing
| autoreconf: configure.ac: creating directory 
$TOPDIR/common/autoconf/build-aux
| autoreconf: error: cannot create $TOPDIR/common/autoconf/build-aux: No 
such file or directory

| autoreconf: configure.ac: not using Libtool
| autoreconf: configure.ac: not using Intltool
| autoreconf: configure.ac: not using Gtkdoc
| autoreconf: running: 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/recipe-sysroot-native/usr/bin/autoconf 
--include=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/ 
--include=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/build-aux/ 
--force
| autoreconf: running: 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/recipe-sysroot-native/usr/bin/autoheader 
--include=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/ 
--include=/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/jdk8u-jdk8u272-ga/common/autoconf/build-aux/ 
--force

| autoreconf: configure.ac: not using Automake
| Error in tempfile() using template 
$TOPDIR/common/autoconf/build-aux/XX: Parent directory 
($TOPDIR/common/autoconf/build-aux/) does not exist at 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/recipe-sysroot-native/usr/bin/autoreconf 
line 411.
| WARNING: 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646:284 
exit 1 from 'exit 1'

| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646, 
line 284
|     #2: die, 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646, 
line 274
|     #3: autotools_do_configure, 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646, 
line 236
|     #4: do_configure, 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646, 
line 160
|     #5: main, 
/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646, 
line 298

|
| Backtrace (metadata-relative locations):
|     #1: bbfatal_log, /home/.../oe-core/meta/classes/logging.bbclass, 
line 72

|     #2: die, /home/.../oe-core/meta/classes/base.bbclass, line 56
|     #3: autotools_do_configure, 
/home/.../oe-core/meta/classes/autotools.bbclass, line 224

|     #4: do_configure, autogenerated, line 6
ERROR: Task 
(/home/.../meta-java/recipes-core/openjdk/openjdk-8-native_272.bb:do_configure) 
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4517 tasks of which 4312 didn't need to 
be rerun and 1 failed.


Summary: 1 task failed:
/home/.../meta-java/recipes-core/openjdk/openjdk-8-native_272.bb:do_configure





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#90273): 
https://lists.openembedded.org/g/openembedded-devel/message/90273
Mute This Topic: https://lists.openembedded.org/mt/81520404/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

But that yields something that doesn't work runtime:

# java -version
Error: dl failure on line 893
Error: failed /usr/lib/jvm/openjre-8/lib/aarch64/server/libjvm.so, 
because /usr/lib/jvm/openjre-8/lib/aarch64/server/libjvm.so: undefined 
symbol: _ZN17FloatRegisterImpl8as_VMRegEv





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 16:36, Mike Looijmans via lists.openembedded.org wrote:
If I just bluntly set the CFLAGS and CXXFLAGS like in the attached 
patch, then the compile succeeds.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 16:04, Mike Looijmans via lists.openembedded.org wrote:

In Line 72 of that makefile:

# set flags for adlc compilation
CXXFLAGS = $(SYSDEFS) $(INCLUDES)


So that kills the patch I guess



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 15:52, Mike Looijmans via lists.openembedded.org wrote:
Yes, the patch does get applied, I can see the extra lines in the 
work directory.


But it somehow doesn't quite work...




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 13:36, Richard Leitner wrote:

If I get it right these flags should be filtered out by the adlc flags
patch [1].

Can you verify that it's getting applied?

Unfortunately I don't have a gcc-7 host machine available right now 

regards;rl

[1]https://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/patches-openjdk-8/1009-hotspot-fix-adlc-flags.patch 



On Mon, Mar 22, 2021 at 01:15:14PM +0100, Mike Looijmans wrote:

Both "gatesgarth".

Issue seems to be that the build host (Ubuntu 18) has gcc 7 and 
the one used
for cross-compiling is much newer. Apparently there's something 
wrong in the

makefile that it uses host compiler flags for the build compiler.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 12:53, Richard Leitner wrote:

Hi Mike,

which meta-java and oe-core branch are you using?

regards;rl

On Mon, Mar 22, 2021 at 10:43:53AM +0100, Mike Looijmans wrote:

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_c.o' failed
| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/main.o' failed
| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_h.o' failed
| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91:

recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:28

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

If I just bluntly set the CFLAGS and CXXFLAGS like in the attached 
patch, then the compile succeeds.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 16:04, Mike Looijmans via lists.openembedded.org wrote:

In Line 72 of that makefile:

# set flags for adlc compilation
CXXFLAGS = $(SYSDEFS) $(INCLUDES)


So that kills the patch I guess



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 15:52, Mike Looijmans via lists.openembedded.org wrote:
Yes, the patch does get applied, I can see the extra lines in the 
work directory.


But it somehow doesn't quite work...




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 13:36, Richard Leitner wrote:

If I get it right these flags should be filtered out by the adlc flags
patch [1].

Can you verify that it's getting applied?

Unfortunately I don't have a gcc-7 host machine available right now 

regards;rl

[1]https://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/patches-openjdk-8/1009-hotspot-fix-adlc-flags.patch 



On Mon, Mar 22, 2021 at 01:15:14PM +0100, Mike Looijmans wrote:

Both "gatesgarth".

Issue seems to be that the build host (Ubuntu 18) has gcc 7 and the 
one used
for cross-compiling is much newer. Apparently there's something 
wrong in the

makefile that it uses host compiler flags for the build compiler.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 12:53, Richard Leitner wrote:

Hi Mike,

which meta-java and oe-core branch are you using?

regards;rl

On Mon, Mar 22, 2021 at 10:43:53AM +0100, Mike Looijmans wrote:

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_c.o' failed
| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/main.o' failed
| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_h.o' failed
| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91:

recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:284:

recipe for target 'product' failed
| make[4]: *** [product] Error 2
| Makefile:230: recipe for target 'generic_build2' failed
| make[3]: *** [generic_build2] Error 2
| make[2]: *** [product] Error 2
| Makefile:177: recipe for target 'product' failed
| HotspotWrapper.gmk:44: recipe for target 
'/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp'

failed
| make[1]: *** 
[/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp]

Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10//mak

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

In Line 72 of that makefile:

# set flags for adlc compilation
CXXFLAGS = $(SYSDEFS) $(INCLUDES)


So that kills the patch I guess



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 15:52, Mike Looijmans via lists.openembedded.org wrote:
Yes, the patch does get applied, I can see the extra lines in the work 
directory.


But it somehow doesn't quite work...




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 13:36, Richard Leitner wrote:

If I get it right these flags should be filtered out by the adlc flags
patch [1].

Can you verify that it's getting applied?

Unfortunately I don't have a gcc-7 host machine available right now 

regards;rl

[1]https://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/patches-openjdk-8/1009-hotspot-fix-adlc-flags.patch 



On Mon, Mar 22, 2021 at 01:15:14PM +0100, Mike Looijmans wrote:

Both "gatesgarth".

Issue seems to be that the build host (Ubuntu 18) has gcc 7 and the 
one used
for cross-compiling is much newer. Apparently there's something 
wrong in the

makefile that it uses host compiler flags for the build compiler.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 12:53, Richard Leitner wrote:

Hi Mike,

which meta-java and oe-core branch are you using?

regards;rl

On Mon, Mar 22, 2021 at 10:43:53AM +0100, Mike Looijmans wrote:

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_c.o' failed
| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/main.o' failed
| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:

recipe for target '../generated/adfiles/output_h.o' failed
| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91:

recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:284:

recipe for target 'product' failed
| make[4]: *** [product] Error 2
| Makefile:230: recipe for target 'generic_build2' failed
| make[3]: *** [generic_build2] Error 2
| make[2]: *** [product] Error 2
| Makefile:177: recipe for target 'product' failed
| HotspotWrapper.gmk:44: recipe for target 
'/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp'

failed
| make[1]: *** 
[/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp]

Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10//make/Main.gmk:109:

recipe for target 'hotspot-only' failed
| make: *** [hotspot-only] Error 2
| WARNING: 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267:189

exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,

line 189
|     #2: die, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/2

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

Yes, the patch does get applied, I can see the extra lines in the work 
directory.


But it somehow doesn't quite work...




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 13:36, Richard Leitner wrote:

If I get it right these flags should be filtered out by the adlc flags
patch [1].

Can you verify that it's getting applied?

Unfortunately I don't have a gcc-7 host machine available right now 

regards;rl

[1]https://git.yoctoproject.org/cgit/cgit.cgi/meta-java/tree/recipes-core/openjdk/patches-openjdk-8/1009-hotspot-fix-adlc-flags.patch

On Mon, Mar 22, 2021 at 01:15:14PM +0100, Mike Looijmans wrote:

Both "gatesgarth".

Issue seems to be that the build host (Ubuntu 18) has gcc 7 and the one used
for cross-compiling is much newer. Apparently there's something wrong in the
makefile that it uses host compiler flags for the build compiler.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 12:53, Richard Leitner wrote:

Hi Mike,

which meta-java and oe-core branch are you using?

regards;rl

On Mon, Mar 22, 2021 at 10:43:53AM +0100, Mike Looijmans wrote:

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/output_c.o' failed
| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/main.o' failed
| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/output_h.o' failed
| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91:
recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:284:
recipe for target 'product' failed
| make[4]: *** [product] Error 2
| Makefile:230: recipe for target 'generic_build2' failed
| make[3]: *** [generic_build2] Error 2
| make[2]: *** [product] Error 2
| Makefile:177: recipe for target 'product' failed
| HotspotWrapper.gmk:44: recipe for target 
'/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp'
failed
| make[1]: *** 
[/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp]
Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10//make/Main.gmk:109:
recipe for target 'hotspot-only' failed
| make: *** [hotspot-only] Error 2
| WARNING: 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267:189
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 189
|     #2: die, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 179
|     #3: oe_runmake, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 168
|     #4: autotools_do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 163
|     #5: do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 158
|     #6: main, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.

Re: [oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

Both "gatesgarth".

Issue seems to be that the build host (Ubuntu 18) has gcc 7 and the one 
used for cross-compiling is much newer. Apparently there's something 
wrong in the makefile that it uses host compiler flags for the build 
compiler.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 12:53, Richard Leitner wrote:

Hi Mike,

which meta-java and oe-core branch are you using?

regards;rl

On Mon, Mar 22, 2021 at 10:43:53AM +0100, Mike Looijmans wrote:

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/output_c.o' failed
| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/main.o' failed
| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228:
recipe for target '../generated/adfiles/output_h.o' failed
| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91:
recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:284:
recipe for target 'product' failed
| make[4]: *** [product] Error 2
| Makefile:230: recipe for target 'generic_build2' failed
| make[3]: *** [generic_build2] Error 2
| make[2]: *** [product] Error 2
| Makefile:177: recipe for target 'product' failed
| HotspotWrapper.gmk:44: recipe for target 
'/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp'
failed
| make[1]: *** 
[/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp]
Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10//make/Main.gmk:109:
recipe for target 'hotspot-only' failed
| make: *** [hotspot-only] Error 2
| WARNING: 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267:189
exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 189
|     #2: die, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 179
|     #3: oe_runmake, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 168
|     #4: autotools_do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 163
|     #5: do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 158
|     #6: main, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267,
line 202
|
| Backtrace (metadata-relative locations):
|     #1: bbfatal_log, /.../oe-core/meta/classes/logging.bbclass, line 72
|     #2: die, /.../oe-core/meta/classes/base.bbclass, line 56
|     #3: oe_runmake, /.../oe-core/meta/classes/base.bbclass, line 65
|     #4: autotools_do_compile, /.../oe-core/meta/classes/autotools.bbclass,
line 243
|     #5: do_compile, autogenerated, line 2
ERROR: Task
(/.../meta-java/recipes-core/openjdk/openjre-8_272.bb:do_compile) failed
with exit code '1'

--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail



--
Mike Looijmans


-=-=-=-=-=-=-=-=-=-=-=-
Links: Y

[oe] [meta-java] openjre8 fails to compile on aarch64

[Mike Looijmans]

I cannot get openjre8 to compile. Any ideas what the real issue is?

Compile for 32-bit ARM is okay, but building for aarch64 fails:

...
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228: 
recipe for target '../generated/adfiles/output_c.o' failed

| make[6]: *** [../generated/adfiles/output_c.o] Error 1
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228: 
recipe for target '../generated/adfiles/main.o' failed

| make[6]: *** [../generated/adfiles/main.o] Error 1
| g++: error: unrecognized command line option 
‘-fmacro-prefix-map=/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0=/usr/src/debug/openjre-8/272-r0’
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/adlc.make:228: 
recipe for target '../generated/adfiles/output_h.o' failed

| make[6]: *** [../generated/adfiles/output_h.o] Error 1
| make[5]: *** [ad_stuff] Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/makefiles/top.make:91: 
recipe for target 'ad_stuff' failed
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10/hotspot/make/linux/Makefile:284: 
recipe for target 'product' failed

| make[4]: *** [product] Error 2
| Makefile:230: recipe for target 'generic_build2' failed
| make[3]: *** [generic_build2] Error 2
| make[2]: *** [product] Error 2
| Makefile:177: recipe for target 'product' failed
| HotspotWrapper.gmk:44: recipe for target 
'/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp' 
failed
| make[1]: *** 
[/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/build/hotspot/_hotspot.timestamp] 
Error 2
| 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/jdk8u-shenandoah-aarch64-shenandoah-jdk8u272-b10//make/Main.gmk:109: 
recipe for target 'hotspot-only' failed

| make: *** [hotspot-only] Error 2
| WARNING: 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267:189 
exit 1 from 'exit 1'

| WARNING: Backtrace (BB generated script):
|     #1: bbfatal_log, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 189
|     #2: die, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 179
|     #3: oe_runmake, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 168
|     #4: autotools_do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 163
|     #5: do_compile, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 158
|     #6: main, 
/.../build/tmp-glibc/work/cortexa72-oe-linux/openjre-8/272-r0/temp/run.do_compile.9267, 
line 202

|
| Backtrace (metadata-relative locations):
|     #1: bbfatal_log, /.../oe-core/meta/classes/logging.bbclass, line 72
|     #2: die, /.../oe-core/meta/classes/base.bbclass, line 56
|     #3: oe_runmake, /.../oe-core/meta/classes/base.bbclass, line 65
|     #4: autotools_do_compile, 
/.../oe-core/meta/classes/autotools.bbclass, line 243

|     #5: do_compile, autogenerated, line 2
ERROR: Task 
(/.../meta-java/recipes-core/openjdk/openjre-8_272.bb:do_compile) failed 
with exit code '1'


--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#90251): 
https://lists.openembedded.org/g/openembedded-devel/message/90251
Mute This Topic: https://lists.openembedded.org/mt/81520404/21656
Group Owner: openembedded-devel+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[oe] [warrior][meta-qt4][PATCH] qt4: Apply build fix for GCC8 to both x11 and embedded variants

[Mike Looijmans]

The fix to remove "volatile" also applies to the x11 version of Qt, so apply the
patch for both variants by moving it to the common qt4-${PV} include file. This 
fixes
that the 32-bit version of qt4-x11 fails to build with the same error as 
qt4-embedded.

Signed-off-by: Mike Looijmans 
---
 recipes-qt4/qt4/qt4-4.8.7.inc| 1 +
 recipes-qt4/qt4/qt4-embedded.inc | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4-4.8.7.inc b/recipes-qt4/qt4/qt4-4.8.7.inc
index eea6061..fae7df8 100644
--- a/recipes-qt4/qt4/qt4-4.8.7.inc
+++ b/recipes-qt4/qt4/qt4-4.8.7.inc
@@ -28,6 +28,7 @@ SRC_URI = 
"http://download.qt-project.org/archive/qt/4.8/${PV}/qt-everywhere-ope
file://0035-Add-nios2-support.patch \
file://0036-qt-everywhere-opensource-src-4.8.7-gcc6.patch \
   file://0037-fix-configure-with-icu60.patch \
+   
file://0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch \
file://gcc-version.patch \
file://Fix-QWSLock-invalid-argument-logs.patch \
file://add_check_for_aarch64_32.patch \
diff --git a/recipes-qt4/qt4/qt4-embedded.inc b/recipes-qt4/qt4/qt4-embedded.inc
index 5298d65..9c2d9da 100644
--- a/recipes-qt4/qt4/qt4-embedded.inc
+++ b/recipes-qt4/qt4/qt4-embedded.inc
@@ -12,7 +12,6 @@ QT_BASE_LIB  ?= "libqt-embedded"
 # Set necessary variables in the profile
 SRC_URI += "file://qte.sh \
 file://0033-configure-support-c-0x-standard-for-directfd.patch \
-
file://0038-3rdparty-javascriptcore-JITStubs.cpp-allow-builds-of.patch \
 "
 
 QT_EMBEDDED_FLAGS ?= " \
-- 
2.17.1

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

[oe] [warrior] [meta-qt4] qt4-xqq fails to compile on arm64

[Mike Looijmans]

Apparently there's some cross-compiler badness in the Qt4-x11 stuff, since it 
attempts to use something from /usr/include.

Am I the only one seeing this, or is there a known workaround?


The error looks like this:


In file included from 
/home/mike/projects/my-desktop/build/tmp-glibc/work/aarch64-oe-linux/qt4-x11-free/4.8.7-r0/recipe-sysroot/usr/include/stdlib.h:55,
   from 
/home/mike/projects/my-desktop/build/tmp-glibc/work/aarch64-oe-linux/qt4-x11-free/4.8.7-r0/recipe-sysroot/usr/include/c++/8.3.0/cstdlib:75,
   from 
/home/mike/projects/my-desktop/build/tmp-glibc/work/aarch64-oe-linux/qt4-x11-free/4.8.7-r0/recipe-sysroot/usr/include/c++/8.3.0/bits/stl_algo.h:59,
   from 
/home/mike/projects/my-desktop/build/tmp-glibc/work/aarch64-oe-linux/qt4-x11-free/4.8.7-r0/recipe-sysroot/usr/include/c++/8.3.0/algorithm:62,
   from 
../../../include/QtCore/../../src/corelib/global/qglobal.h:68,
   from ../../../include/QtCore/qglobal.h:1,
   from 
../../../include/QtCore/../../src/corelib/global/qnamespace.h:45,
   from ../../../include/QtCore/qnamespace.h:1,
   from 
../../../include/QtCore/../../src/corelib/kernel/qobjectdefs.h:45,
   from ../../../include/QtCore/qobjectdefs.h:1,
   from 
../../../include/QtGui/../../src/gui/kernel/qwindowdefs.h:45,
   from ../../../include/QtGui/qwindowdefs.h:1,
   from 
../../../include/QtGui/../../src/gui/kernel/qwidget.h:46,
   from ../../../include/QtGui/qwidget.h:1,
   from ../../../include/QtGui/QWidget:1,
   from testwidget.h:44,
   from main.cpp:41:
/usr/include/bits/floatn.h:87:9: error: '__float128' does not name a type; did 
you mean '__cfloat128'?
   typedef __float128 _Float128;
   ^~
   __cfloat128

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
Postbus 440, 5680 AK Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
-- 
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] Python3 bytecode is stale

[Mike Looijmans]

On 25-01-19 18:26, Stefan Agner wrote:
> On 25.01.2019 15:35, Mike Looijmans wrote:
>> Most likely the date/time stamps on the files are such that the "py" files
>> appear to be newer.
> 
> Indeed, this seems to be the issue. We are using OSTree, which removes
> mtimes. Ricardo (now on CC) also pointed me to the relevant issue in
> OSTree:
> https://github.com/ostreedev/ostree/issues/1469
> 
>>
>> A very simple fix would be to simply delete the ".py" files, they aren't
>> really needed anyway so you'll save a lot of space in the process.
>>
>> To do this compile-time, you could add something like this in a bbappend:
>> PACKAGES =+ "${PN}-src"
>> FILES_${PN}-src = "{installdir}/*.py {installdir}/*/*.py"
>>
>> That'll push the "py" files into another package and prevent them being
>> installed by default. Change "{installdir}" into something more appropriate.
>> Of just delete them in a do_install_append.
> 
> Hm, interesting idea, will give this a try.
> 
> Wouldn't be something like this be a nice OpenEmbedded addition in
> general? Optimizing embedded rootfs size by deleting py files seems to
> be a common use case.

Here's a bbappend example for python:

https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-devtools/python/python_2.7.13.bbappend#L20

> In a simple test deleting all py files on my rootfs did not go well (the
> application does not start anymore). I need to investigate further.

The "main" module (the one started from commandline) needs to be in .py 
format still, otherwise you cannot "run" it. As a workaround, you can 
run it using "python -m", or make sure that that one .py file gets 
installed.

It's actually even possible to put the pyc files into a ZIP file and 
load directly from that at runtime. This reduces the number of files. On 
a compressed filesystem, this won't make a difference of course, and is 
likely to increase the total size.

--
M.

> 
> --
> Stefan
> 
>>
>>
>> On 25-01-19 14:46, Stefan Agner wrote:
>>> Hi,
>>>
>>> Recently I noticed that Python3 programs got rather slow. Running the
>>> test application took 12.5 seconds. We are using a read-only file system
>>> and I immediately suspected the bytecode cache. After mounting the
>>> rootfs rw, from the second execution on running the test application
>>> took below 4 seconds.
>>>
>>> By simply executing a Hello World, Python declares all code objects as
>>> being stale and tries to rewrite them:
>>>
>>> # python3 -v -c 'print("Hello World")'
>>> import _frozen_importlib # frozen
>>> import _imp # builtin
>>> import sys # builtin
>>> import '_warnings' # 
>>> import '_thread' # 
>>> import '_weakref' # 
>>> import '_frozen_importlib_external' # >> '_frozen_importlib.FrozenImporter'>
>>> import '_io' # 
>>> import 'marshal' # 
>>> import 'posix' # 
>>> import _thread # previously loaded ('_thread')
>>> import '_thread' # 
>>> import _weakref # previously loaded ('_weakref')
>>> import '_weakref' # 
>>> # installing zipimport hook
>>> import 'zipimport' # 
>>> # installed zipimport hook
>>> # bytecode is stale for 'encodings'
>>> # code object from /usr/lib/python3.5/encodings/__init__.py
>>> # could not create
>>> '/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc':
>>> OSError(30, 'Read-only file system')
>>> # wrote
>>> '/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc'
>>> # bytecode is stale for 'codecs'
>>> # code object from /usr/lib/python3.5/codecs.py
>>> # could not create
>>> '/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc': OSError(30,
>>> 'Read-only file system')
>>> # wrote '/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc'
>>> import '_codecs' # 
>>> import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at
>>> 0xb6b33130>
>>> # bytecode is stale for 'encodings.aliases'
>>> # code object from /usr/lib/python3.5/encodings/aliases.py
>>> # could not create
>>> '/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc':
>>> OSError(30, 'Read-only file system')
>>> # wrote
>>> '/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc'
>>> import 'encodings.aliases' #
>>> <_frozen_importlib_external.SourceFileLoader

Re: [oe] Python3 bytecode is stale

[Mike Looijmans]

Most likely the date/time stamps on the files are such that the "py" files 
appear to be newer.

A very simple fix would be to simply delete the ".py" files, they aren't 
really needed anyway so you'll save a lot of space in the process.

To do this compile-time, you could add something like this in a bbappend:
PACKAGES =+ "${PN}-src"
FILES_${PN}-src = "{installdir}/*.py {installdir}/*/*.py"

That'll push the "py" files into another package and prevent them being 
installed by default. Change "{installdir}" into something more appropriate.
Of just delete them in a do_install_append.


On 25-01-19 14:46, Stefan Agner wrote:
> Hi,
> 
> Recently I noticed that Python3 programs got rather slow. Running the
> test application took 12.5 seconds. We are using a read-only file system
> and I immediately suspected the bytecode cache. After mounting the
> rootfs rw, from the second execution on running the test application
> took below 4 seconds.
> 
> By simply executing a Hello World, Python declares all code objects as
> being stale and tries to rewrite them:
> 
> # python3 -v -c 'print("Hello World")'
> import _frozen_importlib # frozen
> import _imp # builtin
> import sys # builtin
> import '_warnings' # 
> import '_thread' # 
> import '_weakref' # 
> import '_frozen_importlib_external' #  '_frozen_importlib.FrozenImporter'>
> import '_io' # 
> import 'marshal' # 
> import 'posix' # 
> import _thread # previously loaded ('_thread')
> import '_thread' # 
> import _weakref # previously loaded ('_weakref')
> import '_weakref' # 
> # installing zipimport hook
> import 'zipimport' # 
> # installed zipimport hook
> # bytecode is stale for 'encodings'
> # code object from /usr/lib/python3.5/encodings/__init__.py
> # could not create
> '/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc':
> OSError(30, 'Read-only file system')
> # wrote
> '/usr/lib/python3.5/encodings/__pycache__/__init__.cpython-35.pyc'
> # bytecode is stale for 'codecs'
> # code object from /usr/lib/python3.5/codecs.py
> # could not create
> '/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc': OSError(30,
> 'Read-only file system')
> # wrote '/usr/lib/python3.5/__pycache__/codecs.cpython-35.pyc'
> import '_codecs' # 
> import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at
> 0xb6b33130>
> # bytecode is stale for 'encodings.aliases'
> # code object from /usr/lib/python3.5/encodings/aliases.py
> # could not create
> '/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc':
> OSError(30, 'Read-only file system')
> # wrote
> '/usr/lib/python3.5/encodings/__pycache__/aliases.cpython-35.pyc'
> import 'encodings.aliases' #
> <_frozen_importlib_external.SourceFileLoader object at 0xb6b3d9d0>
> import 'encodings' # <_frozen_importlib_external.SourceFileLoader object
> at 0xb6b154b0>
> # bytecode is stale for 'encodings.ascii'
> # code object from /usr/lib/python3.5/encodings/ascii.py
> # could not create
> '/usr/lib/python3.5/encodings/__pycache__/ascii.cpython-35.pyc':
> OSError(30, 'Read-only file system')
> # wrote '/usr/lib/python3.5/encodings/__pycache__/ascii.cpython-35.pyc'
> import 'encodings.ascii' # <_frozen_importlib_external.SourceFileLoader
> object at 0xb6b3db10>
> import '_signal' # 
> 
> 
> 
> This is on a Armv7 device. OpenEmbedded layers are current master.
> Python version is 3.5.6. Is this a known issue? Any idea?
> 
> --
> Stefan
> 

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

[oe] [PATCH][meta-filesystems] fuse: Remove unneeded RDEPENDS on util-linux-mount

[Mike Looijmans]

Fuse claimed to need util-linux-mount at runtime, which isn't true. This
drags util-linux-mount into any image that uses fuse.

Encountered no problems with busybox's mount command and fuse (and never
had). Fuse doesn't call the "mount" program anywhere, so the dependency
doesn't make sense anyway.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb 
b/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
index 9a2dc11..153fcb4 100644
--- a/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
+++ b/meta-filesystems/recipes-support/fuse/fuse_2.9.4.bb
@@ -29,9 +29,6 @@ DEPENDS = "gettext-native"
 
 PACKAGES =+ "fuse-utils-dbg fuse-utils libulockmgr libulockmgr-dev 
libulockmgr-dbg"
 
-# Fusermount requires features from the util-linux version of mount.
-RDEPENDS_${PN}_class-target += "util-linux-mount"
-
 RRECOMMENDS_${PN}_class-target = "kernel-module-fuse libulockmgr fuse-utils"
 
 FILES_${PN} += "${libdir}/libfuse.so.*"
-- 
2.1.4

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

Re: [oe] morty branch XFCE no longer builds, missing libwnck3

[Mike Looijmans]

There's no trace of any attempt to bring back 'libwnck3' in the morty branch, 
am I the only one in the world using morty to build an XCFE image?



On 21-12-16 02:33, akuster808 wrote:



On 12/20/2016 03:53 AM, Andreas Müller wrote:

On Tue, Dec 20, 2016 at 10:54 AM, Mike Looijmans
<mike.looijm...@topic.nl> wrote:

With current "morty" branches of OE-core and meta-openembedded, a build of
an xfce desktop image fails:

There is a patch pending merge to Morty sitting in my morty-next

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akuster/morty-next=4cb131f10885a84489cbcd3750a45f64f0547cda


I will send a pull request.

- armin


NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'libwnck3' (but
/.../meta-oe/meta-xfce/recipes-panel-plugins/hotcorner/xfce4-hotcorner-plugin_0.0.2.bb

DEPENDS on or otherwise requires it). Close matches:
   libwnck
NOTE: Runtime target 'xfce4-hotcorner-plugin' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['xfce4-hotcorner-plugin',
'libwnck3']
NOTE: Runtime target 'packagegroup-xfce-extended' is unbuildable,
removing...
Missing or unbuildable dependency chain was: ['packagegroup-xfce-extended',
'xfce4-hotcorner-plugin', 'libwnck3']
NOTE: Runtime target 'desktop-image' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['desktop-image',
'packagegroup-xfce-extended', 'xfce4-hotcorner-plugin', 'libwnck3']




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



So we need in morty at least

commit 5b0060bbbacf405405e292e8a8e5db9589f63325
Author: Alexander Kanavin <alexander.kana...@linux.intel.com>
Date:   Tue Nov 1 17:28:21 2016 +0200

 libwnck3: add a recipe

 It is no longer needed in oe-core.

 Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com>
 Signed-off-by: Martin Jansa <martin.ja...@gmail.com>


and maybe (don't know the status of gnome.bbclass in morty) - but
should not do any harm

commit 3be9eea720ba70fd3a9e4744401fd268e31731f8
Author: Khem Raj <raj.k...@gmail.com>
Date:   Mon Dec 5 18:36:21 2016 -0800

 libwnck3: Add missing dependency on gnome-common-native

 Fixes configure errors
 ../libwnck-3.20.1/configure: line 13391: syntax error near
unexpected token `maximum'
 ../libwnck-3.20.1/configure: line 13391: `GNOME_COMPILE_WARNINGS(maximum)'

 Signed-off-by: Khem Raj <raj.k...@gmail.com>
 Signed-off-by: Martin Jansa <martin.ja...@gmail.com>






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] morty branch XFCE no longer builds, missing libwnck3

[Mike Looijmans]

With current "morty" branches of OE-core and meta-openembedded, a build of an 
xfce desktop image fails:


NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'libwnck3' (but 
/.../meta-oe/meta-xfce/recipes-panel-plugins/hotcorner/xfce4-hotcorner-plugin_0.0.2.bb 
DEPENDS on or otherwise requires it). Close matches:

  libwnck
NOTE: Runtime target 'xfce4-hotcorner-plugin' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['xfce4-hotcorner-plugin', 
'libwnck3']

NOTE: Runtime target 'packagegroup-xfce-extended' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-xfce-extended', 
'xfce4-hotcorner-plugin', 'libwnck3']

NOTE: Runtime target 'desktop-image' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['desktop-image', 
'packagegroup-xfce-extended', 'xfce4-hotcorner-plugin', 'libwnck3']





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [meta-oe][morty][PATCH] libwnck3: Resurrect recipe

[Mike Looijmans]

libwnck3 moved to OE-core, then OE-core removed all dependencies on it
and removed the recipe, so now it's gone. Bring back the recipe into
meta-openembedded.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-gnome/recipes-gnome/libwnck/libwnck3_3.20.1.bb | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 meta-gnome/recipes-gnome/libwnck/libwnck3_3.20.1.bb

diff --git a/meta-gnome/recipes-gnome/libwnck/libwnck3_3.20.1.bb 
b/meta-gnome/recipes-gnome/libwnck/libwnck3_3.20.1.bb
new file mode 100644
index 000..d3c3a86
--- /dev/null
+++ b/meta-gnome/recipes-gnome/libwnck/libwnck3_3.20.1.bb
@@ -0,0 +1,19 @@
+SUMMARY = "Window navigation construction toolkit"
+LICENSE = "LGPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
+
+BPN = "libwnck"
+
+SECTION = "x11/libs"
+DEPENDS = "intltool-native gtk+3 gdk-pixbuf-native libxres"
+
+PACKAGECONFIG ??= "startup-notification"
+PACKAGECONFIG[startup-notification] = 
"--enable-startup-notification,--disable-startup-notification,startup-notification"
+
+inherit gnomebase gobject-introspection
+SRC_URI[archive.md5sum] = "487938d65d4bfae1f2501052b1bd7492"
+SRC_URI[archive.sha256sum] = 
"1cb03716bc477058dfdf3ebfa4f534de3b13b1aa067fcd064d0b7813291cba72"
+
+inherit distro_features_check
+# libxres means x11 only
+REQUIRED_DISTRO_FEATURES = "x11"
-- 
1.9.1

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

Re: [oe] [meta-qt4][PATCH] qt4-embedded: Default to build tslib when touchscreen is defined

[Mike Looijmans]

Having some more experience with it, my suggestion would be to REVERT 
c4671873af5ab6c7d15ca397538f154c11c3486e "qt4-embedded.inc: provide 
PACKAGECONFIG for tslib".


The problem with using MACHINE_FEATURES for building the qt4 libs is that the 
qt4 package becomes machine-specific, and if you're buiding for multiple 
machines (with and without touchscreen), there'll be lots of "setstate" 
activity to take care of that.


Building tslib hardly hurts, it's a small dependency, while building qt4 takes 
something like 5 minutes on our big ass i7 build server. And deciding not to 
install the plugin is quite efficient.


At the very least, "tslib" should be in the default config.

I don't know the rationale behind commit c4671873af5, if reducing compile time 
was the incentive, it's not really paying off. Time would be better spent 
avoiding building "perl" or "bash"...



On 31-10-16 15:12, Max Krummenacher wrote:

Hi

I sent a similar patch:
https://lists.yoctoproject.org/pipermail/yocto/2016-October/032661.html

Both fix the build error with the HEAD of meta-qt4.

Question is if "touchscreen" in MACHINE_FEATURES should build for
tslib by default.
If yes, your patch is needed.

However the error will pop up again if someone chooses to set
PACKAGECONFIG to not include tslib.
That would be handled by the patch above, so applying both patches
would fix the problem and default to having tslib support.

Max

P.S.What is the 'correct' mailinglist for meta-qt4?

2016-10-31 8:29 GMT+01:00 Mike Looijmans <mike.looijm...@topic.nl>:

When "touchscreen" is in the MACHINE_FEATURES, packagegroup-core-qt4e
will RDEPEND on qt4-embedded-plugin-mousedriver-tslib, but that
library is not being built by default, resulting in an error like:
opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'qt4-embedded-plugin-mousedriver-tslib'.

To prevent that from happening, add "tslib" to the default
PACKAGECONFIG when touchscreen is defined.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Applies to both morty and master branches.

 recipes-qt4/qt4/qt4-embedded.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4-embedded.inc b/recipes-qt4/qt4/qt4-embedded.inc
index 1122080..9c2d9da 100644
--- a/recipes-qt4/qt4/qt4-embedded.inc
+++ b/recipes-qt4/qt4/qt4-embedded.inc
@@ -3,7 +3,7 @@ DESCRIPTION = "Qt is a versatile cross-platform application 
framework -- this is
 SECTION = "libs"
 HOMEPAGE = "http://qt-project.org/;

-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= '${@bb.utils.contains("MACHINE_FEATURES", "touchscreen", "tslib", 
"",d)}'
 PACKAGECONFIG[tslib] = " -plugin-mouse-tslib, ,tslib"

 QT4EDEPENDS = ""
--
1.9.1

--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

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] [meta-qt4][PATCH] qt4-embedded: Default to build tslib when touchscreen is defined

[Mike Looijmans]

When "touchscreen" is in the MACHINE_FEATURES, packagegroup-core-qt4e
will RDEPEND on qt4-embedded-plugin-mousedriver-tslib, but that
library is not being built by default, resulting in an error like:
opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'qt4-embedded-plugin-mousedriver-tslib'.

To prevent that from happening, add "tslib" to the default
PACKAGECONFIG when touchscreen is defined.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Applies to both morty and master branches.

 recipes-qt4/qt4/qt4-embedded.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-qt4/qt4/qt4-embedded.inc b/recipes-qt4/qt4/qt4-embedded.inc
index 1122080..9c2d9da 100644
--- a/recipes-qt4/qt4/qt4-embedded.inc
+++ b/recipes-qt4/qt4/qt4-embedded.inc
@@ -3,7 +3,7 @@ DESCRIPTION = "Qt is a versatile cross-platform application 
framework -- this is
 SECTION = "libs"
 HOMEPAGE = "http://qt-project.org/;
 
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= '${@bb.utils.contains("MACHINE_FEATURES", "touchscreen", 
"tslib", "",d)}'
 PACKAGECONFIG[tslib] = " -plugin-mouse-tslib, ,tslib"
 
 QT4EDEPENDS = ""
-- 
1.9.1

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

[oe] [meta-networking][PATCH v5] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v5: Correct revision, v4 got sent with the v3 patch contents
v4: Add comment on why $bindir is not being used
v3: Add SRCPV to PV
Indent using spaces instead of tab
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)
 meta-networking/recipes-support/phytool/phytool.bb | 15 +++
 1 file changed, 15 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..4ed3ed1
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,15 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1+git${SRCPV}"
+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+# The Makefile has "$PREFIX/bin" hardcoded into it, hence not using $bindir 
here
+do_install() {
+install -d ${D}${prefix}/bin
+oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
-- 
1.9.1

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

[oe] [meta-networking][PATCH v4] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v4: Add comment on why $bindir is not being used
v3: Add SRCPV to PV
Indent using spaces instead of tab
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)

 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..e4391df
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1+git${SRCPV}"
+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+install -d ${D}${prefix}/bin
+oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
-- 
1.9.1

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

Re: [oe] [meta-networking][PATCH v3] phytool: Add recipe

[Mike Looijmans]

On 07-10-16 08:10, Koen Kooi wrote:

Op 06-10-16 om 07:59 schreef Mike Looijmans:

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v3: Add SRCPV to PV
Indent using spaces instead of tab
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)
 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..e4391df
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1+git${SRCPV}"
+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+install -d ${D}${prefix}/bin


${D}${bindir}


The makefile installs to $PREFIX/bin so I deliberately put the same folder in 
the recipe (the makefile doesn't create the directory). If anyone changes 
$bindir the install will fail.


I see I need to add a comment to explain that.


+oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}








Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [meta-networking][PATCH v3] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v3: Add SRCPV to PV
Indent using spaces instead of tab
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)
 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..e4391df
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1+git${SRCPV}"
+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+install -d ${D}${prefix}/bin
+oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
-- 
1.9.1

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

Re: [oe] [meta-networking][PATCH v2] phytool: Add recipe

[Mike Looijmans]

On 05-10-16 18:32, Martin Jansa wrote:

On Wed, Oct 05, 2016 at 08:38:07AM -0700, Khem Raj wrote:

On Wed, Oct 5, 2016 at 2:34 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)

 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..d451aa9
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1"


perhaps its better to include SRCPV in PV above since the SRCREV
below is really 1.0.1+some more commits. moreover we get srcrev
accounted for task hashes


Will do.




+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+   install -d ${D}${prefix}/bin
+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install


We're not using tabs for indentation.
see http://www.openembedded.org/wiki/Styleguide


Will fix in v3.

I also want to move it to another location in meta-oe, because meta-networking 
depends on meta-python and it's really weird to have to add meta-python to 
your layers just to get a simple C binary tool.


Mike.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [meta-networking][PATCH v2] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2: Fix LICENSE filename and checksum
Honor LDFLAGS value (patch accepted upstream)

 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..d451aa9
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1"
+SRCREV = "3149bfdb4f513e2f0da0a7d0bc5d0873578696f2"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+   install -d ${D}${prefix}/bin
+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
-- 
1.9.1

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

Re: [oe] [meta-networking][PATCH] phytool: Add recipe

[Mike Looijmans]

On 28-09-16 09:30, Mike Looijmans wrote:

On 26-09-16 22:34, Martin Jansa wrote:

2 more issues:

WARNING: phytool-1.0.1-r0 do_populate_lic: Could not copy license file
phytool/1.0.1-r0/git/COPYING to
phytool/1.0.1-r0/license-destdir/phytool/COPYING: [Errno 2] No such
file or directory: 'phytool/1.0.1-r0/git/COPYING'
ERROR: phytool-1.0.1-r0 do_populate_lic: QA Issue: phytool:
LIC_FILES_CHKSUM points to an invalid file:
phytool/1.0.1-r0/git/COPYING [license-checksum]
NOTE: recipe phytool-1.0.1-r0: task do_populate_lic: Succeeded
...


Weird, it didn't barf on that on my system until I cleaned it and started
over. Ah well, I;ll send a v2 which fixes it.


NOTE: recipe phytool-1.0.1-r0: task do_package_qa: Started
ERROR: phytool-1.0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
elf binary: 'phytool/1.0.1-r0/packages-split/phytool/usr/bin/phytool'
[ldflags]
ERROR: phytool-1.0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
elf binary: 'phytool/1.0.1-r0/packages-split/phytool/usr/bin/phytool'
[ldflags]
ERROR: phytool-1.0.1-r0 do_package_qa: QA run found fatal errors.
Please consider fixing them.
ERROR: phytool-1.0.1-r0 do_package_qa: Function failed: do_package_qa


I have no clue what that means. I also have no clue what I'm supposed to do
about it. And on my build it was only a warning.


A bit of experimentation revealed that apparently this is OE complaining that 
$LDFLAGS didn't get passed to the linker. Created a patch to solve that and 
upstream it.


It would be helpful if the message wasn't so cryptic.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [PATCH v2] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
v2:
  Add $bindir comment
  Add patch (pending upstream) to fix LDFLAGS warning
  Fix license filename

 meta-networking/recipes-support/phytool/phytool.bb | 17 
 .../0001-Makefile-Honor-LDFLAGS-variable.patch | 31 ++
 2 files changed, 48 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb
 create mode 100644 
meta-networking/recipes-support/phytool/phytool/0001-Makefile-Honor-LDFLAGS-variable.patch

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..e95b035
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,17 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=39bba7d2cf0ba1036f2a6e2be52fe3f0"
+
+PV = "1.0.1"
+SRCREV = "1a3ea62a218206e9faf3b27fb5d01c85692024c8"
+SRC_URI = "git://github.com/wkz/phytool.git \
+   file://0001-Makefile-Honor-LDFLAGS-variable.patch"
+
+S = "${WORKDIR}/git"
+
+# Intentionally not using $bindir here because the Makefile is hard-coded to
+# install into $PREFIX/bin
+do_install() {
+   install -d ${D}${prefix}/bin
+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
diff --git 
a/meta-networking/recipes-support/phytool/phytool/0001-Makefile-Honor-LDFLAGS-variable.patch
 
b/meta-networking/recipes-support/phytool/phytool/0001-Makefile-Honor-LDFLAGS-variable.patch
new file mode 100644
index 000..8b99d09
--- /dev/null
+++ 
b/meta-networking/recipes-support/phytool/phytool/0001-Makefile-Honor-LDFLAGS-variable.patch
@@ -0,0 +1,31 @@
+From 8b75a5e6238fe30661b672743560fe4d357237fd Mon Sep 17 00:00:00 2001
+From: Mike Looijmans <mike.looijm...@topic.nl>
+Date: Wed, 28 Sep 2016 09:42:45 +0200
+Subject: [PATCH] Makefile: Honor LDFLAGS variable
+
+Passing $(LDFLAGS) to the linker is important for cross-compile environments.
+OpenEmbedded builds will display QA errors like this:
+... QA Issue: No GNU_HASH in the elf binary ... [ldflags]
+
+Upstream-Status: Pending
+Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
+---
+ Makefile | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile b/Makefile
+index b52843b..70bb414 100644
+--- a/Makefile
 b/Makefile
+@@ -22,7 +22,7 @@ hdrs = $(wildcard *.h)
+ 
+ phytool: $(objs)
+   @printf "  CC  $(subst $(ROOTDIR)/,,$(shell pwd)/$@)\n"
+-  @$(CC) $(LDLIBS) -o $@ $^
++  @$(CC) $(LDFLAGS) $(LDLIBS) -o $@ $^
+ 
+ all: phytool
+ 
+-- 
+1.9.1
+
-- 
1.9.1

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

Re: [oe] [meta-networking][PATCH] phytool: Add recipe

[Mike Looijmans]

On 26-09-16 22:34, Martin Jansa wrote:

2 more issues:

WARNING: phytool-1.0.1-r0 do_populate_lic: Could not copy license file
phytool/1.0.1-r0/git/COPYING to
phytool/1.0.1-r0/license-destdir/phytool/COPYING: [Errno 2] No such
file or directory: 'phytool/1.0.1-r0/git/COPYING'
ERROR: phytool-1.0.1-r0 do_populate_lic: QA Issue: phytool:
LIC_FILES_CHKSUM points to an invalid file:
phytool/1.0.1-r0/git/COPYING [license-checksum]
NOTE: recipe phytool-1.0.1-r0: task do_populate_lic: Succeeded
...


Weird, it didn't barf on that on my system until I cleaned it and started 
over. Ah well, I;ll send a v2 which fixes it.



NOTE: recipe phytool-1.0.1-r0: task do_package_qa: Started
ERROR: phytool-1.0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
elf binary: 'phytool/1.0.1-r0/packages-split/phytool/usr/bin/phytool'
[ldflags]
ERROR: phytool-1.0.1-r0 do_package_qa: QA Issue: No GNU_HASH in the
elf binary: 'phytool/1.0.1-r0/packages-split/phytool/usr/bin/phytool'
[ldflags]
ERROR: phytool-1.0.1-r0 do_package_qa: QA run found fatal errors.
Please consider fixing them.
ERROR: phytool-1.0.1-r0 do_package_qa: Function failed: do_package_qa


I have no clue what that means. I also have no clue what I'm supposed to do 
about it. And on my build it was only a warning.






On Mon, Sep 26, 2016 at 9:31 AM, Khem Raj <raj.k...@gmail.com> wrote:


On Sat, Sep 24, 2016 at 8:01 AM, Mike Looijmans <mike.looijm...@topic.nl>
wrote:

On 23-09-16 20:33, Khem Raj wrote:


On Fri, Sep 23, 2016 at 5:33 AM, Mike Looijmans <

mike.looijm...@topic.nl>

wrote:


A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
   meta-networking/recipes-support/phytool/phytool.bb | 14

++

   1 file changed, 14 insertions(+)
   create mode 100644 meta-networking/recipes-support/phytool/

phytool.bb


diff --git a/meta-networking/recipes-support/phytool/phytool.bb
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..9d541b7
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae1

9f"

+
+PV = "1.0.1"
+SRCREV = "1a3ea62a218206e9faf3b27fb5d01c85692024c8"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+   install -d ${D}${prefix}/bin



perhaps use base_bindir here



The makefile installs to $PREFIX/bin so I deliberately put the same

folder

in the recipe (the makefile doesn't create the directory). If anyone

changes

$bindir the install will fail.


I see the logic,  if you dont want to use bitbake variables then perhaps
its
good to add a comment to explain why it was not done






+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
--
1.9.1

--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





___

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




--
Mike Looijmans

--
___
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



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

Re: [oe] [meta-networking][PATCH] phytool: Add recipe

[Mike Looijmans]

On 23-09-16 20:33, Khem Raj wrote:

On Fri, Sep 23, 2016 at 5:33 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
  meta-networking/recipes-support/phytool/phytool.bb | 14 ++
  1 file changed, 14 insertions(+)
  create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..9d541b7
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+PV = "1.0.1"
+SRCREV = "1a3ea62a218206e9faf3b27fb5d01c85692024c8"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+   install -d ${D}${prefix}/bin


perhaps use base_bindir here


The makefile installs to $PREFIX/bin so I deliberately put the same 
folder in the recipe (the makefile doesn't create the directory). If 
anyone changes $bindir the install will fail.





+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
--
1.9.1

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



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

[oe] [meta-networking][PATCH] phytool: Add recipe

[Mike Looijmans]

A nice tool to directly read, write and interpret ethernet PHY data.
Very useful when debugging PHY or MDIO problems, which ethtool does
not do.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-networking/recipes-support/phytool/phytool.bb | 14 ++
 1 file changed, 14 insertions(+)
 create mode 100644 meta-networking/recipes-support/phytool/phytool.bb

diff --git a/meta-networking/recipes-support/phytool/phytool.bb 
b/meta-networking/recipes-support/phytool/phytool.bb
new file mode 100644
index 000..9d541b7
--- /dev/null
+++ b/meta-networking/recipes-support/phytool/phytool.bb
@@ -0,0 +1,14 @@
+SUMMARY = "PHY interface tool for Linux"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+
+PV = "1.0.1"
+SRCREV = "1a3ea62a218206e9faf3b27fb5d01c85692024c8"
+SRC_URI = "git://github.com/wkz/phytool.git"
+
+S = "${WORKDIR}/git"
+
+do_install() {
+   install -d ${D}${prefix}/bin
+   oe_runmake 'DESTDIR=${D}' 'PREFIX=${prefix}' install
+}
-- 
1.9.1

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

Re: [oe] [PATCH 4/4] tslib: move recipe from oe-core

[Mike Looijmans]

On 17-09-16 02:43, Paul Eggleton wrote:

On Fri, 16 Sep 2016 16:08:57 Burton, Ross wrote:

On 16 September 2016 at 13:10, Andrea Adami <andrea.ad...@gmail.com> wrote:

Well, there is still one drawback...the 'custom' xserver-nodm-init is
still present but there are patches on the ML for its removal.


Hopefully the improvements in oe-core mean the meta-oe recipe can be
removed, but it was decided that it was too late in the cycle to push this
and will wait for 2.3 to release before looking at deleting bits of meta-oe.


The trouble is there are still people using it and we didn't wait for the
recipe to be merged into meta-oe before removing it from oe-core. Can we
please put in place procedures to avoid this happening in future?


... again.

Has happened a few times before, and it's really frustrating...


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacancy/topic-zoekt-technische-software-engineers/


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

Re: [oe] [PATCH] libnl: Fix possible host contamination error

[Mike Looijmans]

Usually this is the result from using a "cp" (typically "cp -r") command in 
the install script instead of "install". Use "install" if possible, patch the 
makefile if you have to. If the install script uses "cp -r", add a few extra 
--preserve options to the command to prevent it overriding ownership.


On 14-09-16 12:45, Mats Karrman wrote:

 From 975b7e64462a465449d367ff6a4e5240a59221d9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mats=20K=C3=A4rrman?= <m...@southpole.se>
Date: Wed, 14 Sep 2016 12:29:27 +0200
Subject: [PATCH] libnl: Fix possible host contamination error

---
  meta/recipes-support/libnl/libnl_3.2.28.bb | 4 
  1 file changed, 4 insertions(+)

  Possibly a cannon to swat a fly but I get "WARNING: libnl-1_3.2.28-r0
do_package_qa: QA Issue: libnl: /libnl-nf/usr/lib/libnl-nf-3.so.200.23.0 is
owned by uid 1001, which is the same as the user running bitbake. This may be
due to host contamination [host-user-contaminated]"
  type errors on every file.

diff --git a/meta/recipes-support/libnl/libnl_3.2.28.bb
b/meta/recipes-support/libnl/libnl_3.2.28.bb
index 26982f3..3fcfbc1 100644
--- a/meta/recipes-support/libnl/libnl_3.2.28.bb
+++ b/meta/recipes-support/libnl/libnl_3.2.28.bb
@@ -23,6 +23,10 @@ SRC_URI[sha256sum] =
"cd608992c656e8f6e3ab6c1391b162a5a51c49336b9219f7f390e61fc5

  inherit autotools pkgconfig

+do_install_append() {
+chown -R root:root ${D}
+}
+
  FILES_${PN} = "${libdir}/libnl-3.so.* \
     ${libdir}/libnl.so.* \
 ${sysconfdir}"




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacancy/topic-zoekt-technische-software-engineers/


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

Re: [oe] [PATCH 1/3] gitkpkgv: Ensure files are closed

[Mike Looijmans]

On 07-06-16 15:49, Richard Purdie wrote:

On Tue, 2016-06-07 at 11:02 +0200, Mike Looijmans wrote:

Looks like regression in Python itself?

In both Python 2 and 3, the file is closed properly if the file
object is not
being stored:

  >>> import os
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
  >>> l=open('/proc/self/stat').readline()
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
  >>> f=open('/proc/self/stat')
  >>> os.listdir('/proc/self/fd')
['0', '1', '2', '3', '4']
  >>>


(file descriptor "3" is the one being used to read the /proc/self/fd
directory, "4" is the one used for reading the stat file)

The "with" construction should not be needed here. Something else is
causing
this (e.g. nested function definition or exception handler?).


$ python2 -Wdefault -c "open('/bin/bash')"
$ python3 -Wdefault -c "open('/bin/bash')"
-c:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/bin/bash' mode='r' 
encoding='UTF-8'>

Admittedly its not an out the box warning but it is one that seems to
be enabled under bitbake. Details in:

https://bugs.python.org/issue10093

but the gist of the issue is that relying on the garbage collector to
close files is a cpython'ism and other implementations of python may
not do this.

So whilst "with" might not be strictly required, it is recommended.


Oh dear, looks like's there's been a change of sorts in the Python community 
and they're now adopting the Java stupidity of "the garbage collector doesn't 
actually work so you'll have to do all your own resource management".


These are reasons why projects are so reluctant to move from Python 2 to 3. 
Python 3 is just a different language.


Ah well, guess we'll have to live with that. I'm already getting used to 
embedded devices running 30MB of software to enable the flashlight...



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] [PATCH 1/3] gitkpkgv: Ensure files are closed

[Mike Looijmans]

Looks like regression in Python itself?

In both Python 2 and 3, the file is closed properly if the file object is not 
being stored:


>>> import os
>>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
>>> l=open('/proc/self/stat').readline()
>>> os.listdir('/proc/self/fd')
['0', '1', '2', '3']
>>> f=open('/proc/self/stat')
>>> os.listdir('/proc/self/fd')
['0', '1', '2', '3', '4']
>>>


(file descriptor "3" is the one being used to read the /proc/self/fd 
directory, "4" is the one used for reading the stat file)


The "with" construction should not be needed here. Something else is causing 
this (e.g. nested function definition or exception handler?).


Mike.


On 02-06-16 11:34, Richard Purdie wrote:

This avoids warnings with python 3.

Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
---
  meta-oe/classes/gitpkgv.bbclass | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta-oe/classes/gitpkgv.bbclass b/meta-oe/classes/gitpkgv.bbclass
index 1cba00c..4866fac 100644
--- a/meta-oe/classes/gitpkgv.bbclass
+++ b/meta-oe/classes/gitpkgv.bbclass
@@ -87,11 +87,13 @@ def get_git_pkgv(d, use_tags):

  if commits != "":
  oe.path.remove(rev_file, recurse=False)
-open(rev_file, "w").write("%d\n" % int(commits))
+with open(rev_file, "w") as f:
+f.write("%d\n" % int(commits))
  else:
  commits = "0"
  else:
-commits = open(rev_file, "r").readline(128).strip()
+with open(rev_file, "r") as f:
+commits = f.readline(128).strip()

  if use_tags:
  try:





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] opencv was skipped: Recipe is blacklisted: Not compatible with currently used ffmpeg 3

[Mike Looijmans]

With current master I cannot build any package that depends on OpenCV. I get 
the message:


opencv was skipped: Recipe is blacklisted: Not compatible with currently used 
ffmpeg 3


I don't want or need (I guess) ffmpeg, so what can I do to unblacklist it 
without hacking meta-openembedded itself?




Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] [PATCH] waf-cross-answers: Fix faulty link cross-answers-mipsel.txt

[Mike Looijmans]

On 06-04-16 19:14, Joe MacDonald wrote:

Hi Mike,

[Re: [PATCH] waf-cross-answers: Fix faulty link cross-answers-mipsel.txt] On 
16.04.05 (Tue 08:17) Mike Looijmans wrote:


Just a reminder that currently "waf" is broken and still won't work on
mipsel platforms without this bugfix.


I merged this for you and pushed it a few minutes ago.  I don't have any
MIPS hardware to test this on but I'm trusting that since you're
reporting it's a build failure that validating for the Edgerouter is a
valid test case.  Is that true?


Don't know that particular box, but if it failed to build (because it's mipsel 
and reports a missing file) before this patch, then yes, that's okay as a test.


M.







On 02-04-16 10:22, Mike Looijmans wrote:

Apparently something was wrong in the patch "waf-cross-answers:
Add cross-answers-mipsel.txt". and it created a dead symlink.
Solve it by just copying the cross-answers-mips.txt instead of
linking it.

Fixes: 0898fb01ccea229cb0c64796b62f20a7c596ac0b

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
  .../waf-cross-answers/cross-answers-mipsel.txt | 40 +-
  1 file changed, 39 insertions(+), 1 deletion(-)
  mode change 12 => 100644 
meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt

diff --git a/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt 
b/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt
deleted file mode 12
index 59b4337..000
--- a/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt
+++ /dev/null
@@ -1 +0,0 @@
-cross-answers-mips.txt
diff --git a/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt 
b/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt
new file mode 100644
index 000..18bfa02
--- /dev/null
+++ b/meta-networking/files/waf-cross-answers/cross-answers-mipsel.txt
@@ -0,0 +1,39 @@
+Checking uname sysname type: "Linux"
+Checking uname version type: "# Wed May 20 10:34:39 UTC 2015"
+Checking simple C program: "hello world"
+rpath library support: OK
+-Wl,--version-script support: OK
+Checking getconf LFS_CFLAGS: NO
+Checking correct behavior of strtoll: NO
+Checking for working strptime: OK
+Checking for C99 vsnprintf: "1"
+Checking for HAVE_SHARED_MMAP: OK
+Checking for HAVE_MREMAP: OK
+Checking for HAVE_SECURE_MKSTEMP: OK
+Checking for HAVE_IFACE_GETIFADDRS: NO
+Checking for HAVE_IFACE_IFCONF: NO
+Checking for HAVE_IFACE_IFREQ: NO
+Checking for large file support without additional flags: NO
+Checking for -D_FILE_OFFSET_BITS=64: OK
+Checking for HAVE_INCOHERENT_MMAP: NO
+Checking value of NSIG: "128"
+Checking value of _NSIG: "128"
+Checking value of SIGRTMAX: "127"
+Checking value of SIGRTMIN: "34"
+Checking whether the WRFILE -keytab is supported: OK
+Checking for kernel change notify support: OK
+Checking for Linux kernel oplocks: OK
+Checking for kernel share modes: OK
+Checking whether POSIX capabilities are available: OK
+Checking if can we convert from CP850 to UCS-2LE: OK
+Checking if can we convert from UTF-8 to UCS-2LE: OK
+vfs_fileid checking for statfs() and struct statfs.f_fsid: OK
+Checking whether we can use Linux thread-specific credentials: OK
+Checking whether fcntl locking is available: OK
+Checking for the maximum value of the 'time_t' type: NO
+Checking whether the realpath function allows a NULL argument: OK
+Checking for ftruncate extend: OK
+getcwd takes a NULL argument: OK
+Checking for small off_t: NO
+Checking whether blkcnt_t is 32 bit: NO
+Checking whether blkcnt_t is 64 bit: OK





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail











Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [PATCH] waf-cross-answers/README: Fix typo "bbaclss"

[Mike Looijmans]

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-oe/files/waf-cross-answers/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/files/waf-cross-answers/README 
b/meta-oe/files/waf-cross-answers/README
index 0c23344..dda45c5 100644
--- a/meta-oe/files/waf-cross-answers/README
+++ b/meta-oe/files/waf-cross-answers/README
@@ -1,3 +1,3 @@
 The files in this directory are cross answers files
-used by waf-samba.bbaclss, please see waf-samba.bbaclss
+used by waf-samba.bbclass, please see waf-samba.bbclass
 for details about how they are used.
-- 
2.1.4

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

[oe] [PATCH] waf-cross-answers: Add cross-answers-mipsel.txt

[Mike Looijmans]

Build fails on "mipsel" platforms due to missing cross-answers-mipsel.txt.
Fix this by linking it to cross-answers-mips.txt, since there's no hint
of taking endianess into account.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-oe/files/waf-cross-answers/cross-answers-mipsel.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 meta-oe/files/waf-cross-answers/cross-answers-mipsel.txt

diff --git a/meta-oe/files/waf-cross-answers/cross-answers-mipsel.txt 
b/meta-oe/files/waf-cross-answers/cross-answers-mipsel.txt
new file mode 12
index 000..61bc751
--- /dev/null
+++ b/meta-oe/files/waf-cross-answers/cross-answers-mipsel.txt
@@ -0,0 +1 @@
+cross-answers-mips.txt
\ No newline at end of file
-- 
2.1.4

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

Re: [oe] [meta-oe][PATCH 0/4] host-user-contaminated fixes for meta-oe

[Mike Looijmans]

Instead of patching things up with chown, you could also instruct the "cp" 
command to not attempt to preserve ownership (the -a and -p options will do that).


Instead of "cp -r -p ..." use "cp -r --preserve=mode,links ..."

Instead of "cp -a ..." use "cp -R --no-dereference --preserve=mode,links ..."

This fixes these QA warnings in a more structured way.


On 14-01-16 09:19, Yi Zhao wrote:


The following changes since commit 73af5c278f6617149a46b2d2a1549bc154fa79e5:

   mime-construct: Perform more mangling for perl path (2016-01-06 13:27:21 
+0100)

are available in the git repository at:

   git://git.openembedded.org/meta-openembedded-contrib yzhao/4-fixes
   
http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=yzhao/4-fixes

Yi Zhao (4):
   debootstrap: fix host-user-contaminated
   espeak: fix host-user-contaminated
   orrery: fix host-user-contaminated
   logwatch: fix host-user-contaminated

  .../debootstrap/debootstrap_1.0.67.bb  |1 +
  .../recipes-extended/logwatch/logwatch_7.4.1.bb|1 +
  meta-oe/recipes-navigation/orrery/orrery_2.7.bb|1 +
  meta-oe/recipes-support/espeak/espeak_1.37.bb  |1 +
  4 files changed, 4 insertions(+)





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] [meta-networking][PATCH v2] recipes-connectivity/samba: Remove /run directory tree

[Mike Looijmans]

Depending on PACKAGECONFIG selection, the /run/samba directory may not
have been created, causing build errors.

Since the /run directory is volatile on target, anything installed
there will vanish anyway, so just remove the /run tree if it exists.

This fixes do_install failing with an error like this:
 rmdir: failed to remove '/.../samba/4.1.12-r0/image/run/samba': No such file 
or directory
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
Alternative patch that just removes /run unconditionally.

 meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index e51f518..49df0f4 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -104,8 +104,7 @@ EXTRA_OECONF += "--enable-fhs \
 LDFLAGS += "-Wl,-z,relro,-z,now"
 
 do_install_append() {
-rmdir --ignore-fail-on-non-empty "${D}/run/samba"
-rmdir --ignore-fail-on-non-empty "${D}/run"
+rm -rf "${D}/run"
 
 if ${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'true', 'false', d)}; 
then
 install -d ${D}${systemd_unitdir}/system
-- 
2.1.4

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

Re: [oe] [meta-networking][PATCH] recipes-connectivity/samba: Only rmdir directories that exist

[Mike Looijmans]

On 11-01-16 19:11, Khem Raj wrote:



On Jan 11, 2016, at 10:06 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

On 11-01-16 19:00, Khem Raj wrote:



On Jan 11, 2016, at 9:53 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

Depending on PACKAGECONFIG selection, the /run/samba directory may not
have been created. Make the do_install_append handle both situations
by checking whether these directories exist before attempting to remove
them.

This fixes do_install failing with an error like this:
rmdir: failed to remove '/.../samba/4.1.12-r0/image/run/samba': No such file or 
directory

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index a51d31f..8e89e49 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -104,8 +104,12 @@ EXTRA_OECONF += "--enable-fhs \
LDFLAGS += "-Wl,-z,relro,-z,now"

do_install_append() {
-rmdir --ignore-fail-on-non-empty "${D}/run/samba"
-rmdir --ignore-fail-on-non-empty "${D}/run"
+if [ -d "${D}/run" ]; then
+if [ -d "${D}/run/samba" ]; then
+rmdir --ignore-fail-on-non-empty "${D}/run/samba"
+fi
+rmdir --ignore-fail-on-non-empty "${D}/run"
+fi


why don’t we delete /run completely ? it won’t work if package contents are in 
there anyway



That's what I do in a bbappend, just "rm -rf ${D}/run" (and also replace the 
non-functional startup script, but that's distro specific), but I thought that it might 
serve some purpose for the one who wrote the recipe.

/run is usually volatile, so putting files in there is pointless, right?


yes although, you should add code to generate those files during post_inst


That wouldn't work, they'll be gone when the system boots. Only way to 
create files there would be to use the 'volatiles' system.


Just removing /run with "rm -rf ${D}/run" will work just fine. The code 
above will generate a QA warning if something gets installed into /run.


Just let me know which you prefer, I'll send a v2 patch.
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-networking][PATCH] recipes-connectivity/samba: Only rmdir directories that exist

[Mike Looijmans]

On 11-01-16 19:00, Khem Raj wrote:



On Jan 11, 2016, at 9:53 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

Depending on PACKAGECONFIG selection, the /run/samba directory may not
have been created. Make the do_install_append handle both situations
by checking whether these directories exist before attempting to remove
them.

This fixes do_install failing with an error like this:
rmdir: failed to remove '/.../samba/4.1.12-r0/image/run/samba': No such file or 
directory

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index a51d31f..8e89e49 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -104,8 +104,12 @@ EXTRA_OECONF += "--enable-fhs \
LDFLAGS += "-Wl,-z,relro,-z,now"

do_install_append() {
-rmdir --ignore-fail-on-non-empty "${D}/run/samba"
-rmdir --ignore-fail-on-non-empty "${D}/run"
+if [ -d "${D}/run" ]; then
+if [ -d "${D}/run/samba" ]; then
+rmdir --ignore-fail-on-non-empty "${D}/run/samba"
+fi
+rmdir --ignore-fail-on-non-empty "${D}/run"
+fi


why don’t we delete /run completely ? it won’t work if package contents are in 
there anyway



That's what I do in a bbappend, just "rm -rf ${D}/run" (and also replace 
the non-functional startup script, but that's distro specific), but I 
thought that it might serve some purpose for the one who wrote the recipe.


/run is usually volatile, so putting files in there is pointless, right?
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-networking][PATCH] recipes-connectivity/samba: Only rmdir directories that exist

[Mike Looijmans]

Depending on PACKAGECONFIG selection, the /run/samba directory may not
have been created. Make the do_install_append handle both situations
by checking whether these directories exist before attempting to remove
them.

This fixes do_install failing with an error like this:
 rmdir: failed to remove '/.../samba/4.1.12-r0/image/run/samba': No such file 
or directory

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index a51d31f..8e89e49 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -104,8 +104,12 @@ EXTRA_OECONF += "--enable-fhs \
 LDFLAGS += "-Wl,-z,relro,-z,now"
 
 do_install_append() {
-rmdir --ignore-fail-on-non-empty "${D}/run/samba"
-rmdir --ignore-fail-on-non-empty "${D}/run"
+if [ -d "${D}/run" ]; then
+if [ -d "${D}/run/samba" ]; then
+rmdir --ignore-fail-on-non-empty "${D}/run/samba"
+fi
+rmdir --ignore-fail-on-non-empty "${D}/run"
+fi
 
 if ${@bb.utils.contains('PACKAGECONFIG', 'systemd', 'true', 'false', d)}; 
then
 install -d ${D}${systemd_unitdir}/system
-- 
2.1.4

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

Re: [oe] Building java

[Mike Looijmans]

On 08-01-16 10:48, Jens Rehsack wrote:
...

What did I do wrong?


meta-java is master, so you need poky on master, too - or cherry-pick the 
autotools.bbclass patch



Current master is borked, it won't parse because about a dozen recipes need 
QT4 things that have been removed.


...


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] Building java

[Mike Looijmans]

On 08-01-16 10:48, Jens Rehsack wrote:



Am 08.01.2016 um 08:39 schrieb Mike Looijmans <mike.looijm...@topic.nl>:

Someone in our project decided he wanted Java on the board, so I just added 
"meta-java" to the layers and attempted to follow the README.

So without a clue as to what I'm really doing (I haven't touched Java in 15 
years) I added these to my local.conf:

# Headless java
PREFERRED_PROVIDER_classpath = "classpath-minimal"
# Possible provider: cacao-initial-native and jamvm-initial-native
PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"
# Possible provider: cacao-native and jamvm-native
PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"

And of course added meta-java to bblayers.conf.

I added "openjdk-8" to the image's things to install, and let things build.

While building "openjdk-8-native", things went south, and I get the following 
error message:

ERROR: no configure script found at 
/home/mike/projects/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/configure


What did I do wrong?


meta-java is master, so you need poky on master, too - or cherry-pick the 
autotools.bbclass patch


I was close to master already, but apparently not close enough.

Upgrading everything to current master results in:

ERROR: ParseError at 
/home/mike/projects/.../meta-oe/meta-oe/recipes-extended/sip/sip_4.16.4.bb:19: 
Could not inherit file classes/qmake2.bbclass






(Note: the board does not have a display, so I don't need/want x11. I tried 
building openjdk-7 instead, but that fails to parse because it requires x11 in 
the distro)


You could port the remove-x11-patches to openjdk-7, since we currently need Java8, I have 
no "business case" to fix openjdk-7 :/


I don't care either, I'm happy when "helloworld.java" runs on target.



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] Building java

[Mike Looijmans]

On 08-01-16 12:06, Jens Rehsack wrote:



Am 08.01.2016 um 11:21 schrieb Mike Looijmans <mike.looijm...@topic.nl>:

On 08-01-16 10:48, Jens Rehsack wrote:
...

What did I do wrong?


meta-java is master, so you need poky on master, too - or cherry-pick the 
autotools.bbclass patch



Current master is borked, it won't parse because about a dozen recipes need QT4 
things that have been removed.


cherry-pick fe506edd from poky/master


Ran into too much trouble with oe-core, I'll wait until the dust has settled.

For now, I just added x11 to the DISTRO_FEATURES and built version 7 which 
runs okay on the board.


I'm puzzled by this message though:

NOTE: multiple providers are available for runtime java2-runtime (cacao, 
openjre-8, jamvm, openjdk-7-jre, openjdk-8)

NOTE: consider defining a PREFERRED_PROVIDER entry to match java2-runtime

To prevent picking another package, I tried adding:

PREFERRED_PROVIDER_java2-runtime = "openjdk-7-jre"

But that did not make the message go away.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] Building java

[Mike Looijmans]

Someone in our project decided he wanted Java on the board, so I just added 
"meta-java" to the layers and attempted to follow the README.


So without a clue as to what I'm really doing (I haven't touched Java in 15 
years) I added these to my local.conf:


# Headless java
PREFERRED_PROVIDER_classpath = "classpath-minimal"
# Possible provider: cacao-initial-native and jamvm-initial-native
PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"
# Possible provider: cacao-native and jamvm-native
PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"

And of course added meta-java to bblayers.conf.

I added "openjdk-8" to the image's things to install, and let things build.

While building "openjdk-8-native", things went south, and I get the following 
error message:


ERROR: no configure script found at 
/home/mike/projects/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/72b05-r0/jdk8u-e8bed1496ff2/configure



What did I do wrong?



(Note: the board does not have a display, so I don't need/want x11. I tried 
building openjdk-7 instead, but that fails to parse because it requires x11 in 
the distro)



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] [meta-networking][PATCH] samba: move RDEPENDS of perl from samba to samba-pidl

[Mike Looijmans]

On 04-01-16 20:06, Jens Rehsack wrote:

samba-pidl is the package containing the perl-extension, so RDEPENDS
must include perl for samba-pidl, not for samba.

Signed-off-by: Jens Rehsack <s...@netbsd.org>
---
  meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index 5b343f2..de1f033 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -39,6 +39,8 @@ SRC_URI[md5sum] = "232016d7581a1ba11e991ec2674553c4"
  SRC_URI[sha256sum] = 
"033604674936bf5c77d7df299b0626052b84a41505a6a6afe902f6274fc29898"

  inherit systemd waf-samba cpan-base perlnative
+# remove default added RDEPENDS on perl
+RDEPENDS_${PN}_remove = "perl"


This is a hack, not a solution.

Better to fix this at its core: cpan-base.bbclass forces both DEPENDS_${PN} 
and RDEPENDS_${PN} to contain "perl".


All that the recipe really wants to have is the perl version. It does not need 
a perl for the target, regardless of whether you'd want to install samba-pidl.


Fixing this at the proper level will considerably reduce compilation time for 
samba, which is already excessively long because of parallel build issues (the 
patch that fixes that isn't integrated).




  DEPENDS += "readline virtual/libiconv zlib popt libtalloc libtdb libtevent libldb 
krb5 ctdb libbsd"

@@ -319,4 +321,5 @@ FILES_${PN}-python-dbg = 
"${libdir}/python${PYTHON_BASEVERSION}/site-packages/.d

${libdir}/python${PYTHON_BASEVERSION}/site-packages/samba/dcerpc/.debug/* \
  "

+RDEPENDS_${PN}-pidl_append = " perl "
  FILES_${PN}-pidl = "${bindir}/pidl ${PERL_VERNDORLIB}/*"
--
1.9.1

--
Jens Rehsack - rehs...@gmail.com





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] Why does samba think it (R)DEPENDS on perl?

[Mike Looijmans]

Found that the cause is "inherit cpan-base", this hardcodes "perl" into 
the package.


I think this requires a split-up of cpan-base.bbclass into two parts, so 
that one get obtain the perl version without adding these dependencies.


On 30-12-15 11:34, Mike Looijmans wrote:

When building the current version of samba, it builds perl and drags it
into the image through an RDEPENDS.

I've been researching this for a while, but failed to figure out what
causes this runtime relation. Is there a way to find out where this is
being "detected"?

The workaround I implemented is simply adding this line to the samba
recipe, which at least gets rid of the overhead in the image:

RDEPENDS_${PN}_remove = "perl"

(Samba 4 is bloated enough by itself, it doesn't need other packages to
inflate its runtime even more)




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

[oe] Why does samba think it (R)DEPENDS on perl?

[Mike Looijmans]

When building the current version of samba, it builds perl and drags it 
into the image through an RDEPENDS.


I've been researching this for a while, but failed to figure out what 
causes this runtime relation. Is there a way to find out where this is 
being "detected"?


The workaround I implemented is simply adding this line to the samba 
recipe, which at least gets rid of the overhead in the image:


RDEPENDS_${PN}_remove = "perl"

(Samba 4 is bloated enough by itself, it doesn't need other packages to 
inflate its runtime even more)


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

[oe] [PATCH] samba: Fix typo in PACKAGECONFIG for "acl" and "aio"

[Mike Looijmans]

There's a "-" too many in PACKAGECONFIG[acl] and PACKAGECONFIG[aio]
resulting in errors like this if built without acl:
  waf: error: no such option: ---without-acl-support

Remove the extra "-" to fix the issue.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-networking/recipes-connectivity/samba/samba_4.1.12.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb 
b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
index cb29ab9..5eab07e 100644
--- a/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
+++ b/meta-networking/recipes-connectivity/samba/samba_4.1.12.bb
@@ -55,8 +55,8 @@ PACKAGECONFIG ??= "${@base_contains('DISTRO_FEATURES', 'pam', 
'pam', '', d)} \
 
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'lsb', 'lsb', '', d)}"
 
-PACKAGECONFIG[acl] = "--with-acl-support,---without-acl-support,acl"
-PACKAGECONFIG[aio] = "--with-aio-support,---without-aio-support,libaio"
+PACKAGECONFIG[acl] = "--with-acl-support,--without-acl-support,acl"
+PACKAGECONFIG[aio] = "--with-aio-support,--without-aio-support,libaio"
 PACKAGECONFIG[fam] = "--with-fam,--without-fam,gamin"
 PACKAGECONFIG[pam] = "--with-pam --with-pam_smbpass 
--with-pammodulesdir=${base_libdir}/security,--without-pam 
--without-pam_smbpass,libpam"
 PACKAGECONFIG[lsb] = ",,lsb"
-- 
2.1.4

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

Re: [oe] "krb" fails to build, suspect GCC bug

[Mike Looijmans]

On 27-10-15 21:25, Martin Jansa wrote:

On Tue, Oct 27, 2015 at 08:57:42PM +0100, Martin Jansa wrote:

On Tue, Oct 27, 2015 at 11:26:32AM -0700, Khem Raj wrote:

On Tue, Oct 27, 2015 at 11:21 AM, Martin Jansa <martin.ja...@gmail.com> wrote:

On Sat, Sep 05, 2015 at 02:39:14PM +0200, Mike Looijmans wrote:

I got this weird build failure from the "krb" package:

| make[3]: Entering directory
'/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
| mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32
--sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED
-DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I.
   -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g
-feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1
-I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align
-Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow
-Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes
-Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function
-Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas
-Wsign-compare -Werror=uninitialized -Werror=pointer-arith
-Werror=declaration-after-statement
-Werror-implicit-function-declaration -pthread -c cc_file.c -o
cc_file.so.o && mv -f cc_file.so.o cc_file.so
| cc_file.c: In function 'fcc_next_cred':
| cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
|  ret = load_data(context, id, maxsize, buf);
|  ^
| cc_file.c:1091:12: note: 'maxsize' was declared here
|  size_t maxsize;
| ^
| cc1: some warnings being treated as errors

Looking at the source, this doesn't make any sense at all. The
declaration of the variable isn't even in the same method body. And the
line it complains about is about the fifth time it passes that variable
to another method.

And working around it by initializing maxsize=0 just makes the compiler
choke on a similar situation elsewhere:
| packet.c:50:67: error: 'id' may be used uninitialized in this function


I suspect the problem here is GCC and not the krb code. Anyone seen this?


I've seen it today in my world builds, It seems to fail only when building with 
-Os.

I've seen similar issue in mdadm, also only with -Os.



is this regression ? or seen for first time?


krb5 fails to build like this with -Os at least since dizzy


Since the move to gcc5 this fails. This workaround makes the build pass once 
more:

https://github.com/OpenPLi/openpli-oe-core/commit/781fea2e5e5e9a18ee905a01b1e2ee80b3aa4721

...

Quick grep in my last -Os world build shows 2 more recipes with
similar issue (smbnetfs is failing in krb5 dependency already):

...

I suspect the bug is in GCC, not in the code of these recipes.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 
17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand 
number C65
http://www.aesexpo.eu


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

[oe] meta-openembedded "toolchain-layer" is broken

[Mike Looijmans]

If you happen to have "toolchain-layer" in your bblayer list, it will trigger 
this:


ERROR: ExpansionError during parsing 
.../meta-oe/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk_4.6.bb: Failure 
expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which 
triggered exception FetchError: Fetcher failure: SRCREV was used yet no valid 
SCM was found in SRC_URI


I just happened to notice. Maybe it's time to take gcc 4.6 to the glue factory?


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] "libgudev" fails to build with current master

[Mike Looijmans]

On 25-09-15 01:22, Andreas Müller wrote:

On Thu, Sep 24, 2015 at 6:45 PM, Andreas Müller
<schnitzelt...@googlemail.com> wrote:

On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

| checking for LIBUDEV... no
| configure: error: Package requirements (libudev >= 199) were not met:
|
| Requested 'libudev >= 199' but version of libudev is 182
|
...

ERROR: Task 5548
(/.../meta-oe/meta-oe/recipes-gnome/libgudev/libgudev_230.bb, do_configure)
failed with exit code '1'


Which init system are you using - I guess not systemd


Let's assume it is not systemd. Could you try attached  0001.. for
oe-core and 0002.. foe meta-oe and give feedback. I tested these for
systemd distro without new issues.


Applied both patches, and the errors went away. Have yet to test if it 
actually produces a working image as there are still a few more issues I need 
to look into.


M.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] "libgudev" fails to build with current master

[Mike Looijmans]

On 25-09-15 08:11, Mike Looijmans wrote:

On 25-09-15 01:22, Andreas Müller wrote:

On Thu, Sep 24, 2015 at 6:45 PM, Andreas Müller
<schnitzelt...@googlemail.com> wrote:

On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans <mike.looijm...@topic.nl>
wrote:

| checking for LIBUDEV... no
| configure: error: Package requirements (libudev >= 199) were not met:
|
| Requested 'libudev >= 199' but version of libudev is 182
|
...

ERROR: Task 5548
(/.../meta-oe/meta-oe/recipes-gnome/libgudev/libgudev_230.bb, do_configure)
failed with exit code '1'


Which init system are you using - I guess not systemd


Let's assume it is not systemd. Could you try attached  0001.. for
oe-core and 0002.. foe meta-oe and give feedback. I tested these for
systemd distro without new issues.


Applied both patches, and the errors went away. Have yet to test if it
actually produces a working image as there are still a few more issues I need
to look into.


Just finished building, image runs okay on the board.

M.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] "libgudev" fails to build with current master

[Mike Looijmans]

On 25-09-15 08:28, Martin Jansa wrote:

On Fri, Sep 25, 2015 at 07:18:24AM +0200, Mike Looijmans wrote:

On 24-09-15 18:45, Andreas Müller wrote:

On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

| checking for LIBUDEV... no
| configure: error: Package requirements (libudev >= 199) were not met:
|
| Requested 'libudev >= 199' but version of libudev is 182
|
...

ERROR: Task 5548
(/.../meta-oe/meta-oe/recipes-gnome/libgudev/libgudev_230.bb, do_configure)
failed with exit code '1'



Which init system are you using - I guess not systemd


sysvinit (busybox).

I don't even use udev. But some packages think they depend on udev components,
so it's virtually impossible to not have udev being built.


I wonder how the init system would affect compilation of a package though.


When you use systemd, you get newer udev version from systemd recipe.

Standalone udev recipe (used together with other init systems) is older version
(which includes libgudev), and apparently not good enough for building latest
standalone libgudev.


Basic problem is that I really don't want to have any udev at all in my image, 
I use mdev for hotplug and other device stuff.


Systemd made things way more complex, since it provides udev, so I can't just 
check on "udev" being the hotplug provider in recipes.





Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[oe] "libgudev" fails to build with current master

[Mike Looijmans]

| checking for LIBUDEV... no
| configure: error: Package requirements (libudev >= 199) were not met:
|
| Requested 'libudev >= 199' but version of libudev is 182
|
...

ERROR: Task 5548 (/.../meta-oe/meta-oe/recipes-gnome/libgudev/libgudev_230.bb, 
do_configure) failed with exit code '1'



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] "libgudev" fails to build with current master

[Mike Looijmans]

On 24-09-15 18:45, Andreas Müller wrote:

On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

| checking for LIBUDEV... no
| configure: error: Package requirements (libudev >= 199) were not met:
|
| Requested 'libudev >= 199' but version of libudev is 182
|
...

ERROR: Task 5548
(/.../meta-oe/meta-oe/recipes-gnome/libgudev/libgudev_230.bb, do_configure)
failed with exit code '1'



Which init system are you using - I guess not systemd


sysvinit (busybox).

I don't even use udev. But some packages think they depend on udev components, 
so it's virtually impossible to not have udev being built.



I wonder how the init system would affect compilation of a package though.

M.


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] gnome-icon-theme?

[Mike Looijmans]

On 15-09-15 13:14, Burton, Ross wrote:

On 15 September 2015 at 12:13, Burton, Ross  wrote:


Yeah this was just removed from oe-core but the addition to meta-oe hasn't
happened.  I can send a patch now if there isn't one on the list.



Hm, alternatively,  we make adwaita-icon-theme provide gnome-icon-theme, as
they're broadly compatible anyway.  Any thoughts?


In that case, you might as well replace the dependencies in the other recipes 
to adwaita-icon-theme directly I guess.



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

[oe] [PATCH][meta-oe] python-pyopenssl: Add missing RDEPENDS on "six" and "cryptography"

[Mike Looijmans]

Fixes the following errors when doing "import OpenSSL":

File "/usr/lib/python2.7/site-packages/OpenSSL/_util.py", line 6, in 

  from cryptography.hazmat.bindings.openssl.binding import Binding
  ImportError: No module named cryptography.hazmat.bindings.openssl.binding
File "/usr/lib/python2.7/site-packages/OpenSSL/rand.py", line 9, in 
  from six import integer_types as _integer_types
  ImportError: No module named six

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb 
b/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
index 7f93012..d80e666 100644
--- a/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
+++ b/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
@@ -21,5 +21,5 @@ inherit setuptools
 PACKAGES =+ "${PN}-tests"
 FILES_${PN}-tests = "${libdir}/${PYTHON_DIR}/site-packages/OpenSSL/test"
 
-RDEPENDS_${PN} = "python-threading"
+RDEPENDS_${PN} = "python-threading python-six python-cryptography"
 RDEPENDS_${PN}-tests = "${PN}"
-- 
2.1.0

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

[oe] Where is libunique?

[Mike Looijmans]

Current meta-openembedded master fails to build with errors like this:

ERROR: Nothing PROVIDES 'libunique' (but 
.../meta-oe/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb 
DEPENDS on or otherwise requires it).


Searching for 'unique' in meta-openembedded and openembedded-core reveiled 
nothing that would provide it, there's no recipe with 'unique' in its name, 
nor any recipe that mentions the word 'unique' provides it, even though I 
found various recipes that DEPEND on it.


Where is libunique?


Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

Re: [oe] Where is libunique?

[Mike Looijmans]

On 07-09-15 17:09, Martin Jansa wrote:

On Mon, Sep 07, 2015 at 03:33:09PM +0300, Alexander Kanavin wrote:

On 09/07/2015 12:13 PM, Mike Looijmans wrote:

Current meta-openembedded master fails to build with errors like this:

ERROR: Nothing PROVIDES 'libunique' (but
.../meta-oe/meta-gnome/recipes-gnome/gnome-disk-utility/gnome-disk-utility_2.32.0.bb
DEPENDS on or otherwise requires it).

Searching for 'unique' in meta-openembedded and openembedded-core
reveiled nothing that would provide it, there's no recipe with 'unique'
in its name, nor any recipe that mentions the word 'unique' provides it,
even though I found various recipes that DEPEND on it.

Where is libunique?


You should check not just the current state of master branches of
various layers, but also their commit history.


Oh sure, make it my fault.
FYI, I did look in the log, and I didn't find anything about libunique 
in the meta-openembedded repo. It somehow never occured to me to go look 
for it in other repos too.



libunique was just removed from oe-core and a patch was sent to add it
to meta-oe. There is no way to keep the removal/addition perfectly in
sync because the two layers are kept in separate repos and have
different maintainers.


This case can be prevented by adding it to meta-oe before it's removed
from oe-core (just like when someone is migrating recipes from meta-oe
to oe-core, they are first added to oe-core and then removed from
meta-oe).


I was going to suggest that too.

Maybe this would make a good entry for the maintainers handbook?


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

[oe] [PATCH][meta-python] python-pyopenssl: Inherit setuptools to fix failing install

[Mike Looijmans]

From: Mike Looijmans <mike.looijm...@topic.nl>

Fixes the following error during install phase:

 ImportError: No module named setuptools_ext
 ERROR: python setup.py install execution failed.

Reported-by: ath...@openpli.org
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb 
b/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
index 694da27..7f93012 100644
--- a/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
+++ b/meta-python/recipes-devtools/python/python-pyopenssl_0.15.1.bb
@@ -16,7 +16,7 @@ SRC_URI[sha256sum] = 
"f0a26070d6db0881de8bcc7846934b7c3c930d8f9c79d45883ee48984b
 
 S = "${WORKDIR}/${SRCNAME}-${PV}"
 
-inherit distutils
+inherit setuptools
 
 PACKAGES =+ "${PN}-tests"
 FILES_${PN}-tests = "${libdir}/${PYTHON_DIR}/site-packages/OpenSSL/test"
-- 
2.1.0

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

Re: [oe] [OE-core] "sub" machine types?

[Mike Looijmans]

On 04-09-15 09:35, Steffen Sledz wrote:

We have some products which differ in bootloaders (u-boot) and kernel device 
trees only. They use the same kernel and root filesystem.

Does OE have concepts for this? Or any suggestions to realize this without 
building for many machines?


The way I handled this was to make it so that all machines have the same 
MACHINE_ARCH, but MACHINE has some suffixes. This combines the kernels 
and such. Only problem with that approach is that OE will erase the 
kernel for a previous machine if you build for the next one, so you have 
to copy the resulting images to another location at the end of the build.


For your case, I think you can just use a single MACHINE. You can just 
supply multiple devicetrees, and I think the u-boot recipe recently 
learned to have multiple targets, so you can build multiple bootloaders 
for a single machine too.



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

[oe] "krb" fails to build, suspect GCC bug

[Mike Looijmans]

I got this weird build failure from the "krb" package:

| make[3]: Entering directory 
'/TOPDIR/build/tmp/work/mips32el-oe-linux/krb5/1.13.2-r0/krb5-1.13.2/src/lib/krb5/ccache'
| mipsel-oe-linux-gcc  -mel -mabi=32 -mhard-float -march=mips32 
--sysroot=/TOPDIR/build/tmp/sysroots/formuler1 -fPIC -DSHARED 
-DHAVE_CONFIG_H  -I../../../include -I../../../include -I./ccapi -I. -I. 
 -DKRB5_DEPRECATED=1 -DKRB5_PRIVATE  -Os -pipe -g 
-feliminate-unused-debug-types -DDESTRUCTOR_ATTR_WORKS=1 
-I/TOPDIR/build/tmp/sysroots/formuler1/usr/include/et -Wall -Wcast-align 
-Wshadow -Wmissing-prototypes -Wno-format-zero-length -Woverflow 
-Wstrict-overflow -Wmissing-format-attribute -Wmissing-prototypes 
-Wreturn-type -Wmissing-braces -Wparentheses -Wswitch -Wunused-function 
-Wunused-label -Wunused-variable -Wunused-value -Wunknown-pragmas 
-Wsign-compare -Werror=uninitialized -Werror=pointer-arith 
-Werror=declaration-after-statement 
-Werror-implicit-function-declaration -pthread -c cc_file.c -o 
cc_file.so.o && mv -f cc_file.so.o cc_file.so

| cc_file.c: In function 'fcc_next_cred':
| cc_file.c:368:9: error: 'maxsize' may be used uninitialized in this 
function [-Werror=maybe-uninitialized]

|  ret = load_data(context, id, maxsize, buf);
|  ^
| cc_file.c:1091:12: note: 'maxsize' was declared here
|  size_t maxsize;
| ^
| cc1: some warnings being treated as errors

Looking at the source, this doesn't make any sense at all. The 
declaration of the variable isn't even in the same method body. And the 
line it complains about is about the fifth time it passes that variable 
to another method.


And working around it by initializing maxsize=0 just makes the compiler 
choke on a similar situation elsewhere:

| packet.c:50:67: error: 'id' may be used uninitialized in this function


I suspect the problem here is GCC and not the krb code. Anyone seen this?

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

[oe] [meta-oe][PATCH v2] opencv: Upgrade to 2.4.11

[Mike Looijmans]

Upgrade OpenCV to the 2.4.11 release.

Remove the opencv-fix-pkgconfig-generation patch which has been integrated 
upstream,
be it in modified form.
Disable 1394 support by default to get a deterministic build.
Fix jasper dependency, the BUILD_JASPER parameter served only to build an 
internal
library, while WITH_JASPER actually controls whether jpeg2000 support was 
desired.
---
v2: Fix non-deterministic jasper and lib1394 dependencies. Tested by first 
building
these libraries and building opencv after that.

 .../opencv/opencv-fix-pkgconfig-generation.patch   | 44 --
 meta-oe/recipes-support/opencv/opencv_2.4.bb   | 11 +++---
 2 files changed, 5 insertions(+), 50 deletions(-)
 delete mode 100644 
meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch

diff --git 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch 
b/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
deleted file mode 100644
index d352778..000
--- 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-Fix pkg-config generation
-
-Replace absolute library path with library name spec and library search
-path option.
-
-The fix has been provided by Ray Rashif (code.opencv.org/issues/1925)
-
-Upstream-Status: Pending
-
-diff -Nbaur OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake 
OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake
 OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake   2012-11-04 
08:40:14.243505926 +
-+++ OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake2012-11-04 
08:40:42.286649120 +
-@@ -10,7 +10,7 @@
- # 
---
- set(prefix  ${CMAKE_INSTALL_PREFIX})
- set(exec_prefix \${prefix})
--set(libdir  ) #TODO: need link paths for OpenCV_EXTRA_COMPONENTS
-+set(libdir  \${prefix}/${OPENCV_LIB_INSTALL_PATH})
- set(includedir  \${prefix}/${OPENCV_INCLUDE_INSTALL_PATH})
- set(VERSION ${OPENCV_VERSION})
- 
-@@ -36,10 +36,11 @@
- ocv_list_reverse(OpenCV_EXTRA_COMPONENTS)
- 
- #build the list of components
--set(OpenCV_LIB_COMPONENTS_ )
-+set(OpenCV_LIB_COMPONENTS_ -L\${libdir})
- foreach(CVLib ${OpenCV_LIB_COMPONENTS})
-   get_target_property(libpath ${CVLib} LOCATION_${CMAKE_BUILD_TYPE})
-   get_filename_component(libname ${libpath} NAME)
-+  get_filename_component(lname ${libpath} NAME_WE)
- 
-   if(INSTALL_TO_MANGLED_PATHS)
- set(libname ${libname}.${OPENCV_VERSION})
-@@ -52,7 +53,8 @@
- set(installDir ${OPENCV_LIB_INSTALL_PATH})
-   endif()
- 
--  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} 
\${exec_prefix}/${installDir}/${libname})
-+  string(REPLACE libopencv -lopencv lname ${lname})
-+  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} ${lname})
- endforeach()
- 
- # add extra dependencies required for OpenCV
diff --git a/meta-oe/recipes-support/opencv/opencv_2.4.bb 
b/meta-oe/recipes-support/opencv/opencv_2.4.bb
index 63d7c8b..2754616 100644
--- a/meta-oe/recipes-support/opencv/opencv_2.4.bb
+++ b/meta-oe/recipes-support/opencv/opencv_2.4.bb
@@ -9,12 +9,10 @@ ARM_INSTRUCTION_SET = arm
 
 DEPENDS = python-numpy libtool swig swig-native python bzip2 zlib glib-2.0
 
-SRCREV = df8e28283f09825cca0c2902160b7abebcfe1b64
-SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4 \
-   file://opencv-fix-pkgconfig-generation.patch \
-
+SRCREV = 2c9547e3147779001811d01936aed38f560929fc
+SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4
 
-PV = 2.4.9+git${SRCPV}
+PV = 2.4.11+git${SRCPV}
 
 S = ${WORKDIR}/git
 
@@ -25,6 +23,7 @@ OECMAKE_BUILDPATH = ${WORKDIR}/build-${TARGET_ARCH}
 EXTRA_OECMAKE = 
-DPYTHON_NUMPY_INCLUDE_DIR:PATH=${STAGING_LIBDIR}/${PYTHON_DIR}/site-packages/numpy/core/include
 \
  -DBUILD_PYTHON_SUPPORT=ON \
  -DWITH_GSTREAMER=OFF \
+ -DWITH_1394=OFF \
  -DCMAKE_SKIP_RPATH=ON \
  ${@bb.utils.contains(TARGET_CC_ARCH, -msse3, 
-DENABLE_SSE=1 -DENABLE_SSE2=1 -DENABLE_SSE3=1 -DENABLE_SSSE3=1, , d)} \
  ${@base_conditional(libdir, /usr/lib64, 
-DLIB_SUFFIX=64, , d)} \
@@ -40,7 +39,7 @@ PACKAGECONFIG[libav] = 
-DWITH_FFMPEG=ON,-DWITH_FFMPEG=OFF,libav,
 PACKAGECONFIG[png] = -DWITH_PNG=ON,-DWITH_PNG=OFF,libpng,
 PACKAGECONFIG[tiff] = -DWITH_TIFF=ON,-DWITH_TIFF=OFF,tiff,
 PACKAGECONFIG[v4l] = -DWITH_V4L=ON,-DWITH_V4L=OFF,v4l-utils,
-PACKAGECONFIG[jasper] = -DBUILD_JASPER=ON,-DBUILD_JASPER=OFF,jasper
+PACKAGECONFIG[jasper] = -DWITH_JASPER=ON,-DWITH_JASPER=OFF,jasper,
 
 inherit distutils-base pkgconfig cmake
 
-- 
1.9.1

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

Re: [oe] [meta-oe][PATCH] opencv: Upgrade to 2.4.11

[Mike Looijmans]

On 04-03-15 23:03, Martin Jansa wrote:

On Wed, Mar 04, 2015 at 09:20:52AM +0100, Mike Looijmans wrote:

Upgrade OpenCV to the 2.4.11 release.

Remove the opencv-fix-pkgconfig-generation patch which has been integrated 
upstream,
be it in modified form.
---
  .../opencv/opencv-fix-pkgconfig-generation.patch   | 44 --
  meta-oe/recipes-support/opencv/opencv_2.4.bb   |  8 ++--
  2 files changed, 3 insertions(+), 49 deletions(-)
  delete mode 100644 
meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch

diff --git 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch 
b/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
deleted file mode 100644
index d352778..000
--- 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-Fix pkg-config generation
-
-Replace absolute library path with library name spec and library search
-path option.
-
-The fix has been provided by Ray Rashif (code.opencv.org/issues/1925)
-
-Upstream-Status: Pending
-
-diff -Nbaur OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake 
OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake
 OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake   2012-11-04 
08:40:14.243505926 +
-+++ OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake2012-11-04 
08:40:42.286649120 +
-@@ -10,7 +10,7 @@
- # 
---
- set(prefix  ${CMAKE_INSTALL_PREFIX})
- set(exec_prefix \${prefix})
--set(libdir  ) #TODO: need link paths for OpenCV_EXTRA_COMPONENTS
-+set(libdir  \${prefix}/${OPENCV_LIB_INSTALL_PATH})
- set(includedir  \${prefix}/${OPENCV_INCLUDE_INSTALL_PATH})
- set(VERSION ${OPENCV_VERSION})
-
-@@ -36,10 +36,11 @@
- ocv_list_reverse(OpenCV_EXTRA_COMPONENTS)
-
- #build the list of components
--set(OpenCV_LIB_COMPONENTS_ )
-+set(OpenCV_LIB_COMPONENTS_ -L\${libdir})
- foreach(CVLib ${OpenCV_LIB_COMPONENTS})
-   get_target_property(libpath ${CVLib} LOCATION_${CMAKE_BUILD_TYPE})
-   get_filename_component(libname ${libpath} NAME)
-+  get_filename_component(lname ${libpath} NAME_WE)
-
-   if(INSTALL_TO_MANGLED_PATHS)
- set(libname ${libname}.${OPENCV_VERSION})
-@@ -52,7 +53,8 @@
- set(installDir ${OPENCV_LIB_INSTALL_PATH})
-   endif()
-
--  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} 
\${exec_prefix}/${installDir}/${libname})
-+  string(REPLACE libopencv -lopencv lname ${lname})
-+  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} ${lname})
- endforeach()
-
- # add extra dependencies required for OpenCV
diff --git a/meta-oe/recipes-support/opencv/opencv_2.4.bb 
b/meta-oe/recipes-support/opencv/opencv_2.4.bb
index 63d7c8b..e57f9a6 100644
--- a/meta-oe/recipes-support/opencv/opencv_2.4.bb
+++ b/meta-oe/recipes-support/opencv/opencv_2.4.bb
@@ -9,12 +9,10 @@ ARM_INSTRUCTION_SET = arm

  DEPENDS = python-numpy libtool swig swig-native python bzip2 zlib glib-2.0

-SRCREV = df8e28283f09825cca0c2902160b7abebcfe1b64
-SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4 \
-   file://opencv-fix-pkgconfig-generation.patch \
-
+SRCREV = 2c9547e3147779001811d01936aed38f560929fc
+SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4

-PV = 2.4.9+git${SRCPV}
+PV = 2.4.11+git${SRCPV}


Please Fix this issue first:
WARNING: QA Issue: libopencv-highgui rdepends on jasper, but it isn't a
build dependency? [build-deps]
WARNING: QA Issue: libopencv-highgui rdepends on libdc1394, but it isn't
a build dependency? [build-deps]


I didn't get any warnings, which platform did you use?
I guess the recipe needs some explicit disable calls, it probably 
auto-detected these on your system.






  S = ${WORKDIR}/git

--
1.9.1

--



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

___

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] [meta-oe][PATCH] opencv: Upgrade to 2.4.11

[Mike Looijmans]

Upgrade OpenCV to the 2.4.11 release.

Remove the opencv-fix-pkgconfig-generation patch which has been integrated 
upstream,
be it in modified form.
---
 .../opencv/opencv-fix-pkgconfig-generation.patch   | 44 --
 meta-oe/recipes-support/opencv/opencv_2.4.bb   |  8 ++--
 2 files changed, 3 insertions(+), 49 deletions(-)
 delete mode 100644 
meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch

diff --git 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch 
b/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
deleted file mode 100644
index d352778..000
--- 
a/meta-oe/recipes-support/opencv/opencv/opencv-fix-pkgconfig-generation.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-Fix pkg-config generation
-
-Replace absolute library path with library name spec and library search
-path option.
-
-The fix has been provided by Ray Rashif (code.opencv.org/issues/1925)
-
-Upstream-Status: Pending
-
-diff -Nbaur OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake 
OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake
 OpenCV-2.4.3.orig/cmake/OpenCVGenPkgconfig.cmake   2012-11-04 
08:40:14.243505926 +
-+++ OpenCV-2.4.3/cmake/OpenCVGenPkgconfig.cmake2012-11-04 
08:40:42.286649120 +
-@@ -10,7 +10,7 @@
- # 
---
- set(prefix  ${CMAKE_INSTALL_PREFIX})
- set(exec_prefix \${prefix})
--set(libdir  ) #TODO: need link paths for OpenCV_EXTRA_COMPONENTS
-+set(libdir  \${prefix}/${OPENCV_LIB_INSTALL_PATH})
- set(includedir  \${prefix}/${OPENCV_INCLUDE_INSTALL_PATH})
- set(VERSION ${OPENCV_VERSION})
- 
-@@ -36,10 +36,11 @@
- ocv_list_reverse(OpenCV_EXTRA_COMPONENTS)
- 
- #build the list of components
--set(OpenCV_LIB_COMPONENTS_ )
-+set(OpenCV_LIB_COMPONENTS_ -L\${libdir})
- foreach(CVLib ${OpenCV_LIB_COMPONENTS})
-   get_target_property(libpath ${CVLib} LOCATION_${CMAKE_BUILD_TYPE})
-   get_filename_component(libname ${libpath} NAME)
-+  get_filename_component(lname ${libpath} NAME_WE)
- 
-   if(INSTALL_TO_MANGLED_PATHS)
- set(libname ${libname}.${OPENCV_VERSION})
-@@ -52,7 +53,8 @@
- set(installDir ${OPENCV_LIB_INSTALL_PATH})
-   endif()
- 
--  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} 
\${exec_prefix}/${installDir}/${libname})
-+  string(REPLACE libopencv -lopencv lname ${lname})
-+  set(OpenCV_LIB_COMPONENTS_ ${OpenCV_LIB_COMPONENTS_} ${lname})
- endforeach()
- 
- # add extra dependencies required for OpenCV
diff --git a/meta-oe/recipes-support/opencv/opencv_2.4.bb 
b/meta-oe/recipes-support/opencv/opencv_2.4.bb
index 63d7c8b..e57f9a6 100644
--- a/meta-oe/recipes-support/opencv/opencv_2.4.bb
+++ b/meta-oe/recipes-support/opencv/opencv_2.4.bb
@@ -9,12 +9,10 @@ ARM_INSTRUCTION_SET = arm
 
 DEPENDS = python-numpy libtool swig swig-native python bzip2 zlib glib-2.0
 
-SRCREV = df8e28283f09825cca0c2902160b7abebcfe1b64
-SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4 \
-   file://opencv-fix-pkgconfig-generation.patch \
-
+SRCREV = 2c9547e3147779001811d01936aed38f560929fc
+SRC_URI = git://github.com/Itseez/opencv.git;branch=2.4
 
-PV = 2.4.9+git${SRCPV}
+PV = 2.4.11+git${SRCPV}
 
 S = ${WORKDIR}/git
 
-- 
1.9.1

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

[oe] [PATCH] python-twisted: Fix dependencies of twisted modules

[Mike Looijmans]

When installing just twisted-web on a device, none of the dependencies
are being copied, it wouldn't even install python-core. Fix the recipe so
that its packages have proper dependencies, and no longer require to install
the empty python-twisted meta recipe.

Add python-contextlib to the core dependencies and stop causing systems
to crash with:
  File /usr/lib/python2.7/site-packages/twisted/python/threadpool.py, line 
18, in module
ImportError: No module named contextlib

Signed-off-by: Mike Looijmans milo-softw...@users.sourceforge.net
---
 .../python/python-twisted_13.2.0.bb|   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb 
b/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
index 80d64a0..8930169 100644
--- a/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
+++ b/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
@@ -38,8 +38,7 @@ PACKAGES += \
 ${PN}-core \
 
 
-RDEPENDS_${PN} = python-core python-zopeinterface
-RDEPENDS_${PN} += \
+RDEPENDS_${PN} = \
 ${PN}-conch \
 ${PN}-lore \
 ${PN}-mail \
@@ -50,6 +49,20 @@ RDEPENDS_${PN} += \
 ${PN}-words \
 
 
+RDEPENDS_${PN}-core = python-core python-zopeinterface python-contextlib
+RDEPENDS_${PN}-test = ${PN}
+RDEPENDS_${PN}-conch = ${PN}-core ${PN}-protocols
+RDEPENDS_${PN}-lore = ${PN}-core
+RDEPENDS_${PN}-mail = ${PN}-core ${PN}-protocols
+RDEPENDS_${PN}-names = ${PN}-core
+RDEPENDS_${PN}-news = ${PN}-core ${PN}-protocols
+RDEPENDS_${PN}-runner = ${PN}-core ${PN}-protocols
+RDEPENDS_${PN}-web += ${PN}-core ${PN}-protocols
+RDEPENDS_${PN}-words += ${PN}-core
+RDEPENDS_${PN}-flow += ${PN}-core
+RDEPENDS_${PN}-pair += ${PN}-core
+RDEPENDS_${PN}-dbg = ${PN}
+
 ALLOW_EMPTY_${PN} = 1
 FILES_${PN} = 
 
-- 
1.7.9.5

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

[oe] [PATCH] python-twisted: Create a separate source code package and bin package

[Mike Looijmans]

Python-twisted installs about 1MB of .py files that are not actually
being used for anything. To save on flash space on devices, move the
source code into its own package.

This modification has been in use for several years in the OpenPLi project,
which heavily leans on twisted for the GUI and web interfaces, and did not
cause any problems.

Move the /usr/bin/ scripts into their own package as well. Installing
python-twisted will still install these scripts.

Signed-off-by: Mike Looijmans milo-softw...@users.sourceforge.net
---
 .../python/python-twisted_13.2.0.bb|   12 
 1 file changed, 12 insertions(+)

diff --git a/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb 
b/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
index 8930169..2b433f7 100644
--- a/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
+++ b/meta-python/recipes-devtools/python/python-twisted_13.2.0.bb
@@ -38,7 +38,13 @@ PACKAGES += \
 ${PN}-core \
 
 
+PACKAGES =+ \
+${PN}-src \
+${PN}-bin \
+
+
 RDEPENDS_${PN} = \
+${PN}-bin \
 ${PN}-conch \
 ${PN}-lore \
 ${PN}-mail \
@@ -233,3 +239,9 @@ ${libdir}/${PYTHON_DIR}/site-packages/twisted/*/.debug \
 ${libdir}/${PYTHON_DIR}/site-packages/twisted/*/*/.debug \
 
 
+RDEPENDS_{PN}-src = ${PN}
+FILES_${PN}-src =  \
+   ${libdir}/${PYTHON_DIR}/site-packages/twisted/*.py \
+   ${libdir}/${PYTHON_DIR}/site-packages/twisted/*/*.py \
+   ${libdir}/${PYTHON_DIR}/site-packages/twisted/*/*/*.py \
+   
-- 
1.7.9.5

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

[oe] [PATCH] iperf3: Add native support

[Mike Looijmans]

If you want to use iperf3 to measure your board's IP performance, you
may also want to compile if for the build host, because unlike iperf,
iperf3 isn't readily available as a standard Ubuntu package for example.

Add a BBCLASSEXTEND=native to the recipe so that you just can build
iperf3-native and have bitbake compile it for you, instead of having to
download, compile and install it manually on the build machine.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
 meta-oe/recipes-benchmark/iperf3/iperf3_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-oe/recipes-benchmark/iperf3/iperf3_git.bb 
b/meta-oe/recipes-benchmark/iperf3/iperf3_git.bb
index d34eb69..b4d2b61 100644
--- a/meta-oe/recipes-benchmark/iperf3/iperf3_git.bb
+++ b/meta-oe/recipes-benchmark/iperf3/iperf3_git.bb
@@ -23,3 +23,4 @@ SRCREV = de420cc741dd8967ebc57f80b7712556442de81b
 S = ${WORKDIR}/git
 
 inherit autotools
+BBCLASSEXTEND = native
-- 
1.9.1

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

Re: [oe] [meta-oe][PATCH v2 2/2] mplayer2: cleanup empty directories

[Mike Looijmans]

On 12/16/2014 08:26 AM, Belal, Awais wrote:

ping!

BR,
Awais




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/



From: openembedded-devel-boun...@lists.openembedded.org 
[openembedded-devel-boun...@lists.openembedded.org] on behalf of Belal, Awais
Sent: Monday, December 08, 2014 3:42 PM
To: openembedded-devel@lists.openembedded.org
Subject: [oe] [meta-oe][PATCH v2 2/2] mplayer2: cleanup empty directories

The mplayer make install phase leaves an empty
/usr/lib directory seemingly regardless of the setting
of libdir.  Remove it to avoid a packaging warning.

Signed-off-by: Drew Moseley drew_mose...@mentor.com
Signed-off-by: Awais Belal awais_be...@mentor.com
---
  meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb |1 +
  1 file changed, 1 insertion(+)

diff --git a/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb 
b/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb
index 6b3d120..a68a2ba 100644
--- a/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb
+++ b/meta-oe/recipes-multimedia/mplayer/mplayer2_git.bb
@@ -141,4 +141,5 @@ do_install() {
  install ${S}/etc/input.conf ${D}/usr/etc/mplayer/
  install ${S}/etc/example.conf ${D}/usr/etc/mplayer/
  install ${S}/etc/codecs.conf ${D}/usr/etc/mplayer/
+[ -e ${D}/usr/lib ]  rmdir ${D}/usr/lib


This will cause the script to fail when someone fixes the install and /usr/lib 
was not created, because test -e ${D}/usr/lib would return failure.




  }
--
1.7.9.5

--
___
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] There is no LAYERVERSION and LAYERDEPENDS for most meta-FOO layers

[Mike Looijmans]

On 11/24/2014 09:53 AM, Huang, Jie (Jackie) wrote:

Hi,

I know LAYERVERSION is optional but I think LAYERDEPENDS is required and at 
least we should specify the main oe-core,
but I found only meta-networking and meta-webser have this:

$ grep -r LAYERDEPENDS *
meta-networking/conf/layer.conf:LAYERDEPENDS_networking-layer = core
meta-networking/conf/layer.conf:LAYERDEPENDS_networking-layer = 
openembedded-layer
meta-networking/conf/layer.conf:LAYERDEPENDS_networking-layer = meta-python
meta-webserver/conf/layer.conf:LAYERDEPENDS_webserver = core
$ grep -r LAYERVERSION *
meta-networking/conf/layer.conf:LAYERVERSION_networking-layer = 1
meta-webserver/conf/layer.conf:LAYERVERSION_webserver = 1

I found dependencies section in README for most of the meta-FOO layers, but no 
definition of LAYERDEPENDS in the layer.conf.

Thanks,
Jackie



And reading this:

LAYERDEPENDS_networking-layer = core
LAYERDEPENDS_networking-layer = openembedded-layer
LAYERDEPENDS_networking-layer = meta-python

makes me wonder whether:
- The author forgot to use += instead of =; or
- The syntax of LAYERDEPENDS is different from what the rest of the variables 
use (in that case, an RFC may be in order here); or

- These lines are parsed by something else than bitbake's regular parser.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt gedreven (embedded) software specialisten!
http://topic.nl/vacatures/topic-zoekt-software-engineers/

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

[oe] [meta-oe][PATCH v2] vlc/libdvdcss: Upgrade to 1.3.0

[Mike Looijmans]

Tested and in use for a while in OpenPLi.

Signed-off-by: Mike Looijmans milo-softw...@users.sourceforge.net
---
 .../{libdvdcss_1.2.13.bb = libdvdcss_1.3.0.bb}|4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta-multimedia/recipes-multimedia/vlc/{libdvdcss_1.2.13.bb = 
libdvdcss_1.3.0.bb} (72%)

diff --git a/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb 
b/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb
similarity index 72%
rename from meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb
rename to meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb
index 1a316d3..79e64ae 100644
--- a/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb
+++ b/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb
@@ -8,5 +8,5 @@ inherit autotools
 
 EXTRA_OECONF =  --disable-doc 
 
-SRC_URI[md5sum] = 53cfc52a60a156763c425572e5179273
-SRC_URI[sha256sum] = 
84f1bba6cfef1df87f774fceaefc8e73c4cda32e8f6700b224ad0acb5511ba2c
+SRC_URI[md5sum] = 7f0fdb3ff91d638f5e45ed7536f7eb67
+SRC_URI[sha256sum] = 
7c414acd520c4e4dd7267952f72d738ff50321a7869af4d75c65aefad44f1395
-- 
1.7.9.5

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

[oe] [PATCH] libdvdcss: Upgrade to 1.3.0

[Mike Looijmans]

License is still GPLv2. Has been in use for a while, and no problems detected.
---
 .../recipes-multimedia/vlc/libdvdcss_1.2.13.bb |   12 
 .../recipes-multimedia/vlc/libdvdcss_1.3.0.bb  |   12 
 2 files changed, 12 insertions(+), 12 deletions(-)
 delete mode 100644 meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb
 create mode 100644 meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb

diff --git a/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb 
b/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb
deleted file mode 100644
index 1a316d3..000
--- a/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.2.13.bb
+++ /dev/null
@@ -1,12 +0,0 @@
-DESCRIPTION = libdvdcss is a simple library designed for accessing DVDs like 
a block device without having to bother about the decryption.
-LICENSE = GPLv2
-LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-
-SRC_URI = 
http://download.videolan.org/pub/libdvdcss/${PV}/libdvdcss-${PV}.tar.bz2;
-
-inherit autotools
-
-EXTRA_OECONF =  --disable-doc 
-
-SRC_URI[md5sum] = 53cfc52a60a156763c425572e5179273
-SRC_URI[sha256sum] = 
84f1bba6cfef1df87f774fceaefc8e73c4cda32e8f6700b224ad0acb5511ba2c
diff --git a/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb 
b/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb
new file mode 100644
index 000..79e64ae
--- /dev/null
+++ b/meta-multimedia/recipes-multimedia/vlc/libdvdcss_1.3.0.bb
@@ -0,0 +1,12 @@
+DESCRIPTION = libdvdcss is a simple library designed for accessing DVDs like 
a block device without having to bother about the decryption.
+LICENSE = GPLv2
+LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
+
+SRC_URI = 
http://download.videolan.org/pub/libdvdcss/${PV}/libdvdcss-${PV}.tar.bz2;
+
+inherit autotools
+
+EXTRA_OECONF =  --disable-doc 
+
+SRC_URI[md5sum] = 7f0fdb3ff91d638f5e45ed7536f7eb67
+SRC_URI[sha256sum] = 
7c414acd520c4e4dd7267952f72d738ff50321a7869af4d75c65aefad44f1395
-- 
1.7.9.5

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

Re: [oe] [PATCH 02/14] autofs: add bash to RDEPENDS_autofs

[Mike Looijmans]

Okay on that.

Mike.

On 09/14/2014 06:13 AM, Robert Yang wrote:


Hi Mike,

I've updated the patch in the repo:

git://git.openembedded.org/meta-openembedded-contrib rbt/rdeps

And used a patch rather than sed command since patch is preferred, here
is the patch with your signed off:

diff --git
a/meta-networking/recipes-daemons/autofs/autofs-5.1.0/remove-bashism.patch
b/meta-networking/recipes-daemons/autofs/autofs-5.1.0/remove-bashism.patch
new file mode 100644
index 000..282d6f0
--- /dev/null
+++ b/meta-networking/recipes-daemons/autofs/autofs-5.1.0/remove-bashism.patch
@@ -0,0 +1,120 @@
+From 79034f969bbd12215d65b4337dfd38a13d02d4ef Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Sat, 13 Sep 2014 20:19:28 -0700
+Subject: [PATCH] autofs.init.in: remove bashism
+
+It can work without the bashism.
+
+Upstream-Status: Pending
+
+Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ redhat/autofs.init.in |   12 ++--
+ samples/rc.autofs.in  |   10 +-
+ 2 files changed, 11 insertions(+), 11 deletions(-)
+
+diff --git a/redhat/autofs.init.in b/redhat/autofs.init.in
+index 9d008ff..4f1c0d8 100644
+--- a/redhat/autofs.init.in
 b/redhat/autofs.init.in
+@@ -1,4 +1,4 @@
+-#!/bin/bash
++#!/bin/sh
+ #
+ # rc file for automount using a Sun-style master map.
+ #
+@@ -42,7 +42,7 @@ if [ -r $confdir/autofs ]; then
+   . $confdir/autofs
+ fi
+
+-function start() {
++start() {
+   # Make sure autofs4 module is loaded
+   if ! grep -q autofs /proc/filesystems

+   then
+@@ -102,7 +102,7 @@ function start() {
+   return $RETVAL
+ }
+
+-function stop() {
++stop() {
+   echo -n $Stopping $prog: 
+   count=0
+   while [ -n `pidof $prog` -a $count -lt 15 ] ; do
+@@ -125,7 +125,7 @@ function stop() {
+   return $RETVAL
+ }
+
+-function restart() {
++restart() {
+   status autofs  /dev/null 21
+   if [ $? -eq 0 ]; then
+   stop
+@@ -143,7 +143,7 @@ function restart() {
+   start
+ }
+
+-function reload() {
++reload() {
+   if [ ! -f /var/lock/subsys/autofs ]; then
+   echo $$prog not running
+   RETVAL=1
+@@ -161,7 +161,7 @@ function reload() {
+   return $RETVAL
+ }
+
+-function usage_message() {
++usage_message() {
+   echo $Usage: $0
{start|forcestart|stop|status|restart|force-reload|forcerestart|reload|condrestart|try-restart|usage}

+ }
+
+diff --git a/samples/rc.autofs.in b/samples/rc.autofs.in
+index 487669f..e96cde1 100644
+--- a/samples/rc.autofs.in
 b/samples/rc.autofs.in
+@@ -1,4 +1,4 @@
+-#!/bin/bash
++#!/bin/sh
+ #
+ # rc file for automount using a Sun-style master map.
+ #
+@@ -36,7 +36,7 @@ if [ -r $confdir/autofs ]; then
+   . $confdir/autofs
+ fi
+
+-function start() {
++start() {
+   echo -n Starting $prog: 
+
+   # Make sure autofs4 module is loaded
+@@ -85,7 +85,7 @@ function start() {
+   return $RETVAL
+ }
+
+-function stop() {
++stop() {
+   echo -n $Stopping $prog: 
+   count=0
+   while [ -n `pidof $prog` -a $count -lt 15 ] ; do
+@@ -102,7 +102,7 @@ function stop() {
+   return $RETVAL
+ }
+
+-function restart() {
++restart() {
+   stop
+   while [ -n `pidof $prog` ] ; do
+   sleep 5
+@@ -110,7 +110,7 @@ function restart() {
+   start
+ }
+
+-function reload() {
++reload() {
+   pid=`pidof $prog`
+   if [ -z $pid ]; then
+   echo $$prog not running
+--
+1.7.9.5
+
diff --git a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
index aab2187..13af2fe 100644
--- a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
+++ b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
@@ -19,6 +19,7 @@ SRC_URI =
${KERNELORG_MIRROR}/linux/daemons/autofs/v5/autofs-${PV}.tar.gz \
 file://add-the-needed-stdarg.h.patch \
 file://using-pkg-config-to-detect-libxml-2.0-and-krb5.patch \
 file://force-STRIP-to-emtpy.patch \
+   file://remove-bashism.patch \
  

  SRC_URI[md5sum] = b7724a9a55923f3c06933a8dfd1e79d3



// Robert

On 09/12/2014 08:57 PM, Mike Looijmans wrote:

On 09/11/2014 05:28 PM, Robert Yang wrote:



On 09/11/2014 01:08 AM, Mike Looijmans wrote:

Wouldn't it be a LOT more constructive to fix the bashism. I fail to
see the
virtue in adding 2MB of bash to an embedded system just for a text echo
statement that no-one will actually read unless they hook up a serial
console to
their TV set or so.


The problem is that there are more bashism, here is the full list:

possible bashism in autofs/etc/init.d/autofs line 39 ('function' is
useless):
function start() {
possible bashism in autofs/etc/init.d/autofs line 52 ([^] should be [!]):
 elif ([ -f /proc/modules ]  lsmod) | grep -q autofs[^4]
possible bashism in autofs/etc/init.d/autofs line 88 ('function' is
useless):
function stop() {
possible bashism in autofs/etc

Re: [oe] [PATCH 02/14] autofs: add bash to RDEPENDS_autofs

[Mike Looijmans]

On 09/11/2014 05:28 PM, Robert Yang wrote:



On 09/11/2014 01:08 AM, Mike Looijmans wrote:

Wouldn't it be a LOT more constructive to fix the bashism. I fail to
see the
virtue in adding 2MB of bash to an embedded system just for a text echo
statement that no-one will actually read unless they hook up a serial
console to
their TV set or so.


The problem is that there are more bashism, here is the full list:

possible bashism in autofs/etc/init.d/autofs line 39 ('function' is
useless):
function start() {
possible bashism in autofs/etc/init.d/autofs line 52 ([^] should be [!]):
 elif ([ -f /proc/modules ]  lsmod) | grep -q autofs[^4]
possible bashism in autofs/etc/init.d/autofs line 88 ('function' is
useless):
function stop() {
possible bashism in autofs/etc/init.d/autofs line 89 ($foo should be
eval_gettext foo):
 echo -n $Stopping $prog: 
possible bashism in autofs/etc/init.d/autofs line 92 (should be word
21):
 killall -TERM $prog  /dev/null
possible bashism in autofs/etc/init.d/autofs line 105 ('function' is
useless):
function restart() {
possible bashism in autofs/etc/init.d/autofs line 113 ('function' is
useless):
function reload() {
possible bashism in autofs/etc/init.d/autofs line 116 ($foo should be
eval_gettext foo):
 echo $$prog not running
possible bashism in autofs/etc/init.d/autofs line 120 ($foo should be
eval_gettext foo):
 echo $Reloading maps
possible bashism in autofs/etc/init.d/autofs line 150 ($foo should be
eval_gettext foo):
 echo $Usage: $0
{start|forcestart|stop|restart|forcerestart|reload}

// Robert



I put the following in a bbappend to work around the bashism, this was 
enough to make the scripts work just fine with busybox's shell:



# Remove bash scripting from init script (meaning, remove function
# from each shell function)
do_configure_prepend () {
for bashfile in redhat/autofs.init.in samples/rc.autofs.in
do
sed -i 's.#!/bin/bash.#!/bin/sh.' $bashfile
sed -i 's/^function //g' $bashfile
done
}


I wanted to point to the commit on sourceforge, but the site is 
unresponsive at the moment.





On 9-9-2014 18:27, Robert Yang wrote:

Bashism:
[snip]
possible bashism in autofs/etc/init.d/autofs line 116 ($foo should be
eval_gettext foo):
 echo $$prog not running
possible bashism in autofs/etc/init.d/autofs line 120 ($foo should be
eval_gettext foo):
 echo $Reloading maps
possible bashism in autofs/etc/init.d/autofs line 150 ($foo should be
eval_gettext foo):
 echo $Usage: $0
{start|forcestart|stop|restart|forcerestart|reload}
[snip]

Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
  .../recipes-daemons/autofs/autofs_5.1.0.bb |1 +
  1 file changed, 1 insertion(+)

diff --git a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
index aab2187..06ee77b 100644
--- a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
+++ b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
@@ -4,6 +4,7 @@ LICENSE = GPL-2.0
  LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3

  DEPENDS += libtirpc flex-native bison-native
+RDEPENDS_${PN} += bash

  inherit autotools-brokensep systemd








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

Re: [oe] [PATCH 02/14] autofs: add bash to RDEPENDS_autofs

[Mike Looijmans]

Wouldn't it be a LOT more constructive to fix the bashism. I fail to see 
the virtue in adding 2MB of bash to an embedded system just for a text 
echo statement that no-one will actually read unless they hook up a 
serial console to their TV set or so.



On 9-9-2014 18:27, Robert Yang wrote:

Bashism:
[snip]
possible bashism in autofs/etc/init.d/autofs line 116 ($foo should be eval_gettext 
foo):
 echo $$prog not running
possible bashism in autofs/etc/init.d/autofs line 120 ($foo should be eval_gettext 
foo):
 echo $Reloading maps
possible bashism in autofs/etc/init.d/autofs line 150 ($foo should be eval_gettext 
foo):
 echo $Usage: $0 
{start|forcestart|stop|restart|forcerestart|reload}
[snip]

Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
  .../recipes-daemons/autofs/autofs_5.1.0.bb |1 +
  1 file changed, 1 insertion(+)

diff --git a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb 
b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
index aab2187..06ee77b 100644
--- a/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
+++ b/meta-networking/recipes-daemons/autofs/autofs_5.1.0.bb
@@ -4,6 +4,7 @@ LICENSE = GPL-2.0
  LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3

  DEPENDS += libtirpc flex-native bison-native
+RDEPENDS_${PN} += bash

  inherit autotools-brokensep systemd





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

Re: [oe] Style issue for recipes

[Mike Looijmans]

On 09/04/2014 07:29 PM, Andreas Müller wrote:

On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross ross.bur...@intel.com wrote:

On 4 September 2014 15:12, Burton, Ross ross.bur...@intel.com wrote:

Quick question of style for the community to bikeshed on:  in the
general case should recipes be split into foo_1.2.bb and foo.inc, or
should they only split to bb/inc if there are multiple versions and
generally there should just be foo_1.2.bb.


Another argument against widespread inc files: they encourage the
impression that maintaining multiple versions is just a matter of
having a .inc file.  The moment you start having to put
version-specific statements into a .bb you've entered a world of pain
in keeping the .bb files in sync, moving options into the .inc as they
become used by all versions, and purging old version-specific
statements.

Ross
--

I agree with Ross: It often took me time to find out where
functionality comes from. Inc-files do only make sense for multiple
versions of recipes or if different recipes share same code (only
example I can remember is meta-gnome gvfs/gvfs-gdu-volume-monitor
circular-dependency hack).

My feeling is that the inc-files are still from classic oe times where
we had multiple versions for many recipes and most can be merged into
recipes without loosing something.


Why not take it one step further and remove the version from the bb 
filename? Only use the versioned filename if there actually is more 
than one version.


I'd propose that the recipe for package foo is always called foo.bb. 
A PV setting in that file can provide the information that bitbake needs.


If there's an alternative, but not mainstream or recommended version for 
that package, it can be named foo_1.1.bb.


That way, you can see in a glance what recipe is the default one and 
which are the extras.


I guess for 99% of the recipes, there's only one version. It's much 
easier to track it if the filename remains constant. Yes, I know about 
git's fancy features, but...


What about the mighty simple usecase of just being able to search for 
foo.bb using your favorite search engine and then actually finding it 
in a public overlay repository on the web? For example, you will be able 
to find a recipe for libdvdcss by simply hunting for libdvdcss.bb, but 
you'll have a hard time finding the hamsterdb recipe because it happens 
to be named hamsterdb_git.bb in that same repository.


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

Re: [oe] Fwd: [yocto] Community Demo Area at ELCE

[Mike Looijmans]

Is this solely for Yocto or is it good enough to have used plain 
OpenEmbedded?

If plain is enough, I can probably bring some stuff to interact with :)

M.

On 08/20/2014 12:34 PM, Philip Balister wrote:

FYI. Bring your toys.

Philip


 Original Message 
Subject: [yocto] Community Demo Area at ELCE
Date: Tue, 19 Aug 2014 17:50:37 -0700
From: Osier-mixon, Jeffrey jeffrey.osier-mi...@intel.com
To: yo...@yoctoproject.org yo...@yoctoproject.org

At the Embedded Linux Conference in San Jose, CA USA this past spring, we
had six great demos in the Yocto Project booth. However, only two of those
were demos that we arrived with. Four were from community members who
spontaneously showed up, including a homebuilt audio player (hi nerdboy)
and we thank them very much for their support and willingness to share.

As a response to that, the Yocto Project would like to invite Embedded
Linux Conference Europe* participants to bring your projects to the Yocto
Project booth if you'd like to show off your work. We will have a screen,
keyboard, mouse, and power available. Small embedded projects are best, but
if you have a scale robotic dinosaur or a Yocto-powered Lamborghini, we
won't turn you away. (Probably.)

Please RSVP to me directly and let me know when to expect you.

If there is enough interest, we can also set up a table at lunchtime at the
Yocto Project Developer Day** following ELCE.

* http://events.linuxfoundation.org/events/embedded-linux-conference-europe
**
https://www.yoctoproject.org/tools-resources/events/yocto-project-developer-day-elce-2014







Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Bezoek ons op 9 en 10 september tijdens Technology for Health Den Bosch (stand 
53)
http://www.technologyforhealth.nl

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

[oe] bitcoin recipe

[Mike Looijmans]

Just out of curiousity, I tried to build bitcoin for an ARM target using 
bitbake.

Googling a bit reveils tons of claims of people having compiled it for their
board (e.g. the raspberry pi), and very likely, some of them were using OE.

Somewhere, someone knows how to do this...

Strangely, i couldn't find a recipe online. So i did a quick try with this 
recipe:

SUMMARY = Bitcoin miner
LICENSE = MIT
LIC_FILES_CHKSUM = file://COPYING;md5=9eef91148a9b14ec7f9df333daebc746
# https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md
DEPENDS += boost db
SRCREV = 5e94d0036a76ea9d63e4ed17b12554caef7f55da
SRC_URI = git://github.com/bitcoin/bitcoin/
S = ${WORKDIR}/git
inherit pkgconfig autotools
# Workarounds...
EXTRA_OECONF += \
--with-incompatible-bdb \
--with-boost-libdir=${STAGING_LIBDIR} \



This didn't get very far, apparently the bitcoin people aren't very aware of 
crosscompiling...


It fails to configure with a cryptic message like this:

checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Chrono library is available... yes
configure: error: Could not find a version of the boost_chrono library!

A similar one about the boost_system library was fixed using the 
--with-boost-libdir=${STAGING_LIBDIR} hack, but this one has me baffled.



Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail

Topic zoekt FPGA experts
http://topic.nl/vacatures/word-jij-onze-nieuwe-fpga-expert/

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

Re: [oe] [meta-oe][PATCH] fuse-exfat, ntfs-3g-ntfsprogs: Move util-linux-mount to RRECOMMENDS

[Mike Looijmans]

Just a ping to inform if this patch will ever make it into mainstream, 
of if there's something wrong with it.


Mike.

On 09/20/2013 11:00 AM, Mike Looijmans wrote:

Soften the dependency to allow distros to use another mount provider
like busybox instead of being forced to use util-linux-mount.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
  .../fuse-exfat/fuse-exfat_1.0.1.bb |2 +-
  .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb 
b/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
index d29dc0a..f984c4b 100644
--- a/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
+++ b/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=d32239bcb673463ab874e80d47fae504
  SRC_URI = ${DEBIAN_MIRROR}/main/f/fuse-exfat/fuse-exfat_${PV}.orig.tar.gz \
  
  DEPENDS = fuse virtual/libc
-RDEPENDS_${PN} += util-linux-mount
+RRECOMMENDS_${PN} = util-linux-mount

  inherit scons

diff --git 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
index e084187..c1392cc 100644
--- 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
+++ 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
@@ -23,7 +23,8 @@ EXTRA_OEMAKE = LDCONFIG=echo
  PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g

  FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* 
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse
+RRECOMMENDS_ntfs-3g = util-linux-mount

  FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
  FILES_libntfs-3g = ${libdir}/*${SOLIBS}





Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any enclosures.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

On 09/22/2013 03:28 AM, Hongxu Jia wrote:

On 09/20/2013 04:21 PM, Mike Looijmans wrote:


On 09/19/2013 07:29 AM, Mike Looijmans wrote:

On 09/18/2013 11:13 AM, Hongxu Jia wrote:

Hi Mike,

The reason why add util-linux-mount to RDEPENDS is the mount in
busybox doesn't support 'syntax of external mount helpers' very well.

Which means you could directly invoke mount rather than
mount.ntfs/mount.exfat
to mount ntfs/exfat filesystem.


I really don't have the faintest clue what you're referring to. Could
you please explain?

And my experience is exactly the opposite - When util-linux-mount gets
installed, it breaks things. Busybox mount works just fine.

If anything, it should rdepend on something like virtual/mount or so.

It doesn't seem right for a package to enforce choices that the distro
should make. Regardless of how broken busybox might be - that's the
distro's problem, not something a filesystem driver should care about.


Additionally:

How about a compromise: Put util-linux-mount into the RRECOMMENDS
instead of RDEPENDS. Then at least the distro can get rid of it using
a BAD_RECOMMENDS or similar construct.

Let me know, I'll post a patch.


Looks good to me.


I already posted that as a patch. Any news, comments, request? Should I 
post it again?


Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any enclosures.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

 On 09/18/2013 11:13 AM, Hongxu Jia wrote:

Hi Mike,

The reason why add util-linux-mount to RDEPENDS is the mount in
busybox doesn't support 'syntax of external mount helpers' very well.

Which means you could directly invoke mount rather than
mount.ntfs/mount.exfat
to mount ntfs/exfat filesystem.


Could you please explain this?

Using busybox mount, i can just type mount /dev/sdx1 /media/somewhere 
to mount an ntfs-3g volume. (In fact, just inserting an NTFS formatted 
USB stick into the box will mount it using ntfs-3g using mdev scripts)


Works just fine, and has been working at least since busybox version 1.18.x

So I don't understand your claim that BB mount is broken.

Please explain.



Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any enclosures.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]


On 09/19/2013 07:29 AM, Mike Looijmans wrote:

On 09/18/2013 11:13 AM, Hongxu Jia wrote:

Hi Mike,

The reason why add util-linux-mount to RDEPENDS is the mount in
busybox doesn't support 'syntax of external mount helpers' very well.

Which means you could directly invoke mount rather than
mount.ntfs/mount.exfat
to mount ntfs/exfat filesystem.


I really don't have the faintest clue what you're referring to. Could
you please explain?

And my experience is exactly the opposite - When util-linux-mount gets
installed, it breaks things. Busybox mount works just fine.

If anything, it should rdepend on something like virtual/mount or so.

It doesn't seem right for a package to enforce choices that the distro
should make. Regardless of how broken busybox might be - that's the
distro's problem, not something a filesystem driver should care about.


Additionally:

How about a compromise: Put util-linux-mount into the RRECOMMENDS 
instead of RDEPENDS. Then at least the distro can get rid of it using a 
BAD_RECOMMENDS or similar construct.


Let me know, I'll post a patch.

Mike.


Thanks,
Hongxu

On 09/18/2013 01:55 PM, Mike Looijmans wrote:

Ping!

Anything wrong with the patch? anyone reading this at all?

BTW, the same problem is in the exfat recipe, so I was going to send a
patch for that as well.


On 09/12/2013 11:37 AM, Mike Looijmans wrote:

ntfs-3g-ntfsprogs has no runtime dependency on util-linux-mount, for
example busybox mount will also do just fine. It might be less useful
without any mount program, but that's not the same as depending on it.

The dependency broke several images because util-linux-mount behaves
differently than busybox mount, resulting in failure to mount ext2/3
volumes and network shares on user's systems.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
  .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb

b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb


index e084187..a34a791 100644
---
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb


+++
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb


@@ -5,6 +5,7 @@ PROVIDES = ntfsprogs ntfs-3g
  LICENSE = GPLv2  LGPLv2
  LIC_FILES_CHKSUM =
file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a
+PR = r1

  SRC_URI = http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz;
  S = ${WORKDIR}/ntfs-3g_ntfsprogs-${PV}
@@ -23,7 +24,7 @@ EXTRA_OEMAKE = LDCONFIG=echo
  PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g

  FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g*
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse

  FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
  FILES_libntfs-3g = ${libdir}/*${SOLIBS}




Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any

[oe] [meta-oe][PATCH] fuse-exfat, ntfs-3g-ntfsprogs: Move util-linux-mount to RRECOMMENDS

[Mike Looijmans]

Soften the dependency to allow distros to use another mount provider
like busybox instead of being forced to use util-linux-mount.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
 .../fuse-exfat/fuse-exfat_1.0.1.bb |2 +-
 .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb 
b/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
index d29dc0a..f984c4b 100644
--- a/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
+++ b/meta-filesystems/recipes-filesystems/fuse-exfat/fuse-exfat_1.0.1.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=d32239bcb673463ab874e80d47fae504
 SRC_URI = ${DEBIAN_MIRROR}/main/f/fuse-exfat/fuse-exfat_${PV}.orig.tar.gz \
 
 DEPENDS = fuse virtual/libc
-RDEPENDS_${PN} += util-linux-mount
+RRECOMMENDS_${PN} = util-linux-mount
 
 inherit scons
 
diff --git 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
index e084187..c1392cc 100644
--- 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
+++ 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
@@ -23,7 +23,8 @@ EXTRA_OEMAKE = LDCONFIG=echo
 PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g
 
 FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* 
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse
+RRECOMMENDS_ntfs-3g = util-linux-mount
 
 FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
 FILES_libntfs-3g = ${libdir}/*${SOLIBS}
-- 
1.7.9.5

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

Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

On 09/18/2013 11:13 AM, Hongxu Jia wrote:

Hi Mike,

The reason why add util-linux-mount to RDEPENDS is the mount in
busybox doesn't support 'syntax of external mount helpers' very well.

Which means you could directly invoke mount rather than
mount.ntfs/mount.exfat
to mount ntfs/exfat filesystem.


I really don't have the faintest clue what you're referring to. Could 
you please explain?


And my experience is exactly the opposite - When util-linux-mount gets 
installed, it breaks things. Busybox mount works just fine.


If anything, it should rdepend on something like virtual/mount or so.

It doesn't seem right for a package to enforce choices that the distro 
should make. Regardless of how broken busybox might be - that's the 
distro's problem, not something a filesystem driver should care about.


Regards,
Mike.



Thanks,
Hongxu

On 09/18/2013 01:55 PM, Mike Looijmans wrote:

Ping!

Anything wrong with the patch? anyone reading this at all?

BTW, the same problem is in the exfat recipe, so I was going to send a
patch for that as well.


On 09/12/2013 11:37 AM, Mike Looijmans wrote:

ntfs-3g-ntfsprogs has no runtime dependency on util-linux-mount, for
example busybox mount will also do just fine. It might be less useful
without any mount program, but that's not the same as depending on it.

The dependency broke several images because util-linux-mount behaves
differently than busybox mount, resulting in failure to mount ext2/3
volumes and network shares on user's systems.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
  .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb

index e084187..a34a791 100644
---
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb

+++
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb

@@ -5,6 +5,7 @@ PROVIDES = ntfsprogs ntfs-3g
  LICENSE = GPLv2  LGPLv2
  LIC_FILES_CHKSUM =
file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a
+PR = r1

  SRC_URI = http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz;
  S = ${WORKDIR}/ntfs-3g_ntfsprogs-${PV}
@@ -23,7 +24,7 @@ EXTRA_OEMAKE = LDCONFIG=echo
  PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g

  FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g*
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse

  FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
  FILES_libntfs-3g = ${libdir}/*${SOLIBS}





Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn
uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het
e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking
tot een derde instaan. Indien u als niet-geadresseerde dit bericht en
de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit
bericht namens de geadresseerde te ontvangen, wordt u verzocht de
afzender hierover direct te informeren en het e-mail bericht met de
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail
bericht, waaronder de daarbij behorende bijlagen, door een ander dan
de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in
het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC
Embedded Systems is niet aansprakelijk voor enigerlei schade
voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht
of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed
personally to, and thus solely intended for the addressee. They may
contain information regarding a third party. A recipient who is
neither the addressee, nor empowered to receive this message on behalf
of the addressee, is kindly requested to immediately inform the sender
of receipt, and to destroy the message and the enclosures. Any use of
the contents of this message and/or the enclosures by any other person
than the addressee or person who is empowered to receive this message,
is illegal towards the sender and/or the aforementioned third party.
TOPIC Embedded Systems is not  liable for any damage as a result of
the use and/or acceptance of this message and as well as any enclosures.



Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e

Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

Ping!

Anything wrong with the patch? anyone reading this at all?

BTW, the same problem is in the exfat recipe, so I was going to send a 
patch for that as well.



On 09/12/2013 11:37 AM, Mike Looijmans wrote:

ntfs-3g-ntfsprogs has no runtime dependency on util-linux-mount, for
example busybox mount will also do just fine. It might be less useful
without any mount program, but that's not the same as depending on it.

The dependency broke several images because util-linux-mount behaves
differently than busybox mount, resulting in failure to mount ext2/3
volumes and network shares on user's systems.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
  .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
index e084187..a34a791 100644
--- 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
+++ 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
@@ -5,6 +5,7 @@ PROVIDES = ntfsprogs ntfs-3g
  LICENSE = GPLv2  LGPLv2
  LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
  file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a
+PR = r1

  SRC_URI = http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz;
  S = ${WORKDIR}/ntfs-3g_ntfsprogs-${PV}
@@ -23,7 +24,7 @@ EXTRA_OEMAKE = LDCONFIG=echo
  PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g

  FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* 
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse

  FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
  FILES_libntfs-3g = ${libdir}/*${SOLIBS}





Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any enclosures.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Re: [oe] using deb as source while building image.

[Mike Looijmans]

On 09/17/2013 07:00 AM, Lukas Bulwahn wrote:

On 09/16/2013 02:32 PM, Anup Kini wrote:

I am trying to understand how deb packages can be used to build the
image.
Since, i need to install a few pre-built application.
let me know if you have any pointers on how to proceed with this.


If you have the source code available, I believe it is much easier to
write a proper recipe than to use a prebuilt binary, which you do not
know the exact compiler flags, which libraries you need to dynamically
link to, etc.

However, maybe someone on the mailing list has already some experience
trying to integrate prebuilt binaries into the images.


Yes, in some occasions going as far as writing a recipe for unpacking it 
and then re-pack it into an ipk (or whatever OE was set to do).


It's a recipe for disaster. Don't do it. Get source code, and if that 
isn't possible, find or write an alternative.


Mike.


Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijm...@topic.nl
Website: www.topic.nl

Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend 
bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de 
bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als 
niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd 
of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u 
verzocht de afzender hierover direct te informeren en het e-mail bericht met de 
bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, 
waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is 
onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de 
bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet 
aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of 
acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.

The contents of this message, as well as any enclosures, are addressed 
personally to, and thus solely intended for the addressee. They may contain 
information regarding a third party. A recipient who is neither the addressee, 
nor empowered to receive this message on behalf of the addressee, is kindly 
requested to immediately inform the sender of receipt, and to destroy the 
message and the enclosures. Any use of the contents of this message and/or the 
enclosures by any other person than the addressee or person who is empowered to 
receive this message, is illegal towards the sender and/or the aforementioned 
third party. TOPIC Embedded Systems is not  liable for any damage as a result 
of the use and/or acceptance of this message and as well as any enclosures.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

[oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

ntfs-3g-ntfsprogs has no runtime dependency on util-linux-mount, for
example busybox mount will also do just fine. It might be less useful
without any mount program, but that's not the same as depending on it.

The dependency broke several images because util-linux-mount behaves
differently than busybox mount, resulting in failure to mount ext2/3
volumes and network shares on user's systems.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
 .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
index e084187..a34a791 100644
--- 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
+++ 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
@@ -5,6 +5,7 @@ PROVIDES = ntfsprogs ntfs-3g
 LICENSE = GPLv2  LGPLv2
 LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
 file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a
+PR = r1
 
 SRC_URI = http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz;
 S = ${WORKDIR}/ntfs-3g_ntfsprogs-${PV}
@@ -23,7 +24,7 @@ EXTRA_OEMAKE = LDCONFIG=echo
 PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g
 
 FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* 
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse
 
 FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
 FILES_libntfs-3g = ${libdir}/*${SOLIBS}
-- 
1.7.9.5

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

[oe] [PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount

[Mike Looijmans]

ntfs-3g-ntfsprogs has no runtime dependency on util-linux-mount, for
example busybox mount will also do just fine. It might be less useful
without any mount program, but that's not the same as depending on it.

Signed-off-by: Mike Looijmans mike.looijm...@topic.nl
---
 .../ntfs-3g-ntfsprogs_2013.1.13.bb |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
index e084187..a34a791 100644
--- 
a/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
+++ 
b/meta-filesystems/recipes-filesystems/ntfs-3g-ntfsprogs/ntfs-3g-ntfsprogs_2013.1.13.bb
@@ -5,6 +5,7 @@ PROVIDES = ntfsprogs ntfs-3g
 LICENSE = GPLv2  LGPLv2
 LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
 file://COPYING.LIB;md5=f30a9716ef3762e3467a2f62bf790f0a
+PR = r1
 
 SRC_URI = http://tuxera.com/opensource/ntfs-3g_ntfsprogs-${PV}.tgz;
 S = ${WORKDIR}/ntfs-3g_ntfsprogs-${PV}
@@ -23,7 +24,7 @@ EXTRA_OEMAKE = LDCONFIG=echo
 PACKAGES =+ ntfs-3g ntfsprogs libntfs-3g
 
 FILES_ntfs-3g = ${base_sbindir}/*.ntfs-3g ${bindir}/ntfs-3g* 
${base_sbindir}/mount.ntfs
-RDEPENDS_ntfs-3g += fuse util-linux-mount
+RDEPENDS_ntfs-3g += fuse
 
 FILES_ntfsprogs = ${base_sbindir}/* ${bindir}/* ${sbindir}/*
 FILES_libntfs-3g = ${libdir}/*${SOLIBS}
-- 
1.7.9.5

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