Re: [OE-core] About auto-upgrade-helper's enhancement
On 11/30/2017 05:54 AM, Robert Yang wrote: Have you looked at devtool upgrade at all? I tried "devtool upgrade less --version 529" just now. What I like AUH most is it can help update md5sum, do the commit, and do build testing on a few qemu machines, that really helps a lot, which can enhance the quality of patches. Does "devtool upgrade" has a plan to do that, please ? For a while there was this unfortunate situation where devtool and AUH were 'in competition' with each other, but the plan is to clearly separate their responsibilities and replace the part of AUH that devtool also does with simply calling devtool. So you'll get the nice parts of both AUH (making commits and testing them) and devtool (rebasing patches, ability to manually fix failures). Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About auto-upgrade-helper's enhancement
On 11/30/2017 05:27 AM, Paul Eggleton wrote: So for manual (or should I say semi-automatic) recipe upgrades, our primary tool is "devtool upgrade" - at the moment it is true that there are things that the AUH can do that devtool upgrade can't (e.g. auto-detecting the latest upstream version, handling LIC_FILES_CHKSUM, etc.), but I believe Alex will be Both of these are already fixed, patches sent :) working on some of those and then will be moving the AUH to use devtool upgrade itself so that we don't have two codebases for the same task. We don't plan to deprecate manual usage of the AUH, but if there are use cases that devtool upgrade cannot currently handle, then assuming they fit I would like to handle them there first and point most users at devtool upgrade rather than manually running the AUH, since devtool upgrade is much more suited to enabling the work that follows on when an upgrade cannot be completed automatically. Porting AUH to use devtool is in progress now, I got a first successful upgrade yesterday. I'd say that for someone who regularly needs to upgrade recipes, AUH (on top of devtool) is a useful thing to run locally, as it can mass-create commits, and do some preliminary, automatic build and even runtime testing - things that devtool doesn't do and shouldn't. Then those commits can be further fixed manually. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About auto-upgrade-helper's enhancement
On 11/30/2017 04:23 AM, Robert Yang wrote: I tried auto-upgrade-helper, it is very helpful when upgrade recipes. I'd like to make some enhancements to make it can be easily used by the maintainer (recipe upgrader) himself: Great, let's make it awesome :) 1) Don't send email when maintainer uses it, for example, when I want to upgrade "strace", I don't need it send email to anyone. I think email sending can be easily disabled in the configuration, no? 2) Use git's user.name and user.email in git commit when not send email, we need let the maintainer take responsible for it. You can reset the commit authorship via 'git commit --amend --reset-author', but I wouldn't want automatically created commits to have my name by default, especially when mass-creating them. 3) Do the commit on the recipes when the upgrade is succeed, currently, it keeps the commit when failed, but removed it when succeed. Yes. In fact I've deleted all code that does branch and commit manipulation, except the part that creates commits. The tool shouldn't decide for the user how to manage branches, and on which branch to base the work (currently hardcoded to master) etc. 4) Make upgradehelper.py can accept multiple recipes as args. Yep. 5) It's a small tool and helpful when upgrade recipes, can we move it into oe-core/scripts, please ? I agree, after it's been ported to use devtool and I'm happy with how it works. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [Morty][PATCH] binutils: Fix build issue on Centos 6
> > The above link points to gcc rpms of v4.8.1/2, but the "-Wstack-usage"
> > option
> > was introduced in gcc v4.9.x; so I think the problem exists with the
> above
> > rpms.
> > Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=19854
> >
>
> Then you might need to install devtool version 6
>
> https://www.softwarecollections.org/en/scls/rhscl/devtoolset-6/
>
> Basically, we are intentionally building binaries/libraries on
lower versions of distro; in order to make sure they (binaries/libraries)
work on higher/latest distros. Installing this devtoolset can solve the
issue,
but our purpose will not be met.
However, Thank You for the info; it would help someone in future.
Regards,
Jagadeesh
> > Regards,
> > Jagadeesh
> >
> >> > gprof' cc1: error: unrecognized command line option
> >> > "-Wstack-usage=262144"
> >> >
> >> > Signed-off-by: Jagadeesh Krishnanjanappa >
> >> > Reviewed-by: Jeremy Puhlman
> >> > Signed-off-by: Armin Kuster
> >> > ---
> >> > meta/recipes-devtools/binutils/binutils-cross-canadian.inc | 7
> +++
> >> > 1 file changed, 7 insertions(+)
> >> >
> >> > diff --git a/meta/recipes-devtools/binutils/binutils-cross-
> canadian.inc
> >> > b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> >> > index ae14642..30e3bc6 100644
> >> > --- a/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> >> > +++ b/meta/recipes-devtools/binutils/binutils-cross-canadian.inc
> >> > @@ -12,6 +12,13 @@ EXTRA_OECONF +=
> >> > "--with-sysroot=${SDKPATH}/sysroots/${TUNE_PKGARCH}${TARGET_VEND
> >> > # e.g. we switch between different machines with different tunes.
> >> > EXTRA_OECONF[vardepsexclude] = "TUNE_PKGARCH"
> >> >
> >> > +EXTRA_OEMAKE += "WARN_CFLAGS='-W -Wall -Wstrict-prototypes
> >> > -Wmissing-prototypes -Wshadow'"
> >> > +do_configure_prepend () {
> >> > + sed -i ${S}/bfd/warning.m4 -e "/Wstack-usage/D"
> >> > + sed -i ${S}/bfd/configure -e "s/-Wstack-usage=262144//"
> >> > + sed -i ${S}/binutils/configure -e "s/-Wstack-usage=262144//"
> >> > +}
> >> > +
> >> > do_install () {
> >> > autotools_do_install
> >> >
> >> > --
> >> > 2.7.4
> >> >
> >> > --
> >> > ___
> >> > Openembedded-core mailing list
> >> > Openembedded-core@lists.openembedded.org
> >> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >> --
> >> ___
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About auto-upgrade-helper's enhancement
Hi Paul, Thanks for the reply. On 11/30/2017 11:27 AM, Paul Eggleton wrote: Hi Robert, FYI Anibal has left Intel; the AUH is now being worked on by Alex Kanavin (on CC). On Thursday, 30 November 2017 3:23:25 PM NZDT Robert Yang wrote: I tried auto-upgrade-helper, it is very helpful when upgrade recipes. I'd like to make some enhancements to make it can be easily used by the maintainer (recipe upgrader) himself: 1) Don't send email when maintainer uses it, for example, when I want to upgrade "strace", I don't need it send email to anyone. 2) Use git's user.name and user.email in git commit when not send email, we need let the maintainer take responsible for it. It's probably not just about not sending email - manually running the script without sending email is also useful when testing the AUH script during development so we'd need to switch usage of the git user/email a different way, but otherwise yes this seems reasonable. Probably we would just have some kind of local-only mode, possibly that's made the default (or can be configured to be). I prefer default to local. 3) Do the commit on the recipes when the upgrade is succeed, currently, it keeps the commit when failed, but removed it when succeed. No problem as long as it doesn't interfere with automated operation on the server. 4) Make upgradehelper.py can accept multiple recipes as args. Seems reasonable yes. 5) It's a small tool and helpful when upgrade recipes, can we move it into oe-core/scripts, please ? So for manual (or should I say semi-automatic) recipe upgrades, our primary tool is "devtool upgrade" - at the moment it is true that there are things that the AUH can do that devtool upgrade can't (e.g. auto-detecting the latest upstream version, handling LIC_FILES_CHKSUM, etc.), but I believe Alex will be working on some of those and then will be moving the AUH to use devtool upgrade itself so that we don't have two codebases for the same task. We don't plan to deprecate manual usage of the AUH, but if there are use cases that devtool upgrade cannot currently handle, then assuming they fit I would like to handle them there first and point most users at devtool upgrade rather than manually running the AUH, since devtool upgrade is much more suited to enabling the work that follows on when an upgrade cannot be completed automatically. Have you looked at devtool upgrade at all? I tried "devtool upgrade less --version 529" just now. What I like AUH most is it can help update md5sum, do the commit, and do build testing on a few qemu machines, that really helps a lot, which can enhance the quality of patches. Does "devtool upgrade" has a plan to do that, please ? // Robert Cheers, Paul -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] About auto-upgrade-helper's enhancement
Hi Robert, FYI Anibal has left Intel; the AUH is now being worked on by Alex Kanavin (on CC). On Thursday, 30 November 2017 3:23:25 PM NZDT Robert Yang wrote: > I tried auto-upgrade-helper, it is very helpful when upgrade recipes. > I'd like to make some enhancements to make it can be easily used by the > maintainer (recipe upgrader) himself: > 1) Don't send email when maintainer uses it, for example, when I want to > upgrade "strace", I don't need it send email to anyone. > 2) Use git's user.name and user.email in git commit when not send email, > we need let the maintainer take responsible for it. It's probably not just about not sending email - manually running the script without sending email is also useful when testing the AUH script during development so we'd need to switch usage of the git user/email a different way, but otherwise yes this seems reasonable. Probably we would just have some kind of local-only mode, possibly that's made the default (or can be configured to be). > 3) Do the commit on the recipes when the upgrade is succeed, currently, > it keeps the commit when failed, but removed it when succeed. No problem as long as it doesn't interfere with automated operation on the server. > 4) Make upgradehelper.py can accept multiple recipes as args. Seems reasonable yes. > 5) It's a small tool and helpful when upgrade recipes, can we move it into > oe-core/scripts, please ? So for manual (or should I say semi-automatic) recipe upgrades, our primary tool is "devtool upgrade" - at the moment it is true that there are things that the AUH can do that devtool upgrade can't (e.g. auto-detecting the latest upstream version, handling LIC_FILES_CHKSUM, etc.), but I believe Alex will be working on some of those and then will be moving the AUH to use devtool upgrade itself so that we don't have two codebases for the same task. We don't plan to deprecate manual usage of the AUH, but if there are use cases that devtool upgrade cannot currently handle, then assuming they fit I would like to handle them there first and point most users at devtool upgrade rather than manually running the AUH, since devtool upgrade is much more suited to enabling the work that follows on when an upgrade cannot be completed automatically. Have you looked at devtool upgrade at all? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] About auto-upgrade-helper's enhancement
Hi Anibal and Paul, I tried auto-upgrade-helper, it is very helpful when upgrade recipes. I'd like to make some enhancements to make it can be easily used by the maintainer (recipe upgrader) himself: 1) Don't send email when maintainer uses it, for example, when I want to upgrade "strace", I don't need it send email to anyone. 2) Use git's user.name and user.email in git commit when not send email, we need let the maintainer take responsible for it. 3) Do the commit on the recipes when the upgrade is succeed, currently, it keeps the commit when failed, but removed it when succeed. 4) Make upgradehelper.py can accept multiple recipes as args. 5) It's a small tool and helpful when upgrade recipes, can we move it into oe-core/scripts, please ? -- Thanks Robert -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/5] go-native: fix import error when len(TMPDIR) == 410
It is used for saving file path, 500 is a little small when building in deep
path, for example, it would be failed when oe-coe's len(TMPDIR) == 410, use
1000 can fix the problem.
Fixed:
$ bitbake go-native
[snip]
gcc -isystem/workspace2/lyang1//[snip]
exec gcc: No such file or directory
[snip]
Only go-native needs this patch since only it uses go1.4 which has
src/cmd/gc/go.h.
[YOCTO #11351]
Signed-off-by: Robert Yang
---
.../go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch | 35 ++
meta/recipes-devtools/go/go-native.inc | 1 +
2 files changed, 36 insertions(+)
create mode 100644
meta/recipes-devtools/go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch
diff --git
a/meta/recipes-devtools/go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch
b/meta/recipes-devtools/go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch
new file mode 100644
index 000..73aff0c
--- /dev/null
+++ b/meta/recipes-devtools/go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch
@@ -0,0 +1,35 @@
+From 7228802277fa97bf3b3988eeef1ff5b8e97ab082 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Wed, 15 Nov 2017 14:23:48 +0800
+Subject: [PATCH] cmd/gc/go.h: NSYMB: 500 -> 1000
+
+It is used for saving file path, 500 is a little small when building in deep
+path, for example, it would be failed when oe-coe's len(TMPDIR) == 410, use
+1000 can fix the problem.
+
+Fixed:
+cmd/internal/objfile/disasm.go:18: can't find import:
"cmd/internal/rsc.io/arm/armasm"
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ go/src/cmd/gc/go.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/go/src/cmd/gc/go.h b/go/src/cmd/gc/go.h
+index bbb8835..caa326c 100644
+--- a/go/src/cmd/gc/go.h
b/go/src/cmd/gc/go.h
+@@ -27,7 +27,7 @@ enum
+ {
+ NHUNK = 5,
+ BUFSIZ = 8192,
+- NSYMB = 500,
++ NSYMB = 1000,
+ NHASH = 1024,
+ STRINGSZ= 200,
+ MAXALIGN= 7,
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/go/go-native.inc
b/meta/recipes-devtools/go/go-native.inc
index 0791b6d..43426c0 100644
--- a/meta/recipes-devtools/go/go-native.inc
+++ b/meta/recipes-devtools/go/go-native.inc
@@ -6,6 +6,7 @@ inherit native
SRC_URI_append = "
http://golang.org/dl/go1.4.3.src.tar.gz;name=bootstrap;subdir=go1.4 \
file://0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch;patchdir=../go1.4 \
+
file://0002-cmd-gc-go.h-NSYMB-500-1000.patch;patchdir=../go1.4 \
"
SRC_URI[bootstrap.md5sum] = "dfb60455dd402a77a553a5923a04"
SRC_URI[bootstrap.sha256sum] =
"9947fc705b0b841b5938c48b22dc33e9647ec0752bae66e50278df4f23f64959"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/5] go-native: fix PATH issue when len(TMPDIR) == 410
The buf is used for saving PATH, 4096 is a little small when building in deep
path, for example, it would be failed when oe-coe's len(TMPDIR) == 410, use
8192 can fix the problem.
Fixed:
$ bitbake go-native
[snip]
gcc -isystem/workspace2/lyang1//[snip]
exec gcc: No such file or directory
[snip]
Only go-native needs this patch since only it uses go1.4 which has unix.c.
[YOCTO #11351]
Signed-off-by: Robert Yang
---
...01-cmd-dist-unix.c-bprintf-use-larger-buf.patch | 38 ++
meta/recipes-devtools/go/go-native.inc | 4 ++-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/go/files/0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch
diff --git
a/meta/recipes-devtools/go/files/0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch
b/meta/recipes-devtools/go/files/0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch
new file mode 100644
index 000..82c1fc1
--- /dev/null
+++
b/meta/recipes-devtools/go/files/0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch
@@ -0,0 +1,38 @@
+From 443724ac952aa9b7550dc89ac14dbea1c2cd05b0 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Wed, 15 Nov 2017 10:49:03 +0800
+Subject: [PATCH] cmd/dist/unix.c: bprintf(): use larger buf
+
+The buf is used for saving PATH, 4096 is a little small when building in deep
+path, for example, it would be failed when oe-coe's len(TMPDIR) == 410, use
+8192 can fix the problem.
+
+Fixed:
+[snip]
+gcc -isystem/workspace2/lyang1//[snip]
+exec gcc: No such file or directory
+[snip]
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ go/src/cmd/dist/unix.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/go/src/cmd/dist/unix.c b/go/src/cmd/dist/unix.c
+index 4a78684..fa41964 100644
+--- a/go/src/cmd/dist/unix.c
b/go/src/cmd/dist/unix.c
+@@ -32,7 +32,7 @@ char*
+ bprintf(Buf *b, char *fmt, ...)
+ {
+ va_list arg;
+- char buf[4096];
++ char buf[8192];
+
+ breset(b);
+ va_start(arg, fmt);
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/go/go-native.inc
b/meta/recipes-devtools/go/go-native.inc
index 95db1c2..0791b6d 100644
--- a/meta/recipes-devtools/go/go-native.inc
+++ b/meta/recipes-devtools/go/go-native.inc
@@ -4,7 +4,9 @@ nonstaging_libdir := "${libdir}"
inherit native
-SRC_URI_append = "
http://golang.org/dl/go1.4.3.src.tar.gz;name=bootstrap;subdir=go1.4";
+SRC_URI_append = "
http://golang.org/dl/go1.4.3.src.tar.gz;name=bootstrap;subdir=go1.4 \
+
file://0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch;patchdir=../go1.4 \
+"
SRC_URI[bootstrap.md5sum] = "dfb60455dd402a77a553a5923a04"
SRC_URI[bootstrap.sha256sum] =
"9947fc705b0b841b5938c48b22dc33e9647ec0752bae66e50278df4f23f64959"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/5] sqlite3: use 1024 for MAX_PATHNAM
The 512 is a little small when len(TMPDIR) == 410, it would be failed when
do_rootfs, use 1024 to fix problem:
Fixed when len(TMPDIR) == 410:
$ bitbake core-image-minimal
[snip]
"tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/lib/python3.5/site-packages/dnf/yum/history.py",
line 799, in _get_cursor
self._conn = sqlite.connect(self._db_file)
sqlite3.OperationalError: unable to open database file
[YOCTO #12374]
Signed-off-by: Robert Yang
---
.../0001-sqlite3.c-use-1024-MAX_PATHNAME.patch | 37 ++
meta/recipes-support/sqlite/sqlite3_3.21.0.bb | 1 +
2 files changed, 38 insertions(+)
create mode 100644
meta/recipes-support/sqlite/files/0001-sqlite3.c-use-1024-MAX_PATHNAME.patch
diff --git
a/meta/recipes-support/sqlite/files/0001-sqlite3.c-use-1024-MAX_PATHNAME.patch
b/meta/recipes-support/sqlite/files/0001-sqlite3.c-use-1024-MAX_PATHNAME.patch
new file mode 100644
index 000..f000477
--- /dev/null
+++
b/meta/recipes-support/sqlite/files/0001-sqlite3.c-use-1024-MAX_PATHNAME.patch
@@ -0,0 +1,37 @@
+From 9f63bdd623a851c6f4af6d1259161d5d47d94bb3 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Wed, 22 Nov 2017 15:23:24 +0800
+Subject: [PATCH] sqlite3.c: use 1024 for MAX_PATHNAME
+
+The 512 is a little small when build in deep directory, e.g., it would be
+failed to run when oe-core's TMPDIR == 410, use 1024 to fix problem.
+
+Fixed:
+[snip]
+"/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 799, in _get_cursor
+self._conn = sqlite.connect(self._db_file)
+sqlite3.OperationalError: unable to open database file
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ sqlite3.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sqlite3.c b/sqlite3.c
+index 4ec1271..31edaf8 100644
+--- a/sqlite3.c
b/sqlite3.c
+@@ -30379,7 +30379,7 @@ SQLITE_PRIVATE const char *sqlite3OpcodeName(int i){
+ /*
+ ** Maximum supported path-length.
+ */
+-#define MAX_PATHNAME 512
++#define MAX_PATHNAME 1024
+
+ /*
+ ** Maximum supported symbolic links
+--
+2.7.4
+
diff --git a/meta/recipes-support/sqlite/sqlite3_3.21.0.bb
b/meta/recipes-support/sqlite/sqlite3_3.21.0.bb
index 1d51733..33f41e5 100644
--- a/meta/recipes-support/sqlite/sqlite3_3.21.0.bb
+++ b/meta/recipes-support/sqlite/sqlite3_3.21.0.bb
@@ -5,6 +5,7 @@ LIC_FILES_CHKSUM =
"file://sqlite3.h;endline=11;md5=786d3dc581eff03f4fd9e4a77ed0
SRC_URI = "\
http://www.sqlite.org/2017/sqlite-autoconf-${SQLITE_PV}.tar.gz \
+ file://0001-sqlite3.c-use-1024-MAX_PATHNAME.patch \
"
SRC_URI[md5sum] = "7913de4c3126ba3c24689cb7a199ea31"
SRC_URI[sha256sum] =
"d7dd516775005ad87a57f428b6f86afd206cb341722927f104d3f0cf65fbbbe3"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/5] webkitgtk: fix compile error when len(TMPDIR) == 410
One of the gcc command line was too long (longer than 160,000 characters) when
len(TMPDIR) == 410, so there was an "Argument list too long" error:
$ bitbake webkitgtk
i586-poky-linux-g++: error trying to exec [snip] execv: Argument list too long
The cmake doesn't support relative path, so we have to edit flags.make to fix
the problem:
- Replace -I${RECIPE_SYSROOT} with -I=
- Replace "-I${S}/path1/in/S -I ${S}/path2/in/S" with
"-iprefix ${S} -iwithprefixbefore /path1/in/S -iwithprefixbefore /path2/in/S"
Now the length is less than 25,000.
[YOCTO #12362]
Signed-off-by: Robert Yang
---
meta/recipes-sato/webkit/webkitgtk_2.16.6.bb | 27 +++
1 file changed, 27 insertions(+)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
index 0f126cb..3ff5425 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.16.6.bb
@@ -117,3 +117,30 @@ ARM_INSTRUCTION_SET_armv7ve = "thumb"
# Segmentation fault
GI_DATA_ENABLED_armv7a = "False"
GI_DATA_ENABLED_armv7ve = "False"
+
+do_configure[postfuncs] += 'shorter_flags_make'
+
+python shorter_flags_make() {
+recipe_sysroot = d.getVar('RECIPE_SYSROOT')
+for root, dirs, files in os.walk(d.getVar('B')):
+for flags_make in files:
+if flags_make == 'flags.make':
+# To fix build error when len(TMPDIR) == 410:
+# - Replace -I${RECIPE_SYSROOT} with -I=
+# - Replace "-I${S}/path1/in/S -I ${S}/path2/in/S" with
+# "-iprefix ${S} -iwithprefixbefore /path1/in/S
-iwithprefixbefore /path2/in/S"
+flags_make = os.path.join(root, flags_make)
+new_lines = []
+with open(flags_make, 'r') as f:
+for line in f.readlines():
+if line.startswith('CXX_INCLUDES = ') or
line.startswith('C_INCLUDES = '):
+line = line.replace('-I%s' % recipe_sysroot, '-I=')
+line = line.replace('CXX_INCLUDES =',
'CXX_INCLUDES = -iprefix %s/ ' % d.getVar('S'))
+line = line.replace('C_INCLUDES =', 'C_INCLUDES =
-iprefix %s/ ' % d.getVar('S'))
+line = line.replace('-I%s' % d.getVar('S'),
'-iwithprefixbefore ')
+new_lines.append(line)
+
+with open(flags_make, 'w') as f:
+for line in new_lines:
+f.write(line)
+}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/5] ninja: fix for llvm build when len(TMPDIR) == 410
It is used for saving path components, 30 is a little small, use 100.
Fixed when build llvm:
ninja: fatal: path has too many components
[YOCTO #12347]
Signed-off-by: Robert Yang
---
...src-util.cc-use-larger-kMaxPathComponents.patch | 33 ++
meta/recipes-devtools/ninja/ninja_1.7.2.bb | 5 +++-
2 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-devtools/ninja/ninja/0001-src-util.cc-use-larger-kMaxPathComponents.patch
diff --git
a/meta/recipes-devtools/ninja/ninja/0001-src-util.cc-use-larger-kMaxPathComponents.patch
b/meta/recipes-devtools/ninja/ninja/0001-src-util.cc-use-larger-kMaxPathComponents.patch
new file mode 100644
index 000..64cac7b
--- /dev/null
+++
b/meta/recipes-devtools/ninja/ninja/0001-src-util.cc-use-larger-kMaxPathComponents.patch
@@ -0,0 +1,33 @@
+From 04534ec915e08f59b66bf6044290faeea4610394 Mon Sep 17 00:00:00 2001
+From: Robert Yang
+Date: Wed, 15 Nov 2017 16:01:01 +0800
+Subject: [PATCH] src/util.cc: use larger kMaxPathComponents
+
+It is used for saving path components, 30 is a little small, use 100.
+
+Fixed when build llvm:
+ninja: fatal: path has too many components
+
+Upstream-Status: Pending
+
+Signed-off-by: Robert Yang
+---
+ src/util.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/util.cc b/src/util.cc
+index e31fd1f..f84a12e 100644
+--- a/src/util.cc
b/src/util.cc
+@@ -125,7 +125,7 @@ bool CanonicalizePath(char* path, size_t* len, unsigned
int* slash_bits,
+ return false;
+ }
+
+- const int kMaxPathComponents = 30;
++ const int kMaxPathComponents = 100;
+ char* components[kMaxPathComponents];
+ int component_count = 0;
+
+--
+2.7.4
+
diff --git a/meta/recipes-devtools/ninja/ninja_1.7.2.bb
b/meta/recipes-devtools/ninja/ninja_1.7.2.bb
index 4d3b272..0ef2ea0 100644
--- a/meta/recipes-devtools/ninja/ninja_1.7.2.bb
+++ b/meta/recipes-devtools/ninja/ninja_1.7.2.bb
@@ -7,7 +7,10 @@ DEPENDS = "re2c-native ninja-native"
SRCREV = "717b7b4a31db6027207588c0fb89c3ead384747b"
-SRC_URI = "git://github.com/martine/ninja.git;branch=release"
+SRC_URI = "git://github.com/martine/ninja.git;branch=release \
+ file://0001-src-util.cc-use-larger-kMaxPathComponents.patch \
+"
+
UPSTREAM_CHECK_GITTAGREGEX = "v(?P.*)"
S = "${WORKDIR}/git"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/5] fix build when len(TMPDIR) == 410
The following changes since commit 33418ed064fe9cff5b4803f09135a81d9170c189: runqemu: Also specialcase resolution of '.' to the file's location (2017-11-21 17:58:36 +) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/long http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/long Robert Yang (5): go-native: fix PATH issue when len(TMPDIR) == 410 go-native: fix import error when len(TMPDIR) == 410 ninja: fix for llvm build when len(TMPDIR) == 410 webkitgtk: fix compile error when len(TMPDIR) == 410 sqlite3: use 1024 for MAX_PATHNAM ...01-cmd-dist-unix.c-bprintf-use-larger-buf.patch | 38 ++ .../go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch | 35 meta/recipes-devtools/go/go-native.inc | 5 ++- ...src-util.cc-use-larger-kMaxPathComponents.patch | 33 +++ meta/recipes-devtools/ninja/ninja_1.7.2.bb | 5 ++- meta/recipes-sato/webkit/webkitgtk_2.16.6.bb | 27 +++ .../0001-sqlite3.c-use-1024-MAX_PATHNAME.patch | 37 + meta/recipes-support/sqlite/sqlite3_3.21.0.bb | 1 + 8 files changed, 179 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/go/files/0001-cmd-dist-unix.c-bprintf-use-larger-buf.patch create mode 100644 meta/recipes-devtools/go/files/0002-cmd-gc-go.h-NSYMB-500-1000.patch create mode 100644 meta/recipes-devtools/ninja/ninja/0001-src-util.cc-use-larger-kMaxPathComponents.patch create mode 100644 meta/recipes-support/sqlite/files/0001-sqlite3.c-use-1024-MAX_PATHNAME.patch -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On Wed, 2017-11-29 at 13:13 -0500, Bruce Ashfield wrote:
> On 11/29/2017 12:52 PM, Saul Wold wrote:
> > On Wed, 2017-11-29 at 11:56 -0500, Bruce Ashfield wrote:
> > > On 11/29/2017 11:30 AM, Saul Wold wrote:
> > > > On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
> > > > > On 11/28/2017 10:28 PM, Saul Wold wrote:
> > > > > > When using KBUILD_DEFCONFIG, $sccs should be set to the
> > > > > > $WORKDIR/defconfig
> > > > > > regardless if it compares or is copied. Otherwise $sccs is
> > > > > > not
> > > > > > set
> > > > > > and the
> > > > > > defconfig is not found correctly.
> > > > >
> > > > > Actually, looking at this more today, and this morning in my
> > > > > testing.
> > > > > This shouldn't be necessary .. it doesn't hurt anything
> > > > > (well,
> > > > > actually
> > > > > it could end up with two defconfigs in the variable, but that
> > > > > also
> > > > > should be ok).
> > > > >
> > > >
> > > > Ok, I understand, it's in find_sccs() where if you have
> > > > "defconfig"
> > > > in
> > > > the SRC_URI then with my change you could end up with two
> > > > defconfigs.
> > > >
> > > > The problem I saw was if one just sets KBUILD_DEFCONFIG and
> > > > does
> > > > not
> > > > set any config info on the SRC_URI then it's possible for $sccs
> > > > to
> > > > be
> > > > empty, which was bad.
> > >
> > > I took a look at the conditions again, and I can't see that
> > > path. But that doesn't mean it isn't there, is this a
> > > configuration
> > > that I can build and see myself ?
> > >
> >
> > Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does
> > not
> > have any defconfig, .scc or .cfg files. Build once that will
> > populate
> > the $WORKDIR/defconfig with vai the else path of the first if and
> > the
> > cp path in the do_kernel_metadata() code. Build a second time and
> > the
> > $WORKDIR/defconfig exists now and the first part of the if with the
> > cmp
> > will occur and the defconfig will not be found because $sccs does
> > not
> > get set in the original code when the cmp is equal.
>
> That's the ticket .. I didn't think of a 2nd pass through the
> build.
>
> So with that extra assignment + a duplicate removal, it should
> be safe for all the paths.
>
> Did you want to send a v2, or did you want me to make that tweak?
>
If you have the tweak in mind already, might be better for you to make
it.
Thanks
Sau!
> Either way, I'll continue testing here.
>
> Bruce
>
> >
> > Sau!
> >
> > > >
> > > > Maybe a cleaning of multiple "defconfig" entries on $sccs is
> > > > needed?
> > > >
> > >
> > > Yah, regardless of my above statement, it certainly wouldn't hurt
> > > and would be a good safeguard, since two defconfigs would trigger
> > > a M x N configuration audit of options (where M and N could be
> > > in the thousands) .. and hence, take a long time.
> > >
> > > Bruce
> > >
> > > > Sau!
> > > >
> > > >
> > > > > >
> > > > > > Part of
> > > > > > [YOCTO #12162]
> > > > > >
> > > > > > Signed-off-by: Saul Wold
> > > > > > ---
> > > > > > meta/classes/kernel-yocto.bbclass | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/meta/classes/kernel-yocto.bbclass
> > > > > > b/meta/classes/kernel-yocto.bbclass
> > > > > > index 1d447951c49..98ec78fb768 100644
> > > > > > --- a/meta/classes/kernel-yocto.bbclass
> > > > > > +++ b/meta/classes/kernel-yocto.bbclass
> > > > > > @@ -110,8 +110,8 @@ do_kernel_metadata() {
> > > > > > fi
> > > > > > else
> > > > > > cp -f
> > > > > > ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}
> > > > > > ${WORKDIR}/defconfig
> > > > > > - sccs="${WORKDIR}/defconfig
> > > > > > "
> > > > > > fi
> > > > > > + sccs="${WORKDIR}/defconfig"
> > > > >
> > > > > The test that was protecting this assignment is:
> > > > >
> > > > > if [ -f "${WORKDIR}/defconfig" ]; then
> > > > >
> > > > > and then:
> > > > >
> > > > > cmp "${WORKDIR}/defconfig"
> > > > > "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
> > > > >
> > > > > The only way that a defconfig can be in ${WORKDIR}/defconfig
> > > > > by
> > > > > the time this runs, is if the fetcher puts it there. Which
> > > > > means
> > > > > it is on the SRC_URI and comes from the recipe writer's
> > > > > layer.
> > > > >
> > > > > There is existing code that already picks this up and adds it
> > > > > to the configuration queue:
> > > > >
> > > > >sccs="$sccs ${@" ".join(find_sccs(d))}"
> > > > >
> > > > > So that defconfig, is already going to be picked up directly
> > > > > from the SRC_URI.
> > > > >
> > > > > Bruce
> > > > >
> > > > >
> > > > > > else
> > > > > > bbfatal "A KBUILD_DEFCONFIG
> > > > > > '${KBUILD_DEFCONFIG}' was specified, but not present in the
> > > > > > s
Re: [OE-core] [PATCH][PSEUDO 0/4] Fix stripped mode with newer coreutils cp
On Wed, 29 Nov 2017 12:02:38 -0600 Richard Tollerton wrote: > So we noticed that cp -Rp was stripping special bits off of > directories when run under pseudo. The super interesting thing was > that people saw this when upgrading their build machines from Ubuntu > 12.04 to 16.04. Root cause is in the commit message in the first > patch, which also contains the fix. > > I also added a test for this, and fixed up the perms on another test. > run_tests.sh reports 13/13 pass. > > Also updated contact info in the README. This looks good to me. Thanks! (I'm still hoping to get a free day or two to merge patches. Any day now.) -s -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On 11/29/2017 12:52 PM, Saul Wold wrote:
On Wed, 2017-11-29 at 11:56 -0500, Bruce Ashfield wrote:
On 11/29/2017 11:30 AM, Saul Wold wrote:
On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
On 11/28/2017 10:28 PM, Saul Wold wrote:
When using KBUILD_DEFCONFIG, $sccs should be set to the
$WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not
set
and the
defconfig is not found correctly.
Actually, looking at this more today, and this morning in my
testing.
This shouldn't be necessary .. it doesn't hurt anything (well,
actually
it could end up with two defconfigs in the variable, but that
also
should be ok).
Ok, I understand, it's in find_sccs() where if you have "defconfig"
in
the SRC_URI then with my change you could end up with two
defconfigs.
The problem I saw was if one just sets KBUILD_DEFCONFIG and does
not
set any config info on the SRC_URI then it's possible for $sccs to
be
empty, which was bad.
I took a look at the conditions again, and I can't see that
path. But that doesn't mean it isn't there, is this a configuration
that I can build and see myself ?
Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not
have any defconfig, .scc or .cfg files. Build once that will populate
the $WORKDIR/defconfig with vai the else path of the first if and the
cp path in the do_kernel_metadata() code. Build a second time and the
$WORKDIR/defconfig exists now and the first part of the if with the cmp
will occur and the defconfig will not be found because $sccs does not
get set in the original code when the cmp is equal.
That's the ticket .. I didn't think of a 2nd pass through the
build.
So with that extra assignment + a duplicate removal, it should
be safe for all the paths.
Did you want to send a v2, or did you want me to make that tweak?
Either way, I'll continue testing here.
Bruce
Sau!
Maybe a cleaning of multiple "defconfig" entries on $sccs is
needed?
Yah, regardless of my above statement, it certainly wouldn't hurt
and would be a good safeguard, since two defconfigs would trigger
a M x N configuration audit of options (where M and N could be
in the thousands) .. and hence, take a long time.
Bruce
Sau!
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1d447951c49..98ec78fb768 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -110,8 +110,8 @@ do_kernel_metadata() {
fi
else
cp -f
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}
${WORKDIR}/defconfig
- sccs="${WORKDIR}/defconfig"
fi
+ sccs="${WORKDIR}/defconfig"
The test that was protecting this assignment is:
if [ -f "${WORKDIR}/defconfig" ]; then
and then:
cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
The only way that a defconfig can be in ${WORKDIR}/defconfig by
the time this runs, is if the fetcher puts it there. Which means
it is on the SRC_URI and comes from the recipe writer's layer.
There is existing code that already picks this up and adds it
to the configuration queue:
sccs="$sccs ${@" ".join(find_sccs(d))}"
So that defconfig, is already going to be picked up directly
from the SRC_URI.
Bruce
else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the
source
tree"
fi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][PSEUDO 0/4] Fix stripped mode with newer coreutils cp
So we noticed that cp -Rp was stripping special bits off of directories when run under pseudo. The super interesting thing was that people saw this when upgrading their build machines from Ubuntu 12.04 to 16.04. Root cause is in the commit message in the first patch, which also contains the fix. I also added a test for this, and fixed up the perms on another test. run_tests.sh reports 13/13 pass. Also updated contact info in the README. Thanks. Richard Tollerton (4): linux/xattr/pseudo_wrappers.c: Preserve special bits on acl set test-cp-setuid.sh: add test-tclsh-fork.sh: fix permissions README: update contact info README | 9 +++-- ports/linux/xattr/pseudo_wrappers.c | 19 +++ test/test-cp-setuid.sh | 23 +++ test/test-tclsh-fork.sh | 0 4 files changed, 49 insertions(+), 2 deletions(-) create mode 100755 test/test-cp-setuid.sh mode change 100644 => 100755 test/test-tclsh-fork.sh -- 2.14.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][PSEUDO 2/4] test-cp-setuid.sh: add
New test to verify that special bits including setuid are preserved under `cp -Rp`. This is a regression test of [YOCTO #12379]. Without a recently committed fix, this test will fail on coreutils 8.24 and later. Signed-off-by: Richard Tollerton --- test/test-cp-setuid.sh | 23 +++ 1 file changed, 23 insertions(+) create mode 100755 test/test-cp-setuid.sh diff --git a/test/test-cp-setuid.sh b/test/test-cp-setuid.sh new file mode 100755 index 000..cdb2cd3 --- /dev/null +++ b/test/test-cp-setuid.sh @@ -0,0 +1,23 @@ +#!/bin/bash +set -e + +# Verify that special bits (setuid/setgid/sticky) are preserved. +# +# Return vals: +# +# 2 - Incorrect permissions +# All other nonzero - Unexpected command error +# 0 - Pass + +trap "rm -rf d1 d2" EXIT + +mkdir d1 +chmod d1 +cp -Rp d1 d2 +perms=`ls -od d1 d2 | cut -c 1-10 | uniq` +if [ "$perms" != drwsrwsrwt ]; then + exit 2 +fi + + +exit 0 -- 2.14.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][PSEUDO 3/4] test-tclsh-fork.sh: fix permissions
This was mode 644, needs to be mode 755. Signed-off-by: Richard Tollerton --- test/test-tclsh-fork.sh | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 test/test-tclsh-fork.sh diff --git a/test/test-tclsh-fork.sh b/test/test-tclsh-fork.sh old mode 100644 new mode 100755 -- 2.14.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][PSEUDO 4/4] README: update contact info
Explicitly point to oe-core mailing list and yocto bugzilla. Signed-off-by: Richard Tollerton --- README | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/README b/README index afe6b27..093ec56 100644 --- a/README +++ b/README @@ -72,8 +72,13 @@ FUTURE DIRECTIONS: * I have no intention of converting to autoconf. It is the wrong tool for the job. -Please feel free to send bug feedback, change requests, or general -commentary. + +CONTACT: + +Discussions and patches should be directed at the openembedded-core mailing +list at openembedded-core@lists.openembedded.org. More information at +https://www.openembedded.org/wiki/Mailing_lists. Bugs should be filed with +the Yocto project at https://bugzilla.yoctoproject.org/. ACKNOWLEDGEMENTS: -- 2.14.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][PSEUDO 1/4] linux/xattr/pseudo_wrappers.c: Preserve special bits on acl set
Recently (2015) coreutils cp -Rp changed its behavior such that chmod()
is followed by setxattr(); previously it was the other way around. This
broke pseudo when a copied directory has one of the special
bits (setuid, setgid, sticky) set; the special bit wound up getting
removed.
Root cause is that ACLs never included special bits in the first place,
so we need to merge them back in ourselves.
[YOCTO #12379]
Signed-off-by: Richard Tollerton
---
ports/linux/xattr/pseudo_wrappers.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/ports/linux/xattr/pseudo_wrappers.c
b/ports/linux/xattr/pseudo_wrappers.c
index d69d53e..1c228a2 100644
--- a/ports/linux/xattr/pseudo_wrappers.c
+++ b/ports/linux/xattr/pseudo_wrappers.c
@@ -97,6 +97,21 @@ posix_permissions(const acl_header *header, int entries, int
*extra, int *mode)
return 0;
}
+static int get_special_bits(const char *path, int fd) {
+ int rc;
+ struct stat64 buf;
+ if (path) {
+ rc = lstat64(path, &buf);
+ } else {
+ rc = fstat64(fd, &buf);
+ }
+ if (rc == -1) {
+ return rc;
+ }
+
+ return buf.st_mode & (S_ISUID | S_ISGID | S_ISVTX);
+}
+
#define RC_AND_BUF \
int rc; \
PSEUDO_STATBUF buf; \
@@ -172,6 +187,10 @@ static int shared_setxattr(const char *path, int fd, const
char *name, const voi
int entries = (size - sizeof(acl_header)) / sizeof(acl_entry);
int res = posix_permissions(value, entries, &extra, &mode);
if (res == 0) {
+ /* POSIX ACLs don't actually include
+* setuid/setgid/sticky bit. We need to add those back
+* in ourselves. */
+ mode |= get_special_bits(path, fd);
pseudo_debug(PDBGF_XATTR, "posix_acl_access translated
to mode %04o. Remaining attribute(s): %d.\n",
mode, extra);
buf.st_mode = mode;
--
2.14.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On Wed, 2017-11-29 at 11:56 -0500, Bruce Ashfield wrote:
> On 11/29/2017 11:30 AM, Saul Wold wrote:
> > On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
> > > On 11/28/2017 10:28 PM, Saul Wold wrote:
> > > > When using KBUILD_DEFCONFIG, $sccs should be set to the
> > > > $WORKDIR/defconfig
> > > > regardless if it compares or is copied. Otherwise $sccs is not
> > > > set
> > > > and the
> > > > defconfig is not found correctly.
> > >
> > > Actually, looking at this more today, and this morning in my
> > > testing.
> > > This shouldn't be necessary .. it doesn't hurt anything (well,
> > > actually
> > > it could end up with two defconfigs in the variable, but that
> > > also
> > > should be ok).
> > >
> >
> > Ok, I understand, it's in find_sccs() where if you have "defconfig"
> > in
> > the SRC_URI then with my change you could end up with two
> > defconfigs.
> >
> > The problem I saw was if one just sets KBUILD_DEFCONFIG and does
> > not
> > set any config info on the SRC_URI then it's possible for $sccs to
> > be
> > empty, which was bad.
>
> I took a look at the conditions again, and I can't see that
> path. But that doesn't mean it isn't there, is this a configuration
> that I can build and see myself ?
>
Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not
have any defconfig, .scc or .cfg files. Build once that will populate
the $WORKDIR/defconfig with vai the else path of the first if and the
cp path in the do_kernel_metadata() code. Build a second time and the
$WORKDIR/defconfig exists now and the first part of the if with the cmp
will occur and the defconfig will not be found because $sccs does not
get set in the original code when the cmp is equal.
Sau!
> >
> > Maybe a cleaning of multiple "defconfig" entries on $sccs is
> > needed?
> >
>
> Yah, regardless of my above statement, it certainly wouldn't hurt
> and would be a good safeguard, since two defconfigs would trigger
> a M x N configuration audit of options (where M and N could be
> in the thousands) .. and hence, take a long time.
>
> Bruce
>
> > Sau!
> >
> >
> > > >
> > > > Part of
> > > > [YOCTO #12162]
> > > >
> > > > Signed-off-by: Saul Wold
> > > > ---
> > > >meta/classes/kernel-yocto.bbclass | 2 +-
> > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/classes/kernel-yocto.bbclass
> > > > b/meta/classes/kernel-yocto.bbclass
> > > > index 1d447951c49..98ec78fb768 100644
> > > > --- a/meta/classes/kernel-yocto.bbclass
> > > > +++ b/meta/classes/kernel-yocto.bbclass
> > > > @@ -110,8 +110,8 @@ do_kernel_metadata() {
> > > > fi
> > > > else
> > > > cp -f
> > > > ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}
> > > > ${WORKDIR}/defconfig
> > > > - sccs="${WORKDIR}/defconfig"
> > > > fi
> > > > + sccs="${WORKDIR}/defconfig"
> > >
> > > The test that was protecting this assignment is:
> > >
> > > if [ -f "${WORKDIR}/defconfig" ]; then
> > >
> > > and then:
> > >
> > > cmp "${WORKDIR}/defconfig"
> > > "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
> > >
> > > The only way that a defconfig can be in ${WORKDIR}/defconfig by
> > > the time this runs, is if the fetcher puts it there. Which means
> > > it is on the SRC_URI and comes from the recipe writer's layer.
> > >
> > > There is existing code that already picks this up and adds it
> > > to the configuration queue:
> > >
> > > sccs="$sccs ${@" ".join(find_sccs(d))}"
> > >
> > > So that defconfig, is already going to be picked up directly
> > > from the SRC_URI.
> > >
> > > Bruce
> > >
> > >
> > > > else
> > > > bbfatal "A KBUILD_DEFCONFIG
> > > > '${KBUILD_DEFCONFIG}' was specified, but not present in the
> > > > source
> > > > tree"
> > > > fi
> > > >
> > >
> > >
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On 11/29/2017 11:30 AM, Saul Wold wrote:
On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
On 11/28/2017 10:28 PM, Saul Wold wrote:
When using KBUILD_DEFCONFIG, $sccs should be set to the
$WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set
and the
defconfig is not found correctly.
Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well,
actually
it could end up with two defconfigs in the variable, but that also
should be ok).
Ok, I understand, it's in find_sccs() where if you have "defconfig" in
the SRC_URI then with my change you could end up with two defconfigs.
The problem I saw was if one just sets KBUILD_DEFCONFIG and does not
set any config info on the SRC_URI then it's possible for $sccs to be
empty, which was bad.
I took a look at the conditions again, and I can't see that
path. But that doesn't mean it isn't there, is this a configuration
that I can build and see myself ?
Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?
Yah, regardless of my above statement, it certainly wouldn't hurt
and would be a good safeguard, since two defconfigs would trigger
a M x N configuration audit of options (where M and N could be
in the thousands) .. and hence, take a long time.
Bruce
Sau!
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1d447951c49..98ec78fb768 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -110,8 +110,8 @@ do_kernel_metadata() {
fi
else
cp -f
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
- sccs="${WORKDIR}/defconfig"
fi
+ sccs="${WORKDIR}/defconfig"
The test that was protecting this assignment is:
if [ -f "${WORKDIR}/defconfig" ]; then
and then:
cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
The only way that a defconfig can be in ${WORKDIR}/defconfig by
the time this runs, is if the fetcher puts it there. Which means
it is on the SRC_URI and comes from the recipe writer's layer.
There is existing code that already picks this up and adds it
to the configuration queue:
sccs="$sccs ${@" ".join(find_sccs(d))}"
So that defconfig, is already going to be picked up directly
from the SRC_URI.
Bruce
else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source
tree"
fi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On Wed, 2017-11-29 at 09:23 -0500, Bruce Ashfield wrote:
> On 11/28/2017 10:28 PM, Saul Wold wrote:
> > When using KBUILD_DEFCONFIG, $sccs should be set to the
> > $WORKDIR/defconfig
> > regardless if it compares or is copied. Otherwise $sccs is not set
> > and the
> > defconfig is not found correctly.
>
> Actually, looking at this more today, and this morning in my testing.
> This shouldn't be necessary .. it doesn't hurt anything (well,
> actually
> it could end up with two defconfigs in the variable, but that also
> should be ok).
>
Ok, I understand, it's in find_sccs() where if you have "defconfig" in
the SRC_URI then with my change you could end up with two defconfigs.
The problem I saw was if one just sets KBUILD_DEFCONFIG and does not
set any config info on the SRC_URI then it's possible for $sccs to be
empty, which was bad.
Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?
Sau!
> >
> > Part of
> > [YOCTO #12162]
> >
> > Signed-off-by: Saul Wold
> > ---
> > meta/classes/kernel-yocto.bbclass | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/kernel-yocto.bbclass
> > b/meta/classes/kernel-yocto.bbclass
> > index 1d447951c49..98ec78fb768 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -110,8 +110,8 @@ do_kernel_metadata() {
> > fi
> > else
> > cp -f
> > ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
> > - sccs="${WORKDIR}/defconfig"
> > fi
> > + sccs="${WORKDIR}/defconfig"
>
> The test that was protecting this assignment is:
>
> if [ -f "${WORKDIR}/defconfig" ]; then
>
> and then:
>
>cmp "${WORKDIR}/defconfig"
> "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
>
> The only way that a defconfig can be in ${WORKDIR}/defconfig by
> the time this runs, is if the fetcher puts it there. Which means
> it is on the SRC_URI and comes from the recipe writer's layer.
>
> There is existing code that already picks this up and adds it
> to the configuration queue:
>
> sccs="$sccs ${@" ".join(find_sccs(d))}"
>
> So that defconfig, is already going to be picked up directly
> from the SRC_URI.
>
> Bruce
>
>
> > else
> > bbfatal "A KBUILD_DEFCONFIG
> > '${KBUILD_DEFCONFIG}' was specified, but not present in the source
> > tree"
> > fi
> >
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] image-buildinfo.bbclass: include IMAGE related variables
From: Leonardo Sandoval
These variables provide additional information (image related) targeted
for QA image verification. Now, target /etc/build looks like:
root@qemux86:~# cat /etc/build
---
Build Configuration: |
---
DISTRO = poky
DISTRO_VERSION = 2.4+snapshot-20171129
IMAGE_NAME = core-image-minimal-qemux86-20171129162018
IMAGE_OVERHEAD_FACTOR = 1.3
IMAGE_ROOTFS_EXTRA_SPACE = 0
IMAGE_PKGTYPE = rpm
---
Layer Revisions: |
---
meta = master:72867393fe2004ab9f0ee23eb09a975c82938b9e --
modified
meta-poky = master:72867393fe2004ab9f0ee23eb09a975c82938b9e --
modified
meta-yocto-bsp= master:72867393fe2004ab9f0ee23eb09a975c82938b9e --
modified
[YOCTO #10503]
Signed-off-by: Leonardo Sandoval
---
meta/classes/image-buildinfo.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/image-buildinfo.bbclass
b/meta/classes/image-buildinfo.bbclass
index 213fb9cf9b..308fcc630b 100644
--- a/meta/classes/image-buildinfo.bbclass
+++ b/meta/classes/image-buildinfo.bbclass
@@ -10,7 +10,7 @@
#
# Desired variables to display
-IMAGE_BUILDINFO_VARS ?= "DISTRO DISTRO_VERSION"
+IMAGE_BUILDINFO_VARS ?= "DISTRO DISTRO_VERSION IMAGE_NAME
IMAGE_OVERHEAD_FACTOR IMAGE_ROOTFS_EXTRA_SPACE IMAGE_PKGTYPE"
# Desired location of the output file in the image.
IMAGE_BUILDINFO_FILE ??= "${sysconfdir}/build"
--
2.12.3
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] bind: fix python3 dependencies
On 29 November 2017 at 00:09, Alexander Kanavin wrote: > On 11/28/2017 06:54 PM, Dan McGregor wrote: >>> >>> Can you dig a bit deeper and find out the root cause of the error message >>> you are getting without this patch please? Try also with a plain poky >>> checkout, and see if the issue disappears there. >> >> >> Yeah, as I said above python3 distutils seems to be broken when >> multilib is enabled. I'll fix that and send a patch later today or >> tomorrow. > > > Just wondering, do you have this fix in your setup? > > http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=3d29214b20433a506a3d59cdc08fc1a9be09a5a0 > I do. I found that distutils isn't patched in there, it's still hardcoded. > Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG
On 11/28/2017 10:28 PM, Saul Wold wrote:
When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set and the
defconfig is not found correctly.
Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well, actually
it could end up with two defconfigs in the variable, but that also
should be ok).
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold
---
meta/classes/kernel-yocto.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index 1d447951c49..98ec78fb768 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -110,8 +110,8 @@ do_kernel_metadata() {
fi
else
cp -f
${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
- sccs="${WORKDIR}/defconfig"
fi
+ sccs="${WORKDIR}/defconfig"
The test that was protecting this assignment is:
if [ -f "${WORKDIR}/defconfig" ]; then
and then:
cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
The only way that a defconfig can be in ${WORKDIR}/defconfig by
the time this runs, is if the fetcher puts it there. Which means
it is on the SRC_URI and comes from the recipe writer's layer.
There is existing code that already picks this up and adds it
to the configuration queue:
sccs="$sccs ${@" ".join(find_sccs(d))}"
So that defconfig, is already going to be picked up directly
from the SRC_URI.
Bruce
else
bbfatal "A KBUILD_DEFCONFIG '${KBUILD_DEFCONFIG}' was
specified, but not present in the source tree"
fi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv2] devtool: add license checksum change handling to 'devtool upgrade'
On 11/29/2017 03:13 PM, Alexander Kanavin wrote: 3) and the cool part: devtool will create a diff of the old and new licenses, and write the diff into the workspace recipe as a comment, like this: v2 adds a small tweak here: add an empty line at the end of the comment which separates it better from the rest of the recipe. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCHv2] devtool: add license checksum change handling to 'devtool upgrade'
Specifically, 'devtool upgrade' will now do these things:
1) determine if any of the license checksums need updating; if so,
write the new checksums into the LIC_FILES_CHKSUM value in the recipe
that is written to the workspace;
2) print a notice to the standard output:
NOTE: New recipe is
/home/ak/development/poky/build/workspace/recipes/puzzles/puzzles_git.bb
NOTE: License checksums have been updated in the new recipe; please refer to it
for the difference between the old and the new license texts.
3) and the cool part: devtool will create a diff of the old and new licenses,
and write the diff into the workspace recipe as a comment, like this:
==
FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'.
The following is the difference between the old and the new license text.
Please update the LICENSE value if needed, and summarize the changes in
the commit message via 'License-checksum-change:' tag.
(example: 'License-checksum-change: copyright years updated.')
The changes:
--- LICENCE
+++ LICENCE
@@ -1,8 +1,9 @@
This software is copyright (c) 2004-2014 Simon Tatham.
Portions copyright Richard Boulton, James Harvey, Mike Pinna, Jonas
-Klker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
-Schmidt, Steffen Bauer, Lennard Sprong and Rogier Goossens.
+Kölker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
+Schmidt, Steffen Bauer, Lennard Sprong, Rogier Goossens and Michael
+Quevillon.
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
==
Signed-off-by: Alexander Kanavin
---
scripts/lib/devtool/upgrade.py | 75 --
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/devtool/upgrade.py b/scripts/lib/devtool/upgrade.py
index 28fbdaee357..7de9ab5c2db 100644
--- a/scripts/lib/devtool/upgrade.py
+++ b/scripts/lib/devtool/upgrade.py
@@ -291,7 +291,26 @@ def _extract_new_source(newpv, srctree, no_patch, srcrev,
srcbranch, branch, kee
return (rev, md5, sha256, srcbranch, srcsubdir_rel)
-def _create_new_recipe(newpv, md5, sha256, srcrev, srcbranch, srcsubdir_old,
srcsubdir_new, workspace, tinfoil, rd):
+def _add_license_diff_to_recipe(path, diff):
+notice_text = """# FIXME: the LIC_FILES_CHKSUM values have been updated by
'devtool upgrade'.
+# The following is the difference between the old and the new license text.
+# Please update the LICENSE value if needed, and summarize the changes in
+# the commit message via 'License-checksum-change:' tag.
+# (example: 'License-checksum-change: copyright years updated.')
+#
+# The changes:
+#
+"""
+commented_diff = "\n".join(["# {}".format(l) for l in diff.split('\n')])
+with open(path, 'rb') as f:
+orig_content = f.read()
+with open(path, 'wb') as f:
+f.write(notice_text.encode())
+f.write(commented_diff.encode())
+f.write("\n#\n\n".encode())
+f.write(orig_content)
+
+def _create_new_recipe(newpv, md5, sha256, srcrev, srcbranch, srcsubdir_old,
srcsubdir_new, workspace, tinfoil, rd, license_diff, new_licenses):
"""Creates the new recipe under workspace"""
bpn = rd.getVar('BPN')
@@ -400,6 +419,11 @@ def _create_new_recipe(newpv, md5, sha256, srcrev,
srcbranch, srcsubdir_old, src
else:
logger.info('Source subdirectory has changed, updating S
value')
+if license_diff:
+newlicchksum = " ".join(["file://{};md5={}".format(l["path"],
l["actual_md5"]) + (";beginline={}".format(l["beginline"]) if l["beginline"]
else "") + (";endline={}".format(l["endline"]) if l["endline"] else "") for l
in new_licenses])
+newvalues["LIC_FILES_CHKSUM"] = newlicchksum
+_add_license_diff_to_recipe(fullpath, license_diff)
+
rd = tinfoil.parse_recipe_file(fullpath, False)
oe.recipeutils.patch_recipe(rd, fullpath, newvalues)
@@ -427,6 +451,47 @@ def _check_git_config():
if configerr:
raise DevtoolError('Your git configuration is incomplete which will
prevent rebases from working:\n' + '\n'.join(configerr))
+def _extract_licenses(srcpath, recipe_licenses):
+licenses = []
+for url in recipe_licenses.split():
+license = {}
+(type, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
+license['path'] = path
+license['md5'] = parm.get('md5', '')
+license['beginline'], license['endline'] = 0, 0
+if 'beginline' in parm:
+license['beginline'] = int(parm['beginline'])
+if 'endline' in parm:
+license['endline'] = int(parm['endline'])
+license['text'] = []
+with open(os.path.join(srcpath, path), 'rb') as f:
+import hashlib
+actual_md5 = hashlib.md5()
+lineno = 0
+for line in f:
+lineno += 1
+if (lineno >= license['beginline']) and ((lineno
[OE-core] ✗ patchtest: failure for bash: fix build race under musl
== Series Details == Series: bash: fix build race under musl Revision: 1 URL : https://patchwork.openembedded.org/series/9996/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Upstream-Status is Submitted, but it is not mentioned where [test_upstream_status_presence_format] Suggested fixInclude where pathexp-dep.patch was submitted Current Upstream-Status: Submitted (https://savannah.gnu.org/patch/index.php?9503) Standard format Upstream-Status: Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bash: fix build race under musl
Under musl bash uses its own libintl clone but there are some missing
dependencies so it is possible for pathexp.o to be built whilst libintl.h is
being written, leading to compile errors.
Signed-off-by: Ross Burton
---
meta/recipes-extended/bash/bash/pathexp-dep.patch | 13 +
meta/recipes-extended/bash/bash_4.4.bb| 1 +
2 files changed, 14 insertions(+)
create mode 100644 meta/recipes-extended/bash/bash/pathexp-dep.patch
diff --git a/meta/recipes-extended/bash/bash/pathexp-dep.patch
b/meta/recipes-extended/bash/bash/pathexp-dep.patch
new file mode 100644
index 000..e05bbda3174
--- /dev/null
+++ b/meta/recipes-extended/bash/bash/pathexp-dep.patch
@@ -0,0 +1,13 @@
+pathexp includes libintl.h but doesn't depend on it, thus a build race can
occur.
+
+Upstream-Status: Submitted (https://savannah.gnu.org/patch/index.php?9503)
+Signed-off-by: Ross Burton
+
+diff --git a/Makefile.in b/Makefile.in
+index c7b62bc0..241cbf12 100644
+--- a/Makefile.in
b/Makefile.in
+@@ -1281,2 +1281,3 @@ nojobs.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
+ y.tab.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
++pathexp.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
+ pcomplete.o: bashintl.h ${LIBINTL_H} $(BASHINCDIR)/gettext.h
diff --git a/meta/recipes-extended/bash/bash_4.4.bb
b/meta/recipes-extended/bash/bash_4.4.bb
index e544d07c10e..8b989ed3bd8 100644
--- a/meta/recipes-extended/bash/bash_4.4.bb
+++ b/meta/recipes-extended/bash/bash_4.4.bb
@@ -26,6 +26,7 @@ SRC_URI = "${GNU_MIRROR}/bash/${BP}.tar.gz;name=tarball \
file://fix-run-builtins.patch \
file://0001-help-fix-printf-format-security-warning.patch \
file://bash-memleak-bug-fix-for-builtin-command-read.patch \
+ file://pathexp-dep.patch \
"
SRC_URI[tarball.md5sum] = "14a7c95ac23705559b6f477dfe25"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: add license checksum change handling to 'devtool upgrade'
On 11/29/2017 11:10 AM, Burton, Ross wrote: I just tested this new behaviour and I for one like how it worked. It's sufficiently verbose that it obviously needs to be deleted and is stashed somewhere useful. FWIW, I will modify AUH so that it will move the info from recipe into commit, when creating one. So then a human will only need to amend the commit message. The broader goal is to automate the upgrade process as much as possible, give the commits directly to autobuilder and post them to oe-core list, and if they pass and don't need amending, I think it's fine to push them to straight to master with the 'From' still containing a robot name :) So that I (and other recipe maintainers) can spend time on more interesting things. A new patchtest test to automatically tell people if they left it in the recipe would be good too. Yes; will be done after I'm happy with the way AUH works :) Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: add license checksum change handling to 'devtool upgrade'
I just tested this new behaviour and I for one like how it worked. It's sufficiently verbose that it obviously needs to be deleted and is stashed somewhere useful. A new patchtest test to automatically tell people if they left it in the recipe would be good too. Ross On 29 November 2017 at 08:07, Alexander Kanavin < alexander.kana...@linux.intel.com> wrote: > On 11/29/2017 09:43 AM, Khem Raj wrote: > >> I'm not sure if this was clear, but the auto-generated license diff is >>> meant >>> as a starting point for a commit summary written by a human, and once the >>> summary is written, should be deleted, regardless of whether it was >>> placed >>> in a recipe, commit message or a separate file. Devtool does not create >>> or >>> manage commits from the changes it makes to recipes, and so placing this >>> into the recipe felt the most appropriate to me (separate files are more >>> cumbersome to manage and printing to stdout can be forgotten). We can >>> have >>> an automatic patch qa check that it's not accidentally left over, >>> similar to >>> the existing check that license changes have an explanation. >>> >> >> I think emitting this info to stdout should be enough. >> > > Between issuing 'devtool upgrade' and issuing 'git commit' with the > upgrade a lot of things can happen. Patches need to be rebased by hand, > build failures need to be dealt with, fixes need to be submitted upstream. > Oh, and the changes need to be tested on target sometimes. Between all > that, what the original command printed can be easily lost or forgottten. > Much better to stash it somewhere where it will be safe. > > Alex > > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] wic: support filesystem label for rawcopy
On Tue, Nov 28, 2017 at 01:56:11PM +0100, Martin Hundebøll wrote:
> The '--label' argument should work for '--source rawcopy' as it does for
> '--source rootfs', so add a method in RawCopyPlugin to update the label
> on the temporary filesystem images.
>
> Signed-off-by: Martin Hundebøll
Thank you for the patch!
+1
> ---
> scripts/lib/wic/plugins/source/rawcopy.py | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/scripts/lib/wic/plugins/source/rawcopy.py
> b/scripts/lib/wic/plugins/source/rawcopy.py
> index 424ed26ed6..e86398ac8f 100644
> --- a/scripts/lib/wic/plugins/source/rawcopy.py
> +++ b/scripts/lib/wic/plugins/source/rawcopy.py
> @@ -32,6 +32,25 @@ class RawCopyPlugin(SourcePlugin):
>
> name = 'rawcopy'
>
> +@staticmethod
> +def do_image_label(fstype, dst, label):
> +if fstype.startswith('ext'):
> +cmd = 'tune2fs -L %s %s' % (label, dst)
> +elif fstype in ('msdos', 'vfat'):
> +cmd = 'dosfslabel %s %s' % (dst, label)
> +elif fstype == 'btrfs':
> +cmd = 'btrfs filesystem label %s %s' % (dst, label)
> +elif fstype == 'swap':
> +cmd = 'mkswap -L %s %s' % (label, dst)
> +elif fstype == 'squashfs':
> +raise WicError("It's not possible to update a squashfs "
> + "filesystem label '%s'" % (label))
> +else:
> +raise WicError("Cannot update filesystem label: "
> + "Unknown fstype: '%s'" % (fstype))
> +
> +exec_cmd(cmd)
> +
> @classmethod
> def do_prepare_partition(cls, part, source_params, cr, cr_workdir,
> oe_builddir, bootimg_dir, kernel_dir,
> @@ -66,4 +85,7 @@ class RawCopyPlugin(SourcePlugin):
> if filesize > part.size:
> part.size = filesize
>
> +if part.label:
> +RawCopyPlugin.do_image_label(part.fstype, dst, part.label)
> +
> part.source_file = dst
> --
> 2.15.0
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
--
Regards,
Ed
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: add license checksum change handling to 'devtool upgrade'
On 11/29/2017 09:43 AM, Khem Raj wrote: I'm not sure if this was clear, but the auto-generated license diff is meant as a starting point for a commit summary written by a human, and once the summary is written, should be deleted, regardless of whether it was placed in a recipe, commit message or a separate file. Devtool does not create or manage commits from the changes it makes to recipes, and so placing this into the recipe felt the most appropriate to me (separate files are more cumbersome to manage and printing to stdout can be forgotten). We can have an automatic patch qa check that it's not accidentally left over, similar to the existing check that license changes have an explanation. I think emitting this info to stdout should be enough. Between issuing 'devtool upgrade' and issuing 'git commit' with the upgrade a lot of things can happen. Patches need to be rebased by hand, build failures need to be dealt with, fixes need to be submitted upstream. Oh, and the changes need to be tested on target sometimes. Between all that, what the original command printed can be easily lost or forgottten. Much better to stash it somewhere where it will be safe. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
