Re: [OE-core] [PATCH] u-boot: Upgrade to 2018.03 release
On 04/16/2018 10:38 AM, yamada.masah...@socionext.com wrote:
> Hi.
>
>> -Original Message-
>> From: Martin Hundebøll [mailto:m...@prevas.dk]
>> Sent: Wednesday, April 11, 2018 5:42 PM
>> To: Yamada, Masahiro/山田 真弘 ;
>> ma...@denx.de; raj.k...@gmail.com
>> Cc: ota...@ossystems.com.br; openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core] [PATCH] u-boot: Upgrade to 2018.03 release
>>
>> Hi,
>>
>> On 2018-04-11 04:28, yamada.masah...@socionext.com wrote:
>>> Hi.
>>>
> I had to patch up our own u-boot recipe as shown in the attached patch
> to make v2018.03 compile for qemu-x86.
>
> The thing is that the build of pylibfdt became unconditional since
> 15b97f5c5e ('pylibfdt: move pylibfdt to scripts/dtc/pylibfdt and
> refactor makefile')
>
> In my case u-boot/pylibfdt failed to find the correct (native) headers,
> because python setuptools / distutils looks into STAGING_{LIB,INC}DIR
> when compiling the native extension for libfdt. I didn't find any other
> way to specificy this in either the u-boot Makefile or some other magic
> environment variable.
CCing Yamada-san, maybe he has an idea.
Also, do not top post.
>>>
>>>
>>>
>>> The build of pylibfdt is conditional.
>>> It is built only when CONFIG_PYLIBFDT=y,
>>> which is selected by CONFIG_DTOC.
>>>
>>> If you really do not need pylibfdt,
>>> you can disable it by tweaking the configuration.
>>>
>>> If you need pylibfdt but you cannot build it,
>>> it is a different problem.
>>>
>>> Thanks.
>>
>> Correct. But I was building u-boot.rom for qemu-x86, which depends on
>> binman and thus pylibfdt. Before the mentioned commit, one could avoid
>> the building of pylibfdt by installing it on the host, as the makerule
>> checked if python could already import pylibfdt. This check is now removed.
>>
>> Or am I missing something?
>
>
> Understood what you mean, but I do not know
> whether the previous behavior was intended, or just something
> people discovered to work.
>
>
> Now U-Boot bundles its own DTC (scripts/dtc/dtc),
> so compiling also pylibfdt from the source in U-boot tree makes sense.
>
> Isn't it possible to solve your issue in the OE side?
>
Can we NOT compile DTC alongside U-Boot somehow ? :)
That'd be the most desired solution IMO.
--
Best regards,
Marek Vasut
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] dropping commerical flags in mpg123 and lame recipes
I *think* we're good to do this. If you could send a patch with a nice long commit message with sources and comparisons to other distros, then we can have a concrete patch to review and get further advice on. Ross On 15 April 2018 at 09:12, Carlos Rafael Giani wrote: > Please note that the Fraunhofer page is from May 2017. These sources suggest > that the final patent expired in December 2017: > > https://madfileformatscience.garymcgath.com/2016/04/05/mp3patent/ > https://www.tunequest.org/a-big-list-of-mp3-patents/20070226/ > > Fedora now added LAME and mpg123 support, since they consider the patents > expired: https://fedoramagazine.org/full-mp3-support-coming-soon-to-fedora/ > > Fraunhofer terminated the mp3 licensing program in April 2017: > https://www.iis.fraunhofer.de/en/ff/amm/prod/audiocodec/audiocodecs/mp3.html > > (German source) wikimedia now allows mp3 uploads: > https://netzpolitik.org/2017/wikimedia-erlaubt-upload-von-mp3-dateien/ > > > > On 2018-04-14 16:16, Khem Raj wrote: >> >> On Sat, Apr 14, 2018 at 1:30 AM, Carlos Rafael Giani >> wrote: >>> >>> The lame and mpg123 can be built only if the commercial flag is >>> whitelisted. >>> >>> However, the remaining mp3 patents expired in December, and no more >>> royalties exist. This is why in GStreamer, the mpg123 and lame plugins >>> were >>> moved from -ugly to -good. >>> >>> So, can we drop the commercial flag in mpg123 and lame? >>> >> We probably need more clarification see >> http://www.audioblog.iis.fraunhofer.com/mp3-software-patents-licenses/ >> >>> -- >>> ___ >>> 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] [PATCH] run-postinsts: Replace pi_dir variable test
I'll drop it myself, but in the future note that PR bumps are not required.
Ross
On 14 April 2018 at 07:54, Niko Mauno wrote:
> Since commit 5159ddcb62682e1b7e63a20a9218ea96e3fe10a2 string length test
> performed against pi_dir has effectively never been able to succeed.
>
> Change this to rather test if pi_dir is not an existing directory. By
> doing we remove the chance of seeing the following console error message
> during first boot to a pristine rootfs:
>
> 'ls: /etc/ipk-postinsts: No such file or directory'
>
> Signed-off-by: Niko Mauno
> ---
> meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts | 2 +-
> meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
> b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
> index 50c0a1afea..307feb7187 100755
> --- a/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
> +++ b/meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts
> @@ -43,7 +43,7 @@ remove_rcsd_link () {
> fi
> }
>
> -if [ -z "$pi_dir" ]; then
> +if ! [ -d $pi_dir ]; then
> remove_rcsd_link
> exit 0
> fi
> diff --git a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
> b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
> index 31c98ec99c..85b3fc867e 100644
> --- a/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
> +++ b/meta/recipes-devtools/run-postinsts/run-postinsts_1.0.bb
> @@ -1,6 +1,6 @@
> SUMMARY = "Runs postinstall scripts on first boot of the target device"
> SECTION = "devel"
> -PR = "r9"
> +PR = "r10"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
> --
> 2.16.3
>
> --
> ___
> 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
[OE-core] musl patches
Hi, I am not happy plastering patches around for musl. This gets even worse when I see patches like this [1]: Just wipe away security checks unconditionally - the developers did introduce this check not just for fun I guess... I have seen this already elsewhere so: musl maintainers please take care not to modify code for glibc! [1] https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 4/4] python 2.7: fix multilib patch to accept multiarch style paths
Using 'basename' to strip the prefix fails when using multiarch style paths.
Signed-off-by: Koen Kooi
---
meta/recipes-devtools/python/python.inc| 6 ++
meta/recipes-devtools/python/python/multilib.patch | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python.inc
b/meta/recipes-devtools/python/python.inc
index 979b601..84bcb6a 100644
--- a/meta/recipes-devtools/python/python.inc
+++ b/meta/recipes-devtools/python/python.inc
@@ -33,6 +33,12 @@ EXTRA_OECONF = "\
${PYTHONLSBOPTS} \
"
+do_configure_prepend() {
+ libdirleaf="$(echo ${libdir} | sed -e 's:${prefix}/::')"
+ sed -i -e "s:SEDMELIBLEAF:${libdirleaf}:g" \
+ ${S}/configure.ac
+}
+
do_install_append () {
sed -i -e 's:${HOSTTOOLS_DIR}/install:install:g' \
-e 's:${HOSTTOOLS_DIR}/mkdir:mkdir:g' \
diff --git a/meta/recipes-devtools/python/python/multilib.patch
b/meta/recipes-devtools/python/python/multilib.patch
index 1116dd5..d24bc15 100644
--- a/meta/recipes-devtools/python/python/multilib.patch
+++ b/meta/recipes-devtools/python/python/multilib.patch
@@ -11,7 +11,7 @@ Index: Python-2.7.14/configure.ac
+AC_SUBST(LIB)
+AC_MSG_CHECKING(LIB)
-+LIB=`basename ${libdir}`
++LIB="SEDMELIBLEAF"
+AC_MSG_RESULT($LIB)
AC_SUBST(LIBRARY)
--
2.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 1/4] native bbclass: handle base_libdir as well
Native.bbclass needs to fixup both base_libdir and libdir to handle things like
multiarch. This fixes wic and ext4.* image failures during do_rootfs where
mkfs.ext4 can't find its libraries.
Signed-off-by: Koen Kooi
---
meta/classes/native.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index a911f2a..7f2df17 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -78,6 +78,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
bindir = "${STAGING_BINDIR_NATIVE}"
sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
libdir = "${STAGING_LIBDIR_NATIVE}"
includedir = "${STAGING_INCDIR_NATIVE}"
sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +90,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir}
${base_libdir} /lib /lib64
NATIVE_PACKAGE_PATH_SUFFIX ?= ""
bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
--
2.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 3/4] bind: fix openSSL detection when using multiarch
In multiarch /usr/include and /usr/lib/
---
meta/recipes-connectivity/bind/bind_9.10.6.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connectivity/bind/bind_9.10.6.bb
b/meta/recipes-connectivity/bind/bind_9.10.6.bb
index 8b8835b..20c8d7b 100644
--- a/meta/recipes-connectivity/bind/bind_9.10.6.bb
+++ b/meta/recipes-connectivity/bind/bind_9.10.6.bb
@@ -35,7 +35,7 @@ EXTRA_OECONF = " ${ENABLE_IPV6} --with-libtool
--enable-threads \
--disable-devpoll --enable-epoll --with-gost=no \
--with-gssapi=no --with-ecdsa=yes \
--sysconfdir=${sysconfdir}/bind \
- --with-openssl=${STAGING_LIBDIR}/.. \
+ --with-openssl=${STAGING_DIR_HOST}${prefix} \
"
inherit autotools update-rc.d systemd useradd pkgconfig python3-dir
--
2.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2 2/4] libcap: fix (base_)libdir usage
The recipe wants to install libs into base_libdir, but uses "basename $libdir"
to derive that. That breaks in a multiarch setup. Use the proper variable and
remove the inline python usage.
Signed-off-by: Koen Kooi
---
meta/recipes-support/libcap/libcap_2.25.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-support/libcap/libcap_2.25.bb
b/meta/recipes-support/libcap/libcap_2.25.bb
index d619a2e..47ecf34 100644
--- a/meta/recipes-support/libcap/libcap_2.25.bb
+++ b/meta/recipes-support/libcap/libcap_2.25.bb
@@ -32,7 +32,7 @@ PACKAGECONFIG[pam] = "PAM_CAP=yes,PAM_CAP=no,libpam"
EXTRA_OEMAKE = " \
INDENT= \
- lib=${@os.path.basename('${libdir}')} \
+ lib='${base_libdir}' \
RAISE_SETFCAP=no \
DYNAMIC=yes \
BUILD_GPERF=yes \
--
2.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] package.bbclass: Add '-b' option to file call in isELF
The isELF function works by running:
result = file
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass | 2 +-
meta/lib/oe/package.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 9bba021efb..79783071bc 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -918,7 +918,7 @@ python split_and_strip_files () {
# 16 - kernel module
def isELF(path):
type = 0
-ret, result = oe.utils.getstatusoutput("file '%s'" % path)
+ret, result = oe.utils.getstatusoutput("file -b '%s'" % path)
if ret:
msg = "split_and_strip_files: 'file %s' failed" % path
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..599fca60f8 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -73,7 +73,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir,
qa_already_stripped=
def is_elf(path):
exec_type = 0
ret, result = oe.utils.getstatusoutput(
-"file \"%s\"" % path.replace("\"", "\\\""))
+"file -b \"%s\"" % path.replace("\"", "\\\""))
if ret:
bb.error("split_and_strip_files: 'file %s' failed" % path)
--
2.16.0.rc2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status April 16, 2018
Current Dev Position: YP 2.5 M4 final close out. Next Deadline: YP 2.5 M4 release is 4/27/18 SWAT Team Rotation: SWAT lead is currently: Tracy. SWAT team rotation: Tracy -> Stephano on April 20, 2018 SWAT team rotation: Stephano -> Maxin on April 27, 2018 https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * 2.5 M3 was released. There were some issues but we have decided to target these for the final release rather than respinning M3. * Our automated testing shows problems but only on machines in Asia. This was root caused to the timezone settings of the builds. We have therefore moved some of the reproducibility code to be the default (TZ setting) in order to have consistent builds. * Fedora28 has necessitated a late uninative upgrade which is due to merge for 2.5 but may have an issue still to resolve (rpm-native popt issue). * The final 2.5 build is blocked on the fedora28 issue above and the two remaining build issues we are seeing on debian9 machine the QA team has. Our main autobuilder debian9 builds are ok. * Master-next still has a number of recipe upgrades queued which are being rebased continually. We still want to discourage people from sending recipe upgrades until we start 2.6; however, there were simply too many patches to ignore. This has meant various people and build resources have ended up distracted from 2.5 work. * For 2.6 we are looking at a slightly different planning process. In the next monthly team call we will discuss the plans for 2.6. The agenda will be seeded with some high level ideas/goals about what we may be able to do in 2.6. It will then be up to the Yocto Project members and community to decide if they can contribute the time and resources to make them happen (or add to the list). If you are able to work on something in 2.6 please let us know or come to the meeting and discuss it with us so that we can ensure we have an accurate plan! A separate announcement email will be sent out about this in the next few days. Planned upcoming dot releases: YP 2.3.4 (Pyro) will be built after 2.5 YP 2.2.4 (Morty) will be built after 2.5 YP 2.4.3 (Rocko) is planned for post YP 2.5. Key YP 2.5 Dates are: YP 2.5 M4 cut off of 4/2/18 YP 2.5 M4 release of 4/27/18 Tracking Metrics: WDD 2573 (last week 2570) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you'd like to see on this weekly status update, let us know!] -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3
Testing out the upcoming sumo release and ran into an issue. Whenever I attempt to generate an sdk-ext with sumo I get a failure about missing sqlite3. Traceback (most recent call last): File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 344, in ret = main() File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 285, in main scriptutils.logger_setup_color(logger, global_args.color) File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line 38, in logger_setup_color from bb.msg import BBLogFormatter File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line 79, in from bb import fetch2 as fetch File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py", line 39, in import bb.persist_data, bb.utils File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py", line 33, in sqlversion = sqlite3.sqlite_version_info AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info' The issue seems to be isolated only to python3. The sdk partially installs and I am able to source it. I created a small python sqlite app and was able to run it properly with python2, but not 3. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3
Adding python3-misc to the SDK seems to have solved the issue. I saw some commits about separating the two so perhaps this is a side effect? From: Davis, Michael Sent: Monday, April 16, 2018 11:04 AM To: 'openembedded-core@lists.openembedded.org' Subject: [OE-CORE][sumo][python3] Generated SDK missing sqlite3 Testing out the upcoming sumo release and ran into an issue. Whenever I attempt to generate an sdk-ext with sumo I get a failure about missing sqlite3. Traceback (most recent call last): File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 344, in ret = main() File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 285, in main scriptutils.logger_setup_color(logger, global_args.color) File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line 38, in logger_setup_color from bb.msg import BBLogFormatter File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line 79, in from bb import fetch2 as fetch File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py", line 39, in import bb.persist_data, bb.utils File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py", line 33, in sqlversion = sqlite3.sqlite_version_info AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info' The issue seems to be isolated only to python3. The sdk partially installs and I am able to source it. I created a small python sqlite app and was able to run it properly with python2, but not 3. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
From: Ming Liu
It defaults to be '0', but it allows the developers to choose not add
file-checksums to do_compile for the entire source tree, by setting to
'1'.
We need this because we have a huge project with 100G bytes source
files, and we do not want them to be added to file-checksums variable
flag.
Signed-off-by: Ming Liu
---
meta/classes/externalsrc.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index c9f5cf7..16c6862 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -26,6 +26,7 @@
SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
+INHIBIT_SRCTREE_FILE_CHECKSUMES ?= "0"
python () {
externalsrc = d.getVar('EXTERNALSRC')
@@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
with open(oe_hash_file, 'w') as fobj:
fobj.write(sha1)
ret = oe_hash_file + ':True'
-else:
+elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMES'):
ret = s_dir + '/*:True'
return ret
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [pyro][PATCH] package.bbclass: Add '-b' option to file call in isELF
The isELF function works by running:
result = file
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass | 2 +-
meta/classes/staging.bbclass | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index a03c05b9f7..0844fd5065 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -898,7 +898,7 @@ python split_and_strip_files () {
# 16 - kernel module
def isELF(path):
type = 0
-ret, result = oe.utils.getstatusoutput("file \"%s\"" %
path.replace("\"", "\\\""))
+ret, result = oe.utils.getstatusoutput("file -b '%s'" %
path.replace("\"", "\\\""))
if ret:
msg = "split_and_strip_files: 'file %s' failed" % path
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 984051d6aa..bff04373dc 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -84,7 +84,7 @@ python sysroot_strip () {
# 16 - kernel module
def isELF(path):
type = 0
-ret, result = oe.utils.getstatusoutput("file \"%s\"" %
path.replace("\"", "\\\""))
+ret, result = oe.utils.getstatusoutput("file -b \"%s\"" %
path.replace("\"", "\\\""))
if ret:
bb.error("split_and_strip_files: 'file %s' failed" % path)
--
2.16.0.rc2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [rocko][PATCH] package.bbclass: Add '-b' option to file call in isELF
The isELF function works by running:
result = file
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII
text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
Signed-off-by: Mark Hatle
---
meta/classes/package.bbclass | 2 +-
meta/lib/oe/package.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 2053d46395..cee64f3267 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -901,7 +901,7 @@ python split_and_strip_files () {
# 16 - kernel module
def isELF(path):
type = 0
-ret, result = oe.utils.getstatusoutput("file \"%s\"" %
path.replace("\"", "\\\""))
+ret, result = oe.utils.getstatusoutput("file -b '%s'" %
path.replace("\"", "\\\""))
if ret:
msg = "split_and_strip_files: 'file %s' failed" % path
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 1e5c3aa8e1..599fca60f8 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -73,7 +73,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir,
qa_already_stripped=
def is_elf(path):
exec_type = 0
ret, result = oe.utils.getstatusoutput(
-"file \"%s\"" % path.replace("\"", "\\\""))
+"file -b \"%s\"" % path.replace("\"", "\\\""))
if ret:
bb.error("split_and_strip_files: 'file %s' failed" % path)
--
2.16.0.rc2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] recipes-kernel/linux: Enable NUMA Kconfig from DISTRO_FEATURES
If the user has set numa as a distro feature enable NUMA support in the
kernel config.
Signed-off-by: Alistair Francis
---
meta/recipes-kernel/linux/files/numa.cfg | 4
meta/recipes-kernel/linux/linux-yocto.inc | 3 +++
2 files changed, 7 insertions(+)
create mode 100644 meta/recipes-kernel/linux/files/numa.cfg
diff --git a/meta/recipes-kernel/linux/files/numa.cfg
b/meta/recipes-kernel/linux/files/numa.cfg
new file mode 100644
index 000..bb0f9ab
--- /dev/null
+++ b/meta/recipes-kernel/linux/files/numa.cfg
@@ -0,0 +1,4 @@
+CONFIG_NUMA=y
+CONFIG_ACPI_NUMA=y
+CONFIG_NUMA_BALANCING=y
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 3bb872a..cf97cd1 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -28,6 +28,9 @@ KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
+SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'numa', '
file://numa.cfg', '', d)}"
+KERNEL_FEATURES_append = " ${@bb.utils.contains('DISTRO_FEATURES', 'numa',
'features/numa/numa.scc', '', d)}"
+
# A KMACHINE is the mapping of a yocto $MACHINE to what is built
# by the kernel. This is typically the branch that should be built,
# and it can be specific to the machine or shared
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] package.bbclass: Add '-b' option to file call in isELF
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: den 16 april 2018 17:34
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] package.bbclass: Add '-b' option to file
> call in isELF
>
> The isELF function works by running:
>
>result = file
>if 'ELF' in result
>
> By default 'file' will prepend the result with the path name of the file
> that is being checked. This usually works fine, such as:
>
> $ file /home/foo/openembedded-core/meta/classes/package.bbclass
> /home/foo/openembedded-core/meta/classes/package.bbclass: Python
> script, ASCII text executable, with very long lines
>
> However, if the path includes 'ELF', ELF will end up in the result, and then
> the check will return positive.
>
> $ file /home/ELF/openembedded-core/meta/classes/package.bbclass
> /home/ELF/openembedded-core/meta/classes/package.bbclass: Python
> script, ASCII text executable, with very long lines
>
> This will then result in the isELF coming back true, and possibly causing the
> checks that use isELF, such as the 'is it already stripped' check, to do the
> incorrect thing.
>
> Adding the '-b' option to file will result in the path being omitted in the
> result:
>
> $ file /home/ELF/openembedded-core/meta/classes/package.bbclass
> Python script, ASCII text executable, with very long lines
>
> Signed-off-by: Mark Hatle
> ---
> meta/classes/package.bbclass | 2 +-
> meta/lib/oe/package.py | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/package.bbclass
> b/meta/classes/package.bbclass
> index 9bba021efb..79783071bc 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -918,7 +918,7 @@ python split_and_strip_files () {
> # 16 - kernel module
> def isELF(path):
> type = 0
> -ret, result = oe.utils.getstatusoutput("file '%s'" % path)
> +ret, result = oe.utils.getstatusoutput("file -b '%s'" % path)
>
> if ret:
> msg = "split_and_strip_files: 'file %s' failed" % path
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
> index 1e5c3aa8e1..599fca60f8 100644
> --- a/meta/lib/oe/package.py
> +++ b/meta/lib/oe/package.py
> @@ -73,7 +73,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir,
> base_libdir, qa_already_stripped=
> def is_elf(path):
> exec_type = 0
> ret, result = oe.utils.getstatusoutput(
> -"file \"%s\"" % path.replace("\"", "\\\""))
> +"file -b \"%s\"" % path.replace("\"", "\\\""))
>
> if ret:
> bb.error("split_and_strip_files: 'file %s' failed" % path)
> --
> 2.16.0.rc2
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
There was a discussion last year at the beginning of December related
to this, triggered by a patch series to improve isELF that Olof Johansson
sent:
http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145160.html
It also included a patch that added -b to the file call:
http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145158.html
However, the discussion then turned to replace the isELF implementation
with a new one that Ross Burton was working on:
http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145205.html
Whatever became of that? Is that still in progress?
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
On Mon, Apr 16, 2018 at 12:26 PM, wrote:
> From: Ming Liu
>
> It defaults to be '0', but it allows the developers to choose not add
> file-checksums to do_compile for the entire source tree, by setting to
> '1'.
>
> We need this because we have a huge project with 100G bytes source
> files, and we do not want them to be added to file-checksums variable
> flag.
>
> Signed-off-by: Ming Liu
> ---
> meta/classes/externalsrc.bbclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/externalsrc.bbclass
> b/meta/classes/externalsrc.bbclass
> index c9f5cf7..16c6862 100644
> --- a/meta/classes/externalsrc.bbclass
> +++ b/meta/classes/externalsrc.bbclass
> @@ -26,6 +26,7 @@
>
> SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
> EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
> +INHIBIT_SRCTREE_FILE_CHECKSUMES ?= "0"
Plural of CHECKSUM is CHECKSUMS (ie no 'E').
> python () {
> externalsrc = d.getVar('EXTERNALSRC')
> @@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
> with open(oe_hash_file, 'w') as fobj:
> fobj.write(sha1)
> ret = oe_hash_file + ':True'
> -else:
> +elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMES'):
> ret = s_dir + '/*:True'
> return ret
>
> --
> 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
Re: [OE-core] [PATCH] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
My mistake, that is a typo, will send the V2 soon.
//Ming Liu
2018-04-16 23:22 GMT+02:00 Andre McCurdy :
> On Mon, Apr 16, 2018 at 12:26 PM, wrote:
> > From: Ming Liu
> >
> > It defaults to be '0', but it allows the developers to choose not add
> > file-checksums to do_compile for the entire source tree, by setting to
> > '1'.
> >
> > We need this because we have a huge project with 100G bytes source
> > files, and we do not want them to be added to file-checksums variable
> > flag.
> >
> > Signed-off-by: Ming Liu
> > ---
> > meta/classes/externalsrc.bbclass | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/externalsrc.bbclass
> b/meta/classes/externalsrc.bbclass
> > index c9f5cf7..16c6862 100644
> > --- a/meta/classes/externalsrc.bbclass
> > +++ b/meta/classes/externalsrc.bbclass
> > @@ -26,6 +26,7 @@
> >
> > SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
> > EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
> > +INHIBIT_SRCTREE_FILE_CHECKSUMES ?= "0"
>
> Plural of CHECKSUM is CHECKSUMS (ie no 'E').
>
> > python () {
> > externalsrc = d.getVar('EXTERNALSRC')
> > @@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
> > with open(oe_hash_file, 'w') as fobj:
> > fobj.write(sha1)
> > ret = oe_hash_file + ':True'
> > -else:
> > +elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMES'):
> > ret = s_dir + '/*:True'
> > return ret
> >
> > --
> > 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
[OE-core] [PATCH V2] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
From: Ming Liu
It defaults to be '0', but it allows the developers to choose not add
file-checksums to do_compile for the entire source tree, by setting to
'1'.
We need this because we have a huge project with 100G bytes source
files, and we do not want them to be added to file-checksums variable
flag.
Signed-off-by: Ming Liu
---
meta/classes/externalsrc.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index c9f5cf7..2b83193 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -26,6 +26,7 @@
SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
+INHIBIT_SRCTREE_FILE_CHECKSUMS ?= "0"
python () {
externalsrc = d.getVar('EXTERNALSRC')
@@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
with open(oe_hash_file, 'w') as fobj:
fobj.write(sha1)
ret = oe_hash_file + ':True'
-else:
+elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMS'):
ret = s_dir + '/*:True'
return ret
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> liu.min...@gmail.com
> Sent: den 17 april 2018 02:25
> To: openembedded-core@lists.openembedded.org
> Cc: Ming Liu
> Subject: [OE-core] [PATCH V2] externalsrc.bbclass: introduce
> INHIBIT_SRCTREE_FILE_CHECKSUMES
Please correct the subject as well.
> From: Ming Liu
>
> It defaults to be '0', but it allows the developers to choose not add
> file-checksums to do_compile for the entire source tree, by setting to
> '1'.
>
> We need this because we have a huge project with 100G bytes source
> files, and we do not want them to be added to file-checksums variable
> flag.
>
> Signed-off-by: Ming Liu
> ---
> meta/classes/externalsrc.bbclass | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/externalsrc.bbclass
> b/meta/classes/externalsrc.bbclass
> index c9f5cf7..2b83193 100644
> --- a/meta/classes/externalsrc.bbclass
> +++ b/meta/classes/externalsrc.bbclass
> @@ -26,6 +26,7 @@
>
> SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
> EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
> +INHIBIT_SRCTREE_FILE_CHECKSUMS ?= "0"
>
> python () {
> externalsrc = d.getVar('EXTERNALSRC')
> @@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
> with open(oe_hash_file, 'w') as fobj:
> fobj.write(sha1)
> ret = oe_hash_file + ':True'
> -else:
> +elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMS'):
> ret = s_dir + '/*:True'
> return ret
>
> --
> 2.7.4
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMES
Oops, will send a V3.
2018-04-17 2:34 GMT+02:00 Peter Kjellerstedt :
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > liu.min...@gmail.com
> > Sent: den 17 april 2018 02:25
> > To: openembedded-core@lists.openembedded.org
> > Cc: Ming Liu
> > Subject: [OE-core] [PATCH V2] externalsrc.bbclass: introduce
> INHIBIT_SRCTREE_FILE_CHECKSUMES
>
> Please correct the subject as well.
>
> > From: Ming Liu
> >
> > It defaults to be '0', but it allows the developers to choose not add
> > file-checksums to do_compile for the entire source tree, by setting to
> > '1'.
> >
> > We need this because we have a huge project with 100G bytes source
> > files, and we do not want them to be added to file-checksums variable
> > flag.
> >
> > Signed-off-by: Ming Liu
> > ---
> > meta/classes/externalsrc.bbclass | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/externalsrc.bbclass
> > b/meta/classes/externalsrc.bbclass
> > index c9f5cf7..2b83193 100644
> > --- a/meta/classes/externalsrc.bbclass
> > +++ b/meta/classes/externalsrc.bbclass
> > @@ -26,6 +26,7 @@
> >
> > SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
> > EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
> > +INHIBIT_SRCTREE_FILE_CHECKSUMS ?= "0"
> >
> > python () {
> > externalsrc = d.getVar('EXTERNALSRC')
> > @@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
> > with open(oe_hash_file, 'w') as fobj:
> > fobj.write(sha1)
> > ret = oe_hash_file + ':True'
> > -else:
> > +elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMS'):
> > ret = s_dir + '/*:True'
> > return ret
> >
> > --
> > 2.7.4
>
> //Peter
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V3] externalsrc.bbclass: introduce INHIBIT_SRCTREE_FILE_CHECKSUMS
From: Ming Liu
It defaults to be '0', but it allows the developers to choose not add
file-checksums to do_compile for the entire source tree, by setting to
'1'.
We need this because we have a huge project with 100G bytes source
files, and we do not want them to be added to file-checksums variable
flag.
Signed-off-by: Ming Liu
---
meta/classes/externalsrc.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index c9f5cf7..2b83193 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -26,6 +26,7 @@
SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
EXTERNALSRC_SYMLINKS ?= "oe-workdir:${WORKDIR} oe-logs:${T}"
+INHIBIT_SRCTREE_FILE_CHECKSUMS ?= "0"
python () {
externalsrc = d.getVar('EXTERNALSRC')
@@ -212,7 +213,7 @@ def srctree_hash_files(d, srcdir=None):
with open(oe_hash_file, 'w') as fobj:
fobj.write(sha1)
ret = oe_hash_file + ':True'
-else:
+elif not d.getVar('INHIBIT_SRCTREE_FILE_CHECKSUMS'):
ret = s_dir + '/*:True'
return ret
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3
Which commit are you using? https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=4379b29e7eede727993ee68c9eba2bdebace5108 In any case, that one should've solved it. Alejandro From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Davis, Michael Sent: Monday, April 16, 2018 11:19 AM To: Davis, Michael ; openembedded-core@lists.openembedded.org Subject: Re: [OE-core] [OE-CORE][sumo][python3] Generated SDK missing sqlite3 Adding python3-misc to the SDK seems to have solved the issue. I saw some commits about separating the two so perhaps this is a side effect? From: Davis, Michael Sent: Monday, April 16, 2018 11:04 AM To: 'openembedded-core@lists.openembedded.org' Subject: [OE-CORE][sumo][python3] Generated SDK missing sqlite3 Testing out the upcoming sumo release and ran into an issue. Whenever I attempt to generate an sdk-ext with sumo I get a failure about missing sqlite3. Traceback (most recent call last): File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 344, in ret = main() File "/home/mdavis/core_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/devtool", line 285, in main scriptutils.logger_setup_color(logger, global_args.color) File "/home/mdavis/core_sdk/layers/core/scripts/lib/scriptutils.py", line 38, in logger_setup_color from bb.msg import BBLogFormatter File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/__init__.py", line 79, in from bb import fetch2 as fetch File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/fetch2/__init__.py", line 39, in import bb.persist_data, bb.utils File "/home/mdavis/core_sdk/layers/core/bitbake/lib/bb/persist_data.py", line 33, in sqlversion = sqlite3.sqlite_version_info AttributeError: module 'sqlite3' has no attribute 'sqlite_version_info' The issue seems to be isolated only to python3. The sdk partially installs and I am able to source it. I created a small python sqlite app and was able to run it properly with python2, but not 3. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl patches
On 04/16/2018 07:05 PM, Andreas Müller wrote: Hi, I am not happy plastering patches around for musl. This gets even worse when I see patches like this [1]: Just wipe away security checks unconditionally - the developers did introduce this check not just for fun I guess... I have seen this already elsewhere so: musl maintainers please take care not to modify code for glibc! [1] https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch Andreas Hi Anreas, I can see I rebased this patch. So I think I need to reply. I agree with you that musl related patches should not affect glibc. How about we using something like SRC_URI_append_libc-musl to organize the musl related patches? Or do you have some other suggestion? Best Regards, Chen Qi -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] musl patches
On Mon, Apr 16, 2018 at 7:02 PM ChenQi wrote: > On 04/16/2018 07:05 PM, Andreas Müller wrote: > > Hi, > > > > I am not happy plastering patches around for musl. This gets even > > worse when I see patches like this [1]: Just wipe away security checks > > unconditionally - the developers did introduce this check not just for > > fun I guess... > > > > I have seen this already elsewhere so: musl maintainers please take > > care not to modify code for glibc! The idea of musl is not to create a cocoon and live in it but on the contrary it’s about fixing the packages such that they work on any posix complaint libc regardless having said that there are packages which are coded for glibc and we Might have to keep trying to fix them upstream So in the spirit we are making changes such that They work across the board and then also push These patches to respective upstreams so far we Have done good job and upstreamed a whole bunch of patches this would not have been possible if we did the conditional approach We would not like to introduce regressions for sure and if you see regressions please report them ASAP and if you have fixes even better I am hoping that in the end applications will Become more portable and we will also see The cruft clearly that has gone into glibc over the years and be able to address it as you can see there is lot of cleanup happening in glibc already as a result > > > > > [1] > https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-core/systemd/systemd/0001-Use-getenv-when-secure-versions-are-not-available.patch > > > > Andreas > > Hi Anreas, > > I can see I rebased this patch. So I think I need to reply. > > I agree with you that musl related patches should not affect glibc. > How about we using something like SRC_URI_append_libc-musl to organize > the musl related patches? No we should not unless the issue can’t be fixed in a compatible way > > Or do you have some other suggestion? Fix in portable way and contribute the same to package upstream > > Best Regards, > Chen Qi > -- > ___ > 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
