[oe] [PATCH] nvme-cli: Support read-only systems
Attempting to install nvme-cli on a read-only system fails because of
the post-install script that creates /etc/nvme/hostnqn and hostid.
These files aren't actually needed for 99% of nvme-cli functionality.
Split the postinstall into a separate package, nvme-cli-user and also
move the unwanted util-linux-uuidgen dependency to that package.
This allows to install and use nvme-cli on a read-only rootfs. If
someone wants to run nvme-stas it will need a dependency on nvme-cli-user
to create the files.
Signed-off-by: Mike Looijmans
---
meta-oe/recipes-bsp/nvme-cli/nvme-cli_2.8.bb | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/meta-oe/recipes-bsp/nvme-cli/nvme-cli_2.8.bb
b/meta-oe/recipes-bsp/nvme-cli/nvme-cli_2.8.bb
index 81b30c283..2f034a675 100644
--- a/meta-oe/recipes-bsp/nvme-cli/nvme-cli_2.8.bb
+++ b/meta-oe/recipes-bsp/nvme-cli/nvme-cli_2.8.bb
@@ -16,15 +16,16 @@ inherit bash-completion meson pkgconfig systemd
EXTRA_OEMESON += "-Dsystemddir=${systemd_unitdir}/system"
-pkg_postinst_ontarget:${PN}() {
+pkg_postinst_ontarget:${PN}-user() {
${sbindir}/nvme gen-hostnqn > ${sysconfdir}/nvme/hostnqn
${bindir}/uuidgen > ${sysconfdir}/nvme/hostid
}
-PACKAGES =+ "${PN}-dracut ${PN}-zsh-completion"
+PACKAGES =+ "${PN}-dracut ${PN}-zsh-completion ${PN}-user"
FILES:${PN} += "${systemd_system_unitdir}"
FILES:${PN}-dracut = "${nonarch_libdir}/dracut/dracut.conf.d"
FILES:${PN}-zsh-completion = "${datadir}/zsh/site-functions"
+ALLOW_EMPTY:${PN}-user = "1"
-RDEPENDS:${PN} = "util-linux-uuidgen"
+RDEPENDS:${PN}-user = "util-linux-uuidgen"
--
2.34.1
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...@topic.nl
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 (#110901):
https://lists.openembedded.org/g/openembedded-devel/message/110901
Mute This Topic: https://lists.openembedded.org/mt/10578/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
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:
[oe] [PATCH][meta-java][master] openjdk-8: Workaround TOPDIR not getting expanded in configure.ac
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
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',
&#x
Re: [oe] [meta-java] openjre8 fails to compile on aarch64
sroot-native/usr/bin/autoreconf line 411. | ERROR: autoreconf execution failed. | 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 | ERROR: Execution of '/home/.../build/tmp-glibc/work/x86_64-linux/openjdk-8-native/272-r0/temp/run.do_configure.16646' failed with exit code 1: | automake (GNU automake) 1.16.2 | Copyright (C) 2020 Free Software Foundation, Inc. | License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html> | This is free software: you are 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
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-a
Re: [oe] [meta-java] openjre8 fails to compile on aarch64
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-
Re: [oe] [meta-java] openjre8 fails to compile on aarch64
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/openj
Re: [oe] [meta-java] openjre8 fails to compile on aarch64
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_co
Re: [oe] [meta-java] openjre8 fails to compile on aarch64
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
[oe] [meta-java] openjre8 fails to compile on aarch64
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
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
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
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
Re: [oe] Python3 bytecode is stale
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
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
---
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
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
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&id=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
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
Signed-off-by: Martin Jansa
and maybe (don't know the status of gnome.bbclass in morty) - but
should not do any harm
commit 3be9eea720ba70fd3a9e4744401fd268e31731f8
Author: Khem Raj
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
Signed-off-by: Martin Jansa
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
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
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 --- 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
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 :
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
---
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
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
---
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
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
---
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
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
---
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
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
---
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
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
---
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
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 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
---
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
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
---
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
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
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
---
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
+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
+---
+ 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
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 wrote:
On Sat, Sep 24, 2016 at 8:01 AM, Mike Looijmans
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
---
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
On 23-09-16 20:33, Khem Raj wrote:
On Fri, Sep 23, 2016 at 5:33 AM, Mike Looijmans 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
---
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
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
---
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
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 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
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?=
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
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
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
---
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
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
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 --- .../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
Re: [oe] [PATCH] waf-cross-answers: Fix faulty link cross-answers-mipsel.txt
Just a reminder that currently "waf" is broken and still won't work on mipsel platforms without this bugfix. 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 --- .../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 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [PATCH] waf-cross-answers: Fix faulty link cross-answers-mipsel.txt
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 --- .../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 -- 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/README: Fix typo "bbaclss"
Signed-off-by: Mike Looijmans --- 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
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 --- 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
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
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
---
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
On 11-01-16 19:11, Khem Raj wrote:
On Jan 11, 2016, at 10:06 AM, Mike Looijmans wrote:
On 11-01-16 19:00, Khem Raj wrote:
On Jan 11, 2016, at 9:53 AM, Mike Looijmans 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
---
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
On 11-01-16 19:00, Khem Raj wrote:
On Jan 11, 2016, at 9:53 AM, Mike Looijmans 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
---
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
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
---
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
On 08-01-16 12:06, Jens Rehsack wrote: Am 08.01.2016 um 11:21 schrieb 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. 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
Re: [oe] Building java
On 08-01-16 10:48, Jens Rehsack wrote: Am 08.01.2016 um 08:39 schrieb 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? 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
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
[oe] Building java
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
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
---
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?
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?
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"
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
---
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
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 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
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
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 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
Re: [oe] "libgudev" fails to build with current master
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 wrote: On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans 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
On 25-09-15 01:22, Andreas Müller wrote: On Thu, Sep 24, 2015 at 6:45 PM, Andreas Müller wrote: On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans 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
On 24-09-15 18:45, Andreas Müller wrote: On Thu, Sep 24, 2015 at 3:40 PM, Mike Looijmans 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
[oe] "libgudev" fails to build with current master
| 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] gnome-icon-theme?
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] gnome-icon-theme?
With current master I get errors like this: ERROR: Nothing PROVIDES 'gnome-icon-theme' (but .../meta-oe/meta-gnome/recipes-gnome/evince/evince_2.32.0.bb DEPENDS on or otherwise requires it). Close matches: rodent-icon-theme gnome-themes sato-icon-theme ERROR: Required build target 'evince' has no buildable providers. Missing or unbuildable dependency chain was: ['evince', 'gnome-icon-theme'] And similar for quite a few other recipes. Surprisingly, I cannot find any recipe that provides it in meta-oe. Was it moved to another layer maybe? I can't find any mention of gnome-icon-theme for the past few months in the log either. -- ___ 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"
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
---
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
Re: [oe] Where is libunique?
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] Where is libunique?
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
[oe] [PATCH][meta-python] python-pyopenssl: Inherit setuptools to fix failing install
From: Mike Looijmans
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
---
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
[oe] "krb" fails to build, suspect GCC bug
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
Re: [oe] [OE-core] "sub" machine types?
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] python-pyopenssl fails during install phase
/build/tmp/work/mips32el-oe-linux/python-pyopenssl/1_0.15.1-r0/image/usr/lib/python2.7/site-packages/six-1.9.0-py2.7.egg Searching for cryptography>=0.7 Reading https://pypi.python.org/simple/cryptography/ Best match: cryptography 1.0 Downloading https://pypi.python.org/packages/source/c/cryptography/cryptography-1.0.tar.gz#md5=3f2608eb94dcc6e616c3cc2e182181b0 Processing cryptography-1.0.tar.gz Writing /tmp/easy_install-4LpLp5/cryptography-1.0/setup.cfg Running cryptography-1.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-4LpLp5/cryptography-1.0/egg-dist-tmp-gn1Pcd Installed /tmp/easy_install-4LpLp5/cryptography-1.0/.eggs/cffi-1.2.1-py2.7-linux-x86_64.egg Traceback (most recent call last): File "setup.py", line 78, in test_suite="OpenSSL") File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "build/bdist.linux-x86_64/egg/setuptools/command/install.py", line 67, in run File "build/bdist.linux-x86_64/egg/setuptools/command/install.py", line 117, in do_egg_install File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 380, in run File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 610, in easy_install File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 661, in install_item File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 709, in process_distribution File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 836, in resolve File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 1081, in best_match File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 1093, in obtain File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 629, in easy_install File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 659, in install_item File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 842, in install_eggs File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1070, in build_and_install File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1056, in run_setup File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 240, in run_setup File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 193, in setup_context File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 164, in save_modules File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 139, in resume File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 152, in save_modules File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 193, in setup_context File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 237, in run_setup File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 267, in run File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 236, in runner File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 46, in _execfile File "/tmp/easy_install-4LpLp5/cryptography-1.0/setup.py", line 307, in File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/core.py", line 111, in setup _setup_distribution = dist = klass(attrs) File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 272, in __init__ File "/TOPDIR/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/dist.py", line 287, in __init__ self.finalize_options() File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 327, in finalize_options File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2355, in load File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2361, in resolve ImportError: No module named setuptools_ext WARNING: exit code 1 from a shell command. ERROR: python setup.py install execution failed. -- 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
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
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
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: Create a separate source code package and bin package
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
---
.../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] python-twisted: Fix dependencies of twisted modules
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
ImportError: No module named contextlib
Signed-off-by: Mike Looijmans
---
.../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] iperf3: Add native support
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
---
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
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
Signed-off-by: Awais Belal
---
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
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
Tested and in use for a while in OpenPLi.
Signed-off-by: Mike Looijmans
---
.../{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
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
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
+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
+Signed-off-by: Robert Yang
+---
+ 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 2>&1
+ 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
Re: [oe] [PATCH 02/14] autofs: add bash to RDEPENDS_autofs
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
2>&1):
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
---
.../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
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
---
.../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
On 09/04/2014 07:29 PM, Andreas Müller wrote: On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross wrote: On 4 September 2014 15:12, Burton, Ross 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
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 To: 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
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] Correct versioning of unversioned source in git
On 03/13/2014 12:54 PM, Paul Eggleton wrote:
On Thursday 13 March 2014 12:17:40 Koen Kooi wrote:
Op 13 mrt. 2014, om 12:14 heeft Paul Eggleton
het volgende geschreven:
On Thursday 13 March 2014 12:09:21 Koen Kooi wrote:
Op 13 mrt. 2014, om 11:45 heeft Paul Eggleton
het volgende geschreven:
On Thursday 13 March 2014 10:59:38 Koen Kooi wrote:
Tomas Novotny schreef op 13-03-14 10:08:
there is a recipe sunxi-board-fex in meta-sunxi layer. That recipe
fetches sources from unversioned git which contains definitions of
some
boards (in fact it is something like a store). I'm not sure with
correct
versioning in OE. Is that: PV = "1.0+git${SRCPV}" SRCREV =
"" correct? Will be change of SRCREV (only)
catched
by build system (I'm curious how OE handles age of the rev in git)? Or
do
I need to raise PV to 1.1 and so on with every change to SRCREV?
The answer changes if you have more than one buildhost. If you have
only
one buildhost and don't care about other people rebuilding the exact
same versions, 1.0+git${SRCPV} will work.
If you have more than one buildhost and/or care about other people
rebuilding the exact same, you'll need to increase PR (or PV) everytime
SRCREV changes. That will still cause some discrepancies if someone
rebuilds after >1 SRCREV change, but upgrade paths should work when
increasing PV (not with PR!).
Why not with PR?
because SRCPV in in PV, not PR
Right, but if you're using the PR server, that also stores the
incrementing
number at the start of SRCPV; PR may also increment when SRCREV changes as
well (not sure on the latter). The PR server ought to be used if you care
about this sort of thing.
Only if your PR server is publicly available *and* you have network access
during the build. There is currently no workable way to get versioning info
to users trying to rebuild something. The closest I've been to a solution
is to ship prserv-tool exports in git.
If you're saying you want something that doesn't require network access, gets
the right answer for all users *and* automatically increments when something
changes - those are conflicting requirements...
"gitpkgv" from mete-openembedded has been doing a good job at that for me in
several projects. It just counts the number of git commits and uses that as
counter. Everybody thus sees the same number, versions are incremental, and no
server access needed during build.
My only wish would be that this were in oe-core.
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
--
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] musicbrainz: Build with B=S
On 5-3-2014 19:08, Martin Jansa wrote:
On Sat, Mar 01, 2014 at 06:54:47PM +0100, mike.looijm...@topic.nl wrote:
From: Mike Looijmans
This recipe doesn't work when B!=S, so force B=$S to fix the failure.
Signed-off-by: Mike Looijmans
What's the relation of this change to
http://patchwork.openembedded.org/patch/67597/
?
I suspect they both accomplish the same: Make the project compile again.
Mine is the simplistic approach I guess - I did the least I could
possible get away with... "Theirs" looks more like they actually
understand what's going on
Mike.
---
.../musicbrainz/libmusicbrainz_git.bb |3 +++
1 file changed, 3 insertions(+)
diff --git
a/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
b/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
index f6a8f53..4cc04b8 100644
--- a/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
+++ b/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
@@ -37,3 +37,6 @@ do_configure_prepend() {
EXTRA_OECMAKE = "-DLIB_INSTALL_DIR:PATH=${libdir} \
-DIMPORT_EXECUTABLES=build-native/ImportExecutables.cmake"
+
+# out-of-tree building doesn't appear to work for this package.
+B = "${S}"
--
1.7.9.5
___
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] [PATCH] musicbrainz: Build with B=S
From: Mike Looijmans
This recipe doesn't work when B!=S, so force B=$S to fix the failure.
Signed-off-by: Mike Looijmans
---
.../musicbrainz/libmusicbrainz_git.bb |3 +++
1 file changed, 3 insertions(+)
diff --git
a/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
b/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
index f6a8f53..4cc04b8 100644
--- a/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
+++ b/meta-multimedia/recipes-multimedia/musicbrainz/libmusicbrainz_git.bb
@@ -37,3 +37,6 @@ do_configure_prepend() {
EXTRA_OECMAKE = "-DLIB_INSTALL_DIR:PATH=${libdir} \
-DIMPORT_EXECUTABLES=build-native/ImportExecutables.cmake"
+
+# out-of-tree building doesn't appear to work for this package.
+B = "${S}"
--
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] fuse-exfat, ntfs-3g-ntfsprogs: Move util-linux-mount to RRECOMMENDS
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
---
.../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
>>>>> 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
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
[oe] [meta-oe][PATCH] fuse-exfat, ntfs-3g-ntfsprogs: Move util-linux-mount to RRECOMMENDS
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
---
.../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
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
---
.../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,
Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount
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
---
.../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 Syst
Re: [oe] [meta-oe][PATCH] ntfs-3g-ntfsprogs does not rdepend on util-linux-mount
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
---
.../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.
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
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
---
.../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
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
---
.../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
