Hello Raj,
Is this one
https://lists.openembedded.org/g/openembedded-core/message/194128 ok?
Regards,
Andy
On 19.01.2024 15:47, Khem Raj wrote:
On Thu, Jan 18, 2024 at 11:22 PM Andrej Valek wrote:
Hello Raj,
I will try to take a look on this today. Is the patch the same as here
https
- drop irrelevant CVEs
Signed-off-by: Valek Andrej
---
meta/recipes-core/glibc/glibc-version.inc | 5 -
meta/recipes-core/glibc/glibc_2.39.bb | 2 --
2 files changed, 7 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc-version.inc
b/meta/recipes-core/glibc/glibc-version.inc
- drop irrelevant CVEs
Signed-off-by: Valek Andrej
---
meta/recipes-core/glibc/glibc-version.inc | 5 -
meta/recipes-core/glibc/glibc_2.39.bb | 2 --
2 files changed, 7 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc-version.inc
b/meta/recipes-core/glibc/glibc-version.inc
, 2024 at 11:10 PM Andrej Valek wrote:
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
yeah CVEs list will need cleaning anyway as it will be verson bump
Hello Raj,
Don't forget to change the glibc-version.inc too and try to make a
optimization/cleaning like I proposed here:
https://lists.openembedded.org/g/openembedded-core/message/193572 ;).
Regards,
Andy
On 16.01.2024 20:53, Khem Raj wrote:
Upgrade localdef to get glibc 2.39 build fixes
Hi Simone,
I would like make a small improvements here ;).
Once you're touching this file, make it little bit more optimized.
Something like this:
CVE_STATUS_GROUPS += "CVE_STATUS_GLIBC"
CVE_STATUS_GLIBC = "CVE-2023-4527 CVE-2023-4911 CVE-2023-4806"...
CVE_STATUS_GLIBC[status] =
erability.
Those are also currently 'Patched' in cve-check.
This work is in sync with what VEX is doing, is it the use-case
Matsanaga-Shinji?
Regards,
Marta
On Wed, Oct 25, 2023 at 8:44 AM Andrej Valek wrote:
Hi all,
Do we really need a new "not_affected" state? I guess the ignore sta
Hi all,
Do we really need a new "not_affected" state? I guess the ignore state
is exactly designed for those purposes.
Regards,
Andrej
On 25.10.2023 07:13, Matsunaga-Shinji wrote:
CVEs that are currently considered "Patched" are classified into the following
3 statuses:
1. "Patched" -
From: Andrej Valek
andrej.va...@siemens.com -> andre...@skyrain.eu
Signed-off-by: Andrej Valek
---
meta/conf/distro/include/maintainers.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.
- Try to add convert and apply statuses for old CVEs
- Drop some obsolete ignores, while they are not relevant for current
version
Signed-off-by: Andrej Valek
Reviewed-by: Peter Marko
---
.../distro/include/cve-extra-exclusions.inc | 149
meta/recipes-bsp/grub/grub2.inc
Even better,
So I will make one more rebase, just for "[OE-core][PATCH v9 3/3] cve_check:
convert CVE_CHECK_IGNORE to CVE_STATUS"
Regards,
Andrej
On Wed, 2023-07-19 at 11:16 +, Ross Burton wrote:
> On 19 Jul 2023, at 11:54, Richard Purdie
> wrote:
> >
> > On Wed, 2023-07-19 at 10:26
Hello,
I would like to ask, what's the status here?
Regards,
Andrej
On Fri, 2023-06-23 at 13:14 +0200, Andrej Valek wrote:
> After discussion in all parallel threads we proposed following variant which
> covers both expressed requirements to have very small number of different cve
>
On Fri, 2023-06-23 at 10:02 +, Ross Burton wrote:
> On 22 Jun 2023, at 13:00, Andrej Valek via lists.openembedded.org
> wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
> > The CVE_STATUS should contain an information about status wich
> &g
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- descriptio
a link where is not required? Maybe here
> https://autobuilder.yoctoproject.org/typhoon/#/ ?
>
> Regards,
> Andrej
>
> On Thu, 2023-06-22 at 15:55 +0200, Luca Ceresoli wrote:
> > Hello Andrej,
> >
> > On Thu, 22 Jun 2023 13:50:32 +
> > "Andrej Val
t; On Thu, 22 Jun 2023 13:50:32 +
> "Andrej Valek via lists.openembedded.org"
> wrote:
>
> > Hello Luca,
> >
> > How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
> > didn't print any warning. Should I build an
Hello Luca,
How can I reproduce it? I've executed "bitbake qemu -c create_spdx" but it
didn't print any warning. Should I build an image?
Regards,
Andrej
On Thu, 2023-06-22 at 14:42 +0200, Luca Ceresoli wrote:
> Hello Andrej,
>
> On Thu, 22 Jun 2023 08:59:02 +0200
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- descriptio
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- descriptio
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26
ng reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fix
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting
This was sent by misstate, ignore it please.
Andrej
On Mon, 2023-06-12 at 13:57 +0200, Andrej Valek wrote:
> All mentioned CVEs are related to HSTS check feature, which is not
> implemented in version 7.69.1 .
>
> Signed-off-by: Andrej Valek
> ---
> meta/recipes-support/c
- After introducing the CVE_STATUS_DETAIL and CVE_STATUS_DESCRIPTION flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26
All mentioned CVEs are related to HSTS check feature, which is not
implemented in version 7.69.1 .
Signed-off-by: Andrej Valek
---
meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support
002"
CVE_STATUS_WIN[status] = "Ignored"
CVE_STATUS_DETAIL[detail] = "not-applicable-platform"
CVE_STATUS_WIN[description] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-1234-0004"
CVE_STATUS_PATCHED[status] = "Patched"
After discussion in all parallel threads we proposed following variant which
covers both expressed requirements to have very small number of different cve
statuses and also very large number of them at the same time.
This is a compromise version which maybe is not ideal but deals with
conflicting
Hello again Richard,
Maybe this email was little bit unclear..., so I will try to recap it here.
There are 2 open points, where some final decision has to be made.
- Could we rename the CVE_STATUS_REASONING -> CVE_STATUS_REASON? The first idea
came from you.
- What is the final enum for
- regression on x86 is still in place
Signed-off-by: Andrej Valek
---
.../{busybox-inittab_1.36.0.bb => busybox-inittab_1.36.1.bb}| 0
.../busybox/{busybox_1.36.0.bb => busybox_1.36.1.bb}| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/b
Hello Richard,
Could you please take a look on the latest revision a make a decision there?
There are still bunch of unclear statements. So please make a final design and
we will try to implement it.
Thank you,
Andrej
On Mon, 2023-05-22 at 10:57 +0300, Mikko Rapeli wrote:
> Hi,
>
> On Fri, May
them will break my parsing
and status scripts each time.
On Fri, May 19, 2023 at 8:24 AM Andrej Valek via
lists.openembedded.org<http://lists.openembedded.org>
mailto:siemens@lists.openembedded.org>>
wrote:
- Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING
gt; Hi Andrej,
>
> On 19.05.23 at 10:18, Andrej Valek via lists.openembedded.org wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS + [CVE_STATUS_REASONING] to be
> > more flexible. CVE_STATUS should contain flag for each CVE with accepted
> > values "Ignored",
- Try to add convert and apply statuses for old CVEs
- Drop some obsolete ignores, while they are not relevant for current
version
Signed-off-by: Andrej Valek
Reviewed-by: Peter Marko
---
.../distro/include/cve-extra-exclusions.inc | 281 +++---
meta/recipes-bsp/grub/grub2.inc
- After introducing the CVE_STATUS_REASONING flag variable, CVEs could
contain a reason for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 20 ++-
.../logrotate/logrotate_3.21.0
s"
CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Not applicable"
CVE_STATUS_WIN[reason] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-123
- Try to add convert and apply statuses for old CVEs
Signed-off-by: Andrej Valek
Reviewed-by: Peter Marko
---
.../distro/include/cve-extra-exclusions.inc | 281 +++---
meta/recipes-bsp/grub/grub2.inc | 9 +-
meta/recipes-connectivity/avahi/avahi_0.8.bb | 4
- After introducing the CVE_STATUS_REASONING flag variable, CVEs could
contain a reason for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 20 ++-
.../logrotate/logrotate_3.21.0
s"
CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0002"
CVE_STATUS_WIN[status] = "Not applicable"
CVE_STATUS_WIN[reason] = "Issue only applies on Windows"
CVE_STATUS_PATCHED = "CVE-1234-0003 CVE-123
234-0001] = "Not applicable" or "Ignored"
CVE_STATUS[CVE-1234-0002] = "Not applicable"
CVE_STATUS_REASONING[CVE-1234-0002] = "Issue only applies on windows"
Signed-off-by: Andrej Valek
---
meta/classes/cve-check.bbclass | 30 +-
On Fri, 2023-05-05 at 12:30 +0100, Richard Purdie wrote:
> On Fri, 2023-05-05 at 13:18 +0200, Andrej Valek via
> lists.openembedded.org wrote:
> > CVE_CHECK_PATCHED - should contains an additional CVEs which have
> > been
> > fixed and shouldn't be mark as vulnerable nor
CVE_CHECK_PATCHED - should contains an additional CVEs which have been
fixed and shouldn't be mark as vulnerable nor ignored.
Signed-off-by: Andrej Valek
---
meta/classes/cve-check.bbclass | 8
1 file changed, 8 insertions(+)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes
AM Steve Sakoman via
> lists.openembedded.org
> wrote:
> >
> > On Thu, Mar 9, 2023 at 11:54 PM Andrej Valek
> > wrote:
> > >
> > > All mentioned CVEs are related to HSTS check feature, which is
> > > not
> > > implemented in versio
Backport fix from https://github.com/libarchive/libarchive/issues/1672
Signed-off-by: Andrej Valek
---
.../libarchive/CVE-2022-26280.patch | 29 +++
.../libarchive/libarchive_3.4.2.bb| 1 +
2 files changed, 30 insertions(+)
create mode 100644
meta
Can you give me the url which is giving the expired certificate
> error?
>
> Thanks!
>
> Steve
>
> > Regards,
> > Andrej
> >
> > On Fri, 2023-03-10 at 13:45 +0100, Andrej Valek wrote:
> > > https://curl.se/docs/CVE-2021-22897.html
> > >
>
the patch, or apply and remove the
whitelist, or remove patch from hardknott?
- Https certificate at yocto.io has been expired ;)
Regards,
Andrej
On Fri, 2023-03-10 at 13:45 +0100, Andrej Valek wrote:
> https://curl.se/docs/CVE-2021-22897.html
>
> Signed-off-by: Andrej Valek
> ---
> ..
https://curl.se/docs/CVE-2021-22897.html
Signed-off-by: Andrej Valek
---
.../curl/curl/CVE-2021-22897.patch| 73 +++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 74 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2021
All mentioned CVEs are related to HSTS check feature, which is not
implemented in version 7.69.1 .
Signed-off-by: Andrej Valek
---
meta/recipes-support/curl/curl_7.69.1.bb | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-support/curl/curl_7.69.1.bb
b/meta/recipes-support
https://curl.se/docs/CVE-2022-43552.html
Signed-off-by: Andrej Valek
---
.../curl/curl/CVE-2022-43552.patch| 79 +++
meta/recipes-support/curl/curl_7.69.1.bb | 1 +
2 files changed, 80 insertions(+)
create mode 100644 meta/recipes-support/curl/curl/CVE-2022
Hello Steve,
I have a question about curl. Would it be possible to backport some
fixes for CVEs from kirkstone to dunfell?
CVE-2022-32221
CVE-2022-42915
CVE-2022-42916
CVE-2022-43552
CVE-2022-43551
Thank you,
Andrej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
, Alexander Kanavin wrote:
> You probably should make a kirkstone mixin layer like we did for
> dunfell.
> https://git.yoctoproject.org/meta-lts-mixins/
>
> Alex
>
> On Tue, 7 Mar 2023 at 07:32, Andrej Valek
> wrote:
> >
> > Hello everyone,
> >
> > I wo
Hello everyone,
I would like to ask you how to proceed with multiple CVEs for Google Go
component in kirkstone branch.
CVEs in current version 1.17.13:
- CVE-2022-41722
- CVE-2022-41725
- CVE-2022-41724
- CVE-2022-41723
They are fixed in 1.19.6/1.20.1 branches, but a fixing patches are
/steps/11/logs/stdio
>
> hmmm yes. I think texrels is the fundamental problem originally. I
> will take a look and see if this one is harmless
>
> >
> > On 06/01/2023 12:05:05+0100, Andrej Valek wrote:
> > > - update to next (un)stable version 1.36.0
> > > - refresh
next (un)stable version 1.36.0
> > > > - refresh defconfig
> > > > - disable new applets (tree, tsort, seedrng)
> > > > - use hw-accel for sha1/256 sums when available
> > > > - remove and refresh already merged patches
> > > >
> &g
4d4a7e ip b7f5d668 sp bfff6610
> error 7 in libc.so[b7eea000+76000]
>
> and it bails out logging in.
>
> On Fri, Jan 6, 2023 at 3:05 AM Andrej Valek
> wrote:
> >
> > - update to next (un)stable version 1.36.0
> > - refresh defconfig
> > - disable new
- update to next (un)stable version 1.36.0
- refresh defconfig
- disable new applets (tree, tsort, seedrng)
- use hw-accel for sha1/256 sums when available
- remove and refresh already merged patches
Signed-off-by: Andrej Valek
---
...ab_1.35.0.bb => busybox-inittab_1.36.0.bb} | 0
.../0
Hello Steve,
Would it be possible to include these commits
https://git.yoctoproject.org/poky/commit/?id=4fd15f4e3ad50ba1830b20a5e339d75ebb74a4ce
https://git.yoctoproject.org/poky/commit/?id=7e4b96e911f6b308aa1c970db37881d62ddefcac
into
kirkstone branch?
I guess, some older branches are
Without this recursive dependency on do_build task, eSDK includes only
direct image dependencies and there for devtool recipe has to rebuild
them all.
Resolves: [YOCTO#14626]
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
scripts/oe-check-sstate | 2 +-
1 file changed, 1 insertion
. Looks like, that this is exactly what we wanted to achieve.
Let me ask the question about the percentage... why is 28% of match?
Regards,
Andrej
On Thu, 2022-10-13 at 10:15 +, Ross Burton wrote:
>
>
> > On 13 Oct 2022, at 09:23, Andrej Valek via lists.openembedded.org
> >
Hello again,
I had some time and made some more testing.
Looks like, that the problematic commits are here:
https://github.com/openembedded/openembedded-core/commit/41d7f1aa2cc9ef5dba4db38435402d4c9c0a63e1
Hello Richard,
Yes, but variants have set SDK_EXT_TYPE=full. Can't say about the pure
poky eSDK, but with our layers, size is different. Let's say 2/3 of the
"working" one.
Do you really need locked-sigs.inc from both variant? I guess, you only
need to know if some entries are missing and not
Hello Richard and Alex,
Richard:
We tried to revert the commits which you mentioned and it didn't work.
Alex:
Yes, is fully reproducible on latest master.
bitbake core-image-minimal -c populate_sdk_ext
eSDK installed via: poky-glibc-x86_64-core-image-minimal-cortexa15t2hf-
Hello Richard!
I have a question related to eSDK dependencies. We're using the dunfell
branch were everything related to this eSDK topic works fine. Now we're
in the transition phase to new LTS branch, where were we found one big
difference between eSDKs.
The old variant (dunfell) includes all
ping
On Mon, 2022-01-24 at 08:19 +, Andrej Valek via
lists.openembedded.org wrote:
> Hello Richard,
>
> Fine, that we have it, but are you going to take a look on the patch
> :)
> ?
>
> Regards,
> Andrej
>
> On Fri, 2022-01-21 at 10:18 +0100, Michael Opdenacke
On Thu, 2022-03-03 at 06:35 +, Andrej Valek wrote:
> > Hi Daniel,
> >
> > Could you please give here the examples how the layer structure looks
> > before and after change? I want to see how transformation looks like.
>
> With a directory-structure like
>
&
Hi Daniel,
Could you please give here the examples how the layer structure looks
before and after change? I want to see how transformation looks like.
Regards,
Andrej
On Wed, 2022-03-02 at 20:05 +0100, Daniel Wagenknecht wrote:
> Layers could be located anywhere. The eSDK should work with them
Hello Marek,
I think, we have to stop the discussion now, because it is not leading
into any conclusion. Anyway, both of us have a different opinion.
Maybe rewriting into python will solve it, I won't do that.
Cheers,
Andrej
On Wed, 2022-02-02 at 09:17 +0100, Marek Vasut wrote:
> On 2/2/22
Marek,
Sorry, but these are still not an arguments, why to do that.
On Mon, 2022-01-31 at 10:39 +0100, Marek Vasut wrote:
> On 1/31/22 08:01, Valek, Andrej wrote:
> > Hi,
>
> Hello Andrej,
>
> (please avoid top-posting)
>
> > Sorry, but personally I don't like your idea. What's the benefit of
This will allow to use the different DBDIR location, because the /var/lib
could be used as a read-only location.
Signed-off-by: Andrej Valek
---
meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/meta/recipes
Hi,
Sorry, but personally I don't like your idea. What's the benefit of
reverting this? I would keep the ${} for bitbake and $ for shell. The
{} has to be placed only for variables like $a${b}c.
We should respect the workflow on all recipes otherwise we're braking
the "unwritten" rules.
Regards,
Hello Bryan,
So looks like, there is some kind of problem.
Was you able to run the busybox command after upgrade like, "busybox ls
/" ?
- If yes, there is a problem, that update alternatives hasn't been
processed correctly. Try direct command after reboot, if possible
- If no, lets continue
to dump QMP CMD: dump-guest-memory with
| Exception: [Errno 2] No such file or directory:
'.../tmp/log/runtime-hostdump/qmp_00_dump-guest-memory'
The qmp dump commands could fail, because of missing root directory.
So create it before any log writing.
Signed-off-by: Andrej Valek
---
meta/lib
Hello Richard,
Fine, that we have it, but are you going to take a look on the patch :)
?
Regards,
Andrej
On Fri, 2022-01-21 at 10:18 +0100, Michael Opdenacker wrote:
>
> On 1/19/22 5:48 PM, Richard Purdie wrote:
> > On Wed, 2022-01-19 at 12:57 +0100, Andrej Valek wrote:
> >
- extend find command
- disable rootfs skip
- busybox-inittab_1.34.1 -> busybox-inittab_1.35.0
Signed-off-by: Andrej Valek
---
...ab_1.34.1.bb => busybox-inittab_1.35.0.bb} | 0
meta/recipes-core/busybox/busybox/defconfig | 70 +++
2 files changed, 39 insertions(
Hello again,
Maybe a general question. Is it working in current master? I do not
want to brake dunfell, just applying something, which will create a lot
of divergence.
Cheers,
Andrej
On Fri, 2022-01-21 at 15:02 +, Bryan Evenson wrote:
> Andrej,
>
> Thanks for the response. This is an
Hi Bryan,
Sorry, maybe I didn't fully understand the use-case. Are you trying to
upgrade the busybox on demand? If yes, that is not a good idea.
I'm little bit scary about doing "export PATH=$busybox_rmdir:$PATH" and
creating a custom locks is not a good at all.
Cheers,
Andrej
On Fri,
Hello Richard,
Thanks for the response. In other words, take a care about your machine
by yourself => no other pending questions... ;) .
Regards
Andrej
On Fri, 2022-01-21 at 11:36 +, Richard Purdie wrote:
> On Fri, 2022-01-21 at 11:32 +, Valek, Andrej wrote:
> > Hi all,
> >
> > I have
Hi all,
I have a generic question about testimage task. Currently
'TESTIMAGEDEPENDS:append:qemuall = " qemu-native:do_populate_sysroot
qemu-helper-native:do_populate_sysroot qemu-helper-
native:do_addto_recipe_sysroot"' means that no other machine then qemu*
has the feature available. So when
Signed-off-by: Andrej Valek
---
meta/classes/kernel.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 473e28be47..9ea201c936 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -647,6 +647,
no external compression will be used.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
meta/lib/oeqa/selftest/cases/fitimage.py | 8
2 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/meta
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by
Based on d22d87b9c4ac85ffb3506e2acaf2a8a627f55e8e, but kept idn2
as default.
Signed-off-by: Andrej Valek
---
meta/recipes-support/libpsl/libpsl_0.21.0.bb | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-support/libpsl/libpsl_0.21.0.bb
b/meta/recipes
Ok, but I've just copied the existing commit from master. So I have to
send a different configuration for dunfell?
Andrej
On Fri, 2021-10-15 at 10:58 +0100, Richard Purdie wrote:
> On Fri, 2021-10-15 at 06:15 +0000, Andrej Valek wrote:
> > The reason, why I want to apply it here,
The reason, why I want to apply it here, to switch replace libidn2 with
icu. According to libpsl documentation, you can chose who will generate
the PSL database (libidn, libidn2, icu). So I don't want to install a
new component if there is a valid replacement which is already
installed.
Regards,
Hello Steve,
Would it be possible to include this commit
https://lists.openembedded.org/g/openembedded-core/message/150627 into
dunfell branch?
Thanks,
Andrej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#156920):
the compression type.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17 +
meta/lib/oeqa/selftest/cases/fitimage.py | 8 +++-
2 files changed, 4 insertions(+), 21 deletions(-)
diff --git a/meta/classes/kernel-fitimage.bbclass
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by
Even if initramfs_bundle_path was used, a wrong compression was reflected
in output its template file. Use linux.bin as universal kernel image.
The linux.bin file covers both cases.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta/classes/kernel-fitimage.bbclass | 17
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
- make debug info in ramdisk section creation more verbose
Signed-off-by
Even if initramfs_bundle_path was used, kernel compression was not
reflected in output its image. Use linux.bin as kernel compressed output
image. File is correctly created from vmlinux which includes a right
initramfs image.
Signed-off-by: Andrej Valek
Signed-off-by: Walter Schweizer
---
meta
- use bash variable notation without {} where possible
- just to make sure it looks like bash variable not bitbake variable one
- fix indent style in "cat" commands
- replace "! -z" -> "-n"
Signed-off-by: Andrej Valek
---
meta/clas
- update to next stable version 1.34.1
Signed-off-by: Andrej Valek
---
.../{busybox-inittab_1.34.0.bb => busybox-inittab_1.34.1.bb}| 0
.../busybox/{busybox_1.34.0.bb => busybox_1.34.1.bb}| 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-core/b
the changes are not there.
Regards,
Andrej
On Wed, 2021-09-01 at 12:35 -1000, Steve Sakoman wrote:
> On Wed, Sep 1, 2021 at 9:04 AM Andrej Valek
> wrote:
> >
> > Hello Steve,
> >
> > Could you please cherry-pick this patch into dunfell branch too?
>
>
Hello Steve,
Could you please cherry-pick this patch into dunfell branch too?
Thank you,
Andrej
On Thu, 2021-08-26 at 15:15 +0200, Andrej Valek wrote:
> - Some distributions with UTF-8 locale have problem when National
> Language
> Support is enabled. Add there an option t
- Some distributions with UTF-8 locale have problem when National Language
Support is enabled. Add there an option to disable it.
Signed-off-by: Andrej Valek
---
meta/recipes-support/vim/vim.inc | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/vim
1 - 100 of 377 matches
Mail list logo
