[OE-core] ✗ patchtest: failure for qtwebkit_git.bb: Fix configure failure on bison
== Series Details == Series: qtwebkit_git.bb: Fix configure failure on bison Revision: 1 URL : https://patchwork.openembedded.org/series/13588/ 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: * Patch[meta-qt5] qtwebkit_git.bb: Fix configure failure on bison Issue Series sent to the wrong mailing list [test_target_mailing_list] Suggested fixCheck the project's README (meta-qt5) and send the patch to the indicated list * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 176e50fb17) 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] [meta-qt5][PATCH] qtwebkit_git.bb: Fix configure failure on bison
Fix the following error during do_configure | CMake Error at | Could NOT find BISON (missing: BISON_EXECUTABLE) (Required is at least | version "2.1") | Call Stack (most recent call first): Add dependency to bison-native to fix the above error Signed-off-by: Manjukumar Matha --- recipes-qt/qt5/qtwebkit_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-qt/qt5/qtwebkit_git.bb b/recipes-qt/qt5/qtwebkit_git.bb index 9e4617a..a7dad98 100644 --- a/recipes-qt/qt5/qtwebkit_git.bb +++ b/recipes-qt/qt5/qtwebkit_git.bb @@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = " \ file://Source/JavaScriptCore/parser/Parser.h;endline=21;md5=bd69f72183a7af673863f057576e21ee \ " -DEPENDS += "qtbase qtdeclarative icu ruby-native sqlite3 glib-2.0 libxslt gperf-native" +DEPENDS += "qtbase qtdeclarative icu ruby-native sqlite3 glib-2.0 libxslt gperf-native bison-native" inherit cmake_qt5 perlnative pythonnative -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Question regarding docker and sumo
On Fri, Aug 17, 2018 at 1:58 PM, Lukasz Majewski wrote:
> Dear All,
>
> I do port yocto/OE from 2.3 to 2.5.1
>
> For packagegroups-foo-common I do see following error
>
> cd /packagegroup-foo-common/1.0-r0/sstate-build-package/
>
> as expected, there are needed directories: package packages-split
> pkgdata
>
> The problem is in sstate_create_package () at
> poky/meta/classes/sstate.bbclass
>
> To be precise in:
> tar: tar -czf temporary.tgz.XXX package packages-split pkgdata
>
> tar (child): gzip: Cannot exec: Invalid argument
It looks like tar tries to run gzip but the exec call returns "Invalid
argument". According to the execve manpage, that means:
EINVAL The new process image file has the appropriate permission and
has a recognized executable binary format, but the system does not
support execution of a file with this format.
So, first find which gzip binary tar will use (ie check PATH) and then
try to figure out why that gzip binary can't be executed.
> tar (child): Error is not recoverable: exiting now
>
>
> Tar version tar (GNU tar) 1.28 (the same for both versions on host).
> Also 'env' command shows 'unlimited' size for pipes.
>
>
> ls -alh /poky/build-lwn/tmp/hosttools and there is a link
> tar -> /bin/tar
>
> The sumo runs inside docker container (with recommended ubuntu). The
> only change is from pyro to sumo.
>
>
> To be even more strange - the sumo version of BSP builds correctly when
> run natively on Debian 9
>
>
> The problem seems to be with sumo and docker.
>
> | rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =
> 0 | write(4, "packages-split/packagegroup-lwn-"..., 10240) = -1 EPIPE
> (Broken pipe) | --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER,
> si_pid=15063, si_uid=1000} --- | +++ killed by SIGPIPE
> +++
>
> Any idea on how to solve (or debug) this issue further? Apparently
> something is closing the pipe between tar and gzip...
>
> Thanks in advance for any hints :-)
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>
> --
> ___
> 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] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
Respect PERSISTENT_LOG_DIR variable. In this way, if the user overrides
this variable to be e.g "/home/root/log", /var/log on the final image would
be a link pointing to /home/root/log on persistent storage.
Signed-off-by: Ankur Tyagi
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 1c0863b..597fdaa 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir}
${base_libdir} \
${localstatedir}/backups ${localstatedir}/lib \
/sys ${localstatedir}/lib/misc ${localstatedir}/spool \
${localstatedir}/volatile \
- ${localstatedir}/${@'volatile/' if
oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
+ ${@'${localstatedir}/volatile/log' if
oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}' if
d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
/home ${prefix}/src ${localstatedir}/local \
/media"
@@ -106,6 +106,10 @@ do_install () {
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+ if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a ! -z
${PERSISTENT_LOG_DIR} ]; then
+ ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
+ fi
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable
This variable is only respected when VOLATILE_LOG_DIR is "no".
The default value is "" which results in the /var/log being log directory.
The user could override this value to a path e.g "/home/root/log" which
results /var/log being a link pointing to /home/root/log directory on
persistent storage.
Signed-off-by: Ankur Tyagi
---
meta/conf/bitbake.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e5dc1ac..9db22c8 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to
/var/volatile/log.
# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on
persistent storage.
VOLATILE_LOG_DIR ?= "yes"
+# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log links
to PERSISTENT_LOG_DIR
+PERSISTENT_LOG_DIR ??= ""
##
# Architecture-dependent build variables.
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Hi Christopher,
I think I get it now.
Thank you so much for your time!
Davis
On Fri, Aug 17, 2018, 6:57 PM Christopher Larson wrote:
> Layer priority as defined by BBFILE_PRIORITY controls recipe selection,
> not bbclass and config file parsing. See the bitbake reference manual for
> more detail.
>
> On Fri, Aug 17, 2018 at 3:54 PM Davis Roman
> wrote:
>
>> Hi Christopher,
>>
>> I am very intrigued by your response.
>>
>> Initially I had mentioned that the 'bitbake-layers show-layers'
>> command indicates that my layer, meta-hon-grip, has a priority of 8
>> which is among the highest while the meta layer only has a priority of
>> 5.
>>
>> However, now that you mentioned the bblayers.conf file, I see that the
>> meta-hon-grip layer is defined after the meta layer.
>>
>> Therefore it appears to me that my bblayers.conf contradicts
>> 'bitbake-layers show-layers'
>>
>> Could you please help me make sense of this?
>>
>> Thank you,
>>
>> Davis
>>
>>
>>
>>
>>
>> POKY_BBLAYERS_CONF_VERSION = "2"
>>
>> BBPATH = "${TOPDIR}"
>> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True))
>> + '/../..')}"
>>
>> BBFILES ?= ""
>> BBLAYERS = " \
>> ${BSPDIR}/sources/poky/meta \
>> ${BSPDIR}/sources/poky/meta-poky \
>> \
>> ${BSPDIR}/sources/meta-openembedded/meta-oe \
>> ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
>> \
>> ${BSPDIR}/sources/meta-fsl-arm \
>> ${BSPDIR}/sources/meta-fsl-arm-extra \
>> ${BSPDIR}/sources/meta-fsl-demos \
>> "
>> ##Freescale Yocto Project Release layer
>> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp "
>> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-sdk "
>> BBLAYERS += " ${BSPDIR}/sources/meta-browser "
>> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-gnome "
>> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-networking "
>> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-python "
>> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-filesystems "
>> BBLAYERS += " ${BSPDIR}/sources/meta-qt5 "
>> BBLAYERS += " ${BSPDIR}/sources/meta-hon-grip "
>> BBLAYERS += " ${BSPDIR}/sources/meta-java "
>> BBLAYERS += " ${BSPDIR}/sources/meta-swupdate "
>> BBLAYERS += " ${BSPDIR}/sources/meta-bc "
>> BBLAYERS += " ${BSPDIR}/sources/meta-updater "
>> BBLAYERS += " ${BSPDIR}/sources/meta-gplv2 "
>>
>> On Fri, Aug 17, 2018 at 6:01 PM, Christopher Larson
>> wrote:
>> > Your layer has to be before poky/meta in BBLAYERS, as that determines
>> > BBPATH, which is how bbclasses and config files are found (much like
>> PATH).
>> >
>> > On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
>> > wrote:
>> >>
>> >> Hello!
>> >>
>> >>
>> >> I've made a modification in poky/meta/classes/libc-package.bbclass (
>> >> shown below)
>> >>
>> >> However I don't want this change to be stored here long term and
>> >> instead feel that it should live in my project specific layer,
>> >> meta-hon-grip.
>> >>
>> >> After checking with bitbake-layers, I saw that my layer has a higher
>> >> priority than the poky layer so my layer should be checked first ( or
>> >> so I thought)
>> >>
>> >> I copied the modified version of libc-packages.bbclass into
>> >> meta-hon-grip/classes and I restored the version in the poky layer to
>> >> its original state.
>> >>
>> >> After making this change, I found that the modified version in my
>> >> layer is not being used and instead the version in the poky layer is
>> >> the one in play.
>> >>
>> >> I'm trying to figure out what else to try.
>> >>
>> >> Any suggestions would be greatly appreciated!
>> >>
>> >> Thank you,
>> >>
>> >> Davis
>> >>
>> >> diff --git a/meta/classes/libc-package.bbclass
>> >> b/meta/classes/libc-package.bbclass
>> >> index 467d567..72d447a 100644
>> >> --- a/meta/classes/libc-package.bbclass
>> >> +++ b/meta/classes/libc-package.bbclass
>> >> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
>> >> bb.error("locale_arch_options not found for
>> >> target_arch=" + target_arch)
>> >> raise bb.build.FuncFailed("unknown arch:" +
>> >> target_arch + " for locale_arch_options")
>> >>
>> >> -localedef_opts += " --force --old-style --no-archive
>> >> --prefix=%s \
>> >> +localedef_opts += " --force --no-archive --prefix=%s \
>> >> --inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s"
>> \
>> >> % (treedir, treedir, datadir, locale, encoding,
>> >> outputpath, name)
>> >>
>> >> @@ -295,7 +295,7 @@ python package_do_split_gconvs () {
>> >> (path, i18npath, gconvpath, localedef_opts)
>> >> else: # earlier slower qemu way
>> >> qemu = qemu_target_binary(d)
>> >> -localedef_opts = "--force --old-style --no-archive
>> >> --prefix=%s \
>> >> +localedef_opts = "--force --no-archive --prefix=%s \
>> >> --inputfile=%s/i18n/loca
Re: [OE-core] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Layer priority as defined by BBFILE_PRIORITY controls recipe selection, not
bbclass and config file parsing. See the bitbake reference manual for more
detail.
On Fri, Aug 17, 2018 at 3:54 PM Davis Roman wrote:
> Hi Christopher,
>
> I am very intrigued by your response.
>
> Initially I had mentioned that the 'bitbake-layers show-layers'
> command indicates that my layer, meta-hon-grip, has a priority of 8
> which is among the highest while the meta layer only has a priority of
> 5.
>
> However, now that you mentioned the bblayers.conf file, I see that the
> meta-hon-grip layer is defined after the meta layer.
>
> Therefore it appears to me that my bblayers.conf contradicts
> 'bitbake-layers show-layers'
>
> Could you please help me make sense of this?
>
> Thank you,
>
> Davis
>
>
>
>
>
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True))
> + '/../..')}"
>
> BBFILES ?= ""
> BBLAYERS = " \
> ${BSPDIR}/sources/poky/meta \
> ${BSPDIR}/sources/poky/meta-poky \
> \
> ${BSPDIR}/sources/meta-openembedded/meta-oe \
> ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
> \
> ${BSPDIR}/sources/meta-fsl-arm \
> ${BSPDIR}/sources/meta-fsl-arm-extra \
> ${BSPDIR}/sources/meta-fsl-demos \
> "
> ##Freescale Yocto Project Release layer
> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp "
> BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-sdk "
> BBLAYERS += " ${BSPDIR}/sources/meta-browser "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-gnome "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-networking "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-python "
> BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-filesystems "
> BBLAYERS += " ${BSPDIR}/sources/meta-qt5 "
> BBLAYERS += " ${BSPDIR}/sources/meta-hon-grip "
> BBLAYERS += " ${BSPDIR}/sources/meta-java "
> BBLAYERS += " ${BSPDIR}/sources/meta-swupdate "
> BBLAYERS += " ${BSPDIR}/sources/meta-bc "
> BBLAYERS += " ${BSPDIR}/sources/meta-updater "
> BBLAYERS += " ${BSPDIR}/sources/meta-gplv2 "
>
> On Fri, Aug 17, 2018 at 6:01 PM, Christopher Larson
> wrote:
> > Your layer has to be before poky/meta in BBLAYERS, as that determines
> > BBPATH, which is how bbclasses and config files are found (much like
> PATH).
> >
> > On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
> > wrote:
> >>
> >> Hello!
> >>
> >>
> >> I've made a modification in poky/meta/classes/libc-package.bbclass (
> >> shown below)
> >>
> >> However I don't want this change to be stored here long term and
> >> instead feel that it should live in my project specific layer,
> >> meta-hon-grip.
> >>
> >> After checking with bitbake-layers, I saw that my layer has a higher
> >> priority than the poky layer so my layer should be checked first ( or
> >> so I thought)
> >>
> >> I copied the modified version of libc-packages.bbclass into
> >> meta-hon-grip/classes and I restored the version in the poky layer to
> >> its original state.
> >>
> >> After making this change, I found that the modified version in my
> >> layer is not being used and instead the version in the poky layer is
> >> the one in play.
> >>
> >> I'm trying to figure out what else to try.
> >>
> >> Any suggestions would be greatly appreciated!
> >>
> >> Thank you,
> >>
> >> Davis
> >>
> >> diff --git a/meta/classes/libc-package.bbclass
> >> b/meta/classes/libc-package.bbclass
> >> index 467d567..72d447a 100644
> >> --- a/meta/classes/libc-package.bbclass
> >> +++ b/meta/classes/libc-package.bbclass
> >> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
> >> bb.error("locale_arch_options not found for
> >> target_arch=" + target_arch)
> >> raise bb.build.FuncFailed("unknown arch:" +
> >> target_arch + " for locale_arch_options")
> >>
> >> -localedef_opts += " --force --old-style --no-archive
> >> --prefix=%s \
> >> +localedef_opts += " --force --no-archive --prefix=%s \
> >> --inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s" \
> >> % (treedir, treedir, datadir, locale, encoding,
> >> outputpath, name)
> >>
> >> @@ -295,7 +295,7 @@ python package_do_split_gconvs () {
> >> (path, i18npath, gconvpath, localedef_opts)
> >> else: # earlier slower qemu way
> >> qemu = qemu_target_binary(d)
> >> -localedef_opts = "--force --old-style --no-archive
> >> --prefix=%s \
> >> +localedef_opts = "--force --no-archive --prefix=%s \
> >> --inputfile=%s/i18n/locales/%s --charmap=%s %s" \
> >> % (treedir, datadir, locale, encoding, name)
> >> --
> >> ___
> >> bitbake-devel mailing list
> >> bitbake-de...@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinf
Re: [OE-core] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Hi Christopher,
I am very intrigued by your response.
Initially I had mentioned that the 'bitbake-layers show-layers'
command indicates that my layer, meta-hon-grip, has a priority of 8
which is among the highest while the meta layer only has a priority of
5.
However, now that you mentioned the bblayers.conf file, I see that the
meta-hon-grip layer is defined after the meta layer.
Therefore it appears to me that my bblayers.conf contradicts
'bitbake-layers show-layers'
Could you please help me make sense of this?
Thank you,
Davis
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True))
+ '/../..')}"
BBFILES ?= ""
BBLAYERS = " \
${BSPDIR}/sources/poky/meta \
${BSPDIR}/sources/poky/meta-poky \
\
${BSPDIR}/sources/meta-openembedded/meta-oe \
${BSPDIR}/sources/meta-openembedded/meta-multimedia \
\
${BSPDIR}/sources/meta-fsl-arm \
${BSPDIR}/sources/meta-fsl-arm-extra \
${BSPDIR}/sources/meta-fsl-demos \
"
##Freescale Yocto Project Release layer
BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-bsp "
BBLAYERS += " ${BSPDIR}/sources/meta-fsl-bsp-release/imx/meta-sdk "
BBLAYERS += " ${BSPDIR}/sources/meta-browser "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-gnome "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-networking "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-python "
BBLAYERS += " ${BSPDIR}/sources/meta-openembedded/meta-filesystems "
BBLAYERS += " ${BSPDIR}/sources/meta-qt5 "
BBLAYERS += " ${BSPDIR}/sources/meta-hon-grip "
BBLAYERS += " ${BSPDIR}/sources/meta-java "
BBLAYERS += " ${BSPDIR}/sources/meta-swupdate "
BBLAYERS += " ${BSPDIR}/sources/meta-bc "
BBLAYERS += " ${BSPDIR}/sources/meta-updater "
BBLAYERS += " ${BSPDIR}/sources/meta-gplv2 "
On Fri, Aug 17, 2018 at 6:01 PM, Christopher Larson wrote:
> Your layer has to be before poky/meta in BBLAYERS, as that determines
> BBPATH, which is how bbclasses and config files are found (much like PATH).
>
> On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
> wrote:
>>
>> Hello!
>>
>>
>> I've made a modification in poky/meta/classes/libc-package.bbclass (
>> shown below)
>>
>> However I don't want this change to be stored here long term and
>> instead feel that it should live in my project specific layer,
>> meta-hon-grip.
>>
>> After checking with bitbake-layers, I saw that my layer has a higher
>> priority than the poky layer so my layer should be checked first ( or
>> so I thought)
>>
>> I copied the modified version of libc-packages.bbclass into
>> meta-hon-grip/classes and I restored the version in the poky layer to
>> its original state.
>>
>> After making this change, I found that the modified version in my
>> layer is not being used and instead the version in the poky layer is
>> the one in play.
>>
>> I'm trying to figure out what else to try.
>>
>> Any suggestions would be greatly appreciated!
>>
>> Thank you,
>>
>> Davis
>>
>> diff --git a/meta/classes/libc-package.bbclass
>> b/meta/classes/libc-package.bbclass
>> index 467d567..72d447a 100644
>> --- a/meta/classes/libc-package.bbclass
>> +++ b/meta/classes/libc-package.bbclass
>> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
>> bb.error("locale_arch_options not found for
>> target_arch=" + target_arch)
>> raise bb.build.FuncFailed("unknown arch:" +
>> target_arch + " for locale_arch_options")
>>
>> -localedef_opts += " --force --old-style --no-archive
>> --prefix=%s \
>> +localedef_opts += " --force --no-archive --prefix=%s \
>> --inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s" \
>> % (treedir, treedir, datadir, locale, encoding,
>> outputpath, name)
>>
>> @@ -295,7 +295,7 @@ python package_do_split_gconvs () {
>> (path, i18npath, gconvpath, localedef_opts)
>> else: # earlier slower qemu way
>> qemu = qemu_target_binary(d)
>> -localedef_opts = "--force --old-style --no-archive
>> --prefix=%s \
>> +localedef_opts = "--force --no-archive --prefix=%s \
>> --inputfile=%s/i18n/locales/%s --charmap=%s %s" \
>> % (treedir, datadir, locale, encoding, name)
>> --
>> ___
>> bitbake-devel mailing list
>> bitbake-de...@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
>
>
> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [V2][PATCH] gnutls: Update to 3.6.3
On 08/17/2018 02:31 PM, Andre McCurdy wrote:
> On Fri, Aug 17, 2018 at 7:14 AM, Armin Kuster wrote:
>> [v2]
>> Fix new config options form with to disable.
>>
>> [v1]
>> release notes:
>> https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
>>
>> add ssl3 and tls1.3 config options now supported.
>>
>> Signed-off-by: Armin Kuster
>> ---
>> meta/recipes-support/gnutls/gnutls.inc | 2 ++
>> .../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} | 5 +++--
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>> rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb}
>> (53%)
>>
>> diff --git a/meta/recipes-support/gnutls/gnutls.inc
>> b/meta/recipes-support/gnutls/gnutls.inc
>> index 04c0fd2af8..f204e5f4c0 100644
>> --- a/meta/recipes-support/gnutls/gnutls.inc
>> +++ b/meta/recipes-support/gnutls/gnutls.inc
>> @@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
>> PACKAGECONFIG[libtasn1] =
>> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
>> PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
>> PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
>> +PACKAGECONFIG[ssl3] = "--enable-ssl3-support,--disable-ssl3-support,"
>> +PACKAGECONFIG[tls13] = "--enable-tls13-support,--disable-tls13-support,"
> I'm not sure whether either of these should have PACKAGECONFIG options.
>
> SSL v3 is obsolete and if gnutls is disabling it by default now then
> it's probably best to leave it that way (dead and buried). Experienced
> users can always enable via EXTRA_OECONF if they really need it.
>
> TLS 1.3 is the opposite - it's brand new. If we add a PACKAGECONFIG
> option to control it then it becomes the gnutls recipe maintainer's
> job to figure out when to enable it by default. I think it's better to
> leave that decision to upstream gnutls.
No change in behavior in the way its setup now.
You can send a patch to correct them. I am not doing a v3 for this.
- armin
>
>> EXTRA_OECONF = " \
>> --enable-doc \
>> diff --git a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
>> b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
>> similarity index 53%
>> rename from meta/recipes-support/gnutls/gnutls_3.6.2.bb
>> rename to meta/recipes-support/gnutls/gnutls_3.6.3.bb
>> index e540528a8e..c560305032 100644
>> --- a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
>> +++ b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
>> @@ -3,7 +3,8 @@ require gnutls.inc
>> SRC_URI += "file://0001-configure.ac-fix-sed-command.patch \
>> file://arm_eabi.patch \
>> "
>> -SRC_URI[md5sum] = "8b4912c6c0e5ffefd3dbb4888eaf8a58"
>> -SRC_URI[sha256sum] =
>> "bcd5db7b234e02267f36b5d13cf5214baac232b7056a506252b7574ea7738d1f"
>> +
>> +SRC_URI[md5sum] = "d3b1b05c2546b80832101a423a80faf8"
>> +SRC_URI[sha256sum] =
>> "ed642b66a4ecf4851ab2d809cd1475c297b6201d8e8bd14b4d1c08b53ffca993"
>>
>> BBCLASSEXTEND = "native nativesdk"
>> --
>> 2.17.1
>>
>> --
>> ___
>> 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] [bitbake-devel] how to store a modification of a bbclass in the poky layer in my own layer.
Your layer has to be before poky/meta in BBLAYERS, as that determines
BBPATH, which is how bbclasses and config files are found (much like PATH).
On Fri, Aug 17, 2018 at 12:11 PM Davis Roman
wrote:
> Hello!
>
>
> I've made a modification in poky/meta/classes/libc-package.bbclass (
> shown below)
>
> However I don't want this change to be stored here long term and
> instead feel that it should live in my project specific layer,
> meta-hon-grip.
>
> After checking with bitbake-layers, I saw that my layer has a higher
> priority than the poky layer so my layer should be checked first ( or
> so I thought)
>
> I copied the modified version of libc-packages.bbclass into
> meta-hon-grip/classes and I restored the version in the poky layer to
> its original state.
>
> After making this change, I found that the modified version in my
> layer is not being used and instead the version in the poky layer is
> the one in play.
>
> I'm trying to figure out what else to try.
>
> Any suggestions would be greatly appreciated!
>
> Thank you,
>
> Davis
>
> diff --git a/meta/classes/libc-package.bbclass
> b/meta/classes/libc-package.bbclass
> index 467d567..72d447a 100644
> --- a/meta/classes/libc-package.bbclass
> +++ b/meta/classes/libc-package.bbclass
> @@ -287,7 +287,7 @@ python package_do_split_gconvs () {
> bb.error("locale_arch_options not found for
> target_arch=" + target_arch)
> raise bb.build.FuncFailed("unknown arch:" +
> target_arch + " for locale_arch_options")
>
> -localedef_opts += " --force --old-style --no-archive
> --prefix=%s \
> +localedef_opts += " --force --no-archive --prefix=%s \
> --inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s" \
> % (treedir, treedir, datadir, locale, encoding,
> outputpath, name)
>
> @@ -295,7 +295,7 @@ python package_do_split_gconvs () {
> (path, i18npath, gconvpath, localedef_opts)
> else: # earlier slower qemu way
> qemu = qemu_target_binary(d)
> -localedef_opts = "--force --old-style --no-archive
> --prefix=%s \
> +localedef_opts = "--force --no-archive --prefix=%s \
> --inputfile=%s/i18n/locales/%s --charmap=%s %s" \
> % (treedir, datadir, locale, encoding, name)
> --
> ___
> bitbake-devel mailing list
> bitbake-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] kernel-devsrc: restructure for out of tree (and on target) module builds
On Fri, Aug 17, 2018 at 2:14 PM, wrote: > On Fri, 2018-08-17 at 12:46 -0700, Andre McCurdy wrote: >> On Thu, Aug 16, 2018 at 10:53 PM, Richard Purdie >> wrote: >> > On Thu, 2018-08-16 at 22:44 +0100, richard.purdie@linuxfoundation.o >> > rg >> > wrote: >> > > On Thu, 2018-08-16 at 17:08 -0400, Bruce Ashfield wrote: >> > > > I'm getting a strange install issue with x86 that I've never >> > > > seen >> > > > before, and that >> > > > part is unchanged from v3 to v4. >> > > > >> > > > .. and then I realized that a file has changed in my builds, >> > > > since >> > > > I'm >> > > > working on 4.18. >> > > > >> > > > This is worth testing on the autobuilder, but I will have a v5 >> > > > that >> > > > adds a test for some >> > > > files that may go missing, and hence we'll have issues across >> > > > versions. >> > > >> > > Thanks, I've added it into a build with a glibc and openssl >> > > change >> > > and >> > > set it away so its possible other issues may occur, we'll see how >> > > it >> > > works out... >> > >> > The openssl change caused problems but I did spot qemumips64 >> > failing: >> >> What were the problems related to the openssl updates? > > SDK sanity test failing where wget is failing to work: > > https://autobuilder.yocto.io/builders/nightly-arm/builds/1285/steps/Running%20SDK%20Sanity%20Tests/logs/stdio > > I've not definitively narrowed it down to openssl but it has to be one > of: > > kernel-devsrc: restructure for out of tree (and on target) module > openssl: update 1.1.0h -> 1.1.0i > openssl: update 1.0.2o -> 1.0.2p > vala: refresh patch > glibc: re-package for libnss-db wget builds against gnutls (rather than openssl), but there's a dependency chain from wget -> ca-certificates -> openssl so definitely something could have gone wrong there. Interesting that this test is running wget without passing --no-check-certificate (which the wget fetcher always uses). -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [V2][PATCH] gnutls: Update to 3.6.3
On Fri, Aug 17, 2018 at 7:14 AM, Armin Kuster wrote:
> [v2]
> Fix new config options form with to disable.
>
> [v1]
> release notes:
> https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
>
> add ssl3 and tls1.3 config options now supported.
>
> Signed-off-by: Armin Kuster
> ---
> meta/recipes-support/gnutls/gnutls.inc | 2 ++
> .../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} | 5 +++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
> rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} (53%)
>
> diff --git a/meta/recipes-support/gnutls/gnutls.inc
> b/meta/recipes-support/gnutls/gnutls.inc
> index 04c0fd2af8..f204e5f4c0 100644
> --- a/meta/recipes-support/gnutls/gnutls.inc
> +++ b/meta/recipes-support/gnutls/gnutls.inc
> @@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
> PACKAGECONFIG[libtasn1] =
> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
> PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
> PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
> +PACKAGECONFIG[ssl3] = "--enable-ssl3-support,--disable-ssl3-support,"
> +PACKAGECONFIG[tls13] = "--enable-tls13-support,--disable-tls13-support,"
I'm not sure whether either of these should have PACKAGECONFIG options.
SSL v3 is obsolete and if gnutls is disabling it by default now then
it's probably best to leave it that way (dead and buried). Experienced
users can always enable via EXTRA_OECONF if they really need it.
TLS 1.3 is the opposite - it's brand new. If we add a PACKAGECONFIG
option to control it then it becomes the gnutls recipe maintainer's
job to figure out when to enable it by default. I think it's better to
leave that decision to upstream gnutls.
> EXTRA_OECONF = " \
> --enable-doc \
> diff --git a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
> b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
> similarity index 53%
> rename from meta/recipes-support/gnutls/gnutls_3.6.2.bb
> rename to meta/recipes-support/gnutls/gnutls_3.6.3.bb
> index e540528a8e..c560305032 100644
> --- a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
> +++ b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
> @@ -3,7 +3,8 @@ require gnutls.inc
> SRC_URI += "file://0001-configure.ac-fix-sed-command.patch \
> file://arm_eabi.patch \
> "
> -SRC_URI[md5sum] = "8b4912c6c0e5ffefd3dbb4888eaf8a58"
> -SRC_URI[sha256sum] =
> "bcd5db7b234e02267f36b5d13cf5214baac232b7056a506252b7574ea7738d1f"
> +
> +SRC_URI[md5sum] = "d3b1b05c2546b80832101a423a80faf8"
> +SRC_URI[sha256sum] =
> "ed642b66a4ecf4851ab2d809cd1475c297b6201d8e8bd14b4d1c08b53ffca993"
>
> BBCLASSEXTEND = "native nativesdk"
> --
> 2.17.1
>
> --
> ___
> 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 1/2] populate_sdk_base: only depend on nativesdk-glibc-locale when SDK_OS is not mingw32
On Fri, 2018-08-17 at 01:54 -0700, Zhixiong Chi wrote:
> When we add the nativesdk-glibc-locale dependence for libc-glibc, if
> the SDK_OS
> is mingw32, it will broken the building with the following error:
> > NOTE: Resolving any missing task queue dependencies
> > ERROR: Nothing RPROVIDES 'nativesdk-glibc' (but
> > virtual:nativesdk:layers/oe-core/meta/recipes-core/glibc/glibc-
> > locale_2.24.bb
> > RDEPENDS on or otherwise requires it)
> > ERROR: nativesdk-glibc was skipped:
> > PREFERRED_PROVIDER_virtual/nativesdk-libc set to nativesdk-mingw-
> > w64-runtime, not nativesdk-glibc
> > NOTE: Runtime target 'nativesdk-glibc' is unbuildable, removing...
> > Missing or unbuildable dependency chain was: ['nativesdk-glibc']
> > ERROR: Required build target 'meta-toolchain' has no buildable
> > providers.
> > Missing or unbuildable dependency chain was: ['meta-toolchain',
> > 'nativesdk-glibc-locale', 'nativesdk-glibc']
>
> mingw32 SDK_OS doesn't need to depend on nativesdk-glibc-locale.
>
> Signed-off-by: Zhixiong Chi
> ---
> meta/classes/populate_sdk_base.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/populate_sdk_base.bbclass
> b/meta/classes/populate_sdk_base.bbclass
> index c456c52866..65c27b0077 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -48,7 +48,7 @@ TOOLCHAIN_OUTPUTNAME ?=
> "${SDK_NAME}-toolchain-${SDK_VERSION}"
> SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
> SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native
> nativesdk-qemuwrapper-cross ${@' '.join(["%s-qemuwrapper-cross" % m for m in
> d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross"
> PATH_prepend =
> "${STAGING_DIR_HOST}${SDKPATHNATIVE}${bindir}/crossscripts:${@":".join(all_multilib_tune_values(d,
> 'STAGING_BINDIR_CROSS').split())}:"
> -SDK_DEPENDS_append_libc-glibc = " nativesdk-glibc-locale"
> +SDK_DEPENDS_append_libc-glibc = " ${@bb.utils.contains('SDK_OS', 'mingw32',
> '', 'nativesdk-glibc-locale', d)}"
>
> # We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not
> PACKAGE_ARCH as it
> # could be set to the MACHINE_ARCH
I appreciate this fixes a specific problem but this code is wrong
anyway, libc-glibc is a target override and we're talking about the sdk
here. To illustrate, if a target image was musl based but the sdk
glibc based, this code wouldn't work.
Could we therefore correct this to correctly determine which libc is
being used in the SDK? If we're going to fix it, lets fix it
properly...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] kernel-devsrc: restructure for out of tree (and on target) module builds
On Fri, 2018-08-17 at 12:46 -0700, Andre McCurdy wrote: > On Thu, Aug 16, 2018 at 10:53 PM, Richard Purdie > wrote: > > On Thu, 2018-08-16 at 22:44 +0100, richard.purdie@linuxfoundation.o > > rg > > wrote: > > > On Thu, 2018-08-16 at 17:08 -0400, Bruce Ashfield wrote: > > > > I'm getting a strange install issue with x86 that I've never > > > > seen > > > > before, and that > > > > part is unchanged from v3 to v4. > > > > > > > > .. and then I realized that a file has changed in my builds, > > > > since > > > > I'm > > > > working on 4.18. > > > > > > > > This is worth testing on the autobuilder, but I will have a v5 > > > > that > > > > adds a test for some > > > > files that may go missing, and hence we'll have issues across > > > > versions. > > > > > > Thanks, I've added it into a build with a glibc and openssl > > > change > > > and > > > set it away so its possible other issues may occur, we'll see how > > > it > > > works out... > > > > The openssl change caused problems but I did spot qemumips64 > > failing: > > What were the problems related to the openssl updates? SDK sanity test failing where wget is failing to work: https://autobuilder.yocto.io/builders/nightly-arm/builds/1285/steps/Running%20SDK%20Sanity%20Tests/logs/stdio I've not definitively narrowed it down to openssl but it has to be one of: kernel-devsrc: restructure for out of tree (and on target) module openssl: update 1.1.0h -> 1.1.0i openssl: update 1.0.2o -> 1.0.2p vala: refresh patch glibc: re-package for libnss-db Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Question regarding docker and sumo
Dear All,
I do port yocto/OE from 2.3 to 2.5.1
For packagegroups-foo-common I do see following error
cd /packagegroup-foo-common/1.0-r0/sstate-build-package/
as expected, there are needed directories: package packages-split
pkgdata
The problem is in sstate_create_package () at
poky/meta/classes/sstate.bbclass
To be precise in:
tar: tar -czf temporary.tgz.XXX package packages-split pkgdata
tar (child): gzip: Cannot exec: Invalid argument
tar (child): Error is not recoverable: exiting now
Tar version tar (GNU tar) 1.28 (the same for both versions on host).
Also 'env' command shows 'unlimited' size for pipes.
ls -alh /poky/build-lwn/tmp/hosttools and there is a link
tar -> /bin/tar
The sumo runs inside docker container (with recommended ubuntu). The
only change is from pyro to sumo.
To be even more strange - the sumo version of BSP builds correctly when
run natively on Debian 9
The problem seems to be with sumo and docker.
| rt_sigprocmask(SIG_SETMASK, [], NULL, 8) =
0 | write(4, "packages-split/packagegroup-lwn-"..., 10240) = -1 EPIPE
(Broken pipe) | --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER,
si_pid=15063, si_uid=1000} --- | +++ killed by SIGPIPE
+++
Any idea on how to solve (or debug) this issue further? Apparently
something is closing the pipe between tar and gzip...
Thanks in advance for any hints :-)
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgpS2xgpaioj_.pgp
Description: OpenPGP digital signature
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] kernel-devsrc: restructure for out of tree (and on target) module builds
On Thu, Aug 16, 2018 at 10:53 PM, Richard Purdie wrote: > On Thu, 2018-08-16 at 22:44 +0100, richard.pur...@linuxfoundation.org > wrote: >> On Thu, 2018-08-16 at 17:08 -0400, Bruce Ashfield wrote: >> > I'm getting a strange install issue with x86 that I've never seen >> > before, and that >> > part is unchanged from v3 to v4. >> > >> > .. and then I realized that a file has changed in my builds, since >> > I'm >> > working on 4.18. >> > >> > This is worth testing on the autobuilder, but I will have a v5 that >> > adds a test for some >> > files that may go missing, and hence we'll have issues across >> > versions. >> >> Thanks, I've added it into a build with a glibc and openssl change >> and >> set it away so its possible other issues may occur, we'll see how it >> works out... > > The openssl change caused problems but I did spot qemumips64 failing: What were the problems related to the openssl updates? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] how to store a modification of a bbclass in the poky layer in my own layer.
Hello!
I've made a modification in poky/meta/classes/libc-package.bbclass (
shown below)
However I don't want this change to be stored here long term and
instead feel that it should live in my project specific layer,
meta-hon-grip.
After checking with bitbake-layers, I saw that my layer has a higher
priority than the poky layer so my layer should be checked first ( or
so I thought)
I copied the modified version of libc-packages.bbclass into
meta-hon-grip/classes and I restored the version in the poky layer to
its original state.
After making this change, I found that the modified version in my
layer is not being used and instead the version in the poky layer is
the one in play.
I'm trying to figure out what else to try.
Any suggestions would be greatly appreciated!
Thank you,
Davis
diff --git a/meta/classes/libc-package.bbclass
b/meta/classes/libc-package.bbclass
index 467d567..72d447a 100644
--- a/meta/classes/libc-package.bbclass
+++ b/meta/classes/libc-package.bbclass
@@ -287,7 +287,7 @@ python package_do_split_gconvs () {
bb.error("locale_arch_options not found for
target_arch=" + target_arch)
raise bb.build.FuncFailed("unknown arch:" +
target_arch + " for locale_arch_options")
-localedef_opts += " --force --old-style --no-archive --prefix=%s \
+localedef_opts += " --force --no-archive --prefix=%s \
--inputfile=%s/%s/i18n/locales/%s --charmap=%s %s/%s" \
% (treedir, treedir, datadir, locale, encoding,
outputpath, name)
@@ -295,7 +295,7 @@ python package_do_split_gconvs () {
(path, i18npath, gconvpath, localedef_opts)
else: # earlier slower qemu way
qemu = qemu_target_binary(d)
-localedef_opts = "--force --old-style --no-archive --prefix=%s \
+localedef_opts = "--force --no-archive --prefix=%s \
--inputfile=%s/i18n/locales/%s --charmap=%s %s" \
% (treedir, datadir, locale, encoding, name)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] weston-init: run login before start weston.service
From: Wang Quanyang When systemd start the weston.service, the script "weston-start" will check if the dir "XDG_RUNTIME_DIR" (usually is /run/user/0) exits and create it. Then weston will create a socket file "wayland-0" for communications with clients in this dir. If systemd is built with enabling "pam" feature, the login will call "run-user-0.mount" to mount tmpfs at the dir "/run/user/0", then the socket file "wayland-0" will be missing since it is created in the old "/run/user/0". So add "PAMName=login" to let weston.service call login first, once tmpfs is mounted at "/run/user/0", then call weston-start to create a socket file in it. Signed-off-by: Quanyang Wang --- meta/recipes-graphics/wayland/weston-init/weston.service | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-graphics/wayland/weston-init/weston.service b/meta/recipes-graphics/wayland/weston-init/weston.service index 689ce41..18f7262 100644 --- a/meta/recipes-graphics/wayland/weston-init/weston.service +++ b/meta/recipes-graphics/wayland/weston-init/weston.service @@ -4,6 +4,7 @@ RequiresMountsFor=/run [Service] User=root +PAMName=login EnvironmentFile=-/etc/default/weston ExecStart=/usr/bin/weston-start -v -e -- $OPTARGS -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [V2][PATCH] gnutls: Update to 3.6.3
[v2]
Fix new config options form with to disable.
[v1]
release notes:
https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
add ssl3 and tls1.3 config options now supported.
Signed-off-by: Armin Kuster
---
meta/recipes-support/gnutls/gnutls.inc | 2 ++
.../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} | 5 +++--
2 files changed, 5 insertions(+), 2 deletions(-)
rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} (53%)
diff --git a/meta/recipes-support/gnutls/gnutls.inc
b/meta/recipes-support/gnutls/gnutls.inc
index 04c0fd2af8..f204e5f4c0 100644
--- a/meta/recipes-support/gnutls/gnutls.inc
+++ b/meta/recipes-support/gnutls/gnutls.inc
@@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
PACKAGECONFIG[libtasn1] =
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
+PACKAGECONFIG[ssl3] = "--enable-ssl3-support,--disable-ssl3-support,"
+PACKAGECONFIG[tls13] = "--enable-tls13-support,--disable-tls13-support,"
EXTRA_OECONF = " \
--enable-doc \
diff --git a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
similarity index 53%
rename from meta/recipes-support/gnutls/gnutls_3.6.2.bb
rename to meta/recipes-support/gnutls/gnutls_3.6.3.bb
index e540528a8e..c560305032 100644
--- a/meta/recipes-support/gnutls/gnutls_3.6.2.bb
+++ b/meta/recipes-support/gnutls/gnutls_3.6.3.bb
@@ -3,7 +3,8 @@ require gnutls.inc
SRC_URI += "file://0001-configure.ac-fix-sed-command.patch \
file://arm_eabi.patch \
"
-SRC_URI[md5sum] = "8b4912c6c0e5ffefd3dbb4888eaf8a58"
-SRC_URI[sha256sum] =
"bcd5db7b234e02267f36b5d13cf5214baac232b7056a506252b7574ea7738d1f"
+
+SRC_URI[md5sum] = "d3b1b05c2546b80832101a423a80faf8"
+SRC_URI[sha256sum] =
"ed642b66a4ecf4851ab2d809cd1475c297b6201d8e8bd14b4d1c08b53ffca993"
BBCLASSEXTEND = "native nativesdk"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gnutls: Update to 3.6.3
On 08/17/2018 01:20 AM, Anuj Mittal wrote:
> On 08/17/2018 01:17 PM, Armin Kuster wrote:
>> release notes:
>> https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
>>
>> add ssl3 and tls1.3 config options now supported.
>>
>> Signed-off-by: Armin Kuster
>> ---
>> meta/recipes-support/gnutls/gnutls.inc | 2 ++
>> .../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} | 5 +++--
>> 2 files changed, 5 insertions(+), 2 deletions(-)
>> rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb}
>> (53%)
>>
>> diff --git a/meta/recipes-support/gnutls/gnutls.inc
>> b/meta/recipes-support/gnutls/gnutls.inc
>> index 04c0fd2af8..cf947d445e 100644
>> --- a/meta/recipes-support/gnutls/gnutls.inc
>> +++ b/meta/recipes-support/gnutls/gnutls.inc
>> @@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
>> PACKAGECONFIG[libtasn1] =
>> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
>> PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
>> PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
>> +PACKAGECONFIG[ssl3] = "--with-ssl3-support,--disable-ssl3-support,"
> This should be --enable-ssl3-support ...
>
>> +PACKAGECONFIG[tls13] = "--with-tls13-support,--disable-tls13-support,"
> and, --enable-tls13-support.
yep.
V2 shortly
thanks,
armin
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssh: fix wrong volatile dir for sshd host keys on read-only rootfs
On Thu, 2018-08-16 at 22:33 -0700, Andre McCurdy wrote:
> On Wed, Aug 15, 2018 at 11:26 PM, Martin Hundebøll > wrote:
> > Hi Andre,
> >
> > On 15/08/2018 21.47, Andre McCurdy wrote:
> > >
> > > On Wed, Aug 15, 2018 at 4:59 AM, Martin Hundebøll > > com>
> > > wrote:
> > > >
> > > > When the read-only-rootfs image feature is enabled, and openssh
> > > > is
> > > > installed into an image, the ssh daemon is reconfigured to use
> > > > /var/run/ssh when generating host keys.
> > > >
> > > > Fix up the creation of the volatile dir to actually match what
> > > > sshd is
> > > > configured to.
> > > >
> > > > Signed-off-by: Martin Hundebøll
> > > > ---
> > > > meta/recipes-connectivity/openssh/openssh/volatiles.99_sshd |
> > > > 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-
> > > > connectivity/openssh/openssh/volatiles.99_sshd
> > > > b/meta/recipes-connectivity/openssh/openssh/volatiles.99_sshd
> > > > index a0d2af3c65..fcbc5ae9d5 100644
> > > > --- a/meta/recipes-
> > > > connectivity/openssh/openssh/volatiles.99_sshd
> > > > +++ b/meta/recipes-
> > > > connectivity/openssh/openssh/volatiles.99_sshd
> > > > @@ -1,2 +1,2 @@
> > > > -d root root 0755 /var/run/sshd none
> > > > +d root root 0755 /var/run/ssh none
> > >
> > > This doesn't look right.
> > >
> > > /var/run/sshd is the directory used for privilege separation
> > > (grep for
> > > --with-privsep-path ), so it's not correct to remove it.
> >
> > I see - didn't know about openssh chrooting to do privilege
> > separation.
> >
> > > Note that sshd_check_keys script runs "mkdir -p $SYSCONFDIR" (ie
> > > /var/run/ssh in the read-only rootfs case) at run time before
> > > creating
> > > any keys.
> >
> > Yes, it works without the volatile folder; for openssh at least.
> >
> > > What exactly was the problem that this patch tries to fix?
> >
> > I am running a custom image with the read-only-rootfs feature
> > enabled, and
> > wanted to make the ssh host keys persistent across reboots.
>
> That should be possible by following the steps described in:
>
> http://git.openembedded.org/openembedded-core/commit/?id=106b59d9f9
> 6f70d133fa1421091ad280d27a5b6a
>
> ie add something like the following to a .bbappend:
>
> export SYSCONFDIR = "/data/ssh"
>
> do_install_append () {
> sed 's|HostKey /var/run/ssh|HostKey /data/ssh|g' -i
> ${D}${sysconfdir}/ssh/sshd_config_readonly
> }
>
> The openssh init script has changed a little since then, but I think
> the same basic approach should still work (and if it doesn't we
> should
> fix things so it does).
FWIW, we use volatiles to accomplish something similar:
# cat /etc/default/volatiles/99_sshd
d root root 0755 /data/var/run/ssh none
l root root 0755 /var/run/ssh /data/var/run/ssh
>
> > At first, I tried adding a bind-mount entry to fstab from /data/ssh
> > to
> > /var/run/ssh, but the latter don't exist when mountall.sh is
> > executed by RC
> > (/data is the mountpoint of a persistent partition).
> >
> > I then looked at the volatile entries and noticed that it created
> > the
> > (empty) /var/run/sshd, so changed it to (wrongly) create
> > /var/run/ssh
> > instead.
> >
> > That wasn't enough though, since populate-volatiles.sh comes after
> > mountall.sh.
> >
> > In the end I simply added a new entry to volatiles to create a
> > symlink from
> > /var/run/ssh to /data/ssh, which works for me :)
> >
> > Maybe I should change the patch to add a comment about the
> > /var/run/sshd
> > entry, so we don't end up doing mistakes like the debian-
> > predictable-keys
> > story.
> >
> > // Martin
--
Joshua Watt
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3-git: update to version 2.1.11
Update to the latest stable release
Signed-off-by: Derek Straka
---
meta/recipes-devtools/python/python-git.inc | 4 ++--
.../python/{python3-git_2.1.10.bb => python3-git_2.1.11.bb} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-git_2.1.10.bb =>
python3-git_2.1.11.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-git.inc
b/meta/recipes-devtools/python/python-git.inc
index 5a4d8ff..7ccf168 100644
--- a/meta/recipes-devtools/python/python-git.inc
+++ b/meta/recipes-devtools/python/python-git.inc
@@ -12,8 +12,8 @@ PYPI_PACKAGE = "GitPython"
inherit pypi
-SRC_URI[md5sum] = "e0c773be32ba9cb57a1d703b590f6d3f"
-SRC_URI[sha256sum] =
"b60b045cf64a321e5b620debb49890099fa6c7be6dfb7fb249027e5d34227301"
+SRC_URI[md5sum] = "cee43a39a1468084d49d1c49fb675204"
+SRC_URI[sha256sum] =
"8237dc5bfd6f1366abeee5624111b9d6879393d84745a507de0fda86043b65a8"
DEPENDS = "${PYTHON_PN}-gitdb"
diff --git a/meta/recipes-devtools/python/python3-git_2.1.10.bb
b/meta/recipes-devtools/python/python3-git_2.1.11.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-git_2.1.10.bb
rename to meta/recipes-devtools/python/python3-git_2.1.11.bb
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3-pip: update to version 18.0
License-Update: Update checksum for copyright year changes
Update to the latest stable version
Signed-off-by: Derek Straka
---
.../python/{python3-pip_10.0.1.bb => python3-pip_18.0.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/python/{python3-pip_10.0.1.bb =>
python3-pip_18.0.bb} (71%)
diff --git a/meta/recipes-devtools/python/python3-pip_10.0.1.bb
b/meta/recipes-devtools/python/python3-pip_18.0.bb
similarity index 71%
rename from meta/recipes-devtools/python/python3-pip_10.0.1.bb
rename to meta/recipes-devtools/python/python3-pip_18.0.bb
index 8deec2b..3fcdb80 100644
--- a/meta/recipes-devtools/python/python3-pip_10.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_18.0.bb
@@ -2,12 +2,12 @@ SUMMARY = "The PyPA recommended tool for installing Python
packages"
HOMEPAGE = "https://pypi.python.org/pypi/pip";
SECTION = "devel/python"
LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=3f8d33acaac5c5dac8c613904bd56a6f"
+LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=593c6cd9d639307226978cbcae61ad4b"
DEPENDS += "python3 python3-setuptools-native"
-SRC_URI[md5sum] = "83a177756e2c801d0b3a6f7b0d4f3f7e"
-SRC_URI[sha256sum] =
"f2bd08e0cd1b06e10218feaf6fef299f473ba706582eb3bd9d52203fdbd7ee68"
+SRC_URI[md5sum] = "52f75ceb21e96c258f289859a2996b60"
+SRC_URI[sha256sum] =
"a0e11645ee37c90b40c46d607070c4fd583e2cd46231b1c06e389c5e814eed76"
inherit pypi distutils3
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3-gitdb: update to version 2.0.4
Update to the latest stable release
Signed-off-by: Derek Straka
---
meta/recipes-devtools/python/python-gitdb.inc | 4 ++--
.../python/{python3-gitdb_2.0.3.bb => python3-gitdb_2.0.4.bb} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-gitdb_2.0.3.bb =>
python3-gitdb_2.0.4.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-gitdb.inc
b/meta/recipes-devtools/python/python-gitdb.inc
index 2d5292e..789ab95 100644
--- a/meta/recipes-devtools/python/python-gitdb.inc
+++ b/meta/recipes-devtools/python/python-gitdb.inc
@@ -8,8 +8,8 @@ inherit pypi
PYPI_PACKAGE = "gitdb2"
-SRC_URI[md5sum] = "d5217eb94ebd36fcec62b929d1f72b00"
-SRC_URI[sha256sum] =
"b60e29d4533e5e25bb50b7678bbc187c8f6bcff1344b4f293b2ba55c85795f09"
+SRC_URI[md5sum] = "6e21f5795a204f7afecb0a72fff66932"
+SRC_URI[sha256sum] =
"bb4c85b8a58531c51373c89f92163b92f30f81369605a67cd52d1fc21246c044"
DEPENDS = "${PYTHON_PN}-async ${PYTHON_PN}-setuptools-native
${PYTHON_PN}-smmap"
diff --git a/meta/recipes-devtools/python/python3-gitdb_2.0.3.bb
b/meta/recipes-devtools/python/python3-gitdb_2.0.4.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-gitdb_2.0.3.bb
rename to meta/recipes-devtools/python/python3-gitdb_2.0.4.bb
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] directfb: fix tslib version check in configure.in
Hi Richard, I already sent an updated version of the patch to the openembedded-de...@lists.openembedded.org mailing list because an automatic system informed me that I hit the wrong mailing list. I propose to switch to openembedded-devel for further discussions. [meta-oe,v2] directfb: fix tslib version check in configure.in https://patchwork.openembedded.org/patch/153470/ Sadly, there hasn't been any reaction yet. > > From: Guan Ben > > > > The patch makes sure that the old as well as the new tslib pkg-config > > metadata file naming style is handled correctly. > > > > tslib 0.0 to 1.0 created only a tslib-.pc pkg-config > > metadata > > file. > > > > With tslib 1.1 the tslib-.pc phase out was started. > > Additionally, the pkg-config metadata file tslib.pc was added. > > > > Since tslib 1.6 the tslib-.pc metadata file is deprecated. > > Now, there is only a tslib.pc. > > I'm a little confused about why OE needs this patch? Surely OE is using > the more recent tslib releases and therefore we don't need this patch? OE needs this patch because it uses DirectFB's build system and that is broken with the most recent tslib releases. In the beginning tslib only had a tslib-.pc for pkgconfig. Starting with tslib 1.1, tslib.pc and tslib-.pc were created for pkgconfig. And the tslib-.pc file was declared to be deprecated. From tslib 1.6 on only the tslib.pc file is available. DirectFB's configure.in is not aware that there is a situation without a tslib-.pc file. Thus it will not find tslib and this causes that the tslib input driver won't be built. DirectFB 1.7.7: enable_tslib=no if test "$checkfor_tslib" = "yes"; then PKG_CHECK_MODULES([TSLIB], [tslib-1.0 >= 1.0.0], [enable_tslib=yes], [enable_tslib=no]) if test "$enable_tslib" = "no"; then PKG_CHECK_MODULES([TSLIB], [tslib-0.0], [enable_tslib=yes], [enable_tslib=no AC_MSG_WARN([*** no tslib -- tslib driver will not be built.])]) fi fi Patched: enable_tslib=no if test "$checkfor_tslib" = "yes"; then PKG_CHECK_MODULES([TSLIB], [tslib >= 1.1], [enable_tslib=yes], [enable_tslib=no]) if test "$enable_tslib" = "no"; then PKG_CHECK_MODULES([TSLIB], [tslib-1.0 >= 1.0], [enable_tslib=yes], [enable_tslib=no]) if test "$enable_tslib" = "no"; then PKG_CHECK_MODULES([TSLIB], [tslib-0.0], [enable_tslib=yes], [enable_tslib=no AC_MSG_WARN([*** no tslib -- tslib driver will not be built.])]) fi fi fi Greetings, Mark Building Technologies, Panel Software Fire (BT-FIR/ENG1) Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118 Aufsichtsratsvorsitzender: Stefan Hartung; Geschäftsführung: Tanja Rückert, Andreas Bartz, Thomas Quante, Bernhard Schuster -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4] kernel-devsrc: restructure for out of tree (and on target) module builds
On Fri, Aug 17, 2018 at 1:53 AM, Richard Purdie wrote: > On Thu, 2018-08-16 at 22:44 +0100, richard.pur...@linuxfoundation.org > wrote: >> On Thu, 2018-08-16 at 17:08 -0400, Bruce Ashfield wrote: >> > I'm getting a strange install issue with x86 that I've never seen >> > before, and that >> > part is unchanged from v3 to v4. >> > >> > .. and then I realized that a file has changed in my builds, since >> > I'm >> > working on 4.18. >> > >> > This is worth testing on the autobuilder, but I will have a v5 that >> > adds a test for some >> > files that may go missing, and hence we'll have issues across >> > versions. >> >> Thanks, I've added it into a build with a glibc and openssl change >> and >> set it away so its possible other issues may occur, we'll see how it >> works out... > > The openssl change caused problems but I did spot qemumips64 failing: lttng was getting in the way of my mips testing, so I missed that one. I'll fix this and send a v5 today. Bruce > > NOTE: == > | NOTE: FAIL: test_kernel_module (kernelmodule.KernelModuleTest) > | NOTE: -- > | NOTE: Traceback (most recent call last): > | File > "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips64/build/meta/lib/oeqa/core/decorator/__init__.py", > line 32, in wrapped_f > | return func(*args, **kwargs) > | File > "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips64/build/meta/lib/oeqa/core/decorator/__init__.py", > line 32, in wrapped_f > | return func(*args, **kwargs) > | File > "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips64/build/meta/lib/oeqa/core/decorator/__init__.py", > line 32, in wrapped_f > | return func(*args, **kwargs) > | File > "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-mips64/build/meta/lib/oeqa/runtime/cases/kernelmodule.py", > line 40, in test_kernel_module > | self.assertEqual(status, 0, msg='\n'.join([cmd, output])) > | AssertionError: 2 != 0 : cd /usr/src/kernel && make scripts prepare > | HOSTCC scripts/basic/fixdep > | HOSTCC scripts/basic/bin2c > | HOSTCC scripts/kconfig/conf.o > | SHIPPED scripts/kconfig/zconf.tab.c > | SHIPPED scripts/kconfig/zconf.lex.c > | HOSTCC scripts/kconfig/zconf.tab.o > | In file included from scripts/kconfig/zconf.tab.c:2468: > | scripts/kconfig/confdata.c: In function 'conf_write': > | scripts/kconfig/confdata.c:773:19: warning: '%s' directive writing likely 7 > or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] > | sprintf(newname, "%s%s", dirname, basename); > |^~ > | scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 > bytes > | scripts/kconfig/confdata.c:773:2: note: 'sprintf' output 1 or more bytes > (assuming 4104) into a destination of size 4097 > | sprintf(newname, "%s%s", dirname, basename); > | ^~~ > | scripts/kconfig/confdata.c:776:20: warning: '.tmpconfig.' directive writing > 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] > |sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); > | ^ > | scripts/kconfig/confdata.c:776:3: note: 'sprintf' output between 13 and > 4119 bytes into a destination of size 4097 > |sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); > |^~~ > | HOSTLD scripts/kconfig/conf > | scripts/kconfig/conf --silentoldconfig Kconfig > | WRAParch/mips/include/generated/uapi/asm/ipcbuf.h > | WRAParch/mips/include/generated/asm/clkdev.h > | WRAParch/mips/include/generated/asm/current.h > | WRAParch/mips/include/generated/asm/dma-contiguous.h > | WRAParch/mips/include/generated/asm/emergency-restart.h > | WRAParch/mips/include/generated/asm/export.h > | WRAParch/mips/include/generated/asm/irq_work.h > | WRAParch/mips/include/generated/asm/local64.h > | WRAParch/mips/include/generated/asm/mcs_spinlock.h > | WRAParch/mips/include/generated/asm/mm-arch-hooks.h > | WRAParch/mips/include/generated/asm/parport.h > | WRAParch/mips/include/generated/asm/percpu.h > | WRAParch/mips/include/generated/asm/preempt.h > | WRAParch/mips/include/generated/asm/qrwlock.h > | WRAParch/mips/include/generated/asm/qspinlock.h > | WRAParch/mips/include/generated/asm/sections.h > | WRAParch/mips/include/generated/asm/segment.h > | WRAParch/mips/include/generated/asm/trace_clock.h > | WRAParch/mips/include/generated/asm/unaligned.h > | WRAParch/mips/include/generated/asm/user.h > | WRAParch/mips/include/generated/asm/word-at-a-time.h > | WRAParch/mips/include/generated/asm/xor.h > | HOSTCC scripts/dtc/dtc.o > | HOSTCC scripts/dtc/flattree.o > | HOSTCC scripts/dtc/fs
Re: [OE-core] [PATCH] sstate: Avoid indirect auto-archive-native dependencies (via SSTATE_EXCLUDEDEPS_SYSROOT)
Please update the summary and commit message "auto-" > "autoconf-"
On Fri, Aug 17, 2018 at 11:27 AM wrote:
> From: Changqing Li
>
> remove the indirect dependcy of auto-archive-native to avoid
> not needed .m4 installed into sysroot, which may cause
> compile problem.
>
> Signed-off-by: Changqing Li
> ---
> meta/conf/layer.conf | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
> index cc77d07..63346ae 100644
> --- a/meta/conf/layer.conf
> +++ b/meta/conf/layer.conf
> @@ -90,6 +90,8 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
> .*->.*-initial.* \
> .*(base-passwd|shadow-sysroot)->.* \
> "
> -
> +# Avoid adding autoconf-archive-native to sysroot without a specific
> +# dependency in the recipe.
> +SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
> # We need to keep bitbake tools in PATH
> PATH :=
> "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}"
> --
> 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] rpm: remove dbus depend for natove rpm
From: Changqing Li
remove dbus from rpm native, PACKAGECONFIG disable rpm
already there
Signed-off-by: Changqing Li
---
meta/recipes-devtools/rpm/rpm_4.14.1.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/rpm/rpm_4.14.1.bb
b/meta/recipes-devtools/rpm/rpm_4.14.1.bb
index e5e87d3..6d66a62 100644
--- a/meta/recipes-devtools/rpm/rpm_4.14.1.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.14.1.bb
@@ -50,8 +50,9 @@ SRCREV = "bfee1410af51c1cc9724791fb8d985260a62102b"
S = "${WORKDIR}/git"
-DEPENDS = "nss libarchive db file popt xz bzip2 dbus elfutils python3"
+DEPENDS = "nss libarchive db file popt xz bzip2 elfutils python3"
DEPENDS_append_class-native = " file-replacement-native
bzip2-replacement-native"
+DEPENDS_append_class-target = " dbus"
inherit autotools gettext pkgconfig python3native
export PYTHON_ABI
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sstate: Avoid indirect auto-archive-native dependencies (via SSTATE_EXCLUDEDEPS_SYSROOT)
From: Changqing Li
remove the indirect dependcy of auto-archive-native to avoid
not needed .m4 installed into sysroot, which may cause
compile problem.
Signed-off-by: Changqing Li
---
meta/conf/layer.conf | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index cc77d07..63346ae 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -90,6 +90,8 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
.*->.*-initial.* \
.*(base-passwd|shadow-sysroot)->.* \
"
-
+# Avoid adding autoconf-archive-native to sysroot without a specific
+# dependency in the recipe.
+SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
# We need to keep bitbake tools in PATH
PATH :=
"${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}:${HOSTTOOLS_DIR}"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] assimp.py: fix AttributeError in tearDownClass
*** BLURB HERE *** The following changes since commit 704e725bba37911e56ecd0edda694edfe9fce40f: runtime selftest: limit kernel hw bp arches (2018-08-16 22:40:28 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/assimp http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/assimp Chen Qi (1): assimp.py: fix AttributeError in tearDownClass meta/lib/oeqa/sdk/cases/assimp.py | 5 - 1 file changed, 5 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] assimp.py: fix AttributeError in tearDownClass
When running this test case, we will see the following error. AttributeError: type object 'BuildAssimp' has no attribute 'project' assimp.py test case does not make use of SDKBuildProject, so remove the import statement and the tearDownClass. Signed-off-by: Chen Qi --- meta/lib/oeqa/sdk/cases/assimp.py | 5 - 1 file changed, 5 deletions(-) diff --git a/meta/lib/oeqa/sdk/cases/assimp.py b/meta/lib/oeqa/sdk/cases/assimp.py index 7251bdf..26c1df0 100644 --- a/meta/lib/oeqa/sdk/cases/assimp.py +++ b/meta/lib/oeqa/sdk/cases/assimp.py @@ -1,7 +1,6 @@ import os, subprocess, unittest import bb from oeqa.sdk.case import OESDKTestCase -from oeqa.sdk.utils.sdkbuildproject import SDKBuildProject from oeqa.utils.subprocesstweak import errors_have_output errors_have_output() @@ -62,7 +61,3 @@ class BuildAssimp(OESDKTestCase): self.assertEqual(machine, elf.machine()) self.assertEqual(bits, elf.abiSize()) self.assertEqual(endian, elf.isLittleEndian()) - -@classmethod -def tearDownClass(self): -self.project.clean() -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] populate_sdk_base: only depend on nativesdk-glibc-locale when SDK_OS is not mingw32
When we add the nativesdk-glibc-locale dependence for libc-glibc, if the SDK_OS
is mingw32, it will broken the building with the following error:
>NOTE: Resolving any missing task queue dependencies
>ERROR: Nothing RPROVIDES 'nativesdk-glibc' (but
>virtual:nativesdk:layers/oe-core/meta/recipes-core/glibc/glibc-locale_2.24.bb
>RDEPENDS on or otherwise requires it)
>ERROR: nativesdk-glibc was skipped: PREFERRED_PROVIDER_virtual/nativesdk-libc
>set to nativesdk-mingw-w64-runtime, not nativesdk-glibc
>NOTE: Runtime target 'nativesdk-glibc' is unbuildable, removing...
>Missing or unbuildable dependency chain was: ['nativesdk-glibc']
>ERROR: Required build target 'meta-toolchain' has no buildable providers.
>Missing or unbuildable dependency chain was: ['meta-toolchain',
>'nativesdk-glibc-locale', 'nativesdk-glibc']
mingw32 SDK_OS doesn't need to depend on nativesdk-glibc-locale.
Signed-off-by: Zhixiong Chi
---
meta/classes/populate_sdk_base.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/populate_sdk_base.bbclass
b/meta/classes/populate_sdk_base.bbclass
index c456c52866..65c27b0077 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -48,7 +48,7 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native
nativesdk-qemuwrapper-cross ${@' '.join(["%s-qemuwrapper-cross" % m for m in
d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross"
PATH_prepend =
"${STAGING_DIR_HOST}${SDKPATHNATIVE}${bindir}/crossscripts:${@":".join(all_multilib_tune_values(d,
'STAGING_BINDIR_CROSS').split())}:"
-SDK_DEPENDS_append_libc-glibc = " nativesdk-glibc-locale"
+SDK_DEPENDS_append_libc-glibc = " ${@bb.utils.contains('SDK_OS', 'mingw32',
'', 'nativesdk-glibc-locale', d)}"
# We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not
PACKAGE_ARCH as it
# could be set to the MACHINE_ARCH
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2][V2] sdk: don't install glibc locales for mingw32
Signed-off-by: Zhixiong Chi
---
meta/lib/oe/sdk.py | 4
1 file changed, 4 insertions(+)
diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index 153b07d76b..5d7e4ed2ac 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -88,6 +88,10 @@ class Sdk(object, metaclass=ABCMeta):
if self.d.getVar("TCLIBC") != "glibc":
return
+# Don't install locales for mingw32 SDK_OS
+if self.d.getVar("SDK_OS") == "mingw32":
+return
+
linguas = self.d.getVar("SDKIMAGE_LINGUAS")
if linguas:
import fnmatch
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] sdk: don't install glibc locales for mingw32
Sorry for that, I will resend the v2 later.
Thanks.
On 2018年08月17日 16:29, Anuj Mittal wrote:
On 08/17/2018 12:29 PM, Zhixiong Chi wrote:
Signed-off-by: Zhixiong Chi > ---
meta/lib/oe/sdk.py | 4
1 file changed, 4 insertions(+)
diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
index 153b07d76b..5d7e4ed2ac 100644
--- a/meta/lib/oe/sdk.py
+++ b/meta/lib/oe/sdk.py
@@ -88,6 +88,10 @@ class Sdk(object, metaclass=ABCMeta):
if self.d.getVar("TCLIBC") != "glibc":
return
+# Don't install locales for mingw32 SDK_OS
+ if self.d.getVar("SDK_OS") == "mingw32":
+return
The alignment seems off here ...
File "../meta/lib/oe/sdk.py", line 138
if self.d.getVar("SDK_OS") == "mingw32":
^
TabError: inconsistent use of tabs and spaces in indentation
--
-
Thanks,
Zhixiong Chi
Tel: +86-10-8477-7036
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] sdk: don't install glibc locales for mingw32
On 08/17/2018 12:29 PM, Zhixiong Chi wrote:
> Signed-off-by: Zhixiong Chi > ---
> meta/lib/oe/sdk.py | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/meta/lib/oe/sdk.py b/meta/lib/oe/sdk.py
> index 153b07d76b..5d7e4ed2ac 100644
> --- a/meta/lib/oe/sdk.py
> +++ b/meta/lib/oe/sdk.py
> @@ -88,6 +88,10 @@ class Sdk(object, metaclass=ABCMeta):
> if self.d.getVar("TCLIBC") != "glibc":
> return
>
> +# Don't install locales for mingw32 SDK_OS
> + if self.d.getVar("SDK_OS") == "mingw32":
> +return
The alignment seems off here ...
File "../meta/lib/oe/sdk.py", line 138
if self.d.getVar("SDK_OS") == "mingw32":
^
TabError: inconsistent use of tabs and spaces in indentation
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] gnutls: Update to 3.6.3
On 08/17/2018 01:17 PM, Armin Kuster wrote:
> release notes:
> https://lists.gnupg.org/pipermail/gnutls-devel/2018-July/008584.html
>
> add ssl3 and tls1.3 config options now supported.
>
> Signed-off-by: Armin Kuster
> ---
> meta/recipes-support/gnutls/gnutls.inc | 2 ++
> .../gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} | 5 +++--
> 2 files changed, 5 insertions(+), 2 deletions(-)
> rename meta/recipes-support/gnutls/{gnutls_3.6.2.bb => gnutls_3.6.3.bb} (53%)
>
> diff --git a/meta/recipes-support/gnutls/gnutls.inc
> b/meta/recipes-support/gnutls/gnutls.inc
> index 04c0fd2af8..cf947d445e 100644
> --- a/meta/recipes-support/gnutls/gnutls.inc
> +++ b/meta/recipes-support/gnutls/gnutls.inc
> @@ -30,6 +30,8 @@ PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn2"
> PACKAGECONFIG[libtasn1] =
> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
> PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
> PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
> +PACKAGECONFIG[ssl3] = "--with-ssl3-support,--disable-ssl3-support,"
This should be --enable-ssl3-support ...
> +PACKAGECONFIG[tls13] = "--with-tls13-support,--disable-tls13-support,"
and, --enable-tls13-support.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] busybox: update to 1.29.1
ping
On 07/19/18 13:30, Andrej Valek wrote:
> - refresh busybox-udhcpc-no_deconfig.patch
> - remove obsolete patches which are included in this update
> - update defconfig
>
> Signed-off-by: Andrej Valek
> ---
> ...inittab_1.27.2.bb => busybox-inittab_1.29.1.bb} | 0
> .../busybox/busybox/CVE-2011-5325.patch| 481
> -
> .../busybox/busybox/CVE-2017-15873.patch | 95
> .../busybox/busybox/busybox-CVE-2017-16544.patch | 43 --
> .../busybox/busybox-fix-lzma-segfaults.patch | 106 -
> .../busybox/busybox-udhcpc-no_deconfig.patch | 48 +-
> meta/recipes-core/busybox/busybox/defconfig| 46 +-
> .../busybox/busybox/umount-ignore-c.patch | 40 --
> .../{busybox_1.27.2.bb => busybox_1.29.1.bb} | 9 +-
> 9 files changed, 66 insertions(+), 802 deletions(-)
> rename meta/recipes-core/busybox/{busybox-inittab_1.27.2.bb =>
> busybox-inittab_1.29.1.bb} (100%)
> delete mode 100755 meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
> delete mode 100644 meta/recipes-core/busybox/busybox/CVE-2017-15873.patch
> delete mode 100644
> meta/recipes-core/busybox/busybox/busybox-CVE-2017-16544.patch
> delete mode 100644
> meta/recipes-core/busybox/busybox/busybox-fix-lzma-segfaults.patch
> delete mode 100644 meta/recipes-core/busybox/busybox/umount-ignore-c.patch
> rename meta/recipes-core/busybox/{busybox_1.27.2.bb => busybox_1.29.1.bb}
> (82%)
>
> diff --git a/meta/recipes-core/busybox/busybox-inittab_1.27.2.bb
> b/meta/recipes-core/busybox/busybox-inittab_1.29.1.bb
> similarity index 100%
> rename from meta/recipes-core/busybox/busybox-inittab_1.27.2.bb
> rename to meta/recipes-core/busybox/busybox-inittab_1.29.1.bb
> diff --git a/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
> b/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
> deleted file mode 100755
> index 0926107bea..00
> --- a/meta/recipes-core/busybox/busybox/CVE-2011-5325.patch
> +++ /dev/null
> @@ -1,481 +0,0 @@
> -busybox-1.27.2: Fix CVE-2011-5325
> -
> -[No upstream tracking] -- https://bugs.busybox.net/show_bug.cgi?id=8411
> -
> -libarchive: do not extract unsafe symlinks
> -
> -Prevent unsafe links extracting unless env variable
> $EXTRACT_UNSAFE_SYMLINKS=1
> -is not set. Untarring file with -C DESTDIR parameter could be extracted with
> -unwanted symlinks. This doesn't feel right, and IIRC GNU tar doesn't do that.
> -Include necessary changes from previous commits.
> -
> -Upstream-Status: Backport
> [https://git.busybox.net/busybox/commit/?id=bc9bbeb2b81001e8731cd2ae501c8fccc8d87cc7]
> -CVE: CVE-2011-5325
> -bug: 8411
> -Signed-off-by: Radovan Scasny
> -Signed-off-by: Andrej Valek
> -
> -diff --git a/archival/libarchive/Kbuild.src b/archival/libarchive/Kbuild.src
> -index 942e755..e1a8a75 100644
> a/archival/libarchive/Kbuild.src
> -+++ b/archival/libarchive/Kbuild.src
> -@@ -12,6 +12,8 @@ COMMON_FILES:= \
> - data_extract_all.o \
> - data_extract_to_stdout.o \
> - \
> -+unsafe_symlink_target.o \
> -+\
> - filter_accept_all.o \
> - filter_accept_list.o \
> - filter_accept_reject_list.o \
> -diff --git a/archival/libarchive/data_extract_all.c
> b/archival/libarchive/data_extract_all.c
> -index 1830ffb..b828b65 100644
> a/archival/libarchive/data_extract_all.c
> -+++ b/archival/libarchive/data_extract_all.c
> -@@ -128,10 +128,9 @@ void FAST_FUNC data_extract_all(archive_handle_t
> *archive_handle)
> - res = link(hard_link, dst_name);
> - if (res != 0 && !(archive_handle->ah_flags &
> ARCHIVE_EXTRACT_QUIET)) {
> - /* shared message */
> --bb_perror_msg("can't create %slink "
> --"%s to %s", "hard",
> --dst_name,
> --hard_link);
> -+bb_perror_msg("can't create %slink '%s' to '%s'",
> -+ "hard", dst_name, hard_link
> -+);
> - }
> - /* Hardlinks have no separate mode/ownership, skip chown/chmod
> */
> - goto ret;
> -@@ -178,15 +177,17 @@ void FAST_FUNC data_extract_all(archive_handle_t
> *archive_handle)
> - case S_IFLNK:
> - /* Symlink */
> - //TODO: what if file_header->link_target == NULL (say, corrupted tarball?)
> --res = symlink(file_header->link_target, dst_name);
> --if (res != 0
> -- && !(archive_handle->ah_flags & ARCHIVE_EXTRACT_QUIET)
> --) {
> --/* shared message */
> --bb_perror_msg("can't create %slink "
> --"%s to %s", "sym",
> --dst_name,
> --file_header->link_target);
> -+if (!unsafe_symlink_target(file_header->link_target)) {
> -+res = symlink(file_header->link_target,
Re: [OE-core] ✗ patchtest: failure for "libxml2: fix CVE-2018-9251 and..." and 1 more
On 2018年08月17日 15:32, Patchwork wrote: == Series Details == Series: "libxml2: fix CVE-2018-9251 and..." and 1 more Revision: 1 URL : https://patchwork.openembedded.org/series/13574/ 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 in incorrect format [test_upstream_status_presence_format] Suggested fixFix Upstream-Status format in 0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch Current Upstream-Status: Cherry pick from upstream bugzilla [https://bugzilla.nasm.us/show_bug.cgi?id=3392447] Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] I am not sure which one to choose, the patch is not from upstream, but its bugzilla, so `Backport' is not accurate //Hongxu 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] expat: upgrade 2.2.5 -> 2.2.6
Signed-off-by: Yi Zhao
---
meta/recipes-core/expat/{expat_2.2.5.bb => expat_2.2.6.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-core/expat/{expat_2.2.5.bb => expat_2.2.6.bb} (82%)
diff --git a/meta/recipes-core/expat/expat_2.2.5.bb
b/meta/recipes-core/expat/expat_2.2.6.bb
similarity index 82%
rename from meta/recipes-core/expat/expat_2.2.5.bb
rename to meta/recipes-core/expat/expat_2.2.6.bb
index c68a2ef..c9e6081 100644
--- a/meta/recipes-core/expat/expat_2.2.5.bb
+++ b/meta/recipes-core/expat/expat_2.2.6.bb
@@ -11,8 +11,8 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \
file://libtool-tag.patch \
"
-SRC_URI[md5sum] = "789e297f547980fc9ecc036f9a070d49"
-SRC_URI[sha256sum] =
"d9dc32efba7e74f788fcc4f212a43216fc37cf5f23f4c2339664d473353aedf6"
+SRC_URI[md5sum] = "ca047ae951b40020ac831c28859161b2"
+SRC_URI[sha256sum] =
"17b43c2716d521369f82fc2dc70f359860e90fa440bea65b3b85f0b246ea81f2"
inherit autotools lib_package
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for "libxml2: fix CVE-2018-9251 and..." and 1 more
== Series Details == Series: "libxml2: fix CVE-2018-9251 and..." and 1 more Revision: 1 URL : https://patchwork.openembedded.org/series/13574/ 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 in incorrect format [test_upstream_status_presence_format] Suggested fixFix Upstream-Status format in 0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch Current Upstream-Status: Cherry pick from upstream bugzilla [https://bugzilla.nasm.us/show_bug.cgi?id=3392447] Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], 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 2/2] nasm: fix CVE-2018-8883 & CVE-2018-8882 & CVE-2018-10016 & CVE-2018-10316
Signed-off-by: Hongxu Jia
---
...t-we-are-not-reading-past-end-of-a-buffer.patch | 65 ++
...001-asm-eval.c-Avoid-possible-divide-by-0.patch | 40 +
.../0001-assemble-Check-global-line-limit.patch| 50 +
.../nasm/nasm/0001-fix-CVE-2018-8882.patch | 30 ++
meta/recipes-devtools/nasm/nasm_2.13.03.bb | 4 ++
5 files changed, 189 insertions(+)
create mode 100644
meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
create mode 100644
meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
create mode 100644
meta/recipes-devtools/nasm/nasm/0001-assemble-Check-global-line-limit.patch
create mode 100644 meta/recipes-devtools/nasm/nasm/0001-fix-CVE-2018-8882.patch
diff --git
a/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
new file mode 100644
index 000..cc755c2
--- /dev/null
+++
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
@@ -0,0 +1,65 @@
+From c5785fdf1d660eaefb9711284414262d0cfe8843 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Fri, 17 Aug 2018 14:48:17 +0800
+Subject: [PATCH] Verify that we are not reading past end of a buffer
+
+Simple reproducer is just,
+
+ret &d:ep
+
+which triggers a buffer overread due to parsing of an invalid
+segment override.
+
+Signed-off-by: Adam Majer
+
+Upstream-Status: Cherry pick from upstream bugzilla
[https://bugzilla.nasm.us/show_bug.cgi?id=3392447]
+CVE: CVE-2018-8883
+Signed-off-by: Hongxu Jia
+---
+ include/opflags.h | 2 +-
+ include/tables.h | 1 +
+ x86/regs.pl | 3 ++-
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/include/opflags.h b/include/opflags.h
+index ef2838c1..8d4b6b1e 100644
+--- a/include/opflags.h
b/include/opflags.h
+@@ -166,7 +166,7 @@
+ #define REG_CLASS_BND GEN_REG_CLASS(9)
+
+ #define is_class(class, op) (!((opflags_t)(class) & ~(opflags_t)(op)))
+-#define is_reg_class(class, reg)is_class((class), nasm_reg_flags[(reg)])
++#define is_reg_class(class, reg)is_class((class), ((reg) <
nasm_reg_flags_size ? nasm_reg_flags[(reg)] : 0))
+
+ #define IS_SREG(reg)is_reg_class(REG_SREG, (reg))
+ #define IS_FSGS(reg)is_reg_class(REG_FSGS, (reg))
+diff --git a/include/tables.h b/include/tables.h
+index 24a665e2..458752ce 100644
+--- a/include/tables.h
b/include/tables.h
+@@ -64,6 +64,7 @@ extern const char * const nasm_reg_names[];
+ typedef uint64_t opflags_t;
+ typedef uint16_t decoflags_t;
+ extern const opflags_t nasm_reg_flags[];
++extern const size_t nasm_reg_flags_size;
+ /* regvals.c */
+ extern const int nasm_regvals[];
+
+diff --git a/x86/regs.pl b/x86/regs.pl
+index 3a1b56f5..cb5cea68 100755
+--- a/x86/regs.pl
b/x86/regs.pl
+@@ -158,7 +158,8 @@ if ( $fmt eq 'h' ) {
+ printf "%-15s /* %-5s */\n",
+ $regs{$reg}.',', $reg;
+ }
+-print "};\n";
++print "};\n\n";
++print "const size_t nasm_reg_flags_size = sizeof(nasm_reg_flags) /
sizeof(opflags_t);\n";
+ } elsif ( $fmt eq 'vc' ) {
+ # Output regvals.c
+ print "/* automatically generated from $file - do not edit */\n\n";
+--
+2.17.1
+
diff --git
a/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
new file mode 100644
index 000..de450d2
--- /dev/null
+++
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
@@ -0,0 +1,40 @@
+From 8ad049cf9ccda2a5133a97506011862bcfc4a0c0 Mon Sep 17 00:00:00 2001
+From: Adam Majer
+Date: Fri, 17 Aug 2018 14:15:35 +0800
+Subject: [PATCH] asm/eval.c: Avoid possible divide by 0
+
+During a divide operation, we already tested that the
+divisor has is_simple, but then when testing it for 0,
+we again verify that it does not contain any unknown parts.
+This extra check prevents detection of cases when
+reloc_value returns 0.
+
+Use reloc_value instead in detection of 0 divisor.
+
+https://bugzilla.nasm.us/show_bug.cgi?id=3392473
+
+Signed-off-by: Adam Majer
+
+Upstream-Status: Cherry pick from upstream bugzilla
[https://bugzilla.nasm.us/show_bug.cgi?id=3392473]
+CVE: CVE-2018-10016
+Signed-off-by: Hongxu Jia
+---
+ asm/eval.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/asm/eval.c b/asm/eval.c
+index 816983b9..57c598c5 100644
+--- a/asm/eval.c
b/asm/eval.c
+@@ -585,7 +585,7 @@ static expr *expr5(int critical)
+ " scalar values");
+ return NULL;
+ }
+-if (j != '*' && !is_unknown(f) && reloc_value(f) == 0) {
++if (j != '*' && reloc_value(f) == 0) {
+ nasm_error(ERR_NONFATAL, "division by zero");
+ return NULL;
+
[OE-core] [PATCH 1/2] libxml2: fix CVE-2018-9251 and CVE-2018-14567
Signed-off-by: Hongxu Jia
---
...1-Fix-infinite-loop-in-LZMA-decompression.patch | 55 ++
meta/recipes-core/libxml/libxml2_2.9.8.bb | 1 +
2 files changed, 56 insertions(+)
create mode 100644
meta/recipes-core/libxml/libxml2/0001-Fix-infinite-loop-in-LZMA-decompression.patch
diff --git
a/meta/recipes-core/libxml/libxml2/0001-Fix-infinite-loop-in-LZMA-decompression.patch
b/meta/recipes-core/libxml/libxml2/0001-Fix-infinite-loop-in-LZMA-decompression.patch
new file mode 100644
index 000..16c2295
--- /dev/null
+++
b/meta/recipes-core/libxml/libxml2/0001-Fix-infinite-loop-in-LZMA-decompression.patch
@@ -0,0 +1,55 @@
+From 28a9dc642ffd759df1e48be247a114f440a6c16e Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Mon, 30 Jul 2018 13:14:11 +0200
+Subject: [PATCH] Fix infinite loop in LZMA decompression
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Check the liblzma error code more thoroughly to avoid infinite loops.
+
+Closes: https://gitlab.gnome.org/GNOME/libxml2/issues/13
+Closes: https://bugzilla.gnome.org/show_bug.cgi?id=794914
+
+This is CVE-2018-9251 and CVE-2018-14567.
+
+Thanks to Dongliang Mu and Simon Wörner for the reports.
+
+CVE: CVE-2018-9251
+CVE: CVE-2018-14567
+Upstream-Status: Backport
[https://gitlab.gnome.org/GNOME/libxml2/commit/2240fbf5912054af025fb6e01e26375100275e74]
+Signed-off-by: Hongxu Jia
+---
+ xzlib.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/xzlib.c b/xzlib.c
+index a839169..0ba88cf 100644
+--- a/xzlib.c
b/xzlib.c
+@@ -562,6 +562,10 @@ xz_decomp(xz_statep state)
+ "internal error: inflate stream corrupt");
+ return -1;
+ }
++/*
++ * FIXME: Remapping a couple of error codes and falling through
++ * to the LZMA error handling looks fragile.
++ */
+ if (ret == Z_MEM_ERROR)
+ ret = LZMA_MEM_ERROR;
+ if (ret == Z_DATA_ERROR)
+@@ -587,6 +591,11 @@ xz_decomp(xz_statep state)
+ xz_error(state, LZMA_PROG_ERROR, "compression error");
+ return -1;
+ }
++if ((state->how != GZIP) &&
++(ret != LZMA_OK) && (ret != LZMA_STREAM_END)) {
++xz_error(state, ret, "lzma error");
++return -1;
++}
+ } while (strm->avail_out && ret != LZMA_STREAM_END);
+
+ /* update available output and crc check value */
+--
+2.7.4
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.8.bb
b/meta/recipes-core/libxml/libxml2_2.9.8.bb
index 4ebd2ef..f01cb2c 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.8.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.8.bb
@@ -22,6 +22,7 @@ SRC_URI =
"http://www.xmlsoft.org/sources/libxml2-${PV}.tar.gz;name=libtar \
file://fix-execution-of-ptests.patch \
file://fix-CVE-2017-8872.patch \
file://fix-CVE-2018-14404.patch \
+ file://0001-Fix-infinite-loop-in-LZMA-decompression.patch \
"
SRC_URI[libtar.md5sum] = "b786e353e2aa1b872d70d5d1ca0c740d"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
