== Series Details ==
Series: YOCTO #12937 - Consistent naming scheme for deployed artifacts (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/19321/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. S
* just to make sure it looks like bash variable not bitbake variable in
run.do_* scripts
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/ker
* drop ${PKGE}-${PKGV}-${PR} from kernel artifacts names (this is the
latest build) and add it only in hardlinks created in do_deploy_links
so that we can use PKGR there again (because these links are generally
used only by human operators and they don't have their own TASKHASH or
the IMAGE
* just RFC, the part for images isn't finished yet and there is
still some issue with DATETIME when kernel artifacts are used
from sstate, this is just to validate the idea behind
[YOCTO #12937] before finishing the implementation (it's already
finished and used by various LGE builds, but h
* do_install doesn't use whole "version" as do_deploy does, e.g.
${PKGE}-${PKGV}-${PKGR}-${MACHINE}
it installs only the files with only ${KERNEL_VERSION} in filename or
path, so it doesn't need expanded AUTOINC value in PKGV nor
EXPANDPRAUTO in PKGR like do_deploy does
* it was introduced
* otherwise PKGR seen in do_install, do_deploy and do_deploy_links will
have different value in each of them (PRSERV will return different
value of EXTENDPRAUTO because TASKHASH is different for each of these
tasks and also cause unnecessary multiple EXTENDPRAUTO increments for
each build).
* similar to kernel-artifact-names for other recipes/bbclasses which
need to use some deployed artifacts
* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
IMAGE_LINK_NAME variables
* image_types.bbclass: move IMAGE_NAME_SUFFIX variable
* currently IMAGE_NAME_SUFFIX is us
Let me explain a bit what these changes do for us in LGE.
We have jenkins jobs for CI as well for official releases.
All built artifacts are moved from jenkins builder to fileserver after
the build.
Each jobs have some identifier which is then included in the filenames
of all relevant build arti
-subversion/subversion-1.12.0-apr_1.7.0_fix-1.patch
Removed since this is included in 1.12.2.
Signed-off-by: Zang Ruochen
---
.../subversion-1.12.0-apr_1.7.0_fix-1.patch| 107 -
.../{subversion_1.12.0.bb => subversion_1.12.2.bb} | 5 +-
2 files changed, 2 insertion
Signed-off-by: Chen Qi
---
meta/lib/oeqa/utils/commands.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index 7140bc73d2..03658928e1 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/comm
- Update Debian patches
http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz
- Rebase Debian patches to 0.177
debian/hppa_backend.diff
debian/mips_backend.diff
debian/arm_backend.diff
debian/mips_readelf_w.patch
debian/testsuite-ignore-elflint.diff
deb
From: Changqing Li
Reproduce steps:
run fileman under examples, history command not work,
nothing is output.
Fix by increase history_offset when add history, if not,
it will make current history event not align with offset,
and cannot get history correctly.
Signed-off-by: Changqing Li
---
...
On 8/23/19 1:01 AM, Adrian Bunk wrote:
On Thu, Aug 22, 2019 at 09:40:18AM +0800, Hongxu Jia wrote:
- Update Debian patches
http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz
- Rebase Debian patches to 0.177
debian/hppa_backend.diff
debian/mips_backend.
On 8/22/19 9:27 PM, Richard Purdie wrote:
On Thu, 2019-08-22 at 09:40 +0800, Hongxu Jia wrote:
- Update Debian patches
http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz
- Rebase Debian patches to 0.177
debian/hppa_backend.diff
debian/mips_backend.dif
On Thu, 22 Aug 2019 at 21:20, Randy MacLeod
wrote:
> I'm checking if you have done any work on upgrading the
> boost recipe? Trevor will work on it if you haven't started.
> He's relatively new to YP so depending on how easy the
> update is he might bail or need help or take a while.
>
I made a
Hey Alex, or anyone,
I'm checking if you have done any work on upgrading the
boost recipe? Trevor will work on it if you haven't started.
He's relatively new to YP so depending on how easy the
update is he might bail or need help or take a while.
The recipes that have a fixed dependency on boost
From: Trevor Gamblin
When building lighttpd with PACKAGECONFIG_append_pn-lighttpd = "lua" in
local.conf,
bitbake gives the following error:
ERROR: Nothing PROVIDES 'lua5.1' (but
/home/tgamblin/build/oe-core/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
DEPENDS on or otherwise requires it)
From: Trevor Gamblin
When building lighttpd with PACKAGECONFIG_append_pn-lighttpd = "lua" in
local.conf,
bitbake gives the following error:
ERROR: Nothing PROVIDES 'lua5.1' (but
/home/tgamblin/build/oe-core/meta/recipes-extended/lighttpd/lighttpd_1.4.54.bb
DEPENDS on or otherwise requires it)
On Thu, Aug 22, 2019, 9:20 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> I wanted to summarise what my local tests with the hash server
> concluded.
>
> a) the opendb() changes I made in:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ca04aaf7b51e3ee2bb04da970d5f20f2c9
On Thu, Aug 22, 2019 at 09:40:18AM +0800, Hongxu Jia wrote:
> - Update Debian patches
>
> http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz
>
> - Rebase Debian patches to 0.177
> debian/hppa_backend.diff
> debian/mips_backend.diff
> debian/arm_backend.dif
== Series Details ==
Series: libedit: Add native and nativesdk to BBCLASSEXTEND
Revision: 1
URL : https://patchwork.openembedded.org/series/19421/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have b
Please send this patch to Oe-devel
Mailing list
On Thu, Aug 22, 2019 at 9:44 AM Maxime Roussin-Bélanger <
maxime.roussinbelan...@gmail.com> wrote:
> To keep support of meta-clang support on thud branch.
> It depends on libedit native
> ---
> meta-oe/recipes-devtools/libedit/libedit_20180525-3.1.
To keep support of meta-clang support on thud branch.
It depends on libedit native
---
meta-oe/recipes-devtools/libedit/libedit_20180525-3.1.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta-oe/recipes-devtools/libedit/libedit_20180525-3.1.bb
b/meta-oe/recipes-devtools/libedit/libedit
On Thu, 2019-08-22 at 18:28 +0800, mazliana.moha...@intel.com wrote:
> From: Mazliana
>
> Purpose of kernel development is basically to customize our
> own recipes kernel by reused existing recipes.
>
> This is an initiative of automating manual kernel development
> test cases. Applying a singl
I wanted to summarise what my local tests with the hash server
concluded.
a) the opendb() changes I made in:
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ca04aaf7b51e3ee2bb04da970d5f20f2c9982cb8
broke things as the database is opened for each request. I have
local patches to fix
On 8/21/19 12:25 PM, Jacob Kroon wrote:
From: Martin Hundebøll
When the populate-volatile.sh initscript tests if a configured symlink
is already in place, it uses readlink with the '-f' (follow) option:
[ "$(readlink -f $source)" = "$dest" ]
If the test fails, it proceeds to delete the exis
The current devtool test for the building of an out-of-tree kernel
module uses something which requires several "high order" kconfigs to
be set. This results in the test failing, not for expected reasons,
but rather because it depends on specific kernel configuration.
You will get error messages s
On Thu, 22 Aug 2019 at 15:33, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> > create mode 100644 meta/recipes-devtools/python-numpy/files/0001-
> > numpy-random-setup.py-remove-the-detection-of-x86-ta.patch
> > rename meta/recipes-devtools/python-numpy/{python3-numpy_1.16.3.bb
>
Rebase files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
License-Update: clarified license for numpy/core/src/multiarray/dragon4.c (it
is MIT)
Signed-off-by: Alexander Kanavin
---
...-and-so-on-for-libraries-by-default-.patch | 47 ---
...up.py-remove-the-det
== Series Details ==
Series: oeqa/kerneldevelopment: Able to apply a single patch to the Linux
kernel source (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/19411/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an aut
From: Mazliana
Purpose of kernel development is basically to customize our
own recipes kernel by reused existing recipes.
This is an initiative of automating manual kernel development
test cases. Applying a single patch to the Linux kernel source
is one of the manual test cases of kernel develo
On Tue, 2019-08-20 at 17:32 +0200, Alexander Kanavin wrote:
> Rebase files/0001-Don-t-search-usr-and-so-on-for-libraries-by-
> default-.patch
>
> License-Update: clarified license for
> numpy/core/src/multiarray/dragon4.c (it is MIT)
> Signed-off-by: Alexander Kanavin
> ---
> ...-and-so-on-for-l
On Thu, 2019-08-22 at 09:40 +0800, Hongxu Jia wrote:
> - Update Debian patches
>
> http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.176-1.debian.tar.xz
>
> - Rebase Debian patches to 0.177
> debian/hppa_backend.diff
> debian/mips_backend.diff
> debian/arm_backend.diff
> d
From: Trevor Gamblin
The quilt "series" option relies on "less -R" but, since that
option is not enabled by busybox in oe-core by default,
hard-code the dependency on 'less'.
>From 'man less':
-r or --raw-control-chars
Causes "raw" control characters to be displayed. ...
-R or --RAW-
From: Trevor Gamblin
The quilt ptest uses a custom Makefile to implement the
"make check" rule, but the ptest Makefile does not export
the variable QUILT_PC, which is user-settable and normally
defaults to ".pc". This causes failures e.g. import.test
with "rm -rf patches/ %{QUILT_PC}/", evaluatin
== Series Details ==
Series: oeqa/kerneldevelopment: Able to apply a single patch to the Linux
kernel source
Revision: 1
URL : https://patchwork.openembedded.org/series/19411/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated
From: Mazliana
Purpose of kernel development is basically to customize our
own recipes kernel by reused existing recipes.
This is an initiative of automating manual kernel development
test cases. Applying a single patch to the Linux kernel source
is one of the manual test cases of kernel develo
37 matches
Mail list logo
