[OE-core] [PATCH] archiver.bbclass: Run after do_unpack
In recipes that are exempt from source code archiving due to
COPYLEFT_LICENSE_EXCLUDE, do_deploy_archives does not have a transitive
dependency on do_unpack. Given enough parallelism, this means
do_deploy_archives can run at the same time or before do_unpack.
Because do_deploy_archives does not specify a working directory, its
working directory is ${B}, which defaults to ${S}, which may be set by
a recipe to a directory that is created by do_unpack.
In this case, do_deploy_archives fails because it cannot change into the
non-existent directory. Avoid this problem by always running
do_deploy_archives after do_unpack.
Signed-off-by: Clemens Lang
---
meta/classes/archiver.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index d908d16..407e538 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -373,7 +373,7 @@ addtask do_ar_patched after do_unpack_and_patch
addtask do_ar_configured after do_unpack_and_patch
addtask do_dumpdata
addtask do_ar_recipe
-addtask do_deploy_archives before do_build
+addtask do_deploy_archives after do_unpack before do_build
addtask do_deploy_all_archives after do_deploy_archives
do_deploy_all_archives[recrdeptask] = "do_deploy_archives"
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Avoid race condition between do_unpack and do_deploy_archives in archiver.bbclass
Hi,
the following patch fixes a race condition in archiver.bbclass that can
occur when a very specific set of preconditions is fulfilled:
- a recipe sets $S to a directory that will be created by do_unpack
- $B is at its default value of $S
- the license of the recipe is in COPYLEFT_LICENSE_EXCLUDE, skipping
source code archiving
When this happens, do_deploy_archives (which is a no-op task that only
prints a single line) does not depend indirectly on do_unpack, as it
would usually do via a dependency on
do_ar_${@d.getVarFlag('ARCHIVER_MODE', 'src', True)}.
Because do_deploy_archives does not specify a working directory, it
defaults to $B, which does not exist when do_deploy_archives is run in
parallel (or before) do_unpack.
The attached patch fixes this by making do_deploy_archives run after
do_unpack in all cases (which is already does for recipes not excluded
due their license).
This problem is also present on dizzy (and thus probably also on fido).
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Avoid race condition between do_unpack and do_deploy_archives in archiver.bbclass
On Thu, Aug 13, 2015 at 12:09:07PM +0100, Burton, Ross wrote:
> I'm not sure I follow this. Functions are executed using exec_func()
> will create and cd to the default directory, so if that is ${B} then
> exec_func will create ${B} before executing the function.
I see this in the code, but my error messages speak a very different
language. Maybe it's a race condition with do_unpack, which actually
deletes and re-creates these directories again? In any case, there is a
race condition that causes the directory to be missing when it should be
there.
For reference, here's one that fails to chdir in Python code:
> 00:07:32.460 NOTE: Running task 2381 of 6712 (ID: 1986,
> /home/builder/src/base/meta-mgu-swint-testing/recipes-test-components/bci-test-component/bci-test-component.bb,
> do_deploy_archives)
> [...]
> 00:07:32.461 NOTE: Running task 2382 of 6712 (ID: 1972,
> /home/builder/src/base/meta-mgu-swint-testing/recipes-test-components/bci-test-component/bci-test-component.bb,
> do_unpack)
> [...]
> 00:07:32.464 NOTE: recipe bci-test-component-0.0.2-r0: task
> do_deploy_archives: Started
> 00:07:32.465 NOTE: recipe bci-test-component-0.0.2-r0: task do_unpack: Started
> 00:07:32.465 ERROR: Build of do_deploy_archives failed
> 00:07:32.465 ERROR: Traceback (most recent call last):
> 00:07:32.466 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
> line 497, in exec_task
> 00:07:32.466 return _exec_task(fn, task, d, quieterr)
> 00:07:32.467 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
> line 440, in _exec_task
> 00:07:32.467 exec_func(func, localdata)
> 00:07:32.467 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
> line 212, in exec_func
> 00:07:32.468 exec_func_python(func, d, runfile, cwd=adir)
> 00:07:32.468 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
> line 237, in exec_func_python
> 00:07:32.469 os.chdir(cwd)
> 00:07:32.469 OSError: [Errno 2] No such file or directory:
> '/home/builder/src/base/build_vmwx86/tmp/work/core2-32-linux/bci-test-component/0.0.2-r0/git'
> 00:07:32.469
> 00:07:32.470 NOTE: recipe bci-test-component-0.0.2-r0: task
> do_deploy_archives: Failed
And here's another one that shows the same problem for a Shell function:
> 00:09:40.943 NOTE: Running task 3484 of 7306 (ID: 2653,
> /home/builder/src/base/meta-mgu-swint-sdk/recipes-extended/dlt-daemon/dlt-daemon-sdktests_2.10.0.bb,
> do_deploy_archives)
> 00:09:40.944 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task do_fetch:
> Succeeded
> [...]
> 00:09:40.946 NOTE: Running task 3485 of 7306 (ID: 2640,
> /home/builder/src/base/meta-mgu-swint-sdk/recipes-extended/dlt-daemon/dlt-daemon-sdktests_2.10.0.bb,
> do_unpack)
> [...]
> 00:09:40.953 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task
> do_deploy_archives: Started
> 00:09:41.930 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task do_unpack:
> Started
> [...]
> 00:09:41.931 ERROR: Function failed: do_deploy_archives (log file is located
> at
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418)
> 00:09:41.932 ERROR: Logfile of failure stored in:
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418
> 00:09:41.933 Log data follows:
> 00:09:41.934 | DEBUG: Executing python function sstate_task_prefunc
> 00:09:41.934 | DEBUG: Python function sstate_task_prefunc finished
> 00:09:41.934 | DEBUG: Executing shell function do_deploy_archives
> 00:09:41.935 |
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/run.do_deploy_archives.25418:
> 102: cd: can't cd to
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/git
> 00:09:41.936 | WARNING: exit code 2 from a shell command.
> 00:09:41.936 | ERROR: Function failed: do_deploy_archives (log file is
> located at
> /home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/all-linux/dlt-daemon-sdktests/2.10.0-r0/temp/log.do_deploy_archives.25418)
> 00:09:41.937 NOTE: recipe dlt-daemon-sdktests-2.10.0-r0: task
> do_deploy_archives: Failed
I do not see any of these issues with my patch applied.
--
Clemens Lang • Development Specialist
BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com
-
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
-
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] archiver.bbclass: Run deploy_archives in $WORKDIR
In recipes that are exempt from source code archiving due to
COPYLEFT_LICENSE_EXCLUDE, do_deploy_archives does not have a transitive
dependency on do_unpack. Given enough parallelism, this means
do_deploy_archives can run at the same time or before do_unpack.
Because do_deploy_archives did not specify a working directory, its
working directory was ${B}, which defaults to ${S}, which may be set by
a recipe to a directory that is created by do_unpack.
In this case, do_deploy_archives can fail because do_unpack deletes and
re-creates the directory and do_deploy_archives cannot change into the
non-existent directory. Avoid this problem by explicitly specifying
a working directory for do_deploy_archives (and for
do_deploy_all_archives as well for good measure).
Signed-off-by: Clemens Lang
---
meta/classes/archiver.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/archiver.bbclass b/meta/classes/archiver.bbclass
index d908d16..f9c439e 100644
--- a/meta/classes/archiver.bbclass
+++ b/meta/classes/archiver.bbclass
@@ -45,6 +45,11 @@ ARCHIVER_WORKDIR = "${WORKDIR}/archiver-work/"
do_dumpdata[dirs] = "${ARCHIVER_OUTDIR}"
do_ar_recipe[dirs] = "${ARCHIVER_OUTDIR}"
do_ar_original[dirs] = "${ARCHIVER_OUTDIR} ${ARCHIVER_WORKDIR}"
+# When not set, the working directory for the following tasks can default to
+# a location that will be deleted and re-created by do_unpack, which can lead
+# to failure; avoid that by explicitly setting them.
+do_deploy_archives[dirs] = "${WORKDIR}"
+do_deploy_all_archives[dirs] = "${WORKDIR}"
# This is a convenience for the shell script to use it
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] archiver.bbclass: Run deploy_archives in $WORKDIR
Hey,
On Mon, Aug 17, 2015 at 10:37:47AM +0200, Clemens Lang wrote:
> In recipes that are exempt from source code archiving due to
> COPYLEFT_LICENSE_EXCLUDE, do_deploy_archives does not have a transitive
> dependency on do_unpack. Given enough parallelism, this means
> do_deploy_archives can run at the same time or before do_unpack.
>
> Because do_deploy_archives did not specify a working directory, its
> working directory was ${B}, which defaults to ${S}, which may be set by
> a recipe to a directory that is created by do_unpack.
>
> In this case, do_deploy_archives can fail because do_unpack deletes and
> re-creates the directory and do_deploy_archives cannot change into the
> non-existent directory. Avoid this problem by explicitly specifying
> a working directory for do_deploy_archives (and for
> do_deploy_all_archives as well for good measure).
>
> Signed-off-by: Clemens Lang
So you merged this change in
- OE Core e22685ff11af6d54c939aa8f327a0aaa1557fbbc
- poky 76d7e8e9c9881afefafed3acfd1a72d97b025d75
but it turns out that even with this fix, we occasionally see the same
problem:
00:06:02.343 NOTE: recipe nativesdk-mgu-can-1.0+gitAUTOINC+ed9c00caae-r0:
task do_unpack: Started
00:06:02.344 ERROR: Build of do_deploy_archives failed
00:06:02.344 ERROR: Traceback (most recent call last):
00:06:02.344 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
line 497, in exec_task
00:06:02.345 return _exec_task(fn, task, d, quieterr)
00:06:02.345 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
line 440, in _exec_task
00:06:02.346 exec_func(func, localdata)
00:06:02.346 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
line 212, in exec_func
00:06:02.346 exec_func_python(func, d, runfile, cwd=adir)
00:06:02.347 File "/home/builder/src/base/poky/bitbake/lib/bb/build.py",
line 237, in exec_func_python
00:06:02.347 os.chdir(cwd)
00:06:02.347 OSError: [Errno 2] No such file or directory:
'/home/builder/src/base/build_xs-baytrail-hmgua1/tmp/work/i686-nativesdk-linux/nativesdk-mgu-can/1.0+gitAUTOINC+ed9c00caae-r0/git'
Again, the license of the recipe that fails is "CLOSED". You can see
that it tries to cd into ${S}, which is set to ${WORKDIR}/git by the
recipe, even though do_deploy_archives[dirs] is set to ${WORKDIR} in
archiver.bbclass. Any ideas why the working directory might still be
${S}? Is there a way to see all flags of a task similar to bitbake -e
(that output doesn't seem to contain it)?
My initially proposed fix that adds the dependency works correctly,
though. I think we should just acknowledge that do_unpack should be run
before attempting any other tasks related to source code and merge the
initial version of my patch instead to fix this problem.
Let me know what you think,
Clemens Lang
--
Clemens Lang • Development Specialist
BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com
-
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Reinhard Stolle
Sitz und Registergericht: München HRB 134810
-
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ldconfig-native: Fix ELF flags on 64-bit binaries
Yocto's ldconfig-native was exported from an old version of glibc and
generates an ld.so.cache that is partially ignored by current versions
of glibc when loading libraries. This occurs for 64-bit binaries, where
glibc expects FLAG_ELF_LIBC6, but ldconfig-native only generates the
standard ELF flag. Fix this with an additional patch on top of the patch
for now.
You can verify this by applying the patch below to your target copy of
glibc and running
LD_DEBUG=libs /lib64/ld-linux-x86-64.so.2 --list $anybinary
--- ./elf/dl-cache.c.orig 2016-01-07 11:05:36.823447171 +0100
+++ ./elf/dl-cache.c2016-01-07 11:19:53.925878628 +0100
@@ -106,6 +106,8 @@
if (_dl_cache_check_flags (flags) \
&& _dl_cache_verify_ptr (lib->value)) \
{ \
+ if (__glibc_unlikely (GLRO_dl_debug_mask & DL_DEBUG_LIBS))\
+ _dl_debug_printf (" considering file %s\n", cache_data
+ lib->value); \
if (best == NULL || flags == GLRO(dl_correct_cache_id)) \
{ \
HWCAP_CHECK; \
@@ -117,6 +119,9 @@
searching. */ \
break; \
} \
+ } else {\
+ if (__glibc_unlikely (GLRO_dl_debug_mask &
DL_DEBUG_LIBS)) \
+ _dl_debug_printf (" ignoring file %s due to flags %x,
expected %x\n", cache_data + lib->value, lib->flags,
GLRO(dl_correct_cache_id)); \
} \
} \
while (++middle <= right);\
@@ -265,14 +270,23 @@
/* Only accept hwcap if it's for the right platform. */
#define HWCAP_CHECK \
- if (lib->hwcap & hwcap_exclude)\
+ if (lib->hwcap & hwcap_exclude) {
\
+ if (__glibc_unlikely (GLRO_dl_debug_mask & DL_DEBUG_LIBS))\
+ _dl_debug_printf (" hwcap mismatch %x vs. %x\n", lib->hwcap,
hwcap_exclude); \
continue; \
- if (GLRO(dl_osversion) && lib->osversion > GLRO(dl_osversion)) \
+ }
\
+ if (GLRO(dl_osversion) && lib->osversion > GLRO(dl_osversion)) { \
+ if (__glibc_unlikely (GLRO_dl_debug_mask & DL_DEBUG_LIBS))\
+ _dl_debug_printf (" os version mismatch %x vs. %x\n",
lib->osversion, GLRO(dl_osversion)); \
continue; \
+ }
\
if (_DL_PLATFORMS_COUNT\
&& (lib->hwcap & _DL_HWCAP_PLATFORM) != 0 \
- && (lib->hwcap & _DL_HWCAP_PLATFORM) != platform) \
- continue
+ && (lib->hwcap & _DL_HWCAP_PLATFORM) != platform) { \
+ if (__glibc_unlikely (GLRO_dl_debug_mask & DL_DEBUG_LIBS))\
+ _dl_debug_printf (" platform mismatch %x vs. %x\n", lib->hwcap &
_DL_HWCAP_PLATFORM, platform); \
+ continue; \
+ }
SEARCH_CACHE (cache_new);
}
else
This version of ldconfig-native should really be replaced with a version
matching the glibc source in use on the target platform.
Signed-off-by: Clemens Lang
---
.../add-64-bit-flag-for-ELF64-entries.patch| 27 --
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git
a/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
index a9af110..f4e38d4 100644
---
a/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
+++
b/meta/recipes-core/glibc/ldconfig-native-2.12.1/add-64-bit-flag-for-ELF64-entries.patch
@@ -64,7 +64,7 @@ index 0bf0de3..6e87afc 100644
#undef check_ptr
#define check_ptr(ptr)
[OE-core] [PATCH] lib/oe/path: Fix tar invocation with --no-recursion
tar's --no-recursion flag only applies to files mentioned after the flag, which made it a no-op in this invocation of tar, because it was at the end of the command line. This is simple to verify with GNU tar 1.29: | $ mkdir foo | $ mkdir foo/dir | $ touch foo/dir/file | $ tar -cf - foo --no-recursion | tar t | foo/ | foo/dir/ | foo/dir/file | $ tar -cf - --no-recursion foo | tar t | foo/ Modify the code so that it actually does what the comment says by moving the flag in front of the --files-from argument. Signed-off-by: Clemens Lang --- meta/lib/oe/path.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/lib/oe/path.py b/meta/lib/oe/path.py index 413ebfb..9e238ea 100644 --- a/meta/lib/oe/path.py +++ b/meta/lib/oe/path.py @@ -77,7 +77,7 @@ def copyhardlinktree(src, dst): if (os.stat(src).st_dev == os.stat(dst).st_dev): # Need to copy directories only with tar first since cp will error if two # writers try and create a directory at the same time -cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p --files-from - --no-recursion | tar -xf - -C %s' % (src, src, dst) +cmd = 'cd %s; find . -type d -print | tar -cf - -C %s -p --no-recursion --files-from - | tar -xf - -C %s' % (src, src, dst) check_output(cmd, shell=True, stderr=subprocess.STDOUT) cmd = 'cd %s; find . -print0 | cpio --null -pdlu %s' % (src, dst) check_output(cmd, shell=True, stderr=subprocess.STDOUT) -- 2.8.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] gitpkgv: Fix $GITPKV for a single named git source
Hi, here's a patch that fixes gitpkgv.bbclass in situations where SRC_URI contains a single git repository with an explicit name set, i.e. SRC_URI = "git://...;name=foo" but SRCREV_FORMAT is not set. At the moment, this causes $GITPKGV to always be "default". If you use $GITPKGV in $PKGV, this leads to QA errors because version numbers do not increase. This problem does not affect recipes with multiple sources, because bitbake enforces that SRCREV_FORMAT is set when fetching from multiple version control systems. While preparing this patch, I noticed a couple of other potential problems: - Should gitpkgv.bbclass also support the Git Annex fetcher? - gitpkgv.bbclass does not work correctly with fetcher names that are substrings of each other. A source named foo and one named foo-tests with a SRVREV_FORMAT of "foo_foo-tests" does not work correctly. That's probably not a openembedded problem but should be addressed in bitbake, right? BR, Clemens Lang -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Alexis Trolin Sitz und Registergericht: München HRB 134810 - -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gitpkgv: Fix $GITPKV for a single named git source
Recipes that fetch from a single git source, assign a name to this
source and do not set SRCREV_FORMAT to this name will always get
a GITPKGV value of "default", which causes version-going-backwards QA
errors.
Fix this by automatically determining a suitable SRCREV_FORMAT from the
SRC_URI if none is set explicitly. This code does not run for multiple
git sources, because bitbake's fetcher enforces setting SRCREV_FORMAT
when multiple version-controlled sources are used.
Signed-off-by: Clemens Lang
---
meta-oe/classes/gitpkgv.bbclass | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/meta-oe/classes/gitpkgv.bbclass b/meta-oe/classes/gitpkgv.bbclass
index 1cba00c..f73304a 100644
--- a/meta-oe/classes/gitpkgv.bbclass
+++ b/meta-oe/classes/gitpkgv.bbclass
@@ -61,7 +61,14 @@ def get_git_pkgv(d, use_tags):
#
format = d.getVar('SRCREV_FORMAT', True)
if not format:
-format = 'default'
+names = []
+for url in ud.values():
+if url.type == 'git' or url.type == 'gitsm':
+names.extend(url.revisions.keys())
+if len(names) > 0:
+format = '_'.join(names)
+else:
+format = 'default'
found = False
for url in ud.values():
--
2.8.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake: install path variables should be relative to the prefix path
Hi, here's a patch to call CMake with relative paths for some variables. We're using this in production since Nov 2015 without issues. We also reported this upstream and confirmed that CMake expects relative paths. HTH, -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Alexis Trolin Sitz und Registergericht: München HRB 134810 - -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] cmake.bbclass: call cmake with a relative path
From: Thomas Witt
CMake wants a relative path for CMAKE_INSTALL_*DIR, an absolute path
breaks cross-compilation. This fact is documented in the following
ticket: https://cmake.org/Bug/view.php?id=14367
$sysconfdir and $localstatedir are not relative to $prefix, so they are
still set as absolute paths. With his change ${PROJECT}Targets.cmake
that are generated by cmakes "export" function will contain relative
paths instead of absolute ones.
Signed-off-by: Thomas Witt
Signed-off-by: Clemens Lang
---
meta/classes/cmake.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index b18152a..5203d8a 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -108,15 +108,15 @@ cmake_do_configure() {
${OECMAKE_SITEFILE} \
${OECMAKE_SOURCEPATH} \
-DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${bindir} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${sbindir} \
- -DCMAKE_INSTALL_LIBEXECDIR:PATH=${libexecdir} \
+ -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir',
True), d.getVar('prefix', True))} \
+ -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir',
True), d.getVar('prefix', True))} \
+
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir',
True), d.getVar('prefix', True))} \
-DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- -DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${sharedstatedir} \
+
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir',
True), d. getVar('prefix', True))} \
-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${libdir} \
- -DCMAKE_INSTALL_INCLUDEDIR:PATH=${includedir} \
- -DCMAKE_INSTALL_DATAROOTDIR:PATH=${datadir} \
+ -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir',
True), d.getVar('prefix', True))} \
+
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir',
True), d.getVar('prefix', True))} \
+
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir', True),
d.getVar('prefix', True))} \
-DCMAKE_INSTALL_SO_NO_EXE=0 \
-DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
-DCMAKE_VERBOSE_MAKEFILE=1 \
--
2.9.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] cmake.bbclass: call cmake with a relative path
Hi Ross, Ross Burton wrote: > Seems to work in my testing, but this breaks piglit's bash-completion > logic again (resulting in it not installing the file). If you understand > cmake then having a quick look at that would be much appreciated. For > reference the buildhistory-diff log is: > > packages/corei7-64-poky-linux/piglit/piglit-bash-completion: FILELIST: > removed all items "/usr/share/bash-completion/completions/piglit: I think this is not related to the patch and currently toggles randomly depending on whether bash-completion’s do_populate_sysroot gets run before piglit’s do_configure. Nothing seems to depend on bash-completion:do_populate_sysroot. $> bitbake -g piglit $> grep -c -- '-> "bash-completion\.do_populate_sysroot' task-depends.dot 0 HTH, -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Alexis Trolin Sitz und Registergericht: München HRB 134810 - -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gitpkgv: Fix $GITPKV for a single named git source
Hi everybody,
Khem Raj wrote:
>> On Aug 11, 2016, at 3:04 AM, Clemens Lang
>> wrote:
>>
>> Recipes that fetch from a single git source, assign a name to this
>> source and do not set SRCREV_FORMAT to this name will always get
>> a GITPKGV value of "default", which causes version-going-backwards QA
>> errors.
>>
>> Fix this by automatically determining a suitable SRCREV_FORMAT from the
>> SRC_URI if none is set explicitly. This code does not run for multiple
>> git sources, because bitbake's fetcher enforces setting SRCREV_FORMAT
>> when multiple version-controlled sources are used.
>
> looks good.
>
>> Signed-off-by: Clemens Lang
>> ---
>> meta-oe/classes/gitpkgv.bbclass | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/meta-oe/classes/gitpkgv.bbclass
>> b/meta-oe/classes/gitpkgv.bbclass
>> index 1cba00c..f73304a 100644
>> --- a/meta-oe/classes/gitpkgv.bbclass
>> +++ b/meta-oe/classes/gitpkgv.bbclass
>> @@ -61,7 +61,14 @@ def get_git_pkgv(d, use_tags):
>> #
>> format = d.getVar('SRCREV_FORMAT', True)
>> if not format:
>> -format = 'default'
>> +names = []
>> +for url in ud.values():
>> +if url.type == 'git' or url.type == 'gitsm':
>> +names.extend(url.revisions.keys())
>> +if len(names) > 0:
>> +format = '_'.join(names)
>> +else:
>> +format = 'default'
>>
>> found = False
>> for url in ud.values():
>> —
>> 2.8.1
Shameless bump. I haven’t heard any feedback on this other than this “looks
good” comment, but it isn’t merged. Is there a problem with the patch?
--
Clemens Lang • Development Specialist
BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com
-
BMW Car IT GmbH
Geschäftsführer: Michael Würtenberger und Alexis Trolin
Sitz und Registergericht: München HRB 134810
-
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gitpkgv: Fix $GITPKV for a single named git source
Hi, Clemens Lang wrote: > Shameless bump. I haven’t heard any feedback on this other than this “looks > good” comment, but it isn’t merged. Is there a problem with the patch? My apologies, it seems this patch should have gone to openembedded-devel rather than this list. I’ll repost it over there. -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Alexis Trolin Sitz und Registergericht: München HRB 134810 - -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] update-alternatives.bbclass: Stabilize iteration order
The use of a dictionary for link_rename causes problems for higher-order
alternatives, i.e. when an alternative link points to another
alternative link, since these links must be processed in the order in
which they were originally added for symlink correction to work.
Switch from a dict to a list of tuples to ensure processing happens in
the original order.
Signed-off-by: Clemens Lang
---
meta/classes/update-alternatives.bbclass | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/meta/classes/update-alternatives.bbclass
b/meta/classes/update-alternatives.bbclass
index ee66379933..1362274d4d 100644
--- a/meta/classes/update-alternatives.bbclass
+++ b/meta/classes/update-alternatives.bbclass
@@ -148,7 +148,7 @@ def apply_update_alternative_renames(d):
pkgdest = d.getVar('PKGD')
for pkg in (d.getVar('PACKAGES') or "").split():
# If the src == dest, we know we need to rename the dest by appending
${BPN}
-link_rename = {}
+link_rename = []
for alt_name in (d.getVar('ALTERNATIVE_%s' % pkg) or "").split():
alt_link = d.getVarFlag('ALTERNATIVE_LINK_NAME', alt_name)
if not alt_link:
@@ -174,7 +174,7 @@ def apply_update_alternative_renames(d):
elif os.path.lexists(src):
if os.path.islink(src):
# Delay rename of links
-link_rename[alt_target] = alt_target_rename
+link_rename.append((alt_target, alt_target_rename))
else:
bb.note('%s: Rename %s -> %s' % (pn, alt_target,
alt_target_rename))
os.rename(src, dest)
@@ -185,22 +185,21 @@ def apply_update_alternative_renames(d):
# Process delayed link names
# Do these after other renames so we can correct broken links
-for alt_target in link_rename:
+for (alt_target, alt_target_rename) in link_rename:
src = '%s/%s' % (pkgdest, alt_target)
-dest = '%s/%s' % (pkgdest, link_rename[alt_target])
-link = os.readlink(src)
+dest = '%s/%s' % (pkgdest, alt_target_rename)
link_target = oe.path.realpath(src, pkgdest, True)
if os.path.lexists(link_target):
# Ok, the link_target exists, we can rename
-bb.note('%s: Rename (link) %s -> %s' % (pn, alt_target,
link_rename[alt_target]))
+bb.note('%s: Rename (link) %s -> %s' % (pn, alt_target,
alt_target_rename))
os.rename(src, dest)
else:
# Try to resolve the broken link to link.${BPN}
link_maybe = '%s.%s' % (os.readlink(src), pn)
if os.path.lexists(os.path.join(os.path.dirname(src),
link_maybe)):
# Ok, the renamed link target exists.. create a new link,
and remove the original
-bb.note('%s: Creating new link %s -> %s' % (pn,
link_rename[alt_target], link_maybe))
+bb.note('%s: Creating new link %s -> %s' % (pn,
alt_target_rename, link_maybe))
os.symlink(link_maybe, dest)
os.unlink(src)
else:
--
2.19.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] Delete all .la files?
Hi, On Wed, Dec 23, 2015 at 09:41:35PM +, Burton, Ross wrote: > One recipe (opensp-native) needs to opt out of the .la deletion as > openjade-native for reasons explicitly expects .la files to > be installed. Some other desktop distros already strip out .la files > so I wouldn't be surprised if there's a patch floating around to solve > this. Note that any software using libltdl will still require the .la files and must thus opt-out of .la file deletion. ImageMagick is probably the most common occurrence of this. To avoid overlinking when keeping the .la files for such recipes, it can be helpful to clear the dependency_libs field in the .la file. HTH, Clemens -- Clemens Lang • Development Specialist BMW Car IT GmbH • Lise-Meitner-Str. 14 • 89081 Ulm • http://bmw-carit.com - BMW Car IT GmbH Geschäftsführer: Michael Würtenberger und Reinhard Stolle Sitz und Registergericht: München HRB 134810 - -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
