Yes, you are correct. White listing isn't right either.
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Mar 12, 2020 at 12:25:21PM +, Mittal, Anuj wrote:
> It looks like this is changing the API. I wonder if this would need any
> other change or break something elsewhere in OE-core, meta-oe?
>
> http://aspell.net/buffer-overread-ucs.txt
Debian classified issues as minor and fixed only b
On Mon, Mar 02, 2020 at 07:40:35AM -0500, rpj...@crashcourse.ca wrote:
> layer i'm currently perusing has many, many bbappend files, of which
> quite a number are nothing more than the single line:
>
> BBCLASSEXTEND += "nativesdk"
>
> literally, at least a hundred append files are like that. so
On Tue, Feb 18, 2020 at 08:43:01PM +1100, JH wrote:
> Hi Mikko,
>
> On 2/18/20, mikko.rap...@bmw.de wrote:
> > I think you may be missing volatile-binds package and service from your
> > image.
> > See poky/meta/recipes-core/volatile-binds/volatile-binds.bb
>
> I got the source in my build syste
(trimming lists to yocto only)
Hi,
I think you may be missing volatile-binds package and service from your image.
See poky/meta/recipes-core/volatile-binds/volatile-binds.bb
It may be missing /var/log but with systemd there should not be needs to write
to that location after image builds...
-Mi
Hi,
slightly off topic but I was checking CVEs for sqlite3 and noticed
this recipe uses the merged source tree format. This makes it very
hard to cherry-pick CVE and other patches from Debian, Ubuntu,
OpenSUSE etc.
Why use sqlite sources in "amalgamation" format?
https://sqlite.org/amalgamation.
On Tue, Jan 21, 2020 at 07:28:44PM +0100, Pierre-Jean Texier via
Openembedded-core wrote:
> License-Update: add GPLv3 text
Which parts of util-linux are now licensed with GPLv3?
-Mikko
> Drop upstreamed patch
>
> See full changelog
> https://lore.kernel.org/util-linux/20200121105711.zzeeolydl
This fixes the crash I was seeing too.
While debugging it, I noticed that host valgrind was not able to work with
yocto host tools and I had to build native valgrind which needed
some patches and workarounds. Will try to submit them...
Thanks for fixing this!
-Mikko
--
_
On Wed, Nov 20, 2019 at 03:53:14PM -0800, Andre McCurdy wrote:
> But anyway, in all cases, the way to debug what's going on isn't to
> try random recipe changes and then rebuild the final image. Instead
> you should build your chosen version of openssl, look in the
> packages-split directory to see
On Thu, Nov 21, 2019 at 01:05:55AM +0200, Adrian Bunk wrote:
> On Wed, Nov 20, 2019 at 09:39:51PM +, mikko.rap...@bmw.de wrote:
> >...
> > I could submit these too if someone wants to setup a communit maintenance
> > branch for sumo.
>
> I would not consider this appropriate for a stable bran
On Wed, Nov 20, 2019 at 06:18:05PM +, Ryan Harkin wrote:
> I'm struggling with backporting OpenSSL to my Sumo build [1], so wondered
> if anyone else had done something similar with success.
I've done it by backporting following changes to poky (sorry for subject only):
openssh: upgrade 7.6p1
Hi,
On Tue, Nov 19, 2019 at 03:21:22PM +, nick83ola wrote:
> Dear Openembedded developer,
>
> a lot of python recipes need to add the
>
> BBCLASSEXTEND = "native nativesdk"
>
> To the recipe to build the native version of the package.
> Wouldn't be better to add it to the pythonnative.bbcla
On Sun, Nov 17, 2019 at 10:19:32PM +0100, Alexander Kanavin wrote:
> I'd write the date into the file at image creation, via
> ROOTFS_POSTPROCESS_COMMAND.
>
> Having it in a recipe means that you either force the recipe to not be a
> part of sstate cache, always rebuilding it and its dependencies
On Wed, Nov 13, 2019 at 07:48:34AM -0800, akuster808 wrote:
> Hello,
>
> Reading through the 2019 OEDeM minutes, I saw a statement regarding a
> more regular update frequency on the stable branches. Based on Richard's
> response I could not tell if it is regarding merge frequency to
> mainline or
Hi,
On Thu, Nov 07, 2019 at 10:41:42AM +, Ryan Harkin wrote:
> Not sure if it helps, but I have a Jenkins job that tests sumo on a trigger
> (there is one for Warrior also):
>
> https://ci.linaro.org/job/warp7-openembedded-sumo/
>
> eg. it was triggered when Armin's patch was merged yesterd
On Thu, Nov 07, 2019 at 10:54:23AM +, Ross Burton wrote:
> On 07/11/2019 08:13, Mikko Rapeli wrote:
> > harfbuzz binary package size increased from 624608 bytes in yocto 2.5 to
> > 1365431 bytes in yocto 3.0. Most of the size increase is in the new
> > libharfbuzz-subset.so* library, which base
Hi,
On Thu, Nov 07, 2019 at 01:13:32PM +0200, Adrian Bunk wrote:
> On Wed, Nov 06, 2019 at 05:37:15PM +0200, Mikko Rapeli wrote:
> > Hi,
>
> Hi Mikko,
>
> >...
> > I use sumo and due to various reasons like BSP layers, binary
> > compatibility, contracts etc can't update to newer release
> > or
Hi,
On Wed, Nov 06, 2019 at 01:46:09PM -0800, akuster808 wrote:
> Hello Mikko;
> I have collected other patches for sumo and built them locally but I
> have no way to inform Richard they pass an AB builds or automated
> testing for them to get into mainline sumo.
>
> I am placing them into
>
Hi,
On Wed, Nov 06, 2019 at 05:53:27PM +, Richard Purdie wrote:
> On Wed, 2019-11-06 at 16:06 +, mikko.rap...@bmw.de wrote:
> > Hi,
> >
> > On Wed, Nov 06, 2019 at 02:59:16PM +, Ryan Harkin wrote:
> > > Hi Ross/Richard,
> > >
> > > I'd like this applied to Sumo also. Should I create
Hi,
On Wed, Nov 06, 2019 at 02:59:16PM +, Ryan Harkin wrote:
> Hi Ross/Richard,
>
> I'd like this applied to Sumo also. Should I create a new patch and send it
> to the list, or is there a process for requesting this is cherry-picked
> across?
I just posted the port of this and all other CVE
On Wed, Oct 16, 2019 at 12:45:20PM +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org > core-boun...@lists.openembedded.org> On Behalf Of Mikko Rapeli
> > Sent: den 16 oktober 2019 14:32
> > To: openembedded-core@lists.openemb
On Wed, Oct 09, 2019 at 09:41:28PM +0200, Alexander Kanavin wrote:
> It wouldn't be too hard to add a condition that checks the (image-specific)
> whitelist, I just wanted to gather a bit of feedback for the overall idea :)
I like the idea. I'm building images with e.g. GPLv3 forbidden but I enabl
On Fri, Sep 20, 2019 at 03:13:44PM +0200, Andrey Zhizhikin wrote:
> Hello Raj,
>
> On Tue, Sep 17, 2019 at 8:50 PM Khem Raj wrote:
> >
> > with openSSL 1.1.1d we start seeing errors like
> >
> > Error Generating Key
> > 139979727451584:error:2406C06E:random number
> > generator:RAND_DRBG_instant
Looks ok, though I would consider updating to point releases or latest
versions of the gcc-8 stable tree, where these patches are already backported
by upstream developers. The 8.3 update does not have this CVE patch, but
a lot of bug fixes which should be useful for gcc 8 users.
Reviewed-by: Mikk
On Mon, Sep 16, 2019 at 08:37:28PM +, Muminul Islam wrote:
> Signed-off-by: Muminul Islam
> ---
> meta/recipes-devtools/gcc/gcc-8.2.inc | 2 +
> .../gcc/gcc/0042-CVE-2019-15847_1.patch | 570
> .../gcc/gcc/0043-CVE-2019-15847_2.patch | 640 ++
Hi,
On Mon, Sep 16, 2019 at 01:37:25PM +0100, Ross Burton wrote:
> Hi Mikko,
>
> This is 1/2 but 2/2 never arrived on the list. Can you repost it?
Sorry, 2/2 from my poky tree was the bitbake svn fetcher patch in
http://lists.openembedded.org/pipermail/bitbake-devel/2019-September/020328.html
On Fri, Sep 06, 2019 at 10:03:14AM +0100, Ross Burton wrote:
> On 06/09/2019 09:02, mikko.rap...@bmw.de wrote:
> > Could this be enabled automatically when local.conf has INHERIT +=
> > "reproducible_build" ?
>
> The default behaviour is to respect that if enabled, otherwise use the
> upstream de
On Fri, Sep 06, 2019 at 12:07:06AM +0100, Ross Burton wrote:
> systemd has the ability to check the time on boot and if it's earlier than an
> epoch determined at build time, set the time to that epoch. This is useful
> for
> systems where the system time is January 1st 1970 (because the unix tim
On Mon, Sep 02, 2019 at 02:33:02PM -0700, akuster808 wrote:
>
>
> On 9/2/19 5:40 AM, Adrian Bunk wrote:
> > On Sun, Sep 01, 2019 at 10:07:13AM -0700, akuster808 wrote:
> >>
> >> On 9/1/19 7:05 AM, Adrian Bunk wrote:
> >>> thud and zeus are providing 2 gcc versions each that need fixing.
> >> That
On Wed, Aug 14, 2019 at 03:38:56PM +0100, Richard Purdie wrote:
> On Wed, 2019-08-14 at 15:56 +0300, Mikko Rapeli wrote:
> > Since stress-ng replaces and is compatible with stress,
> > provide stress to be compatible with the old recipe
> > and binary packages.
> >
> > Signed-off-by: Mikko Rapeli
On Wed, Aug 14, 2019 at 02:08:01PM +0200, Alexander Kanavin wrote:
> On Wed, 14 Aug 2019 at 13:36, wrote:
>
> > On Wed, 2019-08-14 at 13:25 +0200, Alexander Kanavin wrote:
> > > On Tue, 13 Aug 2019 at 21:18, Richard Purdie <
> > > richard.pur...@linuxfoundation.org> wrote:
> > > > I had a glance
Hi,
On Fri, Aug 02, 2019 at 05:17:21PM +0100, Richard Purdie wrote:
> On Fri, 2019-08-02 at 16:53 +0100, Richard Purdie wrote:
> > With the patches in master-next and this configuration in local.conf:
> >
> > BB_HASHSERVE = "localhost:0"
> > BB_SIGNATURE_HANDLER = "OEEquivHash"
> >
> > $ bitbake
On Fri, Aug 02, 2019 at 11:21:24AM +0100, Ross Burton wrote:
> On 02/08/2019 11:24, Robert Yang wrote:
> > There might be processes left after Ctr-C, e.g.:
> > $ rm -f tmp/cache/default-glibc/qemux86/x86_64/
> > $ bitbake -p
> >
> > Press 'Ctrl-C' multiple times during parsing, then bitbake proces
Hi,
On Thu, Aug 01, 2019 at 04:51:38PM +, chris.laplante--- via
Openembedded-core wrote:
> I'm interesting in adding SRC_URI support to buildhistory (or a similar
> mechanism), and would like to get some input.
Yes to this.
Also would be nice if there was an easy way to add bitbake variab
On Wed, Jul 17, 2019 at 12:44:54PM +0100, Richard Purdie wrote:
> On Wed, 2019-07-17 at 12:08 +0300, Mikko Rapeli wrote:
> > While creating and deleting files with unicode or other
> > encodings works, it's annoying when ls and other core utils
> > show questionmarks instead of the unicode characte
On Wed, Jul 03, 2019 at 11:04:06AM -0400, Trevor Woerner wrote:
> Hi,
>
> This came up as a topic in yesterday's Engineering Sync meeting. For roughly a
> year I've been seeing random build failures on my Jenkins setup due to pigz
> failing; apparently the project is now seeing them on their build
On Fri, Jun 21, 2019 at 01:29:18PM +0100, Burton, Ross wrote:
> On Fri, 21 Jun 2019 at 12:11, wrote:
> > This adds python3 urllib3 (python3-urllib3 in Debian) to build environment
> > dependencies. It's the first user of urllib3 in poky, AFAIK. Maybe
> > documentation could be updated too, e.g.
>
On Fri, Jun 21, 2019 at 02:03:36PM +0200, Alexander Kanavin wrote:
> On Fri, 21 Jun 2019 at 13:48, wrote:
>
> >
> > Hmm, possibly? I cherry-picked the patches to sumo and saw this missing
> > dependency in my container.
> >
> > Did poky master switch from using host python to native after sumo?
>
On Fri, Jun 21, 2019 at 01:42:11PM +0200, Alexander Kanavin wrote:
> On Fri, 21 Jun 2019 at 13:11, wrote:
>
> > This adds python3 urllib3 (python3-urllib3 in Debian) to build environment
> > dependencies. It's the first user of urllib3 in poky, AFAIK. Maybe
> > documentation could be updated too,
Hi,
This adds python3 urllib3 (python3-urllib3 in Debian) to build environment
dependencies. It's the first user of urllib3 in poky, AFAIK. Maybe
documentation could be updated too, e.g.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#brief-build-system-packages
On my Debian
Hi,
On Wed, May 15, 2019 at 12:53:44PM +0200, Martin Jansa wrote:
> Can we restore meta/files/common-licenses/Elfutils-Exception in oe-core to
> be used by meta-gplv2 version:
>
> recipes-devtools/elfutils/elfutils_0.148.bb:LICENSE = "(GPL-2+ &
> Elfutils-Exception)"
> causing:
> do_rootfs: The l
On Tue, May 14, 2019 at 10:56:04PM +0100, Richard Purdie wrote:
> Many different ptests are breaking as they assume that ${PN}-ptest
> depends on ${PN}. It doesn't currently but should. If we fix this, many
> different ptests start passing when they previously failed.
>
> It does depend on fixing
On Fri, May 10, 2019 at 01:18:21PM +0100, Burton, Ross wrote:
> I'm very dubious of the need to make this a dependency, as the
> hardware RNG should be used. Note that there's been a slew of fixes
> to the kernel to enable this with modern stacks, for example:
>
> https://github.com/torvalds/linu
On Wed, May 08, 2019 at 06:50:54PM +0300, Mark Hatle wrote:
> On 5/8/19 5:22 PM, mikko.rap...@bmw.de wrote:
> > On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:
> >> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:
> >>> Since openssl 1.1.1 and openssh which uses it, sshd
>
On Wed, May 08, 2019 at 05:07:08PM +0300, Adrian Bunk wrote:
> On Wed, May 08, 2019 at 04:26:09PM +0300, Mikko Rapeli wrote:
> > Since openssl 1.1.1 and openssh which uses it, sshd
> > startup is delayed. The delays range from few seconds
> > to minutes and even to hours. The delays are visible
> >
On Wed, May 08, 2019 at 08:41:21AM -0500, Joshua Watt wrote:
> On Wed, 2019-05-08 at 16:26 +0300, Mikko Rapeli wrote:
> > The commands only work with with bash. If /bin/sh is
> > dash like in Debian, the command execution fails with
> > errors like:
>
> This might possibly be related to
> https:/
On Thu, Apr 11, 2019 at 10:45:21AM -0500, Mark Hatle wrote:
> On 4/11/19 8:41 AM, Mikko Rapeli wrote:
> > Elfutils-Exception no longer exists after upstream release 0.154
> > and commit:
> >
> > commit de2ed97f33139af5c7a0811e4ec66fc896a13cf2
> > Author: Mark Wielaard
> > Date: Tue Jun 5 17:15:
Sorry, this wasn't rebased to latest master with elfutils 0.176. I'll rebase
and resend.
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Apr 11, 2019 at 10:40:43AM +,
openembedded-core-boun...@lists.openembedded.org wrote:
> On Thu, Apr 11, 2019 at 12:48:40PM +0300, Mikko Rapeli wrote:
> > NEWS file in the sources says this about switch from GPLv2 to
> > GPLv3 license:
> >
> > https://sourceware.org/git/?p=elfutils.git
On Thu, Apr 11, 2019 at 12:48:40PM +0300, Mikko Rapeli wrote:
> NEWS file in the sources says this about switch from GPLv2 to
> GPLv3 license:
>
> https://sourceware.org/git/?p=elfutils.git;a=blob;f=NEWS;h=5a06047f255e3c9a63828953759fd18a4ba9a3f3;hb=HEAD#l362
>
> 362 The license is now GPLv2/LGP
On Mon, Mar 18, 2019 at 06:03:05PM +0100, Andreas Müller wrote:
> On Mon, Mar 18, 2019 at 5:45 PM Armin Kuster wrote:
> >
> > This reverts commit a384248938ea9db096866bf4ec8678d35ca62a12.
> >
> > This package update slipped in doing the maint process. Removing it.
> Just my opinion - don't consid
On Mon, Feb 11, 2019 at 12:08:46PM +, André Draszik wrote:
> Please ignore this patch. Looks like a red-herring. Sorry for the noise.
FWIW, I would like to see this patch merged. Had some issues in the past
with busybox umount and added same change as a bbappend.
-Mikko
> On Mon, 2019-02-11
On Tue, Jan 08, 2019 at 11:36:24AM +0100, Jacob Kroon wrote:
> On Tue, Jan 8, 2019 at 11:32 AM wrote:
> >
> > On Mon, Jan 07, 2019 at 03:17:00PM +0100, Jacob Kroon wrote:
> > > On Sun, Jan 6, 2019 at 7:14 PM Jacob Kroon wrote:
> > > >
> > > > Introduce 'md5' in BUILDHISTORY_FEATURES and enable it
On Mon, Jan 07, 2019 at 03:17:00PM +0100, Jacob Kroon wrote:
> On Sun, Jan 6, 2019 at 7:14 PM Jacob Kroon wrote:
> >
> > Introduce 'md5' in BUILDHISTORY_FEATURES and enable it by default
> > when doing reproducible builds.
> >
> > When enabled this will additionally create:
> >
> > files-in-pack
On Thu, Nov 29, 2018 at 02:04:14PM +, Richard Purdie wrote:
> On Thu, 2018-11-29 at 14:21 +0200, Mikko Rapeli wrote:
> > If IMAGE_ROOTFS_SIZE_LIMIT is defined in image configuration, then
> > build will fail if for tar image type the uncompressed tar ball size
> > exceeds the value, as reported
On Tue, Sep 25, 2018 at 07:29:22PM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Tue, 2018-09-25 at 17:11 +, mikko.rap...@bmw.de wrote:
> > On Tue, Sep 25, 2018 at 04:19:39PM +0100, richard.purdie@linuxfoundat
> > ion.org wrote:
> > > On Tue, 2018-09-25 at 11:21 +, mikko.rap...@bmw
On Tue, Sep 25, 2018 at 04:19:39PM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Tue, 2018-09-25 at 11:21 +, mikko.rap...@bmw.de wrote:
> > On Tue, Sep 25, 2018 at 12:08:24PM +0100, Richard Purdie wrote:
> > > I suspect we need to talk to cmake upstream about fixing this
> > > properly
On Tue, Sep 25, 2018 at 12:08:24PM +0100, Richard Purdie wrote:
> On Tue, 2018-09-25 at 10:44 +, mikko.rap...@bmw.de wrote:
> > On Tue, Sep 25, 2018 at 01:28:13PM +0300, Mikko Rapeli wrote:
> > > And enable them by default as ERROR_QA. Reason is that
> > > absolute build directory paths in CMak
On Tue, Sep 25, 2018 at 01:28:13PM +0300, Mikko Rapeli wrote:
> And enable them by default as ERROR_QA. Reason is that
> absolute build directory paths in CMake .cmake modules
> and in pkg-config .pc files cause recipe builds to escape
> their recipe specific sysroots and triggers hard to debug
> a
On Mon, Sep 24, 2018 at 02:56:49PM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Mon, 2018-09-24 at 09:43 -0400, Bruce Ashfield wrote:
> > > On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> > > > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > > > On Mo
On Mon, Sep 24, 2018 at 09:48:26AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 9:46 AM, Bruce Ashfield
> wrote:
> > On Mon, Sep 24, 2018 at 9:44 AM,
> > wrote:
> >> On Mon, 2018-09-24 at 13:42 +, mikko.rap...@bmw.de wrote:
> >>> On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.p
On Mon, Sep 24, 2018 at 02:38:36PM +0100, richard.pur...@linuxfoundation.org
wrote:
> On Mon, 2018-09-24 at 13:20 +, mikko.rap...@bmw.de wrote:
> > On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> > > On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > > > That
On Mon, Sep 24, 2018 at 02:11:13PM +0100, Richard Purdie wrote:
> On Mon, 2018-09-24 at 12:19 +, mikko.rap...@bmw.de wrote:
> > > That was one old way, but not the only. And not for exposing non
> > > uapi
> > > headers.
> >
> > What other ways exist?
> >
> > I don't care how, but I must expo
On Mon, Sep 24, 2018 at 08:12:53AM -0400, Bruce Ashfield wrote:
> On Mon, Sep 24, 2018 at 3:25 AM, wrote:
> >> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli
> >> wrote:
> >> > This change enables kernel recipes to share files with other
> >> > recipes. Firmware, modules and kernel-depmod are st
> On Fri, Sep 21, 2018 at 7:49 AM, Mikko Rapeli wrote:
> > This change enables kernel recipes to share files with other
> > recipes. Firmware, modules and kernel-depmod are still not shared
> > since according to git history they cause problems with multiarch,
> > but all others are allowed. Examp
On Fri, Sep 21, 2018 at 04:41:50PM +, Peter Kjellerstedt wrote:
> > diff --git a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > b/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
> > index b7297fc..f09782c 100644
> > --- a/meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb
>
On Fri, Aug 24, 2018 at 09:23:45AM -0700, Khem Raj wrote:
> On Fri, Aug 24, 2018 at 9:17 AM wrote:
> >
> > On Fri, Aug 24, 2018 at 08:51:42AM -0700, Khem Raj wrote:
> > > On Fri, Aug 24, 2018 at 8:48 AM wrote:
> > > > So to me it looks like using SYSTEM with target_include_directories()
> > > > i
On Fri, Aug 24, 2018 at 08:51:42AM -0700, Khem Raj wrote:
> On Fri, Aug 24, 2018 at 8:48 AM wrote:
> > So to me it looks like using SYSTEM with target_include_directories()
> > is no longer possible with CMake and gcc > 6:
> >
> >
> > https://cmake.org/cmake/help/v3.10/command/target_include_direc
On Fri, Aug 24, 2018 at 03:10:28PM +, Bach, Pascal wrote:
>
> > > Fixes problems which we have also seen on sumo branch. Thanks for this!
> >
> > Sorry, spoke too soon. This fixes compilation on a few recipes in my tree
> > but
> > there are still lots failures with the same error message.
> Fixes problems which we have also seen on sumo branch. Thanks for this!
Sorry, spoke too soon. This fixes compilation on a few recipes in my tree
but there are still lots failures with the same error message. We had a hacky
patch to cmake as a workaround but that too causes some problems:
--- a
On Fri, Aug 24, 2018 at 02:33:46PM +0200, Pascal Bach wrote:
> This already got fixed in the toolchain file that is used during development
> in
> https://github.com/openembedded/openembedded-core/commit/cb42802f2fe1760f894a435b07286bca3a220364
>
> The toolchain file generated by the cmake.bbclas
Martin Jansa wrote:
> I think this will break support for older kernels added in:
> http://git.openembedded.org/openembedded-core/commit/?id=19fb2d11a8bb3c6dfdd5edc1b9155d642dc0f5e0
>
> kernel-source/tools/arch and kernel-source/tools/build are missing in 3.16
> kernel even when it's not completel
On Mon, Aug 13, 2018 at 10:23:28AM +0300, Konstantin Shemyak wrote:
> Disable downloading of the vulnerability DB in do_check_cves() task.
>
> When invoked in this task, cve-check-tool attempts re-download of the CVE DB
> if the latter is older than certain threshold. While reasonable for a
> stan
On Fri, Aug 03, 2018 at 10:37:05PM +, Grygorii Tertychnyi (gtertych) via
Openembedded-core wrote:
> cvert-kernel - generate CVE report for the Linux kernel.
> NVD entries for the Linux kernel is almost always outdated.
> For example, https://nvd.nist.gov/vuln/detail/CVE-2018-1065
> is sh
Yes, we have been affected by this several times too.
In addition to fixing recipes, a sanity test to warn about the situation
would be nice to have so that the issue could be detected in other
meta layers too.
-Mikko
--
___
Openembedded-core mailing l
On Wed, Sep 06, 2017 at 12:14:48PM +, mikko.rap...@bmw.de wrote:
> On Wed, Sep 06, 2017 at 11:34:54AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: "gitsm.py: use download cache f..." and 2 more
> > Revision: 1
> > URL : https://patchwork.openembedded.org/series/8734/
> >
On Wed, Sep 06, 2017 at 11:34:54AM +, Patchwork wrote:
> == Series Details ==
>
> Series: "gitsm.py: use download cache f..." and 2 more
> Revision: 1
> URL : https://patchwork.openembedded.org/series/8734/
> State : failure
>
> == Summary ==
>
>
> Thank you for submitting this patch seri
On Thu, Jul 20, 2017 at 04:22:49PM +0300, Mikko Rapeli wrote:
> LICENSE can be used in various checks after builds. Reading license data
> from buildhistory is better than trying to parse recipes in a source tree.
>
> CVE_PRODUCT can be used by scripts to e.g. check if it matches to the
> CVE prod
On Thu, Jul 20, 2017 at 04:22:50PM +0300, Mikko Rapeli wrote:
> Setting BUILDHISTORY_FORCE_UPDATE = "1" in local.conf forces buildhistory
> updates and recipe rebuilds also when only buildhistory.bbclass changed.
>
> This is handy when using sstate cache and modifying buildhistory to include
> new
On Fri, Jun 23, 2017 at 04:20:41PM -0700, Khem Raj wrote:
> On Fri, Jun 23, 2017 at 7:17 AM, wrote:
> > Hi,
> >
> > I'm chipping in since I've been messing with these things a bit in upstream
> > Linux kernel.
> >
> > On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote:
> >> On Fri, Jun 23,
Hi,
I'm chipping in since I've been messing with these things a bit in upstream
Linux kernel.
On Fri, Jun 23, 2017 at 06:37:52AM -0700, Khem Raj wrote:
> On Fri, Jun 23, 2017 at 3:46 AM, André Draszik wrote:
> > connman is not doing anything wrong here.
> >
>
> yes I am aware of this
>
> > The
On Thu, Jun 22, 2017 at 01:38:15PM +0100, Burton, Ross wrote:
> On 20 June 2017 at 13:48, wrote:
>
> > The bitbake and scripts parts from this patch series were merged already,
> > but
> > this not.
> >
> > Are there problems with this patch?
> >
>
> Sorry, didn't get around to replying. It doe
Hi,
On Thu, Jun 01, 2017 at 06:53:14PM +0300, Mikko Rapeli wrote:
> Python function subprocess.call() returns the return value of the
> executed process. If return values are not checked, errors may
> go unnoticed and bad things can happen.
>
> Change all callers of subprocess.call() which do not
Hmm, do I need to rebase the patches from yocto to upstream
bitbake and meta-poky git trees?
-Mikko
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Thu, Jun 01, 2017 at 01:40:10PM +0100, Burton, Ross wrote:
> On 19 May 2017 at 08:17, Mikko Rapeli wrote:
>
> > bitbake/lib/bb/ui/ncurses.py | 2 +-
> > bitbake/lib/bb/utils.py | 2 +-
> > meta/classes/archiver.bbclass| 2 +-
> > meta/classes/cml1.bbcl
Hi,
On Fri, May 19, 2017 at 10:17:17AM +0300, Mikko Rapeli wrote:
> Python function subprocess.call() returns the return value of the
> executed process. If return values are not checked, errors may
> go unnoticed and bad things can happen.
>
> Change all callers of subprocess.call() which do not
On Tue, Mar 01, 2016 at 09:15:37AM -0600, Mariano Lopez wrote:
>
>
> On 02/29/2016 08:19 AM, mikko.rap...@bmw.de wrote:
> >On Mon, Feb 29, 2016 at 02:17:26PM +, Burton, Ross wrote:
> >>On 26 February 2016 at 08:14, wrote:
> >>
> >>>17:45:37 *** 0013:with open(patch_file, "r") as f:
On Mon, Feb 29, 2016 at 02:17:26PM +, Burton, Ross wrote:
> On 26 February 2016 at 08:14, wrote:
>
> > 17:45:37 *** 0013:with open(patch_file, "r") as f:
> > 17:45:37 0014:patch_text = f.read()
> > 17:45:37 0015:
> > 17:45:37 0016:# Search for the "
On Fri, Feb 26, 2016 at 03:56:24PM +0100, Mikko Rapeli wrote:
> On Fri, Feb 26, 2016 at 08:48:47AM -0600, Mariano Lopez wrote:
> > On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:
> > >Hi,
> > >
> > >On my developer machine the cve-check ran ok for dizzy but on build server
> > >with sstate-cache
On Fri, Feb 26, 2016 at 08:48:47AM -0600, Mariano Lopez wrote:
> On 02/26/2016 02:14 AM, mikko.rap...@bmw.de wrote:
> >Hi,
> >
> >On my developer machine the cve-check ran ok for dizzy but on build server
> >with sstate-cache and rmwork enabled it failed with what looks like a race
> >condition whe
Hi,
On my developer machine the cve-check ran ok for dizzy but on build server
with sstate-cache and rmwork enabled it failed with what looks like a race
condition when scanning the patch files:
17:45:36 ERROR: Error executing a python function in
/home/builder/src/base/poky/meta/recipes-extende
For openssh there must be some bugs or tunings needed to match the version
numbers used in CVE to ones in yocto. openssh-6.6p1 has zero matches
with the check but I think there are several:
downloads/CVE_CHECK$ grep openssh *xml| grep 6\.6\:p1
nvdcve-2.0-2016.xml:
nvdcve-2.0-2016.xml:
On Thu, Feb 25, 2016 at 01:29:13PM +0100, Mikko Rapeli wrote:
> On Thu, Feb 25, 2016 at 01:14:21PM +0100, Mikko Rapeli wrote:
> > On Wed, Feb 24, 2016 at 03:27:05PM +, mariano.lo...@linux.intel.com
> > wrote:
> > > From: Mariano Lopez
> > >
> > > This series add the cve-check-tool recipe, a
On Thu, Feb 25, 2016 at 01:14:21PM +0100, Mikko Rapeli wrote:
> On Wed, Feb 24, 2016 at 03:27:05PM +, mariano.lo...@linux.intel.com wrote:
> > From: Mariano Lopez
> >
> > This series add the cve-check-tool recipe, a tool used to identify
> > potentially vulnerable software through version mat
On Wed, Feb 24, 2016 at 03:27:05PM +, mariano.lo...@linux.intel.com wrote:
> From: Mariano Lopez
>
> This series add the cve-check-tool recipe, a tool used to identify
> potentially vulnerable software through version matching. It will
> check if a vulnerability has been addressed by a patch.
On Tue, Sep 15, 2015 at 08:13:26AM -0700, Khem Raj wrote:
> On Mon, Sep 14, 2015 at 11:33 PM, wrote:
> > On Mon, Sep 14, 2015 at 04:31:17PM +, Khem Raj wrote:
> >> The code is creating more abstract types which is nice however it should
> >> be using standard defines from stdint.h and not ran
On Mon, Sep 14, 2015 at 04:31:17PM +, Khem Raj wrote:
> The code is creating more abstract types which is nice however it should
> be using standard defines from stdint.h and not random defines to base
> its own type system
These types are not random. They are standard Linux kernel types used
On Tue, Sep 08, 2015 at 12:19:51PM +0200, Mike Looijmans wrote:
> Ah, wait, on closer inspection it actually exists, but it's a symlink to
> some none-existing location. Apparently, to save some diskspace and reduce
> maintenance on text files I linked a few files together. Somehow, the link
> got
On Sat, Aug 15, 2015 at 06:38:18PM -0700, Christopher Larson wrote:
> Update: checkbashisms and shellcheck both check for this now.
This is great! How about formulating that oe-core shell scripts should
pass shellcheck and checkbashisms checks without warnings?
-Mikko
--
On Wed, Aug 12, 2015 at 10:51:26AM -0700, Christopher Larson wrote:
> That reminds me, there's a shell portability issue / standards-complaince
> issue that's not identified by shellcheck. Typically, to negate a bracket
> expression in a regular expression, one uses ^, e.g. [^a-z] is everything
>
1 - 100 of 107 matches
Mail list logo
