Re: [OE-core][PATCH v3] python3-calver: Add recipe
> -Original Message-
> From: Trevor Gamblin
> Sent: den 5 maj 2023 20:52
> To: Peter Kjellerstedt ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH v3] python3-calver: Add recipe
>
> On 2023-05-02 18:40, Peter Kjellerstedt wrote:
> >> -Original Message-
> >> From: openembedded-core@lists.openembedded.org
> >> On Behalf Of Trevor Gamblin
> >> Sent: den 2 maj 2023 19:45
> >> To: openembedded-core@lists.openembedded.org
> >> Subject: [OE-core][PATCH v3] python3-calver: Add recipe
> >>
> >> calver is "a setuptools extension for automatically defining your Python
> >> package version as a calendar version." It is required for
> >> python3-trove-classifiers (another new recipe), which in turn is
> >> required for the upgrade of python3-hatchling from 1.13.0 to work.
> >>
> >> v3 clarifies that the recipe now includes ptests, where v2 didn't make
> >> this clear and v1 didn't have them at all.
> > Comments related to the patch versions should go after the "---" below
> > as they will otherwise become part of the commit message, where they
> > typically do not make any sense.
>
> Sorry, missed this earlier. I've resent with the revision notes moved.
I also think you missed the comments below as they were not addressed
in v5. ;)
>
> -Trevor
>
> >
> >> Signed-off-by: Trevor Gamblin
> >> ---
> >> .../distro/include/ptest-packagelists.inc | 1 +
> >> .../python/python3-calver_2022.6.26.bb| 28 +++
> >> 2 files changed, 29 insertions(+)
> >> create mode 100644
> >> meta/recipes-devtools/python/python3-calver_2022.6.26.bb
> >>
> >> diff --git a/meta/conf/distro/include/ptest-packagelists.inc
> >> b/meta/conf/distro/include/ptest-packagelists.inc
> >> index 2f83132aeb..bd95a13ff6 100644
> >> --- a/meta/conf/distro/include/ptest-packagelists.inc
> >> +++ b/meta/conf/distro/include/ptest-packagelists.inc
> >> @@ -56,6 +56,7 @@ PTESTS_FAST = "\
> >> popt \
> >> python3-atomicwrites \
> >> python3-bcrypt \
> >> +python3-calver \
> >> python3-hypothesis \
> >> python3-jinja2 \
> >> python3-jsonpointer \
> >> diff --git a/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
> >> b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
> >> new file mode 100644
> >> index 00..32b6cfbd42
> >> --- /dev/null
> >> +++ b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
> >> @@ -0,0 +1,28 @@
> >> +SUMMARY = "Setuptools extension for CalVer package versions"
> >> +HOMEPAGE = "https://github.com/di/calver;
> >> +LICENSE = "Apache-2.0"
> >> +LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
> >> +
> >> +SRC_URI = " \
> >> +git://github.com/di/calver;branch=master;protocol=https \
> >> +file://run-ptest \
> >> +"
> >> +SRC_URI[sha256sum] =
> >> "e05493a3b17517ef1748fbe610da11f10485faa7c416b9d33fd4a52d74894f8b"
> >
> > This recipe uses Git, and thus should not need a SHA-256 checksum.
> >
> >> +SRCREV ?= "3268d8acf2c345f32a1c5f08ba25dc67f76cca81"
> >
> > Change `?=` to `=`.
> >
> >> +
> >> +inherit python_setuptools_build_meta ptest
> >> +
> >> +S = "${WORKDIR}/git"
> >> +
> >> +RDEPENDS:${PN}-ptest += " \
> >> +${PYTHON_PN}-pretend \
> >> +${PYTHON_PN}-pytest \
> >> +${PYTHON_PN}-unittest-automake-output \
> >> +"
> >> +
> >> +do_install_ptest() {
> >> +install -d ${D}${PTEST_PATH}/tests
> >> +cp -rf ${S}/tests ${D}${PTEST_PATH}/
> >
> > Shell code in OE-Core is expected to be tab-indented.
> >
> >> +}
> >> +
> >> +BBCLASSEXTEND = "native nativesdk"
> >> --
> >> 2.40.0
> >
> > //Peter
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180979):
https://lists.openembedded.org/g/openembedded-core/message/180979
Mute This Topic: https://lists.openembedded.org/mt/98644464/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[mickledore][oe-core][PATCH 1/1] ghostscript: fix CVE-2023-28879
From: Joe Slater
Backport from tag ghostpdl-10.01.1-gse-10174 which is
after 10.01.1.
Signed-off-by: Joe Slater
Signed-off-by: Luca Ceresoli
Signed-off-by: Richard Purdie
(cherry picked from commit 8a70d6935afa38173dbf012b8e1c3d59228504df)
---
.../ghostscript/cve-2023-28879.patch | 60 +++
.../ghostscript/ghostscript_10.0.0.bb | 1 +
2 files changed, 61 insertions(+)
create mode 100644
meta/recipes-extended/ghostscript/ghostscript/cve-2023-28879.patch
diff --git a/meta/recipes-extended/ghostscript/ghostscript/cve-2023-28879.patch
b/meta/recipes-extended/ghostscript/ghostscript/cve-2023-28879.patch
new file mode 100644
index 00..604b927521
--- /dev/null
+++ b/meta/recipes-extended/ghostscript/ghostscript/cve-2023-28879.patch
@@ -0,0 +1,60 @@
+From 37ed5022cecd584de868933b5b60da2e995b3179 Mon Sep 17 00:00:00 2001
+From: Ken Sharp
+Date: Fri, 24 Mar 2023 13:19:57 +
+Subject: [PATCH] Graphics library - prevent buffer overrun in (T)BCP encoding
+
+Bug #706494 "Buffer Overflow in s_xBCPE_process"
+
+As described in detail in the bug report, if the write buffer is filled
+to one byte less than full, and we then try to write an escaped
+character, we overrun the buffer because we don't check before
+writing two bytes to it.
+
+This just checks if we have two bytes before starting to write an
+escaped character and exits if we don't (replacing the consumed byte
+of the input).
+
+Up for further discussion; why do we even permit a BCP encoding filter
+anyway ? I think we should remove this, at least when SAFER is true.
+---
+CVE: CVE-2023-28879
+
+Upstream-Status: Backport [see text]
+
+git://git.ghostscript.com/ghostpdl
+cherry-pick
+
+Signed-off-by: Joe Slater limit - q < 2) {
++p--;
++break;
++}
+ if (p == rlimit) {
+ p--;
+ break;
+--
+2.25.1
+
diff --git a/meta/recipes-extended/ghostscript/ghostscript_10.0.0.bb
b/meta/recipes-extended/ghostscript/ghostscript_10.0.0.bb
index 56a93632e2..86ecdbe24a 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_10.0.0.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_10.0.0.bb
@@ -34,6 +34,7 @@ SRC_URI_BASE =
"https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/d
file://avoid-host-contamination.patch \
file://mkdir-p.patch \
file://cross-compile.patch \
+file://cve-2023-28879.patch \
"
SRC_URI = "${SRC_URI_BASE} \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180978):
https://lists.openembedded.org/g/openembedded-core/message/180978
Mute This Topic: https://lists.openembedded.org/mt/98714349/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
On Fri, 5 May 2023 at 21:21, Michael Opdenacker < michael.opdenac...@bootlin.com> wrote: > Hi Frederic > > On 05.05.23 at 19:17, Frederic Martinsons wrote: > > Hello list > > > > I'm wondering if there are documentations on how contribution are > > managed for the project. > > > > I try to find some but didn't manage to. There are easily reachable > > doc about how to contribute of course (how to make patches, fixe your > > identity, send mail via git... etc) but I didn't find what I usually > > find on other open source project (CONTRIBUTING.md file most of the > > time) like > > - what are the tests do should I run before submitting (I learnt by > > practice about test image or bitbake selftest for example) ? > > - is there a specific configuration that I should test before > > submitting (poky is ok, or should I also test another distro)? > > - does some commit writing rules exist ? (some projects want commits > > to begin with a prefix, usually the software component that is > > modified by the patch for example) > > - what are the coding rules you should follow, if any? (having common > > coding rules helps greatly the review of patches, pylint for python > > code for example, and I saw there are some bitbake recipes linter from > > meta-sca layer) > > > > Long story short, I really would like to know what are the different > > steps a patch should go through before being merged into master (and > > as a side question, what are the steps for a patch to be backported > > into one of the LTS branch). > > > > I'm deeply sorry if all these questions are obvious to you and have > > been already answered somewhere, in that case, please just give me the > > link. > > > > I recently started to contribute to yocto / oe and I think it will > > help me to make better contributions if I know more of how it works > > "under the hood". > > > Thanks for starting this thread! We precisely have plans to consolidate > docs on how to contribute. > > See https://www.openembedded.org/wiki/Document_Consolidation and > https://wiki.yoctoproject.org/wiki/Maintainers_Manual for a list of > documents we want to consolidate. > > Cheers > Michael. > > -- > Michael Opdenacker, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Oh great ! thank you Michael, be sure I will read those links. And thanks everyone for giving all these documents, I'll have a busy weekend to look at them all. Again, I think having a focus point which gathers all these docs would be a great help but maybe the link you gave Michael will be a starting point. By the way, I'm starting to think that I should write an article (blog post, tweet, whatever ...) about my journey about yocto/oe contributions, it may help future contributors. But since I never write a publicly available article, it may not be in the coming weeks (and I should improve my skills in writing before going there) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180977): https://lists.openembedded.org/g/openembedded-core/message/180977 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
On Fri, 5 May 2023 at 21:08, Trevor Gamblin wrote: > > On 2023-05-05 14:31, Frédéric Martinsons wrote: > > > > Le ven. 5 mai 2023, 20:21, Trevor Gamblin a > écrit : > >> >> On 2023-05-05 13:37, Alexander Kanavin wrote: >> > There is >> > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded >> > and some additional pages linked from it: >> > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines >> > http://www.openembedded.org/wiki/Styleguide >> > >> > The wiki is not great, and needs improvements, but the problem is it's >> > difficult to write an authoritative and comprehensive answer to the >> > questions you ask because there's just so many possible things one >> > could check with any change to yocto. If you touch a recipe, you >> > should of course check that 'bitbake recipe' still completes without >> > an error. But that's obvious, isn't it? Beyond that... it depends. And >> > requires a bit of intuition and experience, or advice from someone who >> > knows the specific item better. >> > >> > We generally don't expect people to learn 'the rules' upfront - just >> > write some code, and if you're not certain how to test it properly or >> > whether it even makes sense, submit the patch as RFC and ask to take a >> > look. If it fails in integration testing, you'll hear about it too, >> > and that's normal and expected for anything more complex than a typo >> > fix. My patches appear 'perfect' only because I pre-test them myself >> > on the autobuilder :) >> > >> > Where we would *greatly* appreciate help is a special bot called >> > patchtest that used to check mailing list submissions for common >> > problems. That fell into disrepair due to lack of maintenance. Fixing >> > that would be fantastic - and people could run it locally too. That >> > could act as both a repository of rules-as-code, and a way to check >> > them automatically. It could also offer hints for testing, depending >> > on what the change touches. All sorts of nice things, if there is a >> > person looking after it. >> >> I'm actually working on getting patchtest running again, and I've >> assigned myself as maintainer :) >> >> To add to what Alex said, a good place for you to start might be looking >> at the Newcomer Bugs list: >> https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs >> >> Alternatively, watching AUH failures and figuring out broken upgrades, > > > What is AUH? Where I can see broken upgrades you talked about? And more > important to me, how can I replicate them to investigate on my side? > > AUH is "Auto Upgrade Helper". If you search the OE-core mailing list for > the acronym, you will sometimes see results like this: > > [OE-core] [AUH] icu: upgrading to 73-1 FAILED > > These could be another area to look at contributing in addition to the > Newcomer Bugs or other parts of the Bugzilla, but the Newcomer list is > probably the best place to get yourself familiarized. > > You may find this page useful when it comes to recipe upgrades: > https://docs.yoctoproject.org/dev/dev-manual/upgrading-recipes.html > Alright, I will take a look. Thanks trevor. > - Trevor > > > >> or looking on the Bugzilla under terms like "ptest" could also be very >> useful, while providing better understanding of how recipes are written >> and being somewhat more accessible. >> >> You can also ask questions in the #yocto channel on the Libera.Chat IRC >> server if you need additional help. >> >> - Trevor >> >> > >> > Alex >> > >> > On Fri, 5 May 2023 at 19:17, Frederic Martinsons >> > wrote: >> >> Hello list >> >> >> >> I'm wondering if there are documentations on how contribution are >> managed for the project. >> >> >> >> I try to find some but didn't manage to. There are easily reachable >> doc about how to contribute of course (how to make patches, fixe your >> identity, send mail via git... etc) but I didn't find what I usually find >> on other open source project (CONTRIBUTING.md file most of the time) like >> >>- what are the tests do should I run before submitting (I learnt by >> practice about test image or bitbake selftest for example) ? >> >>- is there a specific configuration that I should test before >> submitting (poky is ok, or should I also test another distro)? >> >>- does some commit writing rules exist ? (some projects want >> commits to begin with a prefix, usually the software component that is >> modified by the patch for example) >> >> - what are the coding rules you should follow, if any? (having >> common coding rules helps greatly the review of patches, pylint for python >> code for example, and I saw there are some bitbake recipes linter from >> meta-sca layer) >> >> >> >> Long story short, I really would like to know what are the different >> steps a patch should go through before being merged into master (and as a >> side question, what are the steps for a patch to be backported into one of >> the LTS branch). >> >> >> >> I'm deeply sorry if all these
Re: [OE-core] Contributing, how it works?
On Fri, 5 May 2023 at 21:05, Alexander Kanavin wrote: > On Fri, 5 May 2023 at 20:26, Frédéric Martinsons > wrote: > > That's what I did for unit test of rust recipes and I didn't get much > comments beside you and khem 15 days ago. And I still don't know if my > patches are an issue or if nobody had the time to look at them, it's pretty > frustrating. > > They've been merged to master I think? Can you check that by > fetch/rebase? Yes, there is no separate notice when it happens, and > it's frustrating to first time contributors, but again, someone needs > to sit down and write an email bot to do the job. > yes, after re-checking, my commits have been merged this morning. I would like to know more about "write an email bot to do the job" because having a submission accepted by maintainers and merged is some kind of "reward" (the only one when we are a fresh submitter to the project). And having a reward is motivating to contribute more. > I would like to know about these, I hear a lot in this list about > autobuilder and it seems close to what I know of continuous integration > (some build of multiple configuration with the submitted patch and tests > towards that) but I don't know how to replicate the config of those locally > on my machine (in case of errors), do you have any links for that? > > > > You probably should to start with reading > https://docs.yoctoproject.org/test-manual/index.html ? > > > Ah great, if you point me to where I can find insights about this > patchset test framework, I would gladly offer my help to fox the issue. > From what you are saying, I understand that fixing this will make the > contribution smoothier. > > That you should discuss with Trevor. > > Alex > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180975): https://lists.openembedded.org/g/openembedded-core/message/180975 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
Hi Frederic On 05.05.23 at 19:17, Frederic Martinsons wrote: Hello list I'm wondering if there are documentations on how contribution are managed for the project. I try to find some but didn't manage to. There are easily reachable doc about how to contribute of course (how to make patches, fixe your identity, send mail via git... etc) but I didn't find what I usually find on other open source project (CONTRIBUTING.md file most of the time) like - what are the tests do should I run before submitting (I learnt by practice about test image or bitbake selftest for example) ? - is there a specific configuration that I should test before submitting (poky is ok, or should I also test another distro)? - does some commit writing rules exist ? (some projects want commits to begin with a prefix, usually the software component that is modified by the patch for example) - what are the coding rules you should follow, if any? (having common coding rules helps greatly the review of patches, pylint for python code for example, and I saw there are some bitbake recipes linter from meta-sca layer) Long story short, I really would like to know what are the different steps a patch should go through before being merged into master (and as a side question, what are the steps for a patch to be backported into one of the LTS branch). I'm deeply sorry if all these questions are obvious to you and have been already answered somewhere, in that case, please just give me the link. I recently started to contribute to yocto / oe and I think it will help me to make better contributions if I know more of how it works "under the hood". Thanks for starting this thread! We precisely have plans to consolidate docs on how to contribute. See https://www.openembedded.org/wiki/Document_Consolidation and https://wiki.yoctoproject.org/wiki/Maintainers_Manual for a list of documents we want to consolidate. Cheers Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180974): https://lists.openembedded.org/g/openembedded-core/message/180974 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC] python3-cryptogaphy upgrade to 40.0.2 issues
Hi,
a short status update:
On 2023-05-05 06:01, Tim Orling wrote:
On Thu, May 4, 2023 at 5:00 AM Peter Bergin
wrote:
On 2023-05-04 11:00, Alexander Kanavin wrote:
> On Thu, 4 May 2023 at 10:41, Peter Bergin
wrote:
>
>> At
>>
https://github.com/pyca/cryptography/blob/f816b457494e010b655cd7fdcd30e3446f86a703/src/rust/build.rs#L46
>> the path to python includes is defined by calling 'python3 -c
"import
>> sysconfig; print(sysconfig.get_path('include'))"' (but from inside
>> rust). With print-debugging this seems to return the bad string
>> '/usr/include/python3.11' which is then passed to cc::Build
>>
>> I executed this in recipe context:
>>
>> do_compile:prepend() {
>> which python3
>> python3 -c "import sysconfig;
print(sysconfig.get_path('include'))"
>> }
>>
>> and then I got the correct return value:
>>
>> |
>>
/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot-native/usr/bin/python3-native/python3
>> |
>>
/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot-native/usr/include/python3.11
> This is pointing to the native sysroot in a target build, so it is
> most likely not actually correct. I believe 'inherit
> python3targetconfig' may help, as it substitutes most places where
> native python gets queried by components with target-specific
values.
>
> Alex
>
The bad thing is that the build.rs script is
running python script to
figure out the path to the headers. I'm not sure we can use target
python exe in the build steps without running qemu instance or
something
which seems overkill in this case. We have the information about
python
include path for the target in the variable PYTHON_INCLUDE_DIR.
With this patch the compilation will find Python.h:
$ git diff src/rust/build.rs
diff --git a/src/rust/build.rs
b/src/rust/build.rs
index 01177ac..7dc13fe 100644
--- a/src/rust/build.rs
+++ b/src/rust/build.rs
@@ -43,11 +43,8 @@ fn main() {
)
.unwrap();
println!("cargo:rustc-cfg=python_implementation=\"{}\"", python_impl);
- let python_include = run_python_script(
- ,
- "import sysconfig; print(sysconfig.get_path('include'),
end='')",
- )
- .unwrap();
+ let python_include = env::var("PYTHON_INCLUDE_DIR").unwrap();
+
let openssl_include =
std::env::var_os("DEP_OPENSSL_INCLUDE").expect("unable to find
openssl include path");
let openssl_c = Path::new(_dir).join("_openssl.c");
This patch at least got `python3-cryptography-native` to build to
completion.
And I was also able to build python3-cryptography for 'qemuarm64'.
Opened an issue at https://github.com/pyca/cryptography/issues/8867 to
see if it is something to be fixed upstream.
But it fails later in the linking step.
.linux/python3-cryptography/40.0.2-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib"
"-L"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/python3-cryptography-40.0.2/target/x86_64-poky-linux-gnu/release/build/cryptography-rust-aa00e39a952c07ee/out"
"-L"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot/usr/lib"
"-L"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot-native/usr/lib/rustlib/x86_64-poky-linux-gnu/lib"
"-Wl,-Bstatic" "-l_openssl.a"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot/usr/lib/rustlib/x86_64-poky-linux-gnu/lib/libcompiler_builtins-45df5d471f0d20d0.rlib"
"-Wl,-Bdynamic" "-lssl" "-lcrypto" "-lgcc_s" "-lutil" "-lrt"
"-lpthread"
"-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-znoexecstack" "-L"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot-native/usr/lib/rustlib/x86_64-poky-linux-gnu/lib"
"-o"
"/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/python3-cryptography-40.0.2/target/x86_64-poky-linux-gnu/release/deps/libcryptography_rust.so"
"-Wl,--gc-sections" "-shared" "-Wl,-O1" "-nodefaultlibs"
= note:
/work/yocto/poky/build/tmp/work/core2-64-poky-linux/python3-cryptography/40.0.2-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/12.2.0/ld:
Re: [OE-core] Contributing, how it works?
On 2023-05-05 14:31, Frédéric Martinsons wrote: Le ven. 5 mai 2023, 20:21, Trevor Gamblin a écrit : On 2023-05-05 13:37, Alexander Kanavin wrote: > There is > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > and some additional pages linked from it: > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > http://www.openembedded.org/wiki/Styleguide > > The wiki is not great, and needs improvements, but the problem is it's > difficult to write an authoritative and comprehensive answer to the > questions you ask because there's just so many possible things one > could check with any change to yocto. If you touch a recipe, you > should of course check that 'bitbake recipe' still completes without > an error. But that's obvious, isn't it? Beyond that... it depends. And > requires a bit of intuition and experience, or advice from someone who > knows the specific item better. > > We generally don't expect people to learn 'the rules' upfront - just > write some code, and if you're not certain how to test it properly or > whether it even makes sense, submit the patch as RFC and ask to take a > look. If it fails in integration testing, you'll hear about it too, > and that's normal and expected for anything more complex than a typo > fix. My patches appear 'perfect' only because I pre-test them myself > on the autobuilder :) > > Where we would *greatly* appreciate help is a special bot called > patchtest that used to check mailing list submissions for common > problems. That fell into disrepair due to lack of maintenance. Fixing > that would be fantastic - and people could run it locally too. That > could act as both a repository of rules-as-code, and a way to check > them automatically. It could also offer hints for testing, depending > on what the change touches. All sorts of nice things, if there is a > person looking after it. I'm actually working on getting patchtest running again, and I've assigned myself as maintainer :) To add to what Alex said, a good place for you to start might be looking at the Newcomer Bugs list: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Alternatively, watching AUH failures and figuring out broken upgrades, What is AUH? Where I can see broken upgrades you talked about? And more important to me, how can I replicate them to investigate on my side? AUH is "Auto Upgrade Helper". If you search the OE-core mailing list for the acronym, you will sometimes see results like this: [OE-core] [AUH] icu: upgrading to 73-1 FAILED These could be another area to look at contributing in addition to the Newcomer Bugs or other parts of the Bugzilla, but the Newcomer list is probably the best place to get yourself familiarized. You may find this page useful when it comes to recipe upgrades: https://docs.yoctoproject.org/dev/dev-manual/upgrading-recipes.html - Trevor or looking on the Bugzilla under terms like "ptest" could also be very useful, while providing better understanding of how recipes are written and being somewhat more accessible. You can also ask questions in the #yocto channel on the Libera.Chat IRC server if you need additional help. - Trevor > > Alex > > On Fri, 5 May 2023 at 19:17, Frederic Martinsons > wrote: >> Hello list >> >> I'm wondering if there are documentations on how contribution are managed for the project. >> >> I try to find some but didn't manage to. There are easily reachable doc about how to contribute of course (how to make patches, fixe your identity, send mail via git... etc) but I didn't find what I usually find on other open source project (CONTRIBUTING.md file most of the time) like >> - what are the tests do should I run before submitting (I learnt by practice about test image or bitbake selftest for example) ? >> - is there a specific configuration that I should test before submitting (poky is ok, or should I also test another distro)? >> - does some commit writing rules exist ? (some projects want commits to begin with a prefix, usually the software component that is modified by the patch for example) >> - what are the coding rules you should follow, if any? (having common coding rules helps greatly the review of patches, pylint for python code for example, and I saw there are some bitbake recipes linter from meta-sca layer) >> >> Long story short, I really would like to know what are the different steps a patch should go through before being merged into master (and as a side question, what are the steps for a patch to be backported into one of the LTS branch). >> >> I'm deeply sorry if all these questions are obvious
Re: [OE-core] Contributing, how it works?
On Fri, 5 May 2023 at 20:26, Frédéric Martinsons wrote: > That's what I did for unit test of rust recipes and I didn't get much > comments beside you and khem 15 days ago. And I still don't know if my > patches are an issue or if nobody had the time to look at them, it's pretty > frustrating. They've been merged to master I think? Can you check that by fetch/rebase? Yes, there is no separate notice when it happens, and it's frustrating to first time contributors, but again, someone needs to sit down and write an email bot to do the job. > I would like to know about these, I hear a lot in this list about autobuilder > and it seems close to what I know of continuous integration (some build of > multiple configuration with the submitted patch and tests towards that) but I > don't know how to replicate the config of those locally on my machine (in > case of errors), do you have any links for that? > You probably should to start with reading https://docs.yoctoproject.org/test-manual/index.html ? > Ah great, if you point me to where I can find insights about this patchset > test framework, I would gladly offer my help to fox the issue. From what you > are saying, I understand that fixing this will make the contribution > smoothier. That you should discuss with Trevor. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180971): https://lists.openembedded.org/g/openembedded-core/message/180971 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v3] python3-calver: Add recipe
On 2023-05-02 18:40, Peter Kjellerstedt wrote:
-Original Message-
From: openembedded-core@lists.openembedded.org
On Behalf Of Trevor Gamblin
Sent: den 2 maj 2023 19:45
To: openembedded-core@lists.openembedded.org
Subject: [OE-core][PATCH v3] python3-calver: Add recipe
calver is "a setuptools extension for automatically defining your Python
package version as a calendar version." It is required for
python3-trove-classifiers (another new recipe), which in turn is
required for the upgrade of python3-hatchling from 1.13.0 to work.
v3 clarifies that the recipe now includes ptests, where v2 didn't make
this clear and v1 didn't have them at all.
Comments related to the patch versions should go after the "---" below
as they will otherwise become part of the commit message, where they
typically do not make any sense.
Sorry, missed this earlier. I've resent with the revision notes moved.
-Trevor
Signed-off-by: Trevor Gamblin
---
.../distro/include/ptest-packagelists.inc | 1 +
.../python/python3-calver_2022.6.26.bb| 28 +++
2 files changed, 29 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3-calver_2022.6.26.bb
diff --git a/meta/conf/distro/include/ptest-packagelists.inc
b/meta/conf/distro/include/ptest-packagelists.inc
index 2f83132aeb..bd95a13ff6 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -56,6 +56,7 @@ PTESTS_FAST = "\
popt \
python3-atomicwrites \
python3-bcrypt \
+python3-calver \
python3-hypothesis \
python3-jinja2 \
python3-jsonpointer \
diff --git a/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
new file mode 100644
index 00..32b6cfbd42
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
@@ -0,0 +1,28 @@
+SUMMARY = "Setuptools extension for CalVer package versions"
+HOMEPAGE = "https://github.com/di/calver;
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRC_URI = " \
+git://github.com/di/calver;branch=master;protocol=https \
+file://run-ptest \
+"
+SRC_URI[sha256sum] =
"e05493a3b17517ef1748fbe610da11f10485faa7c416b9d33fd4a52d74894f8b"
This recipe uses Git, and thus should not need a SHA-256 checksum.
+SRCREV ?= "3268d8acf2c345f32a1c5f08ba25dc67f76cca81"
Change `?=` to `=`.
+
+inherit python_setuptools_build_meta ptest
+
+S = "${WORKDIR}/git"
+
+RDEPENDS:${PN}-ptest += " \
+${PYTHON_PN}-pretend \
+${PYTHON_PN}-pytest \
+${PYTHON_PN}-unittest-automake-output \
+"
+
+do_install_ptest() {
+install -d ${D}${PTEST_PATH}/tests
+cp -rf ${S}/tests ${D}${PTEST_PATH}/
Shell code in OE-Core is expected to be tab-indented.
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.40.0
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180970):
https://lists.openembedded.org/g/openembedded-core/message/180970
Mute This Topic: https://lists.openembedded.org/mt/98644464/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v5] python3-calver: Add recipe
calver is "a setuptools extension for automatically defining your Python
package version as a calendar version." It is required for
python3-trove-classifiers (another new recipe), which in turn is
required for the upgrade of python3-hatchling from 1.13.0 to work.
Signed-off-by: Trevor Gamblin
---
v5 moves these revision notes to the correct place.
v4 adds the run-ptest script and adds maintainer info.
v3 clarifies that the recipe now includes ptests, where v2 didn't make
this clear and v1 didn't have them at all.
meta/conf/distro/include/maintainers.inc | 1 +
.../distro/include/ptest-packagelists.inc | 1 +
.../python/python3-calver/run-ptest | 3 ++
.../python/python3-calver_2022.6.26.bb| 28 +++
4 files changed, 33 insertions(+)
create mode 100644 meta/recipes-devtools/python/python3-calver/run-ptest
create mode 100644 meta/recipes-devtools/python/python3-calver_2022.6.26.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 682ec2cfdf..4853a905ef 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -603,6 +603,7 @@ RECIPE_MAINTAINER:pn-python3-attrs = "Tim Orling
"
RECIPE_MAINTAINER:pn-python3-babel = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-bcrypt = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-build = "Ross Burton "
+RECIPE_MAINTAINER:pn-python3-calver = "Trevor Gamblin "
RECIPE_MAINTAINER:pn-python3-certifi = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-cffi = "Tim Orling "
RECIPE_MAINTAINER:pn-python3-chardet = "Tim Orling "
diff --git a/meta/conf/distro/include/ptest-packagelists.inc
b/meta/conf/distro/include/ptest-packagelists.inc
index 2f83132aeb..bd95a13ff6 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -56,6 +56,7 @@ PTESTS_FAST = "\
popt \
python3-atomicwrites \
python3-bcrypt \
+python3-calver \
python3-hypothesis \
python3-jinja2 \
python3-jsonpointer \
diff --git a/meta/recipes-devtools/python/python3-calver/run-ptest
b/meta/recipes-devtools/python/python3-calver/run-ptest
new file mode 100644
index 00..8d2017d39c
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-calver/run-ptest
@@ -0,0 +1,3 @@
+#!/bin/sh
+
+pytest --automake
diff --git a/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
new file mode 100644
index 00..32b6cfbd42
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-calver_2022.6.26.bb
@@ -0,0 +1,28 @@
+SUMMARY = "Setuptools extension for CalVer package versions"
+HOMEPAGE = "https://github.com/di/calver;
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
+
+SRC_URI = " \
+git://github.com/di/calver;branch=master;protocol=https \
+file://run-ptest \
+"
+SRC_URI[sha256sum] =
"e05493a3b17517ef1748fbe610da11f10485faa7c416b9d33fd4a52d74894f8b"
+SRCREV ?= "3268d8acf2c345f32a1c5f08ba25dc67f76cca81"
+
+inherit python_setuptools_build_meta ptest
+
+S = "${WORKDIR}/git"
+
+RDEPENDS:${PN}-ptest += " \
+${PYTHON_PN}-pretend \
+${PYTHON_PN}-pytest \
+${PYTHON_PN}-unittest-automake-output \
+"
+
+do_install_ptest() {
+install -d ${D}${PTEST_PATH}/tests
+cp -rf ${S}/tests ${D}${PTEST_PATH}/
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180968):
https://lists.openembedded.org/g/openembedded-core/message/180968
Mute This Topic: https://lists.openembedded.org/mt/98712276/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v3] python3-trove-classifiers: Add recipe
python3-trove-classifiers is "Canonical source for classifiers on
PyPI.". It is required to update python3-hatchling from the current
version (1.13.0) in oe-core, and depends on python3-calver (another new
recipe). Also add ptests.
Signed-off-by: Trevor Gamblin
---
v3 adds these revision notices in the right place.
v2 adds maintainer info to maintainers.inc.
meta/conf/distro/include/maintainers.inc | 1 +
.../distro/include/ptest-packagelists.inc | 1 +
.../python3-trove-classifiers/run-ptest | 3 +++
.../python3-trove-classifiers_2023.4.29.bb| 26 +++
4 files changed, 31 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3-trove-classifiers/run-ptest
create mode 100644
meta/recipes-devtools/python/python3-trove-classifiers_2023.4.29.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 4853a905ef..650c7fc076 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -699,6 +699,7 @@ RECIPE_MAINTAINER:pn-python3-subunit = "Oleksandr Kravchuk
https://github.com/pypa/trove-classifiers;
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
+
+SRC_URI[sha256sum] =
"8adcc06f1eb7c495f0bdceb698bd9c044b3e57b0d5767d99ec4b6b17c9bbe957"
+
+inherit pypi python_setuptools_build_meta ptest
+
+DEPENDS += " python3-calver-native"
+
+SRC_URI += " \
+file://run-ptest \
+"
+
+RDEPENDS:${PN}-ptest += " \
+ ${PYTHON_PN}-pytest \
+ ${PYTHON_PN}-unittest-automake-output \
+"
+
+do_install_ptest() {
+ install -d ${D}${PTEST_PATH}/tests
+ cp -rf ${S}/tests/* ${D}${PTEST_PATH}/tests/
+}
+
+BBCLASSEXTEND = "native nativesdk"
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180969):
https://lists.openembedded.org/g/openembedded-core/message/180969
Mute This Topic: https://lists.openembedded.org/mt/98712278/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
Le ven. 5 mai 2023, 20:21, Trevor Gamblin a écrit : > > On 2023-05-05 13:37, Alexander Kanavin wrote: > > There is > > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded > > and some additional pages linked from it: > > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > > http://www.openembedded.org/wiki/Styleguide > > > > The wiki is not great, and needs improvements, but the problem is it's > > difficult to write an authoritative and comprehensive answer to the > > questions you ask because there's just so many possible things one > > could check with any change to yocto. If you touch a recipe, you > > should of course check that 'bitbake recipe' still completes without > > an error. But that's obvious, isn't it? Beyond that... it depends. And > > requires a bit of intuition and experience, or advice from someone who > > knows the specific item better. > > > > We generally don't expect people to learn 'the rules' upfront - just > > write some code, and if you're not certain how to test it properly or > > whether it even makes sense, submit the patch as RFC and ask to take a > > look. If it fails in integration testing, you'll hear about it too, > > and that's normal and expected for anything more complex than a typo > > fix. My patches appear 'perfect' only because I pre-test them myself > > on the autobuilder :) > > > > Where we would *greatly* appreciate help is a special bot called > > patchtest that used to check mailing list submissions for common > > problems. That fell into disrepair due to lack of maintenance. Fixing > > that would be fantastic - and people could run it locally too. That > > could act as both a repository of rules-as-code, and a way to check > > them automatically. It could also offer hints for testing, depending > > on what the change touches. All sorts of nice things, if there is a > > person looking after it. > > I'm actually working on getting patchtest running again, and I've > assigned myself as maintainer :) > > To add to what Alex said, a good place for you to start might be looking > at the Newcomer Bugs list: > https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs > > Alternatively, watching AUH failures and figuring out broken upgrades, What is AUH? Where I can see broken upgrades you talked about? And more important to me, how can I replicate them to investigate on my side? > or looking on the Bugzilla under terms like "ptest" could also be very > useful, while providing better understanding of how recipes are written > and being somewhat more accessible. > > You can also ask questions in the #yocto channel on the Libera.Chat IRC > server if you need additional help. > > - Trevor > > > > > Alex > > > > On Fri, 5 May 2023 at 19:17, Frederic Martinsons > > wrote: > >> Hello list > >> > >> I'm wondering if there are documentations on how contribution are > managed for the project. > >> > >> I try to find some but didn't manage to. There are easily reachable doc > about how to contribute of course (how to make patches, fixe your identity, > send mail via git... etc) but I didn't find what I usually find on other > open source project (CONTRIBUTING.md file most of the time) like > >>- what are the tests do should I run before submitting (I learnt by > practice about test image or bitbake selftest for example) ? > >>- is there a specific configuration that I should test before > submitting (poky is ok, or should I also test another distro)? > >>- does some commit writing rules exist ? (some projects want commits > to begin with a prefix, usually the software component that is modified by > the patch for example) > >> - what are the coding rules you should follow, if any? (having common > coding rules helps greatly the review of patches, pylint for python code > for example, and I saw there are some bitbake recipes linter from meta-sca > layer) > >> > >> Long story short, I really would like to know what are the different > steps a patch should go through before being merged into master (and as a > side question, what are the steps for a patch to be backported into one of > the LTS branch). > >> > >> I'm deeply sorry if all these questions are obvious to you and have > been already answered somewhere, in that case, please just give me the link. > >> > >> I recently started to contribute to yocto / oe and I think it will help > me to make better contributions if I know more of how it works "under the > hood". > >> > >> Best regards. > >> > >> > >> > >> > >> > >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180967): https://lists.openembedded.org/g/openembedded-core/message/180967 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
Le ven. 5 mai 2023, 19:37, Alexander Kanavin a écrit : > There is > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded I do know this one. > > and some additional pages linked from it: > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines > http://www.openembedded.org/wiki/Styleguide I didn't know about these two links, thanks Alexander (and I'll slap myself for not following the links from the first page you mentioned) > > The wiki is not great, and needs improvements, but the problem is it's > difficult to write an authoritative and comprehensive answer to the > questions you ask because there's just so many possible things one > could check with any change to yocto. If you touch a recipe, you > should of course check that 'bitbake recipe' still completes without > an error. But that's obvious, isn't it? Of course it is. I even do a clean of shared state before that, just to be sure (shared state had often caused me trouble in the past). Beyond that... it depends. And > requires a bit of intuition and experience, or advice from someone who > knows the specific item better. > > We generally don't expect people to learn 'the rules' upfront - just > write some code, and if you're not certain how to test it properly or > whether it even makes sense, submit the patch as RFC and ask to take a > look. That's what I did for unit test of rust recipes and I didn't get much comments beside you and khem 15 days ago. And I still don't know if my patches are an issue or if nobody had the time to look at them, it's pretty frustrating. By the way, the statement "just write some code and publish on the list for comments" can be a blocker for a newcomer which don't know about the rules. During my career, I often saw people too shy to contribute because they thought they didn't meet the requirements. I'm sure everyone here is willing to help newcomers but having a clear entry point (a front web page on oe/yocto site on how to make a good contribution and clear guidelines to follow ) can be a relief for shy people. If it fails in integration testing, you'll hear about it too, > and that's normal and expected for anything more complex than a typo > fix. My patches appear 'perfect' only because I pre-test them myself > on the autobuilder :) > I would like to know about these, I hear a lot in this list about autobuilder and it seems close to what I know of continuous integration (some build of multiple configuration with the submitted patch and tests towards that) but I don't know how to replicate the config of those locally on my machine (in case of errors), do you have any links for that? Where we would *greatly* appreciate help is a special bot called > patchtest that used to check mailing list submissions for common > problems. That fell into disrepair due to lack of maintenance. Fixing > that would be fantastic - and people could run it locally too. That > could act as both a repository of rules-as-code, and a way to check > them automatically. It could also offer hints for testing, depending > on what the change touches. All sorts of nice things, if there is a > person looking after it. > > Alex > Ah great, if you point me to where I can find insights about this patchset test framework, I would gladly offer my help to fox the issue. From what you are saying, I understand that fixing this will make the contribution smoothier. On Fri, 5 May 2023 at 19:17, Frederic Martinsons > wrote: > > > > Hello list > > > > I'm wondering if there are documentations on how contribution are > managed for the project. > > > > I try to find some but didn't manage to. There are easily reachable doc > about how to contribute of course (how to make patches, fixe your identity, > send mail via git... etc) but I didn't find what I usually find on other > open source project (CONTRIBUTING.md file most of the time) like > > - what are the tests do should I run before submitting (I learnt by > practice about test image or bitbake selftest for example) ? > > - is there a specific configuration that I should test before > submitting (poky is ok, or should I also test another distro)? > > - does some commit writing rules exist ? (some projects want commits > to begin with a prefix, usually the software component that is modified by > the patch for example) > > - what are the coding rules you should follow, if any? (having common > coding rules helps greatly the review of patches, pylint for python code > for example, and I saw there are some bitbake recipes linter from meta-sca > layer) > > > > Long story short, I really would like to know what are the different > steps a patch should go through before being merged into master (and as a > side question, what are the steps for a patch to be backported into one of > the LTS branch). > > > > I'm deeply sorry if all these questions are obvious to you and have been > already answered somewhere, in that case, please just give me the link. > >
Re: [OE-core] Contributing, how it works?
On 2023-05-05 13:37, Alexander Kanavin wrote: There is http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and some additional pages linked from it: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines http://www.openembedded.org/wiki/Styleguide The wiki is not great, and needs improvements, but the problem is it's difficult to write an authoritative and comprehensive answer to the questions you ask because there's just so many possible things one could check with any change to yocto. If you touch a recipe, you should of course check that 'bitbake recipe' still completes without an error. But that's obvious, isn't it? Beyond that... it depends. And requires a bit of intuition and experience, or advice from someone who knows the specific item better. We generally don't expect people to learn 'the rules' upfront - just write some code, and if you're not certain how to test it properly or whether it even makes sense, submit the patch as RFC and ask to take a look. If it fails in integration testing, you'll hear about it too, and that's normal and expected for anything more complex than a typo fix. My patches appear 'perfect' only because I pre-test them myself on the autobuilder :) Where we would *greatly* appreciate help is a special bot called patchtest that used to check mailing list submissions for common problems. That fell into disrepair due to lack of maintenance. Fixing that would be fantastic - and people could run it locally too. That could act as both a repository of rules-as-code, and a way to check them automatically. It could also offer hints for testing, depending on what the change touches. All sorts of nice things, if there is a person looking after it. I'm actually working on getting patchtest running again, and I've assigned myself as maintainer :) To add to what Alex said, a good place for you to start might be looking at the Newcomer Bugs list: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Alternatively, watching AUH failures and figuring out broken upgrades, or looking on the Bugzilla under terms like "ptest" could also be very useful, while providing better understanding of how recipes are written and being somewhat more accessible. You can also ask questions in the #yocto channel on the Libera.Chat IRC server if you need additional help. - Trevor Alex On Fri, 5 May 2023 at 19:17, Frederic Martinsons wrote: Hello list I'm wondering if there are documentations on how contribution are managed for the project. I try to find some but didn't manage to. There are easily reachable doc about how to contribute of course (how to make patches, fixe your identity, send mail via git... etc) but I didn't find what I usually find on other open source project (CONTRIBUTING.md file most of the time) like - what are the tests do should I run before submitting (I learnt by practice about test image or bitbake selftest for example) ? - is there a specific configuration that I should test before submitting (poky is ok, or should I also test another distro)? - does some commit writing rules exist ? (some projects want commits to begin with a prefix, usually the software component that is modified by the patch for example) - what are the coding rules you should follow, if any? (having common coding rules helps greatly the review of patches, pylint for python code for example, and I saw there are some bitbake recipes linter from meta-sca layer) Long story short, I really would like to know what are the different steps a patch should go through before being merged into master (and as a side question, what are the steps for a patch to be backported into one of the LTS branch). I'm deeply sorry if all these questions are obvious to you and have been already answered somewhere, in that case, please just give me the link. I recently started to contribute to yocto / oe and I think it will help me to make better contributions if I know more of how it works "under the hood". Best regards. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180965): https://lists.openembedded.org/g/openembedded-core/message/180965 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] python3-attrs: upgrade 22.2.0 -> 23.1.0
* Change inherit python_setuptools_build_meta to python_hatchling
* Add DEPENDS:
- python3-hatch-vcs-native
- python3-hatch-fancy-pypi-readme-native
Changes:
https://www.attrs.org/en/stable/changelog.html
Signed-off-by: Tim Orling
---
.../{python3-attrs_22.2.0.bb => python3-attrs_23.1.0.bb} | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-attrs_22.2.0.bb =>
python3-attrs_23.1.0.bb} (63%)
diff --git a/meta/recipes-devtools/python/python3-attrs_22.2.0.bb
b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
similarity index 63%
rename from meta/recipes-devtools/python/python3-attrs_22.2.0.bb
rename to meta/recipes-devtools/python/python3-attrs_23.1.0.bb
index 8c1ff330e7b..c8e2e514a43 100644
--- a/meta/recipes-devtools/python/python3-attrs_22.2.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.1.0.bb
@@ -3,9 +3,14 @@ HOMEPAGE = "http://www.attrs.org/;
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5e55731824cf9205cfabeab9a0600887"
-SRC_URI[sha256sum] =
"c9227bfc2f01993c03f68db37d1d15c9690188323c067c641f1a35ca58185f99"
+SRC_URI[sha256sum] =
"6279836d581513a26f1bf235f9acd333bc9115683f14f7e8fae46c98fc50e015"
-inherit pypi python_setuptools_build_meta
+inherit pypi python_hatchling
+
+DEPENDS += " \
+${PYTHON_PN}-hatch-vcs-native \
+${PYTHON_PN}-hatch-fancy-pypi-readme-native \
+"
RDEPENDS:${PN}:class-target += " \
${PYTHON_PN}-crypt \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180964):
https://lists.openembedded.org/g/openembedded-core/message/180964
Mute This Topic: https://lists.openembedded.org/mt/98711506/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Yocto Project Community Manager updates
Nico, thanks fo all your contributions to project. We will miss you. On Thu, May 4, 2023 at 7:40 AM Nicolas Dechesne wrote: > > Dear all, > > After five years, I have decided to resign from my position as the Yocto > Project Community Manager. I joined the OpenEmbedded community around 2008. I > have fond memories of my early days, and still remember some of my first > interactions on IRC and mailing lists! This is a very welcoming community, > always helping new people with patience and kindness. Serving the project > during the last five years is something I am very proud of, and I will be > forever grateful to all of you for accepting me! > > During these years, we have gone through a lot together, the pandemic gave us > an opportunity to rethink how our community should come together. Setting up > our Virtual Summits has been a lot of work (and stress!) for a group of few > people, but the never ending success of these events has been very rewarding! > Our online presence in social media has dramatically improved, and allows us > to reach out to and interact with our community faster than ever before! > > On the side of all the technical changes, and releases, we have also > established the Yocto LTS process which was a recurring request from the > community and has become a strength of the project! We also revamped the > project documentation to make it easier to maintain and contribute. The Yocto > Project documentation is such a great resource for our community! I have > spent so many hours on these PDFs in my early days! > > Anyway, let’s not focus on the past! The future looks bright and I am really > excited to announce that Josef Holzmayr has accepted to take over the > Community Manager role. Josef needs no introduction, he has been a key member > of this community for so many years. Thanks to Josef's relentless efforts, we > have grown our social media presence on Youtube, Twitter, LinkedIn and > Mastodon! His energy will be a great source of inspiration for this > community! I wish Josef and Yocto the best for the years to come, and I am > convinced this community is in good hands and that Josef will be a great > community leader! > > Many thanks! > Nico > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180963): https://lists.openembedded.org/g/openembedded-core/message/180963 Mute This Topic: https://lists.openembedded.org/mt/98685136/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Contributing, how it works?
There is http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and some additional pages linked from it: http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines http://www.openembedded.org/wiki/Styleguide The wiki is not great, and needs improvements, but the problem is it's difficult to write an authoritative and comprehensive answer to the questions you ask because there's just so many possible things one could check with any change to yocto. If you touch a recipe, you should of course check that 'bitbake recipe' still completes without an error. But that's obvious, isn't it? Beyond that... it depends. And requires a bit of intuition and experience, or advice from someone who knows the specific item better. We generally don't expect people to learn 'the rules' upfront - just write some code, and if you're not certain how to test it properly or whether it even makes sense, submit the patch as RFC and ask to take a look. If it fails in integration testing, you'll hear about it too, and that's normal and expected for anything more complex than a typo fix. My patches appear 'perfect' only because I pre-test them myself on the autobuilder :) Where we would *greatly* appreciate help is a special bot called patchtest that used to check mailing list submissions for common problems. That fell into disrepair due to lack of maintenance. Fixing that would be fantastic - and people could run it locally too. That could act as both a repository of rules-as-code, and a way to check them automatically. It could also offer hints for testing, depending on what the change touches. All sorts of nice things, if there is a person looking after it. Alex On Fri, 5 May 2023 at 19:17, Frederic Martinsons wrote: > > Hello list > > I'm wondering if there are documentations on how contribution are managed for > the project. > > I try to find some but didn't manage to. There are easily reachable doc about > how to contribute of course (how to make patches, fixe your identity, send > mail via git... etc) but I didn't find what I usually find on other open > source project (CONTRIBUTING.md file most of the time) like > - what are the tests do should I run before submitting (I learnt by > practice about test image or bitbake selftest for example) ? > - is there a specific configuration that I should test before submitting > (poky is ok, or should I also test another distro)? > - does some commit writing rules exist ? (some projects want commits to > begin with a prefix, usually the software component that is modified by the > patch for example) > - what are the coding rules you should follow, if any? (having common coding > rules helps greatly the review of patches, pylint for python code for > example, and I saw there are some bitbake recipes linter from meta-sca layer) > > Long story short, I really would like to know what are the different steps a > patch should go through before being merged into master (and as a side > question, what are the steps for a patch to be backported into one of the LTS > branch). > > I'm deeply sorry if all these questions are obvious to you and have been > already answered somewhere, in that case, please just give me the link. > > I recently started to contribute to yocto / oe and I think it will help me to > make better contributions if I know more of how it works "under the hood". > > Best regards. > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180962): https://lists.openembedded.org/g/openembedded-core/message/180962 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: preserve libraries when rm_work is used
On Fri, May 5, 2023 at 6:24 AM Jose Quaresma wrote:
>
> Hi Bruce,
>
> Jose Quaresma via lists.openembedded.org
> escreveu no dia quarta,
> 3/05/2023 à(s) 11:09:
>>
>>
>>
>> Bruce Ashfield escreveu no dia terça, 2/05/2023
>> à(s) 22:12:
>>>
>>> Attached is v2 of the patch. I've consolidated the suggested changes.
>>>
>>> I'm soaking it a bit longer, and then will send it as part of my next
>>> consolidated pull request.
>>
>>
>> I will do some more tests with the v2 and post my comment later if anything
>> new comes up.
>
>
> Nothing new and the v2 patch works pretty well in my kernels.
>
Awesome. Thanks for the test and update!
Bruce
> Jose
>
>>
>>
>> Jose
>>
>>>
>>>
>>> Bruce
>>>
>>> On Thu, Apr 27, 2023 at 9:26 PM Bruce Ashfield via
>>> lists.openembedded.org
>>> wrote:
>>> >
>>> > On Thu, Apr 27, 2023 at 6:32 PM Jose Quaresma
>>> > wrote:
>>> > >
>>> > > Hi Bruce,
>>> > >
>>> > > I have been testing your patch and have some comments.
>>> > > In some of my kernels I don't have the pkg-config changes and so I have
>>> > > some fails linking the scripts/sign-file
>>> > > because for static linking with the libcrypto we need the -ldl -pthread.
>>> > >
>>> > > To fix my build I need to override the CRYPTO_LIBS in my kernel because
>>> > > they use the hardcoded pkg-config
>>> > > where it is not possible to pass the --static argument.
>>> > >
>>> > > With following change on top of your patch I can build moist of my
>>> > > kernels:
>>> > >
>>> > > export HOSTLDFLAGS="-lz"
>>> > >
>>> > > + HOSTPKG_CONFIG="pkg-config --static"
>>> > > + # override CRYPTO_LIBS since HOSTPKG_CONFIG lands only in
>>> > > v5.19-rc1
>>> > > + #
>>> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5ea4fece4508bf8e72b659cd22fa4840d8d61e5
>>> > > + CRYPTO_LIBS="$(pkg-config --static --libs libcrypto 2>/dev/null
>>> > > || echo -lcrypto)"
>>> > > +
>>> > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>> > > for t in prepare scripts_basic scripts; do
>>> > > oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>>> > > AR="${KERNEL_AR}" OBJCOPY="${KERNEL_OBJCOPY}" \
>>> > > - HOSTPKG_CONFIG="pkg-config --static" \
>>> > > + HOSTPKG_CONFIG="${HOSTPKG_CONFIG}"
>>> > > CRYPTO_LIBS="${CRYPTO_LIBS}" \
>>> > > -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} $t
>>> > > done
>>> > >
>>> > >
>>> > > I think belive that the LIBELF_LIBS needs the same fix for the cases
>>> > > where HOSTPKG_CONFIG is not available.
>>> > > Also I think there is a typo in the LIBELF_LIBS because you first
>>> > > populate it with pkg-config but on the export the variable is redefined
>>> > > with the HOST_LIBELF_LIBS. I made a litle change too on that:
>>> > >
>>> > > # for pre-5.15 kernels
>>> > > - LIBELF_LIBS=$(pkg-config libelf --libs 2>/dev/null || echo
>>> > > -lelf)
>>> > > - export LIBELF_LIBS="$HOST_LIBELF_LIBS -lz"
>>> > > + LIBELF_LIBS=$(pkg-config --static libelf --libs 2>/dev/null ||
>>> > > echo -lelf)
>>> > > + export LIBELF_LIBS="$LIBELF_LIBS -lz"
>>> > > export HOSTLDFLAGS="-lz"
>>> > >
>>> > > Thanks for you help.
>>> >
>>> > Those are definitely plausible tweaks to the patch, I was providing
>>> > the two techniques for that reason, and you've used them
>>> > appropriately.
>>> >
>>> > Let me roll your changes into my patch, re-test and I'll submit it to
>>> > the mailing list as a v2.
>>> >
>>> > Thanks for the testing, and fixup, I knew there would be things missing!
>>> > :)
>>> >
>>> > Bruce
>>> >
>>> > >
>>> > > Jose
>>> > >
>>> > > Bruce Ashfield escreveu no dia segunda,
>>> > > 24/04/2023 à(s) 20:25:
>>> > >>
>>> > >> On Mon, Apr 24, 2023 at 6:30 AM Jose Quaresma
>>> > >> wrote:
>>> > >> >
>>> > >> >
>>> > >> >
>>> > >> > Bruce Ashfield escreveu no dia domingo,
>>> > >> > 23/04/2023 à(s) 20:55:
>>> > >> >>
>>> > >> >> On Sat, Apr 22, 2023 at 9:06 AM Christoph Lauer
>>> > >> >> wrote:
>>> > >> >> >
>>> > >> >> > Am 21.04.23 um 22:28 schrieb Bruce Ashfield:
>>> > >> >> > > On Wed, Apr 19, 2023 at 11:03 PM Bruce Ashfield via
>>> > >> >> > > lists.openembedded.org
>>> > >> >> > > wrote:
>>> > >> >> > >>
>>> > >> >> > >> On Wed, Apr 19, 2023 at 6:54 PM Richard Purdie
>>> > >> >> > >> wrote:
>>> > >> >> > >>>
>>> > >> >> > >>> On Wed, 2023-04-19 at 23:34 +0100, Jose Quaresma wrote:
>>> > >> >> > Hi,
>>> > >> >> >
>>> > >> >> > Not related with the previous discussion but just for
>>> > >> >> > your information.
>>> > >> >> > The rm_work.bbclass has an exception for the kernel recipes
>>> > >> >> > [1].
>>> > >> >> > So I don't understand why we can't do the same for the
>>> > >> >> > make-mod-
>>> > >> >> > scripts
>>> > >> >> > who is the twin brother of all these kernel recipes.
>>> > >> >> >
>>> > >> >> > [1]
>>> > >> >> >
[OE-core] Contributing, how it works?
Hello list I'm wondering if there are documentations on how contribution are managed for the project. I try to find some but didn't manage to. There are easily reachable doc about how to contribute of course (how to make patches, fixe your identity, send mail via git... etc) but I didn't find what I usually find on other open source project (CONTRIBUTING.md file most of the time) like - what are the tests do should I run before submitting (I learnt by practice about test image or bitbake selftest for example) ? - is there a specific configuration that I should test before submitting (poky is ok, or should I also test another distro)? - does some commit writing rules exist ? (some projects want commits to begin with a prefix, usually the software component that is modified by the patch for example) - what are the coding rules you should follow, if any? (having common coding rules helps greatly the review of patches, pylint for python code for example, and I saw there are some bitbake recipes linter from meta-sca layer) Long story short, I really would like to know what are the different steps a patch should go through before being merged into master (and as a side question, what are the steps for a patch to be backported into one of the LTS branch). I'm deeply sorry if all these questions are obvious to you and have been already answered somewhere, in that case, please just give me the link. I recently started to contribute to yocto / oe and I think it will help me to make better contributions if I know more of how it works "under the hood". Best regards. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180960): https://lists.openembedded.org/g/openembedded-core/message/180960 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [Yocto-Advocacy] Yocto Project Community Manager updates
Nico: you did a fantastic job as Community Manager, as I knew you would. You always do a great job with everything you take on, and this endeavour was no exception. Your help with the virtual summits is especially appreciated; they wouldn't have happened without your help. Jeffro did a great job setting the tone for this role; you continued on his great work and made the Yocto Project even better. My congratulations to you. Josef has been a visible member of the community for a while. It's exciting to see him take on an even greater role within the community. I know Josef will waste no time making this position his own, and doing interesting things with it! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180959): https://lists.openembedded.org/g/openembedded-core/message/180959 Mute This Topic: https://lists.openembedded.org/mt/98709874/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH 1/1] python3-cryptography: fix for CVE-2023-23931
From: Narpat Mali
cryptography is a package designed to expose cryptographic primitives
and recipes to Python developers. In affected versions `Cipher.update_into`
would accept Python objects which implement the buffer protocol, but
provide only immutable buffers. This would allow immutable objects
(such as `bytes`) to be mutated, thus violating fundamental rules of
Python and resulting in corrupted output. This now correctly raises
an exception. This issue has been present since `update_into` was
originally introduced in cryptography 1.8.
Signed-off-by: Narpat Mali
---
.../python3-cryptography/CVE-2023-23931.patch | 49 +++
.../python/python3-cryptography_36.0.2.bb | 1 +
2 files changed, 50 insertions(+)
create mode 100644
meta/recipes-devtools/python/python3-cryptography/CVE-2023-23931.patch
diff --git
a/meta/recipes-devtools/python/python3-cryptography/CVE-2023-23931.patch
b/meta/recipes-devtools/python/python3-cryptography/CVE-2023-23931.patch
new file mode 100644
index 00..5fc4878978
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-cryptography/CVE-2023-23931.patch
@@ -0,0 +1,49 @@
+From 9fbf84efc861668755ab645530ec7be9cf3c6696 Mon Sep 17 00:00:00 2001
+From: Alex Gaynor
+Date: Tue, 7 Feb 2023 11:34:18 -0500
+Subject: [PATCH] Don't allow update_into to mutate immutable objects (#8230)
+
+CVE: CVE-2023-23931
+
+Upstream-Status: Backport
[https://github.com/pyca/cryptography/commit/9fbf84efc861668755ab645530ec7be9cf3c6696]
+
+Signed-off-by: Narpat Mali
+---
+ src/cryptography/hazmat/backends/openssl/ciphers.py | 2 +-
+ tests/hazmat/primitives/test_ciphers.py | 8
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/src/cryptography/hazmat/backends/openssl/ciphers.py
b/src/cryptography/hazmat/backends/openssl/ciphers.py
+index 286583f93..075d68fb9 100644
+--- a/src/cryptography/hazmat/backends/openssl/ciphers.py
b/src/cryptography/hazmat/backends/openssl/ciphers.py
+@@ -156,7 +156,7 @@ class _CipherContext:
+ data_processed = 0
+ total_out = 0
+ outlen = self._backend._ffi.new("int *")
+-baseoutbuf = self._backend._ffi.from_buffer(buf)
++baseoutbuf = self._backend._ffi.from_buffer(buf,
require_writable=True)
+ baseinbuf = self._backend._ffi.from_buffer(data)
+
+ while data_processed != total_data_len:
+diff --git a/tests/hazmat/primitives/test_ciphers.py
b/tests/hazmat/primitives/test_ciphers.py
+index 02127dd9c..bf3b047de 100644
+--- a/tests/hazmat/primitives/test_ciphers.py
b/tests/hazmat/primitives/test_ciphers.py
+@@ -318,6 +318,14 @@ class TestCipherUpdateInto:
+ with pytest.raises(ValueError):
+ encryptor.update_into(b"testing", buf)
+
++def test_update_into_immutable(self, backend):
++key = b"\x00" * 16
++c = ciphers.Cipher(AES(key), modes.ECB(), backend)
++encryptor = c.encryptor()
++buf = b"\x00" * 32
++with pytest.raises((TypeError, BufferError)):
++encryptor.update_into(b"testing", buf)
++
+ @pytest.mark.supported(
+ only_if=lambda backend: backend.cipher_supported(
+ AES(b"\x00" * 16), modes.GCM(b"\x00" * 12)
+--
+2.40.0
diff --git a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb
b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb
index 9ef5ff39c8..c3ae0c1ab9 100644
--- a/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb
+++ b/meta/recipes-devtools/python/python3-cryptography_36.0.2.bb
@@ -17,6 +17,7 @@ SRC_URI += " \
file://0001-Cargo.toml-specify-pem-version.patch \
file://0002-Cargo.toml-edition-2018-2021.patch \
file://fix-leak-metric.patch \
+file://CVE-2023-23931.patch \
"
inherit pypi python_setuptools3_rust
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180958):
https://lists.openembedded.org/g/openembedded-core/message/180958
Mute This Topic: https://lists.openembedded.org/mt/98709853/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/5] insane.bbclass: add a SUMMARY/HOMEPAGE check (oe-core recipes only)
On Fri, 5 May 2023 at 13:43, Ross Burton wrote: > I’m torn over this and the maintainer check. I like that the checks are > being done earlier so they don’t trip up in oe-selftest, but I don’t like > that they’re errors. > > If I want to add a new recipe to core and use devtool, it will immediately > fail to build with errors due to the summary, homepage, and maintainer fields > being missing. For this reason, I believe these should be warnings: they > tell you that something needs to be done, but you can focus first on making a > recipe that *compiles* before having to write a nice summary. No problem. I'll correct that. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180957): https://lists.openembedded.org/g/openembedded-core/message/180957 Mute This Topic: https://lists.openembedded.org/mt/98532469/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] kernel-devicetree: allow specification of dtb directory
From: Randolph Sapp
Fedora/Redhat and Arch are somewhat standardized on their dtb directory
structure. Let's add some flags to configure yocto to mimic that
behavior.
Add the following variables to the kernel class:
- KERNEL_DTBDEST (controls the destination directory for dtbs)
- KERNEL_DTBVENDORED (controls if vendor subdirectories are to
be respected)
Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST
and KERNEL_DTBVENDORED is expected to be "true"/"false". This only
applies to the package directory structure. The deploydir structure is
purposely left untouched for compatibility with existing recipes.
By default this is configured to behave the same as the current recipe
and produce a flat dtb directory at KERNEL_IMAGEDEST.
Signed-off-by: Randolph Sapp
---
Well, suppose I was breaking things by submitting this to kirkstone
first. This is just the master version of the following patchset:
https://lists.openembedded.org/g/openembedded-core/message/180754
I'd love to get that series merged as well if this patch is acceptable.
meta/classes-recipe/kernel-devicetree.bbclass | 22 ++-
meta/classes-recipe/kernel.bbclass| 2 ++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/meta/classes-recipe/kernel-devicetree.bbclass
b/meta/classes-recipe/kernel-devicetree.bbclass
index 4d0ecb1032..a6c6c5f227 100644
--- a/meta/classes-recipe/kernel-devicetree.bbclass
+++ b/meta/classes-recipe/kernel-devicetree.bbclass
@@ -12,7 +12,12 @@ python () {
d.appendVar("PACKAGES", "
${KERNEL_PACKAGE_NAME}-image-zimage-bundle")
}
-FILES:${KERNEL_PACKAGE_NAME}-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
/${KERNEL_IMAGEDEST}/*.dtbo"
+FILES:${KERNEL_PACKAGE_NAME}-devicetree = " \
+/${KERNEL_DTBDEST}/*.dtb \
+/${KERNEL_DTBDEST}/*.dtbo \
+/${KERNEL_DTBDEST}/*/*.dtb \
+/${KERNEL_DTBDEST}/*/*.dtbo \
+"
FILES:${KERNEL_PACKAGE_NAME}-image-zimage-bundle =
"/${KERNEL_IMAGEDEST}/zImage-*.dtb.bin"
# Generate kernel+devicetree bundle
@@ -73,12 +78,16 @@ do_compile:append() {
}
do_install:append() {
+ install -d ${D}/${KERNEL_DTBDEST}
for dtbf in ${KERNEL_DEVICETREE}; do
dtb=`normalize_dtb "$dtbf"`
- dtb_ext=${dtb##*.}
- dtb_base_name=`basename $dtb .$dtb_ext`
dtb_path=`get_real_dtb_path_in_kernel "$dtb"`
- install -m 0644 $dtb_path
${D}/${KERNEL_IMAGEDEST}/$dtb_base_name.$dtb_ext
+ if [ ${KERNEL_DTBVENDORED} == "false" ]; then
+ dtb_ext=${dtb##*.}
+ dtb_base_name=`basename $dtb .$dtb_ext`
+ dtb=$dtb_base_name.$dtb_ext
+ fi
+ install -Dm 0644 $dtb_path ${D}/${KERNEL_DTBDEST}/$dtb
done
}
@@ -88,7 +97,10 @@ do_deploy:append() {
dtb_ext=${dtb##*.}
dtb_base_name=`basename $dtb .$dtb_ext`
install -d $deployDir
- install -m 0644
${D}/${KERNEL_IMAGEDEST}/$dtb_base_name.$dtb_ext
$deployDir/$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext
+ if [ ${KERNEL_DTBVENDORED} == "false" ]; then
+ dtb=$dtb_base_name.$dtb_ext
+ fi
+ install -m 0644 ${D}/${KERNEL_DTBDEST}/$dtb
$deployDir/$dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext
if [ "${KERNEL_IMAGETYPE_SYMLINK}" = "1" ] ; then
ln -sf $dtb_base_name-${KERNEL_DTB_NAME}.$dtb_ext
$deployDir/$dtb_base_name.$dtb_ext
fi
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index e634eabd49..8f022b234d 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -215,6 +215,8 @@ KERNEL_RELEASE ?= "${KERNEL_VERSION}"
# The directory where built kernel lies in the kernel tree
KERNEL_OUTPUT_DIR ?= "arch/${ARCH}/boot"
KERNEL_IMAGEDEST ?= "boot"
+KERNEL_DTBDEST ?= "${KERNEL_IMAGEDEST}"
+KERNEL_DTBVENDORED ?= "false"
#
# configuration
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180956):
https://lists.openembedded.org/g/openembedded-core/message/180956
Mute This Topic: https://lists.openembedded.org/mt/98709532/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 34/35] kernel: improve initramfs bundle processing time
From: Bruce Ashfield
This is a partial fix for bugzilla 15059
[https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
Signed-off-by: Bruce Ashfield
Signed-off-by: Luca Ceresoli
(cherry picked from commit 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Steve Sakoman
---
meta/classes-recipe/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/kernel.bbclass
b/meta/classes-recipe/kernel.bbclass
index aefa0d21bc..e634eabd49 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -382,7 +382,7 @@ kernel_do_compile() {
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
fi
for typeformake in ${KERNEL_IMAGETYPE_FOR_MAKE} ; do
- oe_runmake ${typeformake} ${KERNEL_EXTRA_ARGS}
$use_alternate_initrd
+ oe_runmake ${PARALLEL_MAKE} ${typeformake} ${KERNEL_EXTRA_ARGS}
$use_alternate_initrd
done
}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180954):
https://lists.openembedded.org/g/openembedded-core/message/180954
Mute This Topic: https://lists.openembedded.org/mt/98707905/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 35/35] update-alternatives.bbclass: fix old override syntax
From: Peter Bergin
Function 'gen_updatealternativesvardeps' still used old override
syntax when fetching variable flags. Update to use ':' instead to match
recipe meta data. This was found by review and no real issue encountered
but it is a bug that affects variable dependencies and can affect rebuilds
as task hashes might not be accurate.
Signed-off-by: Peter Bergin
Signed-off-by: Peter Bergin
Signed-off-by: Richard Purdie
(cherry picked from commit 5691f554b2cd50f256a8cbb1d96781e9eb6b930e)
Signed-off-by: Steve Sakoman
---
meta/classes-recipe/update-alternatives.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes-recipe/update-alternatives.bbclass
b/meta/classes-recipe/update-alternatives.bbclass
index 36a7497fec..b153e1b297 100644
--- a/meta/classes-recipe/update-alternatives.bbclass
+++ b/meta/classes-recipe/update-alternatives.bbclass
@@ -86,10 +86,10 @@ def gen_updatealternativesvardeps(d):
for p in pkgs:
for v in vars:
-for flag in sorted((d.getVarFlags("%s_%s" % (v,p)) or {}).keys()):
+for flag in sorted((d.getVarFlags("%s:%s" % (v,p)) or {}).keys()):
if flag == "doc" or flag == "vardeps" or flag == "vardepsexp":
continue
-d.appendVar('%s_VARDEPS_%s' % (v,p), ' %s:%s' % (flag,
d.getVarFlag('%s_%s' % (v,p), flag, False)))
+d.appendVar('%s_VARDEPS_%s' % (v,p), ' %s:%s' % (flag,
d.getVarFlag('%s:%s' % (v,p), flag, False)))
def ua_extend_depends(d):
if not 'virtual/update-alternatives' in d.getVar('PROVIDES'):
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180955):
https://lists.openembedded.org/g/openembedded-core/message/180955
Mute This Topic: https://lists.openembedded.org/mt/98707907/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 33/35] oeqa/utils/metadata.py: Fix running oe-selftest running with no distro set
From: Thomas Roos
This will use default values when no distribution is set.
[YOCTO #15086]
Signed-off-by: Thomas Roos
Signed-off-by: Luca Ceresoli
(cherry picked from commit 888fe63b46efceeff08dbe8c4f66fec33d06cb7a)
Signed-off-by: Steve Sakoman
---
meta/lib/oeqa/utils/metadata.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/utils/metadata.py b/meta/lib/oeqa/utils/metadata.py
index 8013aa684d..15ec190c4a 100644
--- a/meta/lib/oeqa/utils/metadata.py
+++ b/meta/lib/oeqa/utils/metadata.py
@@ -27,9 +27,9 @@ def metadata_from_bb():
data_dict = get_bb_vars()
# Distro information
-info_dict['distro'] = {'id': data_dict['DISTRO'],
- 'version_id': data_dict['DISTRO_VERSION'],
- 'pretty_name': '%s %s' % (data_dict['DISTRO'],
data_dict['DISTRO_VERSION'])}
+info_dict['distro'] = {'id': data_dict.get('DISTRO', 'NODISTRO'),
+'version_id': data_dict.get('DISTRO_VERSION',
'NO_DISTRO_VERSION'),
+'pretty_name': '%s %s' %
(data_dict.get('DISTRO', 'NODISTRO'), data_dict.get('DISTRO_VERSION',
'NO_DISTRO_VERSION'))}
# Host distro information
os_release = get_os_release()
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180953):
https://lists.openembedded.org/g/openembedded-core/message/180953
Mute This Topic: https://lists.openembedded.org/mt/98707904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 32/35] qemu: Add fix for powerpc instruction fallback issue
From: Richard Purdie
See the patch for more details, fixes a regression in qemu causing
illegal instructions in libm on powerpc, triggered by a libinput
upgrade.
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f1c56cdff09f650ad721fae026eb6a3651631f3d
was the glibc code generating the instruction and triggering the issue.
Signed-off-by: Richard Purdie
Signed-off-by: Steve Sakoman
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
meta/recipes-devtools/qemu/qemu/ppc.patch | 70 +++
2 files changed, 71 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/ppc.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index e2453dd8bc..29bc34d743 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -35,6 +35,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch \
file://qemu-guest-agent.init \
file://qemu-guest-agent.udev \
+ file://ppc.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/qemu/qemu/ppc.patch
b/meta/recipes-devtools/qemu/qemu/ppc.patch
new file mode 100644
index 00..395cdb814f
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/ppc.patch
@@ -0,0 +1,70 @@
+target/ppc: Fix fallback to MFSS for MFFSCRN, MFFSCRNI, MFFSCE and MFFSL
+
+The following commits changed the code such that these instructions became
invalid
+on pre 3.0 ISAs:
+
+ bf8adfd88b547680aa857c46098f3a1e94373160 - target/ppc: Move mffscrn[i] to
decodetree
+ 394c2e2fda70da722f20fb60412d6c0ca4bfaa03 - target/ppc: Move mffsce to
decodetree
+ 3e5bce70efe6bd1f684efbb21fd2a316cbf0657e - target/ppc: Move mffsl to
decodetree
+
+The hardware will handle them as a MFFS instruction as the code did previously.
+Restore that behaviour. This means applications that were segfaulting under
qemu
+when encountering these instructions now operate correctly. The instruction
+is used in glibc libm functions for example.
+
+Upstream-Status: Submitted
[https://lore.kernel.org/qemu-devel/20230504110150.3044402-1-richard.pur...@linuxfoundation.org/]
+
+Signed-off-by: Richard Purdie
+
+Index: qemu-8.0.0/target/ppc/translate/fp-impl.c.inc
+===
+--- qemu-8.0.0.orig/target/ppc/translate/fp-impl.c.inc
qemu-8.0.0/target/ppc/translate/fp-impl.c.inc
+@@ -584,7 +584,10 @@ static bool trans_MFFSCE(DisasContext *c
+ {
+ TCGv_i64 fpscr;
+
+-REQUIRE_INSNS_FLAGS2(ctx, ISA300);
++if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
++return trans_MFFS(ctx, a);
++}
++
+ REQUIRE_FPU(ctx);
+
+ gen_reset_fpstatus();
+@@ -597,7 +600,10 @@ static bool trans_MFFSCRN(DisasContext *
+ {
+ TCGv_i64 t1, fpscr;
+
+-REQUIRE_INSNS_FLAGS2(ctx, ISA300);
++if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
++return trans_MFFS(ctx, a);
++}
++
+ REQUIRE_FPU(ctx);
+
+ t1 = tcg_temp_new_i64();
+@@ -631,7 +637,10 @@ static bool trans_MFFSCRNI(DisasContext
+ {
+ TCGv_i64 t1, fpscr;
+
+-REQUIRE_INSNS_FLAGS2(ctx, ISA300);
++if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
++return trans_MFFS(ctx, a);
++}
++
+ REQUIRE_FPU(ctx);
+
+ t1 = tcg_temp_new_i64();
+@@ -661,7 +670,10 @@ static bool trans_MFFSCDRNI(DisasContext
+ {
+ TCGv_i64 fpscr;
+
+-REQUIRE_INSNS_FLAGS2(ctx, ISA300);
++if (unlikely(!(ctx->insns_flags2 & PPC2_ISA300))) {
++return trans_MFFS(ctx, a);
++}
++
+ REQUIRE_FPU(ctx);
+
+ gen_reset_fpstatus();
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180952):
https://lists.openembedded.org/g/openembedded-core/message/180952
Mute This Topic: https://lists.openembedded.org/mt/98707896/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 31/35] libpam: Fix the xtests/tst-pam_motd[1|3] failures
From: Zhixiong Chi
Reproducer:
1.Enable the ptest of libpam and build the image.
2.Boot the rootfs with nfs, then run the following tests as root:
cd /usr/share/Linux-PAM/xtests
/usr/share/Linux-PAM/xtests# ./run-xtests.sh . tst-pam_motd1
/usr/share/Linux-PAM/xtests# ./run-xtests.sh . tst-pam_motd3
After applying this patch, the ptest doesn't be failed.
Signed-off-by: Zhixiong Chi
Signed-off-by: Luca Ceresoli
(cherry picked from commit 549e54ad6a175359b0a57987ccdab8989df9d3a9)
Signed-off-by: Steve Sakoman
---
...rely-on-all-filesystems-providing-a-.patch | 108 ++
meta/recipes-extended/pam/libpam_1.5.2.bb | 1 +
2 files changed, 109 insertions(+)
create mode 100644
meta/recipes-extended/pam/libpam/0001-pam_motd-do-not-rely-on-all-filesystems-providing-a-.patch
diff --git
a/meta/recipes-extended/pam/libpam/0001-pam_motd-do-not-rely-on-all-filesystems-providing-a-.patch
b/meta/recipes-extended/pam/libpam/0001-pam_motd-do-not-rely-on-all-filesystems-providing-a-.patch
new file mode 100644
index 00..94dcb04f0a
--- /dev/null
+++
b/meta/recipes-extended/pam/libpam/0001-pam_motd-do-not-rely-on-all-filesystems-providing-a-.patch
@@ -0,0 +1,108 @@
+From 42404548721c653317c911c83d885e2fc7fbca70 Mon Sep 17 00:00:00 2001
+From: Per Jessen
+Date: Fri, 22 Apr 2022 18:15:36 +0200
+Subject: [PATCH] pam_motd: do not rely on all filesystems providing a filetype
+
+When using scandir() to look for MOTD files to display, we wrongly
+relied on all filesystems providing a filetype. This is a fix to divert
+to lstat() when we have no filetype. To maintain MT safety, it isn't
+possible to use lstat() in the scandir() filter function, so all of the
+filtering has been moved to an additional loop after scanning all the
+motd dirs.
+Also, remove superfluous alphasort from scandir(), we are doing
+a qsort() later.
+
+Resolves: https://github.com/linux-pam/linux-pam/issues/455
+
+Upstream-Status: Backport
[https://github.com/linux-pam/linux-pam/commit/42404548721c653317c911c83d885e2fc7fbca70]
+
+Signed-off-by: Per Jessen
+Signed-off-by: Zhixiong Chi
+---
+ modules/pam_motd/pam_motd.c | 49 ++---
+ 1 file changed, 40 insertions(+), 9 deletions(-)
+
+diff --git a/modules/pam_motd/pam_motd.c b/modules/pam_motd/pam_motd.c
+index 6ac8cba2..5ca486e4 100644
+--- a/modules/pam_motd/pam_motd.c
b/modules/pam_motd/pam_motd.c
+@@ -166,11 +166,6 @@ static int compare_strings(const void *a, const void *b)
+ }
+ }
+
+-static int filter_dirents(const struct dirent *d)
+-{
+-return (d->d_type == DT_REG || d->d_type == DT_LNK);
+-}
+-
+ static void try_to_display_directories_with_overrides(pam_handle_t *pamh,
+ char **motd_dir_path_split, unsigned int num_motd_dirs, int
report_missing)
+ {
+@@ -199,8 +194,7 @@ static void
try_to_display_directories_with_overrides(pam_handle_t *pamh,
+
+ for (i = 0; i < num_motd_dirs; i++) {
+ int rv;
+- rv = scandir(motd_dir_path_split[i], &(dirscans[i]),
+- filter_dirents, alphasort);
++ rv = scandir(motd_dir_path_split[i], &(dirscans[i]), NULL, NULL);
+ if (rv < 0) {
+ if (errno != ENOENT || report_missing) {
+ pam_syslog(pamh, LOG_ERR, "error scanning directory %s: %m",
+@@ -215,6 +209,41 @@ static void
try_to_display_directories_with_overrides(pam_handle_t *pamh,
+ if (dirscans_size_total == 0)
+ goto out;
+
++/* filter out unwanted names, directories, and complement data with
lstat() */
++for (i = 0; i < num_motd_dirs; i++) {
++ struct dirent **d = dirscans[i];
++ for (unsigned int j = 0; j < dirscans_sizes[i]; j++) {
++ int rc;
++ char *fullpath;
++ struct stat s;
++
++ switch(d[j]->d_type) {/* the filetype determines how to proceed
*/
++ case DT_REG: /* regular files and */
++ case DT_LNK: /* symlinks */
++ continue; /* are good. */
++ case DT_UNKNOWN: /* for file systems that do not provide */
++ /* a filetype, we use lstat() */
++ if (join_dir_strings(, motd_dir_path_split[i],
++ d[j]->d_name) <= 0)
++ break;
++ rc = lstat(fullpath, );
++ _pam_drop(fullpath); /* free the memory alloc'ed by
join_dir_strings */
++ if (rc != 0) /* if the lstat() somehow failed */
++ break;
++
++ if (S_ISREG(s.st_mode) || /* regular files and */
++ S_ISLNK(s.st_mode)) continue; /* symlinks are good */
++ break;
++ case DT_DIR: /* We don't want directories */
++ default: /* nor anything else */
++ break;
++ }
++ _pam_drop(d[j]); /* free memory */
++
[OE-core][mickledore 30/35] populate_sdk_ext.bbclass: set METADATA_REVISION with an DISTRO override
From: Martin Jansa
* otherwise it ends '' inside esdk, because of parsing order:
# $METADATA_REVISION [3 operations]
# set /OE/build/test-D/conf/local.conf:43
# "f2da54ef432eac89b0f18eaad68e602b6990b5de"
# immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9
# "${@oe.buildcfg.detect_revision(d)}"
# set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10
# [vardepvalue] "${METADATA_REVISION}"
# pre-expansion value:
# ""
METADATA_REVISION=""
* This causes base-files.do_install and following tasks to have different
signatures between esdk and the build directory where this esdk was created:
bitbake-diffsigs
{test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata*
NOTE: Starting bitbake server...
basehash changed from
5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to
dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd
Variable METADATA_REVISION value changed from '' to
'f2da54ef432eac89b0f18eaad68e602b6990b5de'
and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK
is being prepared for use:
WARNING: The base-files:do_install sig is computed to be
83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201,
but the sig is locked to
3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in
SIGGEN_LOCKEDSIGS_t-qemux86-64
[RP: Add commit about why we need the override for future reference]
Signed-off-by: Martin Jansa
Signed-off-by: Luca Ceresoli
(cherry picked from commit 675ea7281c17f77bf5dea17cfd4d9da0928382a0)
Signed-off-by: Steve Sakoman
---
meta/classes-recipe/populate_sdk_ext.bbclass | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass
b/meta/classes-recipe/populate_sdk_ext.bbclass
index 2e6673bcd9..476876e03d 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -369,7 +369,8 @@ python copy_buildsystem () {
f.write('BUILDCFG_HEADER = ""\n\n')
# Write METADATA_REVISION
-f.write('METADATA_REVISION = "%s"\n\n' %
d.getVar('METADATA_REVISION'))
+# Needs distro override so it can override the value set in the
bbclass code (later than local.conf)
+f.write('METADATA_REVISION:%s = "%s"\n\n' % (d.getVar('DISTRO'),
d.getVar('METADATA_REVISION')))
f.write('# Provide a flag to indicate we are in the EXT_SDK
Context\n')
f.write('WITHIN_EXT_SDK = "1"\n\n')
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180950):
https://lists.openembedded.org/g/openembedded-core/message/180950
Mute This Topic: https://lists.openembedded.org/mt/98707893/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 29/35] libarchive: Enable acls, xattr for native as well as target
From: Piotr Łobacz
Libarchive is being used by OPKG package manager as default
API for extracting tar files. This fix allows us to extract
ipks packages with preserved ACLs and xattrs.
Partially addresses [YOCTO #15091]
[RP: Merge into main PACKAGECONFIG and tweak commit message]
Signed-off-by: Piotr Łobacz
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
(cherry picked from commit 913aad1ac013368aef8f6af332588ef24bba46bd)
Signed-off-by: Steve Sakoman
---
meta/recipes-extended/libarchive/libarchive_3.6.2.bb | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/meta/recipes-extended/libarchive/libarchive_3.6.2.bb
b/meta/recipes-extended/libarchive/libarchive_3.6.2.bb
index f447035b67..aafede3da8 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.6.2.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.6.2.bb
@@ -7,11 +7,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=d499814247adaee08d88080841cb5665"
DEPENDS = "e2fsprogs-native"
-PACKAGECONFIG ?= "zlib bz2 xz zstd"
-
-PACKAGECONFIG:append:class-target = "\
- ${@bb.utils.filter('DISTRO_FEATURES', 'acl xattr', d)} \
-"
+PACKAGECONFIG ?= "zlib bz2 xz zstd ${@bb.utils.filter('DISTRO_FEATURES', 'acl
xattr', d)}"
DEPENDS_BZIP2 = "bzip2-replacement-native"
DEPENDS_BZIP2:class-target = "bzip2"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180949):
https://lists.openembedded.org/g/openembedded-core/message/180949
Mute This Topic: https://lists.openembedded.org/mt/98707892/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 28/35] kernel-devsrc: depend on python3-core instead of python3
From: "bkyleruss...@gmail.com"
Avoids pulling in potential GPLv3 packages through python3-misc catch-all.
python3-core is the intended minimal RDEPENDS for packages requiring python3
support. Other python3 module dependencies should be listed explicitly.
Signed-off-by: Kyle Russell
Signed-off-by: Luca Ceresoli
(cherry picked from commit 231f93becad619f6afa383f9b1132f1d4b02fa64)
Signed-off-by: Steve Sakoman
---
meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index b4ea5f756a..6764598d48 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -377,7 +377,7 @@ do_install[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
FILES:${PN} = "${KERNEL_BUILD_ROOT} ${KERNEL_SRC_PATH}"
FILES:${PN}-dbg += "${KERNEL_BUILD_ROOT}*/build/scripts/*/.debug/*"
-RDEPENDS:${PN} = "bc python3 flex bison ${TCLIBC}-utils"
+RDEPENDS:${PN} = "bc python3-core flex bison ${TCLIBC}-utils"
# 4.15+ needs these next two RDEPENDS
RDEPENDS:${PN} += "openssl-dev util-linux"
# and x86 needs a bit more for 4.15+
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180948):
https://lists.openembedded.org/g/openembedded-core/message/180948
Mute This Topic: https://lists.openembedded.org/mt/98707890/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 27/35] kernel-fitimage: Fix the default dtb config check
From: Arslan Ahmad
The current check for default dtb image checks if the file exists and is
not empty but appends a slash to the path due to which the file is never
found. It also doesn't replace slash in filename with _ as done when
populating the DTB variable. A better way to check the existence of the
device tree would be from the list of DTBs since this is used during
compilation.
Signed-off-by: Arslan Ahmad
Signed-off-by: Luca Ceresoli
(cherry picked from commit e8e31e11b158837804d029e85f5f8ed3c219a4ea)
Signed-off-by: Steve Sakoman
---
meta/classes-recipe/kernel-fitimage.bbclass | 36 +++--
1 file changed, 26 insertions(+), 10 deletions(-)
diff --git a/meta/classes-recipe/kernel-fitimage.bbclass
b/meta/classes-recipe/kernel-fitimage.bbclass
index b77747404f..6684478c33 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -388,6 +388,7 @@ symlink_points_below() {
# $5 ... u-boot script ID
# $6 ... config ID
# $7 ... default flag
+# $8 ... default DTB image name
fitimage_emit_section_config() {
conf_csum="${FIT_HASH_ALG}"
@@ -404,6 +405,7 @@ fitimage_emit_section_config() {
bootscr_id="$5"
config_id="$6"
default_flag="$7"
+ default_dtb_image="$8"
# Test if we have any DTBs at all
sep=""
@@ -415,7 +417,6 @@ fitimage_emit_section_config() {
bootscr_line=""
setup_line=""
default_line=""
- default_dtb_image="${FIT_CONF_DEFAULT_DTB}"
dtb_image_sect=$(symlink_points_below $dtb_image
"${EXTERNAL_KERNEL_DEVICETREE}")
if [ -z "$dtb_image_sect" ]; then
@@ -469,11 +470,7 @@ fitimage_emit_section_config() {
# Select default node as user specified dtb when
# multiple dtb exists.
if [ -n "$default_dtb_image" ]; then
- if [ -s
"${EXTERNAL_KERNEL_DEVICETREE}/$default_dtb_image" ]; then
- default_line="default =
\"${FIT_CONF_PREFIX}$default_dtb_image\";"
- else
- bbwarn "Couldn't find a valid user
specified dtb in ${EXTERNAL_KERNEL_DEVICETREE}/$default_dtb_image"
- fi
+ default_line="default =
\"${FIT_CONF_PREFIX}$default_dtb_image\";"
else
default_line="default =
\"${FIT_CONF_PREFIX}$dtb_image\";"
fi
@@ -555,7 +552,8 @@ fitimage_assemble() {
ramdiskcount=$3
setupcount=""
bootscr_id=""
- rm -f $1 ${KERNEL_OUTPUT_DIR}/$2
+ default_dtb_image=""
+ rm -f $1 arch/${ARCH}/boot/$2
if [ -n "${UBOOT_SIGN_IMG_KEYNAME}" -a "${UBOOT_SIGN_KEYNAME}" =
"${UBOOT_SIGN_IMG_KEYNAME}" ]; then
bbfatal "Keys used to sign images and configuration nodes must
be different."
@@ -593,6 +591,13 @@ fitimage_assemble() {
DTB_PATH="${KERNEL_OUTPUT_DIR}/$DTB"
fi
+ # Set the default dtb image if it exists in the
devicetree.
+ if [ ${FIT_CONF_DEFAULT_DTB} = $DTB ];then
+ default_dtb_image=$(echo "$DTB" | tr '/' '_')
+ fi
+
+ DTB=$(echo "$DTB" | tr '/' '_')
+
# Skip DTB if we've picked it up previously
echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
@@ -606,6 +611,13 @@ fitimage_assemble() {
dtbcount=1
for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtb'
-printf '%P\n' | sort) \
$(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtbo' -printf
'%P\n' | sort); do
+ # Set the default dtb image if it exists in the
devicetree.
+ if [ ${FIT_CONF_DEFAULT_DTB} = $DTB ];then
+ default_dtb_image=$(echo "$DTB" | tr '/' '_')
+ fi
+
+ DTB=$(echo "$DTB" | tr '/' '_')
+
# Skip DTB/DTBO if we've picked it up previously
echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
@@ -619,6 +631,10 @@ fitimage_assemble() {
done
fi
+ if [ -n "${FIT_CONF_DEFAULT_DTB}" ] && [ -z $default_dtb_image ]; then
+ bbwarn "${FIT_CONF_DEFAULT_DTB} is not available in the list of
device trees."
+ fi
+
#
# Step 3: Prepare a u-boot script section
#
@@ -691,15 +707,15 @@ fitimage_assemble() {
for DTB in ${DTBS}; do
dtb_ext=${DTB##*.}
if [ "$dtb_ext" = "dtbo" ]; then
- fitimage_emit_section_config $1 "" "$DTB" ""
"$bootscr_id" "" "`expr $i = $dtbcount`"
+
[OE-core][mickledore 26/35] libnotify: remove dependency dbus
From: Kai Kang It ported to use GDBus in libnotify 0.7.0 [1]. So remove dbus from DEPENDS. And GDBus is provided by glib-2.0. [1]: https://gitlab.gnome.org/GNOME/libnotify/-/commit/f63e8ab Signed-off-by: Kai Kang Signed-off-by: Alexandre Belloni (cherry picked from commit 3e585e41f561aab73685290631f2263795f571b9) Signed-off-by: Steve Sakoman --- meta/recipes-gnome/libnotify/libnotify_0.8.2.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-gnome/libnotify/libnotify_0.8.2.bb b/meta/recipes-gnome/libnotify/libnotify_0.8.2.bb index b1656fe0fe..08e9899d00 100644 --- a/meta/recipes-gnome/libnotify/libnotify_0.8.2.bb +++ b/meta/recipes-gnome/libnotify/libnotify_0.8.2.bb @@ -9,7 +9,7 @@ SECTION = "libs" LICENSE = "LGPL-2.1-only" LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34" -DEPENDS = "dbus glib-2.0 glib-2.0-native gdk-pixbuf" +DEPENDS = "glib-2.0 glib-2.0-native gdk-pixbuf" PACKAGECONFIG ?= "" PACKAGECONFIG[tests] = "-Dtests=true,-Dtests=false,gtk+3" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180946): https://lists.openembedded.org/g/openembedded-core/message/180946 Mute This Topic: https://lists.openembedded.org/mt/98707888/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 25/35] mesa: upgrade 23.0.0 -> 23.0.2
From: Wang Mingyu
23.0.1 changes
New features
None
Bug fixes
radv: A Plague Tale: Requiem black “flash” on 7900XTX
7900 XTX: Graphical corruption / artifacts in Cyberpunk
radv: CmdCopyQueryPoolResults broken for VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT
with queryCount > 1
radeonsi draws spurious values to depth buffer
rusticl over llvmpipe + ffmpeg’s Opencl filter = error -51
rusticl over llvmpipe + ffmpeg’s Opencl filter = error -51
OpenGL crashes in X-Plane 11
[Bisected] Regression: Project Zomboid renders black
hasvk: Black pixels with 8xMSAA and fast clears on Intel(R) HD Graphics 4400
(HSW GT2)
radv: GTA IV graphical artifacts on 7900XTX
radv: Resident Evil Revelations 2 artifacts on 7900XTX with DCC
radv: Prototype 2 black textures on RDNA 3 when DCC is enabled
Mesa 23.0.0 crashes immediately with indirect rendering
[RADV] Returnal - pistol muzzle flash fills whole screen (graphical artifact)
ACO:
dEQP-VK.binding_model.descriptor_buffer.multiple.graphics_geom_buffers1_sets3_imm_samplers
hangs on NAVI10
Build failures with recent lld
r600,regression: Glitches on terrain with the NIR backend on Transport Fever 2
r600/TURKS: Crash of the game “A Hat in Time” with Gallium Nine and NIR path
(third report)
[gen9atom] Vulkan tests cause gpu hang: dEQP-VK.memory_model.*
GL_SHADER_BINARY_FORMAT_SPIR_V is not added to the list of
GL_SHADER_BINARY_FORMATS even if GL_ARB_gl_spirv is supported.
[ANV/DG2] Vertex explosion in
nvpro-samples/vk_raytracing_tutorial_KHR/ray_tracing_gltf
CUEtools FLACCL hit assert in rusticl
Assertion Failed on Intel HD 5500 with Linux / Mesa 22.3.1 / OpenGL
23.0.2 changes
New features
None
Bug fixes
allwinner a64: DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory after
some time of apps usage
mesa: index buffer leaking
RadeonSI: null dereference in amdgpu_cs_add_buffer, potential refcount
mismatch, running BeyondAllReason
eglCreateImageKHR, error: EGL_BAD_ALLOC (0x3003), message:
“createImageFromDmaBufs failed” on AMD multi-gpu with explicit format modifiers
libgrl.a installed but not used?
radv: crash compiling UE5 lumen hardware RT shader
aco: unused vtmp_in_loop
radv,nir: dEQP-VK.ray_query.builtin.rayqueryterminate.* failures
glsl compiled error when the RHS of operator `>>` is int64_t by enabling
GL_ARB_gpu_shader_int64 extension
QPainter fails to render multiple shapes with a brush set since Mesa 23.0
eglSwapBuffers blocks in wayland when it’s wl_surface_frame event is stolen.
plasmashell sometimes hangs with mesa_glthread
pps_device.h:23:11: error: ‘uint32_t’ does not name a type
Signed-off-by: Wang Mingyu
Signed-off-by: Luca Ceresoli
(cherry picked from commit f7f483f90ba17342a83fdfe7c7dccf5a3f7bf624)
Signed-off-by: Steve Sakoman
---
.../mesa/{mesa-gl_23.0.0.bb => mesa-gl_23.0.2.bb} | 0
meta/recipes-graphics/mesa/mesa.inc | 2 +-
meta/recipes-graphics/mesa/{mesa_23.0.0.bb => mesa_23.0.2.bb} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/mesa/{mesa-gl_23.0.0.bb => mesa-gl_23.0.2.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_23.0.0.bb => mesa_23.0.2.bb} (100%)
diff --git a/meta/recipes-graphics/mesa/mesa-gl_23.0.0.bb
b/meta/recipes-graphics/mesa/mesa-gl_23.0.2.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa-gl_23.0.0.bb
rename to meta/recipes-graphics/mesa/mesa-gl_23.0.2.bb
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 8f72f25c17..babd10a855 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,7 +19,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
"
-SRC_URI[sha256sum] =
"01f3cff3763f09e0adabcb8011e4aebc6ad48f6a4dd4bae904fe918707d253e4"
+SRC_URI[sha256sum] =
"1b7d3399fc6f16f030361f925d33ebc7600cbf98094582f54775b6a1180529e7"
UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
diff --git a/meta/recipes-graphics/mesa/mesa_23.0.0.bb
b/meta/recipes-graphics/mesa/mesa_23.0.2.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa_23.0.0.bb
rename to meta/recipes-graphics/mesa/mesa_23.0.2.bb
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180945):
https://lists.openembedded.org/g/openembedded-core/message/180945
Mute This Topic: https://lists.openembedded.org/mt/98707884/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 24/35] linux-firmware: upgrade 20230210 -> 20230404
From: Dmitry Baryshkov
The LICENCE.qat_firmware license file was updated to reflect Intel
licensing (it removed a term regarding patent licenses).
License-Update: additional files
Signed-off-by: Dmitry Baryshkov
Signed-off-by: Luca Ceresoli
(cherry picked from commit fd43b59ab32e2115fcda7ad63d3a5ccc2683c7d5)
Signed-off-by: Steve Sakoman
---
...inux-firmware_20230210.bb => linux-firmware_20230404.bb} | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20230210.bb =>
linux-firmware_20230404.bb} (99%)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230210.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230404.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20230210.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20230404.bb
index bf5d4f54e6..7412c022ba 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230210.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230404.bb
@@ -108,7 +108,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
file://LICENCE.OLPC;md5=5b917f9d8c061991be4f6f5f108719cd \
file://LICENCE.open-ath9k-htc-firmware;md5=1b33c9f4d17bc4d457bdb23727046837 \
file://LICENCE.phanfw;md5=954dcec0e051f9409812b561ea743bfa
\
-
file://LICENCE.qat_firmware;md5=9e7d8bea77612d7cc7d9e9b54b623062 \
+
file://LICENCE.qat_firmware;md5=72de83dfd9b87be7685ed099a39fbea4 \
file://LICENSE.qcom;md5=164e3362a538eb11d3ac51e8e134294b \
file://LICENSE.qcom_yamato;md5=d0de0eeccaf1843a850bf7a6777eec5c \
file://LICENCE.qla1280;md5=d6895732e622d950609093223a2c4f5d \
@@ -134,7 +134,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
"
# WHENCE checksum is defined separately to ease overriding it if
# class-devupstream is selected.
-WHENCE_CHKSUM = "aadb3cccbde1e53fc244a409e9bd5a22"
+WHENCE_CHKSUM = "0782deea054d4b1b7f10c92c3a245da4"
# These are not common licenses, set NO_GENERIC_LICENSE for them
# so that the license files will be copied from fetched source
@@ -212,7 +212,7 @@ SRC_URI:class-devupstream =
"git://git.kernel.org/pub/scm/linux/kernel/git/firmw
# Pin this to the 20220509 release, override this in local.conf
SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
-SRC_URI[sha256sum] =
"6e3d9e8d52cffc4ec0dbe8533a8445328e0524a20f159a5b61c2706f983ce38a"
+SRC_URI[sha256sum] =
"c3f9ad2bb5311cce2490f37a8052f836703d6936aabd840246b6576f1f71f607"
inherit allarch
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180944):
https://lists.openembedded.org/g/openembedded-core/message/180944
Mute This Topic: https://lists.openembedded.org/mt/98707882/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 23/35] rust: Upgrade 1.68.1 -> 1.68.2
From: Alex Kiernan
Changes:
* Update the GitHub RSA host key bundled within Cargo. The key was
rotated by GitHub on 2023-03-24 after the old one leaked.
* Mark the old GitHub RSA host key as revoked. This will prevent Cargo
from accepting the leaked key even when trusted by the system.
* Add support for @revoked and a better error message for
@cert-authority in Cargo’s SSH host key verification
Signed-off-by: Alex Kiernan
Signed-off-by: Alexandre Belloni
(cherry picked from commit 4563432b41026adc56c54452984b19ab64e7406e)
Signed-off-by: Steve Sakoman
---
meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb} | 0
.../rust/{libstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb} | 0
...t-cross-canadian_1.68.1.bb => rust-cross-canadian_1.68.2.bb} | 0
.../rust/{rust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb} | 0
meta/recipes-devtools/rust/rust-source.inc | 2 +-
meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb} | 0
6 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb} (100%)
rename meta/recipes-devtools/rust/{libstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb}
(100%)
rename meta/recipes-devtools/rust/{rust-cross-canadian_1.68.1.bb =>
rust-cross-canadian_1.68.2.bb} (100%)
rename meta/recipes-devtools/rust/{rust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb}
(100%)
rename meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb} (100%)
diff --git a/meta/recipes-devtools/rust/cargo_1.68.1.bb
b/meta/recipes-devtools/rust/cargo_1.68.2.bb
similarity index 100%
rename from meta/recipes-devtools/rust/cargo_1.68.1.bb
rename to meta/recipes-devtools/rust/cargo_1.68.2.bb
diff --git a/meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
b/meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
similarity index 100%
rename from meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
rename to meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
diff --git a/meta/recipes-devtools/rust/rust-cross-canadian_1.68.1.bb
b/meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
similarity index 100%
rename from meta/recipes-devtools/rust/rust-cross-canadian_1.68.1.bb
rename to meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
diff --git a/meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
b/meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
similarity index 100%
rename from meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
rename to meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
diff --git a/meta/recipes-devtools/rust/rust-source.inc
b/meta/recipes-devtools/rust/rust-source.inc
index d48fcd5bc9..b25b5c17e8 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -8,7 +8,7 @@ SRC_URI +=
"https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
file://0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch;patchdir=${RUSTSRC}
\
"
-SRC_URI[rust.sha256sum] =
"5b8ea94085b65e75c1fa6310e2f90bd706fa80bfcb3544fe26f4037b911d9fb2"
+SRC_URI[rust.sha256sum] =
"ce1a115f6aafa912b4622906a92b626354973afa9288e2c7750df4dcf3390fc0"
RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
diff --git a/meta/recipes-devtools/rust/rust_1.68.1.bb
b/meta/recipes-devtools/rust/rust_1.68.2.bb
similarity index 100%
rename from meta/recipes-devtools/rust/rust_1.68.1.bb
rename to meta/recipes-devtools/rust/rust_1.68.2.bb
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180943):
https://lists.openembedded.org/g/openembedded-core/message/180943
Mute This Topic: https://lists.openembedded.org/mt/98707881/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 22/35] vala: upgrade 0.56.4 -> 0.56.6
From: Wang Mingyu
Changelog:
===
* Regression fix:
- vala: Improve initialization of namespace fields with compound
literal [#1424]
* Bindings:
- gio-2.0,glib-2.0,gobject-2.0: Update 2.74 symbols
- webkit2gtk-4.*: Update to 2.40.0
- webkitgtk-6.0: Update to 2.40.0
- gtk4: Update to 4.10.1~40b154bf from 0.58
- gtk4: Add sealed to all the final types
- gtk+-3.0: Fix ToolPalette.icon_size get-accessor type
- webkitgtk-6.0: Update to 2.39.90
* Various improvements and bug fixes:
- codegen:
+ Consistently handle GLib.Error as boxed type [#1418]
+ Add cast to accessor calls for generic property implementations
+ Use g_object_class_override_property to implement generic interface
properties [#1419]
+ Add declaration for register call of dynamic DBus interfaces [#1422]
- vala:
+ Correctly handle pre/post-increment expression as index of element
access [#1417]
+ Set proper value-type of unary ref/out expression in initializers [#1421]
+ Allow assignment of namespace fields with inline allocated arrays
- gtkmodule: Improve error messages
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit e3eb6b4e6477dea953d4d93d2eadc5f430c160b1)
Signed-off-by: Steve Sakoman
---
meta/recipes-devtools/vala/vala_0.56.4.bb | 3 ---
meta/recipes-devtools/vala/vala_0.56.6.bb | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
delete mode 100644 meta/recipes-devtools/vala/vala_0.56.4.bb
create mode 100644 meta/recipes-devtools/vala/vala_0.56.6.bb
diff --git a/meta/recipes-devtools/vala/vala_0.56.4.bb
b/meta/recipes-devtools/vala/vala_0.56.4.bb
deleted file mode 100644
index 32fa81a08b..00
--- a/meta/recipes-devtools/vala/vala_0.56.4.bb
+++ /dev/null
@@ -1,3 +0,0 @@
-require ${BPN}.inc
-
-SRC_URI[sha256sum] =
"862c41d938543ed3d8d86c8219a61087797193defee8da0c50caf49993c66b6a"
diff --git a/meta/recipes-devtools/vala/vala_0.56.6.bb
b/meta/recipes-devtools/vala/vala_0.56.6.bb
new file mode 100644
index 00..bc5f5477d7
--- /dev/null
+++ b/meta/recipes-devtools/vala/vala_0.56.6.bb
@@ -0,0 +1,3 @@
+require ${BPN}.inc
+
+SRC_URI[sha256sum] =
"050e841cbfe2b8e7d0fb350c9506bd7557be1cd86a90c896765f1a09a1870013"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180942):
https://lists.openembedded.org/g/openembedded-core/message/180942
Mute This Topic: https://lists.openembedded.org/mt/98707879/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 20/35] xserver-xorg: upgrade 21.1.7 -> 21.1.8
From: Wang Mingyu
This release contains the fix for CVE-2023-1393 in today's security
advisory: https://lists.x.org/archives/xorg-announce/2023-March/003374.html
Benno Schulenberg (1):
xkbUtils: use existing symbol names instead of deleted deprecated ones
Olivier Fourdan (2):
composite: Fix use-after-free of the COW
xserver 21.1.8
git tag: xorg-server-21.1.8
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 7b08dff8f46bcaa05f7fbffbe27d524579af4faf)
Signed-off-by: Steve Sakoman
---
.../{xserver-xorg_21.1.7.bb => xserver-xorg_21.1.8.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_21.1.7.bb =>
xserver-xorg_21.1.8.bb} (92%)
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb
b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.8.bb
similarity index 92%
rename from meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb
rename to meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.8.bb
index 212c7d39c2..19db7ea434 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb
+++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.8.bb
@@ -3,7 +3,7 @@ require xserver-xorg.inc
SRC_URI +=
"file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \
file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \
"
-SRC_URI[sha256sum] =
"d9c60b2dd0ec52326ca6ab20db0e490b1ff4f566f59ca742d6532e92795877bb"
+SRC_URI[sha256sum] =
"38aadb735650c8024ee25211c190bf8aad844c5f59632761ab1ef4c4d5aeb152"
# These extensions are now integrated into the server, so declare the migration
# path for in-place upgrades.
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180940):
https://lists.openembedded.org/g/openembedded-core/message/180940
Mute This Topic: https://lists.openembedded.org/mt/98707871/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 21/35] xwayland: upgrade 22.1.8 -> 23.1.1
From: Wang Mingyu
This release contains the fix for CVE-2023-1393 in today's security
advisory: https://lists.x.org/archives/xorg-announce/2023-March/003374.html
Benno Schulenberg (1):
xkbUtils: use existing symbol names instead of deleted deprecated ones
Joshua Ashton (1):
glamor: Don't glFlush/ctx switch unless any work has been performed
Michel Dänzer (2):
xwayland: Refactor xwl_present_for_each_frame_callback helper
xwayland: Prevent nested xwl_present_for_each_frame_callback calls
Olivier Fourdan (2):
composite: Fix use-after-free of the COW
Bump version to 23.1.1
git tag: xwayland-23.1.1
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 35fdbd0ea81650a0421d50fb53989d96c5956331)
Signed-off-by: Steve Sakoman
---
.../xwayland/{xwayland_22.1.8.bb => xwayland_23.1.1.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/xwayland/{xwayland_22.1.8.bb =>
xwayland_23.1.1.bb} (95%)
diff --git a/meta/recipes-graphics/xwayland/xwayland_22.1.8.bb
b/meta/recipes-graphics/xwayland/xwayland_23.1.1.bb
similarity index 95%
rename from meta/recipes-graphics/xwayland/xwayland_22.1.8.bb
rename to meta/recipes-graphics/xwayland/xwayland_23.1.1.bb
index 6919ba421b..a065e92f01 100644
--- a/meta/recipes-graphics/xwayland/xwayland_22.1.8.bb
+++ b/meta/recipes-graphics/xwayland/xwayland_23.1.1.bb
@@ -10,7 +10,7 @@ LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=5df87950af51ac2c5822094553ea1880"
SRC_URI = "https://www.x.org/archive/individual/xserver/xwayland-${PV}.tar.xz;
-SRC_URI[sha256sum] =
"d1173290b88ea8da42a7d9350dedfaba856ce4ae44e58c045ad9ecaa2f73"
+SRC_URI[sha256sum] =
"fb9461f5cb9fea5e07e91882311b0c88b43e8843b017ebac05eb5af69aa34c15"
UPSTREAM_CHECK_REGEX = "xwayland-(?P\d+(\.(?!90\d)\d+)+)\.tar"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180941):
https://lists.openembedded.org/g/openembedded-core/message/180941
Mute This Topic: https://lists.openembedded.org/mt/98707872/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 19/35] Revert "xserver-xorg: backport fix for CVE-2023-1393"
Fixed with subsequent version bump This reverts commit 7828f7026b4cd3ae97ebe5d849c09fabbc17272d. Signed-off-by: Steve Sakoman --- ...posite-Fix-use-after-free-of-the-COW.patch | 46 --- .../xorg-xserver/xserver-xorg_21.1.7.bb | 3 +- 2 files changed, 1 insertion(+), 48 deletions(-) delete mode 100644 meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-composite-Fix-use-after-free-of-the-COW.patch diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-composite-Fix-use-after-free-of-the-COW.patch b/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-composite-Fix-use-after-free-of-the-COW.patch deleted file mode 100644 index fc426daba5..00 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-composite-Fix-use-after-free-of-the-COW.patch +++ /dev/null @@ -1,46 +0,0 @@ -From 26ef545b3502f61ca722a7a3373507e88ef64110 Mon Sep 17 00:00:00 2001 -From: Olivier Fourdan -Date: Mon, 13 Mar 2023 11:08:47 +0100 -Subject: [PATCH] composite: Fix use-after-free of the COW - -ZDI-CAN-19866/CVE-2023-1393 - -If a client explicitly destroys the compositor overlay window (aka COW), -we would leave a dangling pointer to that window in the CompScreen -structure, which will trigger a use-after-free later. - -Make sure to clear the CompScreen pointer to the COW when the latter gets -destroyed explicitly by the client. - -This vulnerability was discovered by: -Jan-Niklas Sohn working with Trend Micro Zero Day Initiative - -Signed-off-by: Olivier Fourdan -Reviewed-by: Adam Jackson - -CVE: CVE-2023-1393 -Upstream-Status: Backport -Signed-off-by: Ross Burton - composite/compwindow.c | 5 + - 1 file changed, 5 insertions(+) - -diff --git a/composite/compwindow.c b/composite/compwindow.c -index 4e2494b86..b30da589e 100644 a/composite/compwindow.c -+++ b/composite/compwindow.c -@@ -620,6 +620,11 @@ compDestroyWindow(WindowPtr pWin) - ret = (*pScreen->DestroyWindow) (pWin); - cs->DestroyWindow = pScreen->DestroyWindow; - pScreen->DestroyWindow = compDestroyWindow; -+ -+/* Did we just destroy the overlay window? */ -+if (pWin == cs->pOverlayWin) -+cs->pOverlayWin = NULL; -+ - /*compCheckTree (pWin->drawable.pScreen); can't check -- tree isn't good*/ - return ret; - } --- -2.34.1 - diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb index f0771cc86e..212c7d39c2 100644 --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg_21.1.7.bb @@ -1,8 +1,7 @@ require xserver-xorg.inc SRC_URI += "file://0001-xf86pciBus.c-use-Intel-ddx-only-for-pre-gen4-hardwar.patch \ -file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \ -file://0001-composite-Fix-use-after-free-of-the-COW.patch \ + file://0001-Avoid-duplicate-definitions-of-IOPortBase.patch \ " SRC_URI[sha256sum] = "d9c60b2dd0ec52326ca6ab20db0e490b1ff4f566f59ca742d6532e92795877bb" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180939): https://lists.openembedded.org/g/openembedded-core/message/180939 Mute This Topic: https://lists.openembedded.org/mt/98707869/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 18/35] wpebackend-fdo: upgrade 1.14.0 -> 1.14.2
From: Wang Mingyu
Changelog:
==
- Reverted a change introduced in 1.14.1 which introduced crashes both
with WebKitGTK and WPE running under Wayland in some configurations.
- Fix a crash caused by wrong assertion, which was typically triggered in
debug builds when using the NVidia drivers.
- Fix WebKit no longer repainting after provisional navigation with
PSON enabled.
- Fix graphics buffer leaks by always freeing them in buffer destroy
listener callbacks.
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit aa37e18a51714af3281b4127dceb40b38aa8ac3c)
Signed-off-by: Steve Sakoman
---
.../{wpebackend-fdo_1.14.0.bb => wpebackend-fdo_1.14.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb =>
wpebackend-fdo_1.14.2.bb} (90%)
diff --git a/meta/recipes-sato/webkit/wpebackend-fdo_1.14.0.bb
b/meta/recipes-sato/webkit/wpebackend-fdo_1.14.2.bb
similarity index 90%
rename from meta/recipes-sato/webkit/wpebackend-fdo_1.14.0.bb
rename to meta/recipes-sato/webkit/wpebackend-fdo_1.14.2.bb
index 708201043b..b3d7b229c8 100644
--- a/meta/recipes-sato/webkit/wpebackend-fdo_1.14.0.bb
+++ b/meta/recipes-sato/webkit/wpebackend-fdo_1.14.2.bb
@@ -13,7 +13,7 @@ inherit meson features_check pkgconfig
REQUIRED_DISTRO_FEATURES = "opengl"
SRC_URI = "https://wpewebkit.org/releases/${BPN}-${PV}.tar.xz;
-SRC_URI[sha256sum] =
"e75b0cb2c7145448416e8696013d8883f675c66c11ed750e06865efec5809155"
+SRC_URI[sha256sum] =
"93c9766ae9864eeaeaee2b0a74f22cbca08df42c1a1bdb55b086f2528e380d38"
# Especially helps compiling with clang which enable this as error when
# using c++11
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180938):
https://lists.openembedded.org/g/openembedded-core/message/180938
Mute This Topic: https://lists.openembedded.org/mt/98707868/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 17/35] texinfo: upgrade 7.0.2 -> 7.0.3
From: Wang Mingyu
Changelog:
==
* texi2any
. fix performance regression when Perl binary extension (XS) modules
are not being used (e.g. with TEXINFO_XS=omit)
* info
. further fix of recoding of UTF-8 files to ASCII to avoid text
disappearing from nodes
. avoid possible freeze at start of a file with '-v nodeline=pointers'
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 87bb580f6a02468d372254480302a60faa965131)
Signed-off-by: Steve Sakoman
---
.../texinfo/{texinfo_7.0.2.bb => texinfo_7.0.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-extended/texinfo/{texinfo_7.0.2.bb => texinfo_7.0.3.bb}
(97%)
diff --git a/meta/recipes-extended/texinfo/texinfo_7.0.2.bb
b/meta/recipes-extended/texinfo/texinfo_7.0.3.bb
similarity index 97%
rename from meta/recipes-extended/texinfo/texinfo_7.0.2.bb
rename to meta/recipes-extended/texinfo/texinfo_7.0.3.bb
index da455df4bb..b149177b72 100644
--- a/meta/recipes-extended/texinfo/texinfo_7.0.2.bb
+++ b/meta/recipes-extended/texinfo/texinfo_7.0.3.bb
@@ -35,7 +35,7 @@ SRC_URI = "${GNU_MIRROR}/texinfo/${BP}.tar.gz \
${TARGET_PATCH} \
"
-SRC_URI[sha256sum] =
"a9c646bc4f6bb31843f129f8408a3a627334575faf7b22ebc416be5cb1570553"
+SRC_URI[sha256sum] =
"3cc5706fb086b895e1dc2b407aade9f95a3a233ff856273e2b659b089f117683"
tex_texinfo = "texmf/tex/texinfo"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180937):
https://lists.openembedded.org/g/openembedded-core/message/180937
Mute This Topic: https://lists.openembedded.org/mt/98707867/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 16/35] ruby: upgrade 3.2.1 -> 3.2.2
From: Wang Mingyu
Ruby 3.1.2
CVE-2022-28738: Double free in Regexp compilation..
CVE-2022-28739: Buffer overrun in String-to-Float conversion..
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit b261bc704839b12769118f6f1c4207f3d19fe4fd)
Signed-off-by: Steve Sakoman
---
meta/recipes-devtools/ruby/{ruby_3.2.1.bb => ruby_3.2.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/ruby/{ruby_3.2.1.bb => ruby_3.2.2.bb} (98%)
diff --git a/meta/recipes-devtools/ruby/ruby_3.2.1.bb
b/meta/recipes-devtools/ruby/ruby_3.2.2.bb
similarity index 98%
rename from meta/recipes-devtools/ruby/ruby_3.2.1.bb
rename to meta/recipes-devtools/ruby/ruby_3.2.2.bb
index 3f1bbc262b..481fe7c23d 100644
--- a/meta/recipes-devtools/ruby/ruby_3.2.1.bb
+++ b/meta/recipes-devtools/ruby/ruby_3.2.2.bb
@@ -51,7 +51,7 @@ do_configure:prepend() {
DEPENDS:append:libc-musl = " libucontext"
-SRC_URI[sha256sum] =
"13d67901660ee3217dbd9dd56059346bd4212ce64a69c306ef52df64935f8dbd"
+SRC_URI[sha256sum] =
"96c57558871a6748de5bc9f274e93f4b5aad06cd8f37befa0e8d94e7b8a423bc"
PACKAGECONFIG ??= ""
PACKAGECONFIG += "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180936):
https://lists.openembedded.org/g/openembedded-core/message/180936
Mute This Topic: https://lists.openembedded.org/mt/98707866/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 15/35] pango: upgrade 1.50.13 -> 1.50.14
From: Wang Mingyu
Changelog:
- Fix underline thickness in scaled contexts
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit f34ee7f08bdf94297042969b114da38b71168c5b)
Signed-off-by: Steve Sakoman
---
.../pango/{pango_1.50.13.bb => pango_1.50.14.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/pango/{pango_1.50.13.bb => pango_1.50.14.bb} (94%)
diff --git a/meta/recipes-graphics/pango/pango_1.50.13.bb
b/meta/recipes-graphics/pango/pango_1.50.14.bb
similarity index 94%
rename from meta/recipes-graphics/pango/pango_1.50.13.bb
rename to meta/recipes-graphics/pango/pango_1.50.14.bb
index e673366dc7..ec7a913009 100644
--- a/meta/recipes-graphics/pango/pango_1.50.13.bb
+++ b/meta/recipes-graphics/pango/pango_1.50.14.bb
@@ -24,7 +24,7 @@ SRC_URI += "file://run-ptest \
file://0001-Skip-running-test-layout-test.patch \
"
-SRC_URI[archive.sha256sum] =
"5cdcf6d761d26a3eb9412b6cb069b32bd1d9b07abf116321167d94c2189299fd"
+SRC_URI[archive.sha256sum] =
"1d67f205bfc318c27a29cfdfb6828568df566795df0cb51d2189cde7f2d581e8"
DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo
harfbuzz fribidi"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180935):
https://lists.openembedded.org/g/openembedded-core/message/180935
Mute This Topic: https://lists.openembedded.org/mt/98707864/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 14/35] mtools: upgrade 4.0.42 -> 4.0.43
From: Wang Mingyu
Changelog:
==
- Fix root directory test in mattrib
- -b BiosDisk flag for mformat to allow setting physdrive to
a user-specified value
- Clearer error message in mformat when trying to mformat a
disk whose total size is not known
- Make recursive copy more consistent
- Trailing slash now always implies target should be a directory
- Code cleanup
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 7f04fd469f9ee989eadd85ea949527300704ca70)
Signed-off-by: Steve Sakoman
---
.../mtools/{mtools_4.0.42.bb => mtools_4.0.43.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/mtools/{mtools_4.0.42.bb => mtools_4.0.43.bb}
(93%)
diff --git a/meta/recipes-devtools/mtools/mtools_4.0.42.bb
b/meta/recipes-devtools/mtools/mtools_4.0.43.bb
similarity index 93%
rename from meta/recipes-devtools/mtools/mtools_4.0.42.bb
rename to meta/recipes-devtools/mtools/mtools_4.0.43.bb
index 85d9e451c2..859103979e 100644
--- a/meta/recipes-devtools/mtools/mtools_4.0.42.bb
+++ b/meta/recipes-devtools/mtools/mtools_4.0.43.bb
@@ -24,7 +24,7 @@ RRECOMMENDS:${PN}:libc-glibc = "\
glibc-gconv-ibm866 \
glibc-gconv-ibm869 \
"
-SRC_URI[sha256sum] =
"64bfdfde4d82af6b22f3c1c72c3e231cbb618f4c2309cc46f54d16d5502ccf15"
+SRC_URI[sha256sum] =
"541e179665dc4e272b9602f2074243591a157da89cc47064da8c5829dbd2b339"
SRC_URI = "${GNU_MIRROR}/mtools/mtools-${PV}.tar.bz2 \
file://mtools-makeinfo.patch \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180934):
https://lists.openembedded.org/g/openembedded-core/message/180934
Mute This Topic: https://lists.openembedded.org/mt/98707863/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 13/35] man-pages: upgrade 6.03 -> 6.04
From: Wang Mingyu
License-Update:
tmp/ -> .tmp/
Changelog:
- Sections:
- Add HISTORY.
- HISTORY: Restore C89 references.
- Repurpose VERSIONS.
- Simplify STANDARDS.
- SYNOPSIS: Mark several functions as deprecated.
- Build system:
- Support installing in different mandirs
(e.g., man3typedir='/usr/share/man/man3').
- Support installing compressed pages (Z='.gz').
- Support installing link pages as symlinks (LINK_PAGES='symlink').
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 17b93f86d17c6164005fa9f3173585f092539dc6)
Signed-off-by: Steve Sakoman
---
.../man-pages/{man-pages_6.03.bb => man-pages_6.04.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/man-pages/{man-pages_6.03.bb =>
man-pages_6.04.bb} (92%)
diff --git a/meta/recipes-extended/man-pages/man-pages_6.03.bb
b/meta/recipes-extended/man-pages/man-pages_6.04.bb
similarity index 92%
rename from meta/recipes-extended/man-pages/man-pages_6.03.bb
rename to meta/recipes-extended/man-pages/man-pages_6.04.bb
index bc02597ef7..fee57e3fbd 100644
--- a/meta/recipes-extended/man-pages/man-pages_6.03.bb
+++ b/meta/recipes-extended/man-pages/man-pages_6.04.bb
@@ -4,7 +4,7 @@ SECTION = "console/utils"
HOMEPAGE = "http://www.kernel.org/pub/linux/docs/man-pages;
LICENSE = "GPL-2.0-or-later & GPL-2.0-only & GPL-1.0-or-later & BSD-2-Clause &
BSD-3-Clause & BSD-4-Clause & MIT"
-LIC_FILES_CHKSUM = "file://README;md5=0fdad39ebaa973a50785f79f0f59f87f \
+LIC_FILES_CHKSUM = "file://README;md5=5b7d7488344f5af8841dc13aaec49cdf \
file://LICENSES/BSD-2-Clause.txt;md5=d0f280d1058e77e66264a9b9e10e6c89 \
file://LICENSES/BSD-3-Clause.txt;md5=71f739ef75581cae312e8c711bcdab16 \
file://LICENSES/BSD-4-Clause-UC.txt;md5=1da3cf8ad50cd8d5d1de3cfc53196d01 \
@@ -16,7 +16,7 @@ LIC_FILES_CHKSUM =
"file://README;md5=0fdad39ebaa973a50785f79f0f59f87f \
"
SRC_URI = "${KERNELORG_MIRROR}/linux/docs/${BPN}/${BP}.tar.gz"
-SRC_URI[sha256sum] =
"76eca045b42a90dd25d094c46d97ac90187bc0f1bfca358bb5dae5c4337acbb0"
+SRC_URI[sha256sum] =
"590623b99bf1f8ee958483c35cc0aaef2363e42998c4d927d1f705890d15d51e"
inherit manpages
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180933):
https://lists.openembedded.org/g/openembedded-core/message/180933
Mute This Topic: https://lists.openembedded.org/mt/98707862/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 12/35] mpg123: upgrade 1.31.2 -> 1.31.3
From: Wang Mingyu
Changelog:
=
- build:
-- Fix --disable-8bit.
-- Fall back to generic decoder if no yasm for MSVC (bug 346).
-- Fix some pedantic compiler warnings, avoid breaking libtool wrappers.
- mpg123:
-- Fix verbose position printout for new resampling outside libmpg123 (where
output rate differs from decoding rate).
- libsyn123:
-- Fix reconfiguration of resampler to avoid double free when reducing
decimator stages to zero (bug 350).
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 01ccf7c55d3d9c32ffd509abebd928ccb402b9f8)
Signed-off-by: Steve Sakoman
---
.../mpg123/{mpg123_1.31.2.bb => mpg123_1.31.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-multimedia/mpg123/{mpg123_1.31.2.bb => mpg123_1.31.3.bb}
(96%)
diff --git a/meta/recipes-multimedia/mpg123/mpg123_1.31.2.bb
b/meta/recipes-multimedia/mpg123/mpg123_1.31.3.bb
similarity index 96%
rename from meta/recipes-multimedia/mpg123/mpg123_1.31.2.bb
rename to meta/recipes-multimedia/mpg123/mpg123_1.31.3.bb
index 0a2d870cfa..90f285872f 100644
--- a/meta/recipes-multimedia/mpg123/mpg123_1.31.2.bb
+++ b/meta/recipes-multimedia/mpg123/mpg123_1.31.3.bb
@@ -10,7 +10,7 @@ LICENSE = "LGPL-2.1-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=e7b9c15fcfb986abb4cc5e8400a24169"
SRC_URI = "https://www.mpg123.de/download/${BP}.tar.bz2;
-SRC_URI[sha256sum] =
"b17f22905e31f43b6b401dfdf6a71ed11bb7d056f68db449d70b9f9ae839c7de"
+SRC_URI[sha256sum] =
"1ca77d3a69a5ff845b7a0536f783fee554e1041139a6b978f6afe14f5814ad1a"
UPSTREAM_CHECK_REGEX = "mpg123-(?P\d+(\.\d+)+)\.tar"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180932):
https://lists.openembedded.org/g/openembedded-core/message/180932
Mute This Topic: https://lists.openembedded.org/mt/98707861/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 11/35] libsdl2: upgrade 2.26.3 -> 2.26.5
From: Wang Mingyu
2.26.4
This is a stable bugfix release, with the following changes:
Fixed relative mouse motion over remote desktop on Windows
Fixed using older game controller mappings on Linux
2.26.5
This is a stable bugfix release, with the following changes:
The minimum deployment target on macOS is now 10.11, due to changes in the
latest Xcode update
Fixed incorrect modifier keys handling on macOS
Fixed occasional duplicate controller visible on macOS
Fixed handling of third party PS4 controller input reports
Added support for the trigger buttons on the Victrix Pro FS for PS5
Added mapping for Flydigi Vader 2 with the latest firmware (6.0.4.9)
Added mapping for DualSense Edge Wireless Controller on Linux
Added mapping for Hori Pokken Tournament DX Pro Pad
Improved the speed and quality of audio resampling
Fixed crash on Linux if dbus can't be initialized
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 106cdae227775f8e3b32462ed68b99231595f075)
Signed-off-by: Steve Sakoman
---
.../libsdl2/{libsdl2_2.26.3.bb => libsdl2_2.26.5.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/libsdl2/{libsdl2_2.26.3.bb => libsdl2_2.26.5.bb}
(97%)
diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.26.3.bb
b/meta/recipes-graphics/libsdl2/libsdl2_2.26.5.bb
similarity index 97%
rename from meta/recipes-graphics/libsdl2/libsdl2_2.26.3.bb
rename to meta/recipes-graphics/libsdl2/libsdl2_2.26.5.bb
index 15054e1ea9..3274475da1 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.26.3.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.26.5.bb
@@ -25,7 +25,7 @@ SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz;
S = "${WORKDIR}/SDL2-${PV}"
-SRC_URI[sha256sum] =
"c661205a553b7d252425f4b751ff13209e5e020b876bbfa1598494af61790057"
+SRC_URI[sha256sum] =
"ad8fea3da1be64c83c45b1d363a6b4ba8fd60f5bde3b23ec73855709ec5eabf7"
inherit cmake lib_package binconfig-disabled pkgconfig upstream-version-is-even
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180931):
https://lists.openembedded.org/g/openembedded-core/message/180931
Mute This Topic: https://lists.openembedded.org/mt/98707859/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 10/35] libpcap: upgrade 1.10.3 -> 1.10.4
From: Wang Mingyu
Summary for 1.10.4 libpcap release
Source code:
Fix spaces before tabs in indentation.
rpcap:
Fix name of launchd service.
Documentation:
Document use of rpcapd with systemd, launchd, inetd, and xinetd.
Building and testing:
Require at least pkg-config 0.17.0, as we use --static.
Get rid of the remains of gnuc.h.
Require at least autoconf 2.69.
Update config.{guess,sub}, timestamps 2023-01-01,2023-01-21.
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit da76bde131a7fe0833c9fd59a1ca48edaed6fa54)
Signed-off-by: Steve Sakoman
---
.../libpcap/{libpcap_1.10.3.bb => libpcap_1.10.4.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/libpcap/{libpcap_1.10.3.bb =>
libpcap_1.10.4.bb} (95%)
diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.10.3.bb
b/meta/recipes-connectivity/libpcap/libpcap_1.10.4.bb
similarity index 95%
rename from meta/recipes-connectivity/libpcap/libpcap_1.10.3.bb
rename to meta/recipes-connectivity/libpcap/libpcap_1.10.4.bb
index eb0a650130..27b167c21f 100644
--- a/meta/recipes-connectivity/libpcap/libpcap_1.10.3.bb
+++ b/meta/recipes-connectivity/libpcap/libpcap_1.10.4.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM =
"file://LICENSE;md5=5eb289217c160e2920d2e35bddc36453 \
DEPENDS = "flex-native bison-native"
SRC_URI = "https://www.tcpdump.org/release/${BP}.tar.gz;
-SRC_URI[sha256sum] =
"2a8885c403516cf7b0933ed4b14d6caa30e02052489ebd414dc75ac52e7559e6"
+SRC_URI[sha256sum] =
"ed19a0383fad72e3ad435fd239d7cd80d64916b87269550159d20e47160ebe5f"
inherit autotools binconfig-disabled pkgconfig
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180930):
https://lists.openembedded.org/g/openembedded-core/message/180930
Mute This Topic: https://lists.openembedded.org/mt/98707857/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 09/35] libhandy: upgrade 1.8.1 -> 1.8.2
From: Wang Mingyu
Changelog:
==
- Demo
- Correctly use GtkSwitch
- Fix a GLib deprecation
- Docs
- Fix dependency names
- HdyTabView
- Fix set_menu_model() input check
- Fix a typo in docs
- HdySwipeable
- Fix get_swipe_area() fallback
- Memory leak fixes
- Translation updates
- Slovenian
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit b1ebdff55fd8ca77eaff6066370c628a9425bec7)
Signed-off-by: Steve Sakoman
---
.../libhandy/{libhandy_1.8.1.bb => libhandy_1.8.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-gnome/libhandy/{libhandy_1.8.1.bb => libhandy_1.8.2.bb}
(95%)
diff --git a/meta/recipes-gnome/libhandy/libhandy_1.8.1.bb
b/meta/recipes-gnome/libhandy/libhandy_1.8.2.bb
similarity index 95%
rename from meta/recipes-gnome/libhandy/libhandy_1.8.1.bb
rename to meta/recipes-gnome/libhandy/libhandy_1.8.2.bb
index 41c8e9bfb8..e863e8d13b 100644
--- a/meta/recipes-gnome/libhandy/libhandy_1.8.1.bb
+++ b/meta/recipes-gnome/libhandy/libhandy_1.8.2.bb
@@ -10,7 +10,7 @@ LICENSE = "LGPL-2.1-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
SRC_URI =
"git://gitlab.gnome.org/GNOME/libhandy.git;protocol=https;branch=libhandy-1-8"
-SRCREV = "f06c1bfa95a3160575b36315c6d9437376d8af77"
+SRCREV = "48ae7ec0f7f9ee5f666da38b0e39e66874957166"
S = "${WORKDIR}/git"
UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+\.(\d*[02468])+(\.\d+))"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180929):
https://lists.openembedded.org/g/openembedded-core/message/180929
Mute This Topic: https://lists.openembedded.org/mt/98707856/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 07/35] bind: upgrade 9.18.12 -> 9.18.13
From: Wang Mingyu
Changelog:
==
[bug] Use two pairs of dns_db_t and dns_dbversion_t in a
catalog zone structure to avoid a race between the
dns__catz_update_cb() and dns_catz_dbupdate_callback()
functions. [GL #3907]
[bug] Make sure to revert the reconfigured zones to the
previous version of the view, when the new view
reconfiguration fails during the configuration of
one of the configured zones. [GL #3911]
[bug] Fix error path cleanup issues in dns_catz_new_zones()
and dns_catz_new_zone() functions. [GL #3900]
[bug] Unregister db update notify callback before detaching
from the previous db inside the catz update notify
callback. [GL #3777]
[func Run the catalog zone update process on the offload
threads. [GL #3881]
[func Add shutdown signaling for catalog zones. [GL !7571]
[func Add reference count tracing for dns_catz_zone_t and
dns_catz_zones_t. [GL !7570]
[bug] Detach 'rpzs' and 'catzs' from the previous view in
configure_rpz() and configure_catz(), respectively,
just after attaching it to the new view. [GL #3880]
[test Don't test HMAC-MD5 when not supported by libcrypto.
[GL #3871]
[bug] Fix RPZ reference counting error on shutdown in
dns__rpz_timer_cb(). [GL #3866]
[test Test various 'islands of trust' configurations when
using managed keys. [GL #3662]
[bug] Building against (or running with) libuv versions
1.35.0 and 1.36.0 is now a fatal error. The rules for
mixing and matching compile-time and run-time libuv
versions have been tightened for libuv versions between
1.35.0 and 1.40.0. [GL #3840]
[bug] dnssec-cds failed to cleanup properly. [GL #3831]
[bug] Source ports configured for query-source,
transfer-source, etc, were being ignored. (This
feature is deprecated, but it is not yet removed,
so the bug still needed fixing.) [GL #3790]
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 51ab191224aa1320d622bf79184940afa3910d60)
Signed-off-by: Steve Sakoman
---
.../0001-avoid-start-failure-with-bind-user.patch | 0
.../0001-named-lwresd-V-and-start-log-hide-build-options.patch | 0
.../bind-ensure-searching-for-json-headers-searches-sysr.patch | 0
.../bind/{bind-9.18.12 => bind-9.18.13}/bind9 | 0
.../bind/{bind-9.18.12 => bind-9.18.13}/conf.patch | 0
.../bind/{bind-9.18.12 => bind-9.18.13}/generate-rndc-key.sh| 0
.../init.d-add-support-for-read-only-rootfs.patch | 0
.../make-etc-initd-bind-stop-work.patch | 0
.../bind/{bind-9.18.12 => bind-9.18.13}/named.service | 0
.../bind/{bind_9.18.12.bb => bind_9.18.13.bb} | 2 +-
10 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/0001-avoid-start-failure-with-bind-user.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/0001-named-lwresd-V-and-start-log-hide-build-options.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/bind-ensure-searching-for-json-headers-searches-sysr.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 => bind-9.18.13}/bind9
(100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/conf.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/generate-rndc-key.sh (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/init.d-add-support-for-read-only-rootfs.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/make-etc-initd-bind-stop-work.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.12 =>
bind-9.18.13}/named.service (100%)
rename meta/recipes-connectivity/bind/{bind_9.18.12.bb => bind_9.18.13.bb}
(97%)
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.12/0001-avoid-start-failure-with-bind-user.patch
b/meta/recipes-connectivity/bind/bind-9.18.13/0001-avoid-start-failure-with-bind-user.patch
similarity index 100%
rename from
meta/recipes-connectivity/bind/bind-9.18.12/0001-avoid-start-failure-with-bind-user.patch
rename to
meta/recipes-connectivity/bind/bind-9.18.13/0001-avoid-start-failure-with-bind-user.patch
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.12/0001-named-lwresd-V-and-start-log-hide-build-options.patch
b/meta/recipes-connectivity/bind/bind-9.18.13/0001-named-lwresd-V-and-start-log-hide-build-options.patch
similarity index 100%
rename from
meta/recipes-connectivity/bind/bind-9.18.12/0001-named-lwresd-V-and-start-log-hide-build-options.patch
rename to
meta/recipes-connectivity/bind/bind-9.18.13/0001-named-lwresd-V-and-start-log-hide-build-options.patch
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.12/bind-ensure-searching-for-json-headers-searches-sysr.patch
[OE-core][mickledore 05/35] cargo: Fix build on musl/riscv
From: Khem Raj
libc needs fix for defining scope of SOCK_SEQPACKET
Signed-off-by: Khem Raj
Signed-off-by: Alexandre Belloni
(cherry picked from commit 378da16ebe2917f26f9fe8cf654bced09ec6ecfe)
Signed-off-by: Steve Sakoman
---
...efine-SOCK_SEQPACKET-in-common-place.patch | 98 +++
meta/recipes-devtools/rust/rust-source.inc| 1 +
2 files changed, 99 insertions(+)
create mode 100644
meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch
diff --git
a/meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch
b/meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch
new file mode 100644
index 00..54478a8e00
--- /dev/null
+++
b/meta/recipes-devtools/rust/files/0001-musl-Define-SOCK_SEQPACKET-in-common-place.patch
@@ -0,0 +1,98 @@
+From 359bfce3da3f47517001bed4a3ab7338faa564f7 Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Sat, 8 Apr 2023 09:25:31 -0700
+Subject: [PATCH] musl: Define SOCK_SEQPACKET in common place
+
+This define is not architecture specific in musl [1]
+
+[1] https://git.musl-libc.org/cgit/musl/tree/include/sys/socket.h#n90
+
+Upstream-Status: Submitted [https://github.com/rust-lang/libc/pull/3191]
+Signed-off-by: Khem Raj
+---
+ vendor/libc/src/unix/linux_like/linux/musl/b32/arm/mod.rs | 1 -
+ vendor/libc/src/unix/linux_like/linux/musl/b32/hexagon.rs | 2 +-
+ vendor/libc/src/unix/linux_like/linux/musl/b32/mips/mod.rs | 1 -
+ vendor/libc/src/unix/linux_like/linux/musl/b32/powerpc.rs | 1 -
+ vendor/libc/src/unix/linux_like/linux/musl/b32/x86/mod.rs | 1 -
+ vendor/libc/src/unix/linux_like/linux/musl/b64/mod.rs | 2 --
+ vendor/libc/src/unix/linux_like/linux/musl/mod.rs | 1 +
+ 7 files changed, 2 insertions(+), 7 deletions(-)
+
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b32/arm/mod.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b32/arm/mod.rs
+@@ -326,7 +326,6 @@ pub const MAP_SYNC: ::c_int = 0x08;
+
+ pub const SOCK_STREAM: ::c_int = 1;
+ pub const SOCK_DGRAM: ::c_int = 2;
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+
+ pub const EDEADLK: ::c_int = 35;
+ pub const ENAMETOOLONG: ::c_int = 36;
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b32/hexagon.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b32/hexagon.rs
+@@ -296,7 +296,6 @@ pub const SIG_BLOCK: ::c_int = 0x00;
+ pub const SIG_UNBLOCK: ::c_int = 0x01;
+ pub const SOCK_DGRAM: ::c_int = 2;
+ pub const SOCK_NONBLOCK: ::c_int = 2048;
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+ pub const SOCK_STREAM: ::c_int = 1;
+ pub const SOL_CAIF: ::c_int = 278;
+ pub const SOL_IUCV: ::c_int = 277;
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b32/mips/mod.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b32/mips/mod.rs
+@@ -350,7 +350,6 @@ pub const ERFKILL: ::c_int = 167;
+
+ pub const SOCK_STREAM: ::c_int = 2;
+ pub const SOCK_DGRAM: ::c_int = 1;
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+
+ pub const SA_ONSTACK: ::c_int = 0x0800;
+ pub const SA_SIGINFO: ::c_int = 8;
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b32/powerpc.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b32/powerpc.rs
+@@ -257,7 +257,6 @@ pub const MAP_STACK: ::c_int = 0x02;
+
+ pub const SOCK_STREAM: ::c_int = 1;
+ pub const SOCK_DGRAM: ::c_int = 2;
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+
+ pub const EDEADLK: ::c_int = 35;
+ pub const ENAMETOOLONG: ::c_int = 36;
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b32/x86/mod.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b32/x86/mod.rs
+@@ -315,7 +315,6 @@ pub const MAP_SYNC: ::c_int = 0x08;
+
+ pub const SOCK_STREAM: ::c_int = 1;
+ pub const SOCK_DGRAM: ::c_int = 2;
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+
+ pub const EDEADLK: ::c_int = 35;
+ pub const ENAMETOOLONG: ::c_int = 36;
+--- a/vendor/libc/src/unix/linux_like/linux/musl/b64/mod.rs
b/vendor/libc/src/unix/linux_like/linux/musl/b64/mod.rs
+@@ -135,8 +135,6 @@ pub const __SIZEOF_PTHREAD_MUTEX_T: usiz
+
+ pub const SOCK_NONBLOCK: ::c_int = 2048;
+
+-pub const SOCK_SEQPACKET: ::c_int = 5;
+-
+ extern "C" {
+ pub fn getrandom(buf: *mut ::c_void, buflen: ::size_t, flags: ::c_uint)
-> ::ssize_t;
+ }
+--- a/vendor/libc/src/unix/linux_like/linux/musl/mod.rs
b/vendor/libc/src/unix/linux_like/linux/musl/mod.rs
+@@ -526,6 +526,7 @@ pub const POSIX_MADV_DONTNEED: ::c_int =
+
+ pub const MAP_ANONYMOUS: ::c_int = MAP_ANON;
+
++pub const SOCK_SEQPACKET: ::c_int = 5;
+ pub const SOCK_DCCP: ::c_int = 6;
+ pub const SOCK_PACKET: ::c_int = 10;
+
+--- a/vendor/libc/.cargo-checksum.json
b/vendor/libc/.cargo-checksum.json
+@@ -1 +1 @@
[OE-core][mickledore 08/35] cracklib: upgrade 2.9.10 -> 2.9.11
From: Wang Mingyu
Changes:
v2.9.11 Added xz dist
Fix incorrect non-static memory return (drfiemost)
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit a3932906cba1e693ff51a4fdcc60a7b15debee9f)
Signed-off-by: Steve Sakoman
---
.../cracklib/{cracklib_2.9.10.bb => cracklib_2.9.11.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-extended/cracklib/{cracklib_2.9.10.bb =>
cracklib_2.9.11.bb} (94%)
diff --git a/meta/recipes-extended/cracklib/cracklib_2.9.10.bb
b/meta/recipes-extended/cracklib/cracklib_2.9.11.bb
similarity index 94%
rename from meta/recipes-extended/cracklib/cracklib_2.9.10.bb
rename to meta/recipes-extended/cracklib/cracklib_2.9.11.bb
index 8197cdad9e..34ef2b65a1 100644
--- a/meta/recipes-extended/cracklib/cracklib_2.9.10.bb
+++ b/meta/recipes-extended/cracklib/cracklib_2.9.11.bb
@@ -13,7 +13,7 @@ SRC_URI =
"git://github.com/cracklib/cracklib;protocol=https;branch=main \
file://0001-packlib.c-support-dictionary-byte-order-dependent.patch
\
"
-SRCREV = "e74c539344d024709ee76e2920b0af7f9a5c5556"
+SRCREV = "4cf5125250c6325ef0a2dc085eabff875227edc3"
S = "${WORKDIR}/git/src"
inherit autotools gettext
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180928):
https://lists.openembedded.org/g/openembedded-core/message/180928
Mute This Topic: https://lists.openembedded.org/mt/98707855/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 06/35] apr: upgrade 1.7.2 -> 1.7.3
From: Wang Mingyu
Changelog:
===
*) apr-1-config: Fix crosscompiling detection in apr-1-config. PR 66510
*) configure: Add --enable-sysv-shm to use SysV shared memory (shmget) if
available.
*) apr_socket_sendfile: Use WSAIoctl() to get TransmitFile function
pointer on Windows.
*) apr_dir_read: Do not request short file names on Windows 7
and later.
*) apr_file_gets: Optimize for buffered files on Windows.
*) Fix a deadlock when writing to locked files opened with APR_FOPEN_APPEND
on Windows. PR 50058.
*) Don't seek to the end when opening files with APR_FOPEN_APPEND on Windows.
*) apr_file_write: Optimize large writes to buffered files on Windows.
*) apr_file_write: Optimize large reads from buffered files on Windows.
Signed-off-by: Wang Mingyu
Signed-off-by: Alexandre Belloni
(cherry picked from commit 1bee38556441fbff9a4e39942271001ec620416b)
Signed-off-by: Steve Sakoman
---
meta/recipes-support/apr/{apr_1.7.2.bb => apr_1.7.3.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-support/apr/{apr_1.7.2.bb => apr_1.7.3.bb} (98%)
diff --git a/meta/recipes-support/apr/apr_1.7.2.bb
b/meta/recipes-support/apr/apr_1.7.3.bb
similarity index 98%
rename from meta/recipes-support/apr/apr_1.7.2.bb
rename to meta/recipes-support/apr/apr_1.7.3.bb
index c9059c9921..9a93fe0967 100644
--- a/meta/recipes-support/apr/apr_1.7.2.bb
+++ b/meta/recipes-support/apr/apr_1.7.3.bb
@@ -24,7 +24,7 @@ SRC_URI = "${APACHE_MIRROR}/apr/${BPN}-${PV}.tar.bz2 \
file://0001-configure-Remove-runtime-test-for-mmap-that-can-map-.patch \
"
-SRC_URI[sha256sum] =
"75e77cc86776c030c0a5c408dfbd0bf2a0b75eed5351e52d5439fa1e5509a43e"
+SRC_URI[sha256sum] =
"455e218c060c474f2c834816873f6ed69c0cf0e4cfee54282cc93e8e989ee59e"
inherit autotools-brokensep lib_package binconfig multilib_header ptest
multilib_script
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180926):
https://lists.openembedded.org/g/openembedded-core/message/180926
Mute This Topic: https://lists.openembedded.org/mt/98707853/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 04/35] cve-update-nvd2-native: added the missing http import
From: Jan Vermaete
Signed-off-by: Jan Vermaete
Signed-off-by: Luca Ceresoli
(cherry picked from commit 39d2cde7eb922cb0a2cf9402cd8b3ae3b4cc2f62)
Signed-off-by: Steve Sakoman
---
meta/recipes-core/meta/cve-update-nvd2-native.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
index 1c14481c21..2b585983ac 100644
--- a/meta/recipes-core/meta/cve-update-nvd2-native.bb
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -118,6 +118,7 @@ def nvd_request_next(url, api_key, args):
import urllib.request
import urllib.parse
import gzip
+import http
headers = {}
if api_key:
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180924):
https://lists.openembedded.org/g/openembedded-core/message/180924
Mute This Topic: https://lists.openembedded.org/mt/98707850/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 03/35] cve-extra-exclusions: linux-yocto: ignore fixed CVE-2023-1652 & CVE-2023-1829
From: Yoann Congal CVE-2023-1652 & CVE-2023-1829 are fixed by all version used by linux-yocto. Fixing commits are not referenced by NVD but are referenced by: * https://www.linuxkernelcves.com * Debian kernel-sec team ... this should be trust worthy enough. Signed-off-by: Yoann Congal (cherry picked from commit 8f9d6c5b0238641313387c139442566752a1d25d) Signed-off-by: Steve Sakoman --- .../distro/include/cve-extra-exclusions.inc | 19 +++ 1 file changed, 19 insertions(+) diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc b/meta/conf/distro/include/cve-extra-exclusions.inc index 8965a15b37..0ca75bae3e 100644 --- a/meta/conf/distro/include/cve-extra-exclusions.inc +++ b/meta/conf/distro/include/cve-extra-exclusions.inc @@ -494,6 +494,25 @@ CVE_CHECK_IGNORE += "CVE-2023-1281" # Backported in version v6.1.13 747ca7c8a0c7bce004709143d1cd6596b79b1deb CVE_CHECK_IGNORE += "CVE-2023-1513" +# https://nvd.nist.gov/vuln/detail/CVE-2023-1652 +# Patched in kernel since v6.2 e6cf91b7b47ff82b624bdfe2fdcde32bb52e71dd +# Backported in version v5.15.91 0a27dcd5343026ac0cb168ee63304255372b7a36 +# Backported in version v6.1.9 32d5eb95f8f0e362e37c393310b13b9e95404560 +# Ref: https://www.linuxkernelcves.com/cves/CVE-2023-1652 +# Ref: Debian kernel-sec team: https://salsa.debian.org/kernel-team/kernel-sec/-/blob/1fa77554d4721da54e2df06fa1908a83ba6b1045/retired/CVE-2023-1652 +CVE_CHECK_IGNORE += "CVE-2023-1652" + +# https://nvd.nist.gov/vuln/detail/CVE-2023-1829 +# Patched in kernel since v6.3-rc1 8c710f75256bb3cf05ac7b1672c82b92c43f3d28 +# Backported in version v5.4.235 7a6fb69bbcb21e9ce13bdf18c008c268874f0480 +# Backported in version v5.10.173 18c3fa7a7fdbb4d21dafc8a7710ae2c1680930f6 +# Backported in version v5.15.100 7c183dc0af472dec33d2c0786a5e356baa8cad19 +# Backported in version v6.1.18 3abebc503a5148072052c229c6b04b329a420ecd +# Backported in version v6.2.5 372ae77cf11d11fb118cbe2d37def9dd5f826abd +# Ref: https://www.linuxkernelcves.com/cves/CVE-2023-1829 +# Ref: Debian kernel-sec team : https://salsa.debian.org/kernel-team/kernel-sec/-/blob/1fa77554d4721da54e2df06fa1908a83ba6b1045/active/CVE-2023-1829 +CVE_CHECK_IGNORE += "CVE-2023-1829" + # https://nvd.nist.gov/vuln/detail/CVE-2023-23005 # Introduced in version v6.1 7b88bda3761b95856cf97822efe8281c8100067b # Patched in kernel since v6.2 4a625ceee8a0ab0273534cb6b432ce6b331db5ee -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180923): https://lists.openembedded.org/g/openembedded-core/message/180923 Mute This Topic: https://lists.openembedded.org/mt/98707849/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore 02/35] tiff: Add fix for CVE-2022-4645
From: Pawan Badganchi
Below patch fixes the CVE-2022-4645 as well.
0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
Link: https://nvd.nist.gov/vuln/detail/CVE-2022-4645
Signed-off-by: Pawan Badganchi
Signed-off-by: Luca Ceresoli
(cherry picked from commit 312393edf0aa5b2c515c08245d1c289ba79bad55)
Signed-off-by: Steve Sakoman
---
...-of-TIFFTAG_INKNAMES-and-related-TIF.patch | 267 ++
1 file changed, 267 insertions(+)
create mode 100644
meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
diff --git
a/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
b/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
new file mode 100644
index 00..17b37be041
--- /dev/null
+++
b/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
@@ -0,0 +1,267 @@
+From f00484b9519df933723deb38fff943dc291a793d Mon Sep 17 00:00:00 2001
+From: Su_Laus
+Date: Tue, 30 Aug 2022 16:56:48 +0200
+Subject: [PATCH] Revised handling of TIFFTAG_INKNAMES and related
+ TIFFTAG_NUMBEROFINKS value
+
+In order to solve the buffer overflow issues related to TIFFTAG_INKNAMES and
related TIFFTAG_NUMBEROFINKS value, a revised handling of those tags within
LibTiff is proposed:
+
+Behaviour for writing:
+`NumberOfInks` MUST fit to the number of inks in the `InkNames` string.
+`NumberOfInks` is automatically set when `InkNames` is set.
+If `NumberOfInks` is different to the number of inks within `InkNames`
string, that will be corrected and a warning is issued.
+If `NumberOfInks` is not equal to samplesperpixel only a warning will be
issued.
+
+Behaviour for reading:
+When reading `InkNames` from a TIFF file, the `NumberOfInks` will be set
automatically to the number of inks in `InkNames` string.
+If `NumberOfInks` is different to the number of inks within `InkNames`
string, that will be corrected and a warning is issued.
+If `NumberOfInks` is not equal to samplesperpixel only a warning will be
issued.
+
+This allows the safe use of the NumberOfInks value to read out the InkNames
without buffer overflow
+
+This MR will close the following issues: #149, #150, #152, #168 (to be
checked), #250, #269, #398 and #456.
+
+It also fixes the old bug at
http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of
`NumberOfInks = SPP` was introduced, which is in my opinion not necessary and
does not solve the general issue.
+
+CVE: CVE-2022-3599 CVE-2022-4645
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/e813112545942107551433d61afd16ac094ff246.patch]
+Signed-off-by: Ross Burton
+Signed-off-by: Pawan Badganchi
+---
+ libtiff/tif_dir.c | 119 -
+ libtiff/tif_dir.h | 2 +
+ libtiff/tif_dirinfo.c | 2 +-
+ libtiff/tif_dirwrite.c | 5 ++
+ libtiff/tif_print.c| 4 ++
+ 5 files changed, 82 insertions(+), 50 deletions(-)
+
+diff --git a/libtiff/tif_dir.c b/libtiff/tif_dir.c
+index 793e8a79..816f7756 100644
+--- a/libtiff/tif_dir.c
b/libtiff/tif_dir.c
+@@ -136,32 +136,30 @@ setExtraSamples(TIFF* tif, va_list ap, uint32_t* v)
+ }
+
+ /*
+- * Confirm we have "samplesperpixel" ink names separated by \0. Returns
++ * Count ink names separated by \0. Returns
+ * zero if the ink names are not as expected.
+ */
+-static uint32_t
+-checkInkNamesString(TIFF* tif, uint32_t slen, const char* s)
++static uint16_t
++countInkNamesString(TIFF *tif, uint32_t slen, const char *s)
+ {
+- TIFFDirectory* td = >tif_dir;
+- uint16_t i = td->td_samplesperpixel;
++ uint16_t i = 0;
++ const char *ep = s + slen;
++ const char *cp = s;
+
+ if (slen > 0) {
+- const char* ep = s+slen;
+- const char* cp = s;
+- for (; i > 0; i--) {
++ do {
+ for (; cp < ep && *cp != '\0'; cp++) {}
+ if (cp >= ep)
+ goto bad;
+ cp++; /* skip \0 */
+- }
+- return ((uint32_t)(cp - s));
++ i++;
++ } while (cp < ep);
++ return (i);
+ }
+ bad:
+ TIFFErrorExt(tif->tif_clientdata, "TIFFSetField",
+- "%s: Invalid InkNames value; expecting %"PRIu16" names, found
%"PRIu16,
+- tif->tif_name,
+- td->td_samplesperpixel,
+- (uint16_t)(td->td_samplesperpixel-i));
++ "%s: Invalid InkNames value; no NUL at given buffer end
location %"PRIu32", after %"PRIu16" ink",
++ tif->tif_name, slen, i);
+ return (0);
+ }
+
+@@ -478,13 +476,61 @@ _TIFFVSetField(TIFF* tif, uint32_t tag, va_list ap)
+ _TIFFsetFloatArray(>td_refblackwhite, va_arg(ap, float*),
6);
+
[OE-core][mickledore 00/35] Patch review
Please review this set of patches for mickledore and have comments back by
end of day Tuesday.
Passed a-full on autobuilder:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5265
The following changes since commit c57d1a561db563ed2f521bbac5fc12d4ac8e11a7:
build-appliance-image: Update to mickledore head revision (2023-04-22
11:11:55 +0100)
are available in the Git repository at:
https://git.openembedded.org/openembedded-core-contrib stable/mickledore-nut
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/mickledore-nut
Alex Kiernan (1):
rust: Upgrade 1.68.1 -> 1.68.2
Arslan Ahmad (1):
kernel-fitimage: Fix the default dtb config check
Bruce Ashfield (1):
kernel: improve initramfs bundle processing time
Dmitry Baryshkov (1):
linux-firmware: upgrade 20230210 -> 20230404
Jan Vermaete (1):
cve-update-nvd2-native: added the missing http import
Kai Kang (1):
libnotify: remove dependency dbus
Khem Raj (1):
cargo: Fix build on musl/riscv
Martin Jansa (1):
populate_sdk_ext.bbclass: set METADATA_REVISION with an DISTRO
override
Pawan Badganchi (1):
tiff: Add fix for CVE-2022-4645
Peter Bergin (1):
update-alternatives.bbclass: fix old override syntax
Piotr Łobacz (1):
libarchive: Enable acls, xattr for native as well as target
Richard Purdie (1):
qemu: Add fix for powerpc instruction fallback issue
Ross Burton (1):
connman: backport fix for CVE-2023-28488
Steve Sakoman (1):
Revert "xserver-xorg: backport fix for CVE-2023-1393"
Thomas Roos (1):
oeqa/utils/metadata.py: Fix running oe-selftest running with no distro
set
Wang Mingyu (17):
apr: upgrade 1.7.2 -> 1.7.3
bind: upgrade 9.18.12 -> 9.18.13
cracklib: upgrade 2.9.10 -> 2.9.11
libhandy: upgrade 1.8.1 -> 1.8.2
libpcap: upgrade 1.10.3 -> 1.10.4
libsdl2: upgrade 2.26.3 -> 2.26.5
mpg123: upgrade 1.31.2 -> 1.31.3
man-pages: upgrade 6.03 -> 6.04
mtools: upgrade 4.0.42 -> 4.0.43
pango: upgrade 1.50.13 -> 1.50.14
ruby: upgrade 3.2.1 -> 3.2.2
texinfo: upgrade 7.0.2 -> 7.0.3
wpebackend-fdo: upgrade 1.14.0 -> 1.14.2
xserver-xorg: upgrade 21.1.7 -> 21.1.8
xwayland: upgrade 22.1.8 -> 23.1.1
vala: upgrade 0.56.4 -> 0.56.6
mesa: upgrade 23.0.0 -> 23.0.2
Yoann Congal (1):
cve-extra-exclusions: linux-yocto: ignore fixed CVE-2023-1652 &
CVE-2023-1829
Zhixiong Chi (1):
libpam: Fix the xtests/tst-pam_motd[1|3] failures
bkyleruss...@gmail.com (1):
kernel-devsrc: depend on python3-core instead of python3
meta/classes-recipe/kernel-fitimage.bbclass | 36 ++-
meta/classes-recipe/kernel.bbclass| 2 +-
meta/classes-recipe/populate_sdk_ext.bbclass | 3 +-
.../update-alternatives.bbclass | 4 +-
.../distro/include/cve-extra-exclusions.inc | 19 ++
meta/lib/oeqa/utils/metadata.py | 6 +-
...1-avoid-start-failure-with-bind-user.patch | 0
...d-V-and-start-log-hide-build-options.patch | 0
...ching-for-json-headers-searches-sysr.patch | 0
.../bind/{bind-9.18.12 => bind-9.18.13}/bind9 | 0
.../{bind-9.18.12 => bind-9.18.13}/conf.patch | 0
.../generate-rndc-key.sh | 0
...t.d-add-support-for-read-only-rootfs.patch | 0
.../make-etc-initd-bind-stop-work.patch | 0
.../named.service | 0
.../bind/{bind_9.18.12.bb => bind_9.18.13.bb} | 2 +-
...ify-and-sanitize-packet-length-first.patch | 63 +
.../connman/connman_1.41.bb | 1 +
.../{libpcap_1.10.3.bb => libpcap_1.10.4.bb} | 2 +-
.../meta/cve-update-nvd2-native.bb| 1 +
.../{mtools_4.0.42.bb => mtools_4.0.43.bb}| 2 +-
meta/recipes-devtools/qemu/qemu.inc | 1 +
meta/recipes-devtools/qemu/qemu/ppc.patch | 70 +
.../ruby/{ruby_3.2.1.bb => ruby_3.2.2.bb} | 2 +-
.../rust/{cargo_1.68.1.bb => cargo_1.68.2.bb} | 0
...efine-SOCK_SEQPACKET-in-common-place.patch | 98 +++
...ibstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb} | 0
68.1.bb => rust-cross-canadian_1.68.2.bb} | 0
...ust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb} | 0
meta/recipes-devtools/rust/rust-source.inc| 3 +-
.../rust/{rust_1.68.1.bb => rust_1.68.2.bb} | 0
meta/recipes-devtools/vala/vala_0.56.4.bb | 3 -
meta/recipes-devtools/vala/vala_0.56.6.bb | 3 +
...{cracklib_2.9.10.bb => cracklib_2.9.11.bb} | 2 +-
.../libarchive/libarchive_3.6.2.bb| 6 +-
.../{man-pages_6.03.bb => man-pages_6.04.bb} | 4 +-
...rely-on-all-filesystems-providing-a-.patch | 108 +++
meta/recipes-extended/pam/libpam_1.5.2.bb | 1 +
.../{texinfo_7.0.2.bb => texinfo_7.0.3.bb}| 2 +-
.../{libhandy_1.8.1.bb => libhandy_1.8.2.bb} | 2 +-
.../libnotify/libnotify_0.8.2.bb | 2 +-
.../{libsdl2_2.26.3.bb => libsdl2_2.26.5.bb} | 2 +-
.../{mesa-gl_23.0.0.bb => mesa-gl_23.0.2.bb} | 0
meta/recipes-graphics/mesa/mesa.inc | 2 +-
.../mesa/{mesa_23.0.0.bb => mesa_23.0.2.bb} | 0
[OE-core][mickledore 01/35] connman: backport fix for CVE-2023-28488
From: Ross Burton
Signed-off-by: Ross Burton
Signed-off-by: Steve Sakoman
---
...ify-and-sanitize-packet-length-first.patch | 63 +++
.../connman/connman_1.41.bb | 1 +
2 files changed, 64 insertions(+)
create mode 100644
meta/recipes-connectivity/connman/connman/0001-gdhcp-Verify-and-sanitize-packet-length-first.patch
diff --git
a/meta/recipes-connectivity/connman/connman/0001-gdhcp-Verify-and-sanitize-packet-length-first.patch
b/meta/recipes-connectivity/connman/connman/0001-gdhcp-Verify-and-sanitize-packet-length-first.patch
new file mode 100644
index 00..8e2f47a1d5
--- /dev/null
+++
b/meta/recipes-connectivity/connman/connman/0001-gdhcp-Verify-and-sanitize-packet-length-first.patch
@@ -0,0 +1,63 @@
+From 99e2c16ea1cced34a5dc450d76287a1c3e762138 Mon Sep 17 00:00:00 2001
+From: Daniel Wagner
+Date: Tue, 11 Apr 2023 08:12:56 +0200
+Subject: [PATCH] gdhcp: Verify and sanitize packet length first
+
+Avoid overwriting the read packet length after the initial test. Thus
+move all the length checks which depends on the total length first
+and do not use the total lenght from the IP packet afterwards.
+
+Fixes CVE-2023-28488
+
+Reported by Polina Smirnova
+
+CVE: CVE-2023-28488
+Upstream-Status: Backport
+Signed-off-by: Ross Burton
+
+---
+ gdhcp/client.c | 16 +---
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/gdhcp/client.c b/gdhcp/client.c
+index 7efa7e45..82017692 100644
+--- a/gdhcp/client.c
b/gdhcp/client.c
+@@ -1319,9 +1319,9 @@ static bool sanity_check(struct ip_udp_dhcp_packet
*packet, int bytes)
+ static int dhcp_recv_l2_packet(struct dhcp_packet *dhcp_pkt, int fd,
+ struct sockaddr_in *dst_addr)
+ {
+- int bytes;
+ struct ip_udp_dhcp_packet packet;
+ uint16_t check;
++ int bytes, tot_len;
+
+ memset(, 0, sizeof(packet));
+
+@@ -1329,15 +1329,17 @@ static int dhcp_recv_l2_packet(struct dhcp_packet
*dhcp_pkt, int fd,
+ if (bytes < 0)
+ return -1;
+
+- if (bytes < (int) (sizeof(packet.ip) + sizeof(packet.udp)))
+- return -1;
+-
+- if (bytes < ntohs(packet.ip.tot_len))
++ tot_len = ntohs(packet.ip.tot_len);
++ if (bytes > tot_len) {
++ /* ignore any extra garbage bytes */
++ bytes = tot_len;
++ } else if (bytes < tot_len) {
+ /* packet is bigger than sizeof(packet), we did partial read */
+ return -1;
++ }
+
+- /* ignore any extra garbage bytes */
+- bytes = ntohs(packet.ip.tot_len);
++ if (bytes < (int) (sizeof(packet.ip) + sizeof(packet.udp)))
++ return -1;
+
+ if (!sanity_check(, bytes))
+ return -1;
+--
+2.34.1
+
diff --git a/meta/recipes-connectivity/connman/connman_1.41.bb
b/meta/recipes-connectivity/connman/connman_1.41.bb
index 79542b2175..3f2e29820f 100644
--- a/meta/recipes-connectivity/connman/connman_1.41.bb
+++ b/meta/recipes-connectivity/connman/connman_1.41.bb
@@ -8,6 +8,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
file://CVE-2022-32293_p1.patch \
file://CVE-2022-32293_p2.patch \
file://CVE-2022-32292.patch \
+ file://0001-gdhcp-Verify-and-sanitize-packet-length-first.patch \
"
SRC_URI:append:libc-musl = "
file://0002-resolve-musl-does-not-implement-res_ninit.patch"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180921):
https://lists.openembedded.org/g/openembedded-core/message/180921
Mute This Topic: https://lists.openembedded.org/mt/98707846/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] python3: use system expat
From: Ross Burton
Instead of statically linking to an integrated expat which may not be
updated to fix security issues, dynamically link to the system expat.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/python/python3_3.11.2.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/python/python3_3.11.2.bb
b/meta/recipes-devtools/python/python3_3.11.2.bb
index 810f0c2e009..421a305e22f 100644
--- a/meta/recipes-devtools/python/python3_3.11.2.bb
+++ b/meta/recipes-devtools/python/python3_3.11.2.bb
@@ -72,11 +72,11 @@ ALTERNATIVE_LINK_NAME[python3-config] =
"${bindir}/python${PYTHON_MAJMIN}-config
ALTERNATIVE_TARGET[python3-config] =
"${bindir}/python${PYTHON_MAJMIN}-config-${MULTILIB_SUFFIX}"
-DEPENDS = "bzip2-replacement-native libffi bzip2 openssl sqlite3 zlib
virtual/libintl xz virtual/crypt util-linux-libuuid libtirpc libnsl2
autoconf-archive-native ncurses"
+DEPENDS = "bzip2-replacement-native expat libffi bzip2 openssl sqlite3 zlib
virtual/libintl xz virtual/crypt util-linux-libuuid libtirpc libnsl2
autoconf-archive-native ncurses"
DEPENDS:append:class-target = " python3-native"
DEPENDS:append:class-nativesdk = " python3-native"
-EXTRA_OECONF = " --without-ensurepip --enable-shared
--with-platlibdir=${baselib}"
+EXTRA_OECONF = " --without-ensurepip --enable-shared
--with-platlibdir=${baselib} --with-system-expat"
EXTRA_OECONF:append:class-native = " --bindir=${bindir}/${PN}"
EXTRA_OECONF:append:class-target = " --with-build-python=nativepython3"
EXTRA_OECONF:append:class-nativesdk = " --with-build-python=nativepython3"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180919):
https://lists.openembedded.org/g/openembedded-core/message/180919
Mute This Topic: https://lists.openembedded.org/mt/98705185/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] python3: use libedit instead of readline
From: Ross Burton
libedit has feature parity with readline but is more permissively
licensed (BSD verses GPLv3), so switch to libedit by default.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/python/python3_3.11.2.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-devtools/python/python3_3.11.2.bb
b/meta/recipes-devtools/python/python3_3.11.2.bb
index 5bd8d32b140..4a9aa9306bc 100644
--- a/meta/recipes-devtools/python/python3_3.11.2.bb
+++ b/meta/recipes-devtools/python/python3_3.11.2.bb
@@ -95,10 +95,10 @@ CACHED_CONFIGUREVARS = " \
"
# PGO currently causes builds to not be reproducible so disable by default,
see YOCTO #13407
-PACKAGECONFIG:class-target ??= "readline gdbm
${@bb.utils.filter('DISTRO_FEATURES', 'lto', d)}"
-PACKAGECONFIG:class-native ??= "readline gdbm"
+PACKAGECONFIG:class-target ??= "editline gdbm
${@bb.utils.filter('DISTRO_FEATURES', 'lto', d)}"
+PACKAGECONFIG:class-native ??= "editline gdbm"
PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
-PACKAGECONFIG[readline] = ",,readline"
+PACKAGECONFIG[readline] = "--with-readline=readline,,readline,,,editline"
PACKAGECONFIG[editline] = "--with-readline=editline,,libedit,,,readline"
# Use profile guided optimisation by running PyBench inside qemu-user
PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180917):
https://lists.openembedded.org/g/openembedded-core/message/180917
Mute This Topic: https://lists.openembedded.org/mt/98705183/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] python3: clean up PACKAGECONFIG
From: Ross Burton
There's no need to define the PACKAGECONFIG for each class when they're
all identical (as native DISTRO_FEATURES are pruned before use).
Also add a disabled case to the LTO configuration to be explicit.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/python/python3_3.11.2.bb | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/python/python3_3.11.2.bb
b/meta/recipes-devtools/python/python3_3.11.2.bb
index 4a9aa9306bc..810f0c2e009 100644
--- a/meta/recipes-devtools/python/python3_3.11.2.bb
+++ b/meta/recipes-devtools/python/python3_3.11.2.bb
@@ -95,9 +95,7 @@ CACHED_CONFIGUREVARS = " \
"
# PGO currently causes builds to not be reproducible so disable by default,
see YOCTO #13407
-PACKAGECONFIG:class-target ??= "editline gdbm
${@bb.utils.filter('DISTRO_FEATURES', 'lto', d)}"
-PACKAGECONFIG:class-native ??= "editline gdbm"
-PACKAGECONFIG:class-nativesdk ??= "readline gdbm"
+PACKAGECONFIG ??= "editline gdbm ${@bb.utils.filter('DISTRO_FEATURES', 'lto',
d)}"
PACKAGECONFIG[readline] = "--with-readline=readline,,readline,,,editline"
PACKAGECONFIG[editline] = "--with-readline=editline,,libedit,,,readline"
# Use profile guided optimisation by running PyBench inside qemu-user
@@ -105,7 +103,7 @@ PACKAGECONFIG[pgo] = "--enable-optimizations,,qemu-native"
PACKAGECONFIG[tk] = ",,tk"
PACKAGECONFIG[tcl] = ",,tcl"
PACKAGECONFIG[gdbm] = ",,gdbm"
-PACKAGECONFIG[lto] = "--with-lto,,"
+PACKAGECONFIG[lto] = "--with-lto,--without-lto"
do_configure:prepend () {
mkdir -p ${B}/Modules
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180918):
https://lists.openembedded.org/g/openembedded-core/message/180918
Mute This Topic: https://lists.openembedded.org/mt/98705184/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] Revert "ipk: Decode byte data to string in manifest handling"
cf9df9e8d89f ("ipk: Decode byte data to string in manifest handling")
did a bit of least-effort fix to a string vs byte sequence issue in the
manifest handling. The approach was chosen as it localised the fix,
rather than having to analyse further call sites.
However since then f2167ae80258 ("package_manager/ipk: do not pipe
stderr to stdout") was applied, reworking the output handling from the
subcommand. dummy_bytes() now returns a string, so stop trying to decode
it.
Fixes: f2167ae80258 ("package_manager/ipk: do not pipe stderr to stdout")
Cc: Curtis Meier
Cc: Pam Eggler
Signed-off-by: Andrew Jeffery
---
meta/lib/oe/package_manager/ipk/manifest.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oe/package_manager/ipk/manifest.py
b/meta/lib/oe/package_manager/ipk/manifest.py
index 469e14c3c6b8..3549d7428d72 100644
--- a/meta/lib/oe/package_manager/ipk/manifest.py
+++ b/meta/lib/oe/package_manager/ipk/manifest.py
@@ -64,7 +64,7 @@ class PkgManifest(Manifest):
if len(pkgs_to_install) == 0:
return
-output = pm.dummy_install(pkgs_to_install).decode('utf-8')
+output = pm.dummy_install(pkgs_to_install)
with open(self.full_manifest, 'w+') as manifest:
pkg_re = re.compile('^Installing ([^ ]+) [^ ].*')
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180916):
https://lists.openembedded.org/g/openembedded-core/message/180916
Mute This Topic: https://lists.openembedded.org/mt/98705163/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] cve-check: add option to add additional patched CVEs
On Fri, 2023-05-05 at 11:36 +, Valek, Andrej wrote: > 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 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/cve- > > > check.bbclass > > > index bd9e7e7445c..957ea0130dc 100644 > > > --- a/meta/classes/cve-check.bbclass > > > +++ b/meta/classes/cve-check.bbclass > > > @@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= "" > > > # > > > CVE_CHECK_IGNORE ?= "" > > > > > > +# Usually a CVE gets treated as patched when a patch with the name > > > of the CVE > > > +# gets applied. Basically this variable should not be used. But if > > > there are > > > +# other reasons to mark a CVE as patched it can be added to this > > > list. > > > +CVE_CHECK_PATCHED ?= "" > > > > We're not adding variables which are documented as "Basically this > > variable should not be used.". If you shouldn't need/use it, we don't > > need it. > Ok, maybe I should change the description a little bit. Do you have > some other preference? > > > > Can't you just use the ignore variable for the same end result? > Nope. If I use a ignore list, the output in the SBOM will be set to > "ignored", which is wrong, because it has been fixed. And that's the > reason. > I suspect "ignored" is a bad way to describe things. Ignore might mean the issue doesn't apply, has been fixed in some way or we really are ignoring it. What does the SBOM spec say about different field values? Should we be providing more reasoning than just adding to an ignore list? I'm a bit worried we're not solving the real problem here by adding a new variable we tell people not to use. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180915): https://lists.openembedded.org/g/openembedded-core/message/180915 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/5] insane.bbclass: add a SUMMARY/HOMEPAGE check (oe-core recipes only)
On 27 Apr 2023, at 08:35, Alexander Kanavin via lists.openembedded.org wrote: > > This was done in a selftest, but that is too late and creates > friction in integration as errors are not seen until autobuilder fails. > > Bonus fix: SUMMARY check wasn't even working, as in the absence > of one set in the recipe there is a default value set from bitbake.conf. > > I left DESCRIPTION check out for now, as many recipes don't actually > have it, and it's set from SUMMARY (plus a dot) if absent. I’m torn over this and the maintainer check. I like that the checks are being done earlier so they don’t trip up in oe-selftest, but I don’t like that they’re errors. If I want to add a new recipe to core and use devtool, it will immediately fail to build with errors due to the summary, homepage, and maintainer fields being missing. For this reason, I believe these should be warnings: they tell you that something needs to be done, but you can focus first on making a recipe that *compiles* before having to write a nice summary. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180914): https://lists.openembedded.org/g/openembedded-core/message/180914 Mute This Topic: https://lists.openembedded.org/mt/98532469/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] cve-check: add option to add additional patched CVEs
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 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/cve- > > check.bbclass > > index bd9e7e7445c..957ea0130dc 100644 > > --- a/meta/classes/cve-check.bbclass > > +++ b/meta/classes/cve-check.bbclass > > @@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= "" > > # > > CVE_CHECK_IGNORE ?= "" > > > > +# Usually a CVE gets treated as patched when a patch with the name > > of the CVE > > +# gets applied. Basically this variable should not be used. But if > > there are > > +# other reasons to mark a CVE as patched it can be added to this > > list. > > +CVE_CHECK_PATCHED ?= "" > > We're not adding variables which are documented as "Basically this > variable should not be used.". If you shouldn't need/use it, we don't > need it. Ok, maybe I should change the description a little bit. Do you have some other preference? > > Can't you just use the ignore variable for the same end result? Nope. If I use a ignore list, the output in the SBOM will be set to "ignored", which is wrong, because it has been fixed. And that's the reason. > > Cheers, > > Richard > Regards, Andrej -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180913): https://lists.openembedded.org/g/openembedded-core/message/180913 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] cve-check: add option to add additional patched CVEs
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 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/cve-check.bbclass > index bd9e7e7445c..957ea0130dc 100644 > --- a/meta/classes/cve-check.bbclass > +++ b/meta/classes/cve-check.bbclass > @@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= "" > # > CVE_CHECK_IGNORE ?= "" > > +# Usually a CVE gets treated as patched when a patch with the name of the CVE > +# gets applied. Basically this variable should not be used. But if there are > +# other reasons to mark a CVE as patched it can be added to this list. > +CVE_CHECK_PATCHED ?= "" We're not adding variables which are documented as "Basically this variable should not be used.". If you shouldn't need/use it, we don't need it. Can't you just use the ignore variable for the same end result? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180912): https://lists.openembedded.org/g/openembedded-core/message/180912 Mute This Topic: https://lists.openembedded.org/mt/98703185/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH] cve-check: add option to add additional patched CVEs
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/cve-check.bbclass
index bd9e7e7445c..957ea0130dc 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -78,6 +78,11 @@ CVE_CHECK_SKIP_RECIPE ?= ""
#
CVE_CHECK_IGNORE ?= ""
+# Usually a CVE gets treated as patched when a patch with the name of the CVE
+# gets applied. Basically this variable should not be used. But if there are
+# other reasons to mark a CVE as patched it can be added to this list.
+CVE_CHECK_PATCHED ?= ""
+
# Layers to be excluded
CVE_CHECK_LAYER_EXCLUDELIST ??= ""
@@ -284,6 +289,9 @@ def check_cves(d, patched_cves):
cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# add additional patched CVEs into existing patched list
+patched_cves.update(d.getVar("CVE_CHECK_PATCHED").split())
+
import sqlite3
db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
conn = sqlite3.connect(db_file, uri=True)
--
2.40.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180911):
https://lists.openembedded.org/g/openembedded-core/message/180911
Mute This Topic: https://lists.openembedded.org/mt/98703185/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] image_types_wic.bbclass: remove MLPREFIX for binutils
On Thu, 2023-05-04 at 21:17 -0700, Chen Qi via lists.openembedded.org wrote: > From: Chen Qi > > With the following two commits, the MLPREFIX needs to be removed > to avoid the 'nothing provides' error. > > gcc/go: Drop crosssdk suffix from virtual provides to improve dependency > handling > binutils: Drop crosssdk suffix from virtual provides to improve dependency > handling > > Signed-off-by: Chen Qi > --- > meta/classes-recipe/image_types_wic.bbclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Thanks, Martin had sent this patch too and I've merged that one. Cheers, Ricahrd -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180910): https://lists.openembedded.org/g/openembedded-core/message/180910 Mute This Topic: https://lists.openembedded.org/mt/98699339/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v4] devicetree.bbclass: Allow selection of dts files to build
On Fri, 2023-05-05 at 10:59 +, Petr Kubizňák - 2N wrote: > Thanks for accepting the patch. > > I can for sure send a doc patch, just want to make sure it is desired > since the glossary does not list any DT_* variable at the moment, and > the devicetree class section in this respect only refers to the class > sources. So I think both DT_FILES and DT_FILES_PATH variables should > be documented at least, right? Ideally all the variables in use would be documented in the manual. We're trying to fix and improve the docs so yes, adding docs for the ones you added would be great, bonus marks if there are others you can add at the same time! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180909): https://lists.openembedded.org/g/openembedded-core/message/180909 Mute This Topic: https://lists.openembedded.org/mt/98510103/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH v4] devicetree.bbclass: Allow selection of dts files to build
Hi Richard,
Thanks for accepting the patch.
I can for sure send a doc patch, just want to make sure it is desired since the
glossary does not list any DT_* variable at the moment, and the devicetree
class section in this respect only refers to the class sources. So I think both
DT_FILES and DT_FILES_PATH variables should be documented at least, right?
Cheers,
Petr
From: Richard Purdie
Sent: Thursday, May 4, 2023 1:38 PM
To: Petr Kubizňák - 2N; openembedded-core@lists.openembedded.org
Cc: Michael Opdenacker
Subject: Re: [OE-core][PATCH v4] devicetree.bbclass: Allow selection of dts
files to build
On Wed, 2023-04-26 at 09:22 +0200, Petr Kubizňák wrote:
> Add DT_FILES variable to allow the user of the class to select specific
> dts files to build. This is useful for packages featuring dts files
> for multiple machines.
>
> To make DT_FILES consistent with KERNEL_DEVICETREE, the list works
> with both dts and dtb files.
>
> Signed-off-by: Petr Kubizňák
> ---
> meta/classes-recipe/devicetree.bbclass | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes-recipe/devicetree.bbclass
> b/meta/classes-recipe/devicetree.bbclass
> index ed2a92e447..bd50d7fa1d 100644
> --- a/meta/classes-recipe/devicetree.bbclass
> +++ b/meta/classes-recipe/devicetree.bbclass
> @@ -53,8 +53,10 @@ KERNEL_INCLUDE ??= " \
>
> DT_INCLUDE[doc] = "Search paths to be made available to both the device tree
> compiler and preprocessor for inclusion."
> DT_INCLUDE ?= "${DT_FILES_PATH} ${KERNEL_INCLUDE}"
> -DT_FILES_PATH[doc] = "Defaults to source directory, can be used to select
> dts files that are not in source (e.g. generated)."
> +DT_FILES_PATH[doc] = "Path to the directory containing dts files to build.
> Defaults to source directory."
> DT_FILES_PATH ?= "${S}"
> +DT_FILES[doc] = "Space-separated list of dts or dtb files (relative to
> DT_FILES_PATH) to build. If empty, all dts files are built."
> +DT_FILES ?= ""
>
> DT_PADDING_SIZE[doc] = "Size of padding on the device tree blob, used as
> extra space typically for additional properties during boot."
> DT_PADDING_SIZE ??= "0x3000"
> @@ -125,9 +127,12 @@ def devicetree_compile(dtspath, includes, d):
> subprocess.run(dtcargs, check = True, stdout=subprocess.PIPE,
> stderr=subprocess.STDOUT)
>
> python devicetree_do_compile() {
> +import re
> includes = expand_includes("DT_INCLUDE", d)
> +dtfiles = d.getVar("DT_FILES").split()
> +dtfiles = [ re.sub(r"\.dtbo?$", ".dts", dtfile) for dtfile in dtfiles ]
> listpath = d.getVar("DT_FILES_PATH")
> -for dts in os.listdir(listpath):
> +for dts in dtfiles or os.listdir(listpath):
> dtspath = os.path.join(listpath, dts)
> try:
> if not(os.path.isfile(dtspath)) or not(dts.endswith(".dts") or
> devicetree_source_is_overlay(dtspath)):
I've taken this but could you send a patch to the documentation to add
this variable to the glossary and to the devicetree class section
please?
Thanks,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#180908):
https://lists.openembedded.org/g/openembedded-core/message/180908
Mute This Topic: https://lists.openembedded.org/mt/98510103/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 1/2] oeqa/utils/qemurunner: change the serial runner
On Fri, 2023-05-05 at 10:32 +, Ross Burton wrote: > On 11 Apr 2023, at 16:05, Louis Rannou via lists.openembedded.org > wrote: > > Create a new runner run_serial_socket which usage matches the traditional > > ssh > > runner. Its return status is 0 when the command succeeded or 0 when it > > failed. If an error is encountered, it raises an Exception. > > > > The previous serial runner is maintained and marked as deprecated. > > I absolutely love this because the existing run_serial has the most > confusing behaviour. However, we’re now duplicating a large chunk of > code: can the old function be implemented such that it calls the new > function and adapts the return values? This has hovered in the patch queue for that reason. I also love the idea of it, it just doesn't feel quite ready. I've been hoping we could convert the existing users and be able to drop the old function but I'm not managed to see how much work is left for that. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180907): https://lists.openembedded.org/g/openembedded-core/message/180907 Mute This Topic: https://lists.openembedded.org/mt/98199478/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 1/2] oeqa/utils/qemurunner: change the serial runner
> On 5 May 2023, at 11:31, Ross Burton wrote: > > On 11 Apr 2023, at 16:05, Louis Rannou via lists.openembedded.org > wrote: >> Create a new runner run_serial_socket which usage matches the traditional ssh >> runner. Its return status is 0 when the command succeeded or 0 when it >> failed. If an error is encountered, it raises an Exception. >> >> The previous serial runner is maintained and marked as deprecated. > > I absolutely love this because the existing run_serial has the most confusing > behaviour. However, we’re now duplicating a large chunk of code: can the old > function be implemented such that it calls the new function and adapts the > return values? Also, for bonus points, make the old function actual spit out a DeprecationWarning with warnings.warn. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180906): https://lists.openembedded.org/g/openembedded-core/message/180906 Mute This Topic: https://lists.openembedded.org/mt/98199478/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 1/2] oeqa/utils/qemurunner: change the serial runner
On 11 Apr 2023, at 16:05, Louis Rannou via lists.openembedded.org wrote: > Create a new runner run_serial_socket which usage matches the traditional ssh > runner. Its return status is 0 when the command succeeded or 0 when it > failed. If an error is encountered, it raises an Exception. > > The previous serial runner is maintained and marked as deprecated. I absolutely love this because the existing run_serial has the most confusing behaviour. However, we’re now duplicating a large chunk of code: can the old function be implemented such that it calls the new function and adapts the return values? Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180905): https://lists.openembedded.org/g/openembedded-core/message/180905 Mute This Topic: https://lists.openembedded.org/mt/98199478/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] make-mod-scripts: preserve libraries when rm_work is used
Hi Bruce,
Jose Quaresma via lists.openembedded.org escreveu no dia quarta, 3/05/2023 à(s)
11:09:
>
>
> Bruce Ashfield escreveu no dia terça,
> 2/05/2023 à(s) 22:12:
>
>> Attached is v2 of the patch. I've consolidated the suggested changes.
>>
>> I'm soaking it a bit longer, and then will send it as part of my next
>> consolidated pull request.
>>
>
> I will do some more tests with the v2 and post my comment later if
> anything new comes up.
>
Nothing new and the v2 patch works pretty well in my kernels.
Jose
>
> Jose
>
>
>>
>> Bruce
>>
>> On Thu, Apr 27, 2023 at 9:26 PM Bruce Ashfield via
>> lists.openembedded.org
>> wrote:
>> >
>> > On Thu, Apr 27, 2023 at 6:32 PM Jose Quaresma
>> wrote:
>> > >
>> > > Hi Bruce,
>> > >
>> > > I have been testing your patch and have some comments.
>> > > In some of my kernels I don't have the pkg-config changes and so I
>> have some fails linking the scripts/sign-file
>> > > because for static linking with the libcrypto we need the -ldl
>> -pthread.
>> > >
>> > > To fix my build I need to override the CRYPTO_LIBS in my kernel
>> because they use the hardcoded pkg-config
>> > > where it is not possible to pass the --static argument.
>> > >
>> > > With following change on top of your patch I can build moist of my
>> kernels:
>> > >
>> > > export HOSTLDFLAGS="-lz"
>> > >
>> > > + HOSTPKG_CONFIG="pkg-config --static"
>> > > + # override CRYPTO_LIBS since HOSTPKG_CONFIG lands only in
>> v5.19-rc1
>> > > + #
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d5ea4fece4508bf8e72b659cd22fa4840d8d61e5
>> > > + CRYPTO_LIBS="$(pkg-config --static --libs libcrypto
>> 2>/dev/null || echo -lcrypto)"
>> > > +
>> > > unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>> > > for t in prepare scripts_basic scripts; do
>> > > oe_runmake CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>> > > AR="${KERNEL_AR}" OBJCOPY="${KERNEL_OBJCOPY}" \
>> > > - HOSTPKG_CONFIG="pkg-config --static" \
>> > > + HOSTPKG_CONFIG="${HOSTPKG_CONFIG}"
>> CRYPTO_LIBS="${CRYPTO_LIBS}" \
>> > > -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR}
>> $t
>> > > done
>> > >
>> > >
>> > > I think belive that the LIBELF_LIBS needs the same fix for the cases
>> where HOSTPKG_CONFIG is not available.
>> > > Also I think there is a typo in the LIBELF_LIBS because you first
>> populate it with pkg-config but on the export the variable is redefined
>> > > with the HOST_LIBELF_LIBS. I made a litle change too on that:
>> > >
>> > > # for pre-5.15 kernels
>> > > - LIBELF_LIBS=$(pkg-config libelf --libs 2>/dev/null || echo
>> -lelf)
>> > > - export LIBELF_LIBS="$HOST_LIBELF_LIBS -lz"
>> > > + LIBELF_LIBS=$(pkg-config --static libelf --libs 2>/dev/null
>> || echo -lelf)
>> > > + export LIBELF_LIBS="$LIBELF_LIBS -lz"
>> > > export HOSTLDFLAGS="-lz"
>> > >
>> > > Thanks for you help.
>> >
>> > Those are definitely plausible tweaks to the patch, I was providing
>> > the two techniques for that reason, and you've used them
>> > appropriately.
>> >
>> > Let me roll your changes into my patch, re-test and I'll submit it to
>> > the mailing list as a v2.
>> >
>> > Thanks for the testing, and fixup, I knew there would be things
>> missing! :)
>> >
>> > Bruce
>> >
>> > >
>> > > Jose
>> > >
>> > > Bruce Ashfield escreveu no dia segunda,
>> 24/04/2023 à(s) 20:25:
>> > >>
>> > >> On Mon, Apr 24, 2023 at 6:30 AM Jose Quaresma <
>> quaresma.j...@gmail.com> wrote:
>> > >> >
>> > >> >
>> > >> >
>> > >> > Bruce Ashfield escreveu no dia
>> domingo, 23/04/2023 à(s) 20:55:
>> > >> >>
>> > >> >> On Sat, Apr 22, 2023 at 9:06 AM Christoph Lauer
>> > >> >> wrote:
>> > >> >> >
>> > >> >> > Am 21.04.23 um 22:28 schrieb Bruce Ashfield:
>> > >> >> > > On Wed, Apr 19, 2023 at 11:03 PM Bruce Ashfield via
>> > >> >> > > lists.openembedded.org
>> > >> >> > > wrote:
>> > >> >> > >>
>> > >> >> > >> On Wed, Apr 19, 2023 at 6:54 PM Richard Purdie
>> > >> >> > >> wrote:
>> > >> >> > >>>
>> > >> >> > >>> On Wed, 2023-04-19 at 23:34 +0100, Jose Quaresma wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > Not related with the previous discussion but just for
>> > >> >> > your information.
>> > >> >> > The rm_work.bbclass has an exception for the kernel
>> recipes [1].
>> > >> >> > So I don't understand why we can't do the same for the
>> make-mod-
>> > >> >> > scripts
>> > >> >> > who is the twin brother of all these kernel recipes.
>> > >> >> >
>> > >> >> > [1]
>> > >> >> >
>> https://git.openembedded.org/openembedded-core/tree/meta/classes/rm_work.bbclass#n168
>> > >> >> > >>>
>> > >> >> > >>> Ideally we wouldn't be doing this for the kernel recipes.
>> > >> >> > >>>
>> > >> >> > >>> There is also a big difference to that and the proposed
>> patch. The
>> > >> >> > >>> proposed patch was preserving a specific directory rather
Re: [OE-core] Yocto Project Community Manager updates
Thank you for the work over the years Nico; it takes a lot of organizational effort for things to simply 'go right', and that effort isn't particularly visible most of the time, which only makes it more valuable from my POV. Alex On Thu, 4 May 2023 at 16:40, Nicolas Dechesne wrote: > > Dear all, > > After five years, I have decided to resign from my position as the Yocto > Project Community Manager. I joined the OpenEmbedded community around 2008. I > have fond memories of my early days, and still remember some of my first > interactions on IRC and mailing lists! This is a very welcoming community, > always helping new people with patience and kindness. Serving the project > during the last five years is something I am very proud of, and I will be > forever grateful to all of you for accepting me! > > During these years, we have gone through a lot together, the pandemic gave us > an opportunity to rethink how our community should come together. Setting up > our Virtual Summits has been a lot of work (and stress!) for a group of few > people, but the never ending success of these events has been very rewarding! > Our online presence in social media has dramatically improved, and allows us > to reach out to and interact with our community faster than ever before! > > On the side of all the technical changes, and releases, we have also > established the Yocto LTS process which was a recurring request from the > community and has become a strength of the project! We also revamped the > project documentation to make it easier to maintain and contribute. The Yocto > Project documentation is such a great resource for our community! I have > spent so many hours on these PDFs in my early days! > > Anyway, let’s not focus on the past! The future looks bright and I am really > excited to announce that Josef Holzmayr has accepted to take over the > Community Manager role. Josef needs no introduction, he has been a key member > of this community for so many years. Thanks to Josef's relentless efforts, we > have grown our social media presence on Youtube, Twitter, LinkedIn and > Mastodon! His energy will be a great source of inspiration for this > community! I wish Josef and Yocto the best for the years to come, and I am > convinced this community is in good hands and that Josef will be a great > community leader! > > Many thanks! > Nico > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180903): https://lists.openembedded.org/g/openembedded-core/message/180903 Mute This Topic: https://lists.openembedded.org/mt/98685136/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [kirkstone][PATCH] webkitgtk: fix CVE-2022-32888 & CVE-2022-32923
From: Kai Kang
Backport patches to fix CVE-2022-32888 and CVE-2022-32923 for webkitgtk
2.36.8. The bugzilla IDs of the CVEs are from https://support.apple.com
which have been listed in patch headers.
Signed-off-by: Kai Kang
---
.../webkit/webkitgtk/CVE-2022-32888.patch | 41 ++
.../webkit/webkitgtk/CVE-2022-32923.patch | 435 ++
meta/recipes-sato/webkit/webkitgtk_2.36.8.bb | 2 +
3 files changed, 478 insertions(+)
create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-32888.patch
create mode 100644 meta/recipes-sato/webkit/webkitgtk/CVE-2022-32923.patch
diff --git a/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32888.patch
b/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32888.patch
new file mode 100644
index 00..1a6b685450
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32888.patch
@@ -0,0 +1,41 @@
+CVE: CVE-2022-32888
+Upstream-Status: Backport [https://github.com/WebKit/WebKit/commit/a3dd7dc]
+
+[1]: https://support.apple.com/en-us/HT213446
+[2]: https://bugs.webkit.org/show_bug.cgi?id=242047
+
+Signed-off-by: Kai Kang
+
+From a3dd7dc5f60b87a7cfd14c372e40ebd339076763 Mon Sep 17 00:00:00 2001
+From: Yusuke Suzuki
+Date: Mon, 27 Jun 2022 21:34:55 -0700
+Subject: [PATCH] [JSC] Drop wasm stale assertion
+ https://bugs.webkit.org/show_bug.cgi?id=242047 rdar://95866655
+
+Reviewed by Mark Lam.
+
+This patch drops stale assertion in addDelegateToUnreachable.
+
+* Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp:
+(JSC::Wasm::LLIntGenerator::addDelegateToUnreachable):
+
+Canonical link: https://commits.webkit.org/251902@main
+---
+ Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
b/Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
+index 39fb39b3331f..d0d2b9725991 100644
+--- a/Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
b/Source/JavaScriptCore/wasm/WasmLLIntGenerator.cpp
+@@ -1182,7 +1182,6 @@ auto
LLIntGenerator::addDelegateToUnreachable(ControlType& target, ControlType&
+
+ ControlTry& tryData = std::get(data);
+ m_codeBlock->addExceptionHandler({ HandlerType::Delegate,
tryData.m_try->location(), delegateLabel->location(), 0, m_tryDepth,
targetDepth });
+-checkConsistency();
+ return { };
+ }
+
+--
+2.34.1
+
diff --git a/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32923.patch
b/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32923.patch
new file mode 100644
index 00..60342a14f8
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk/CVE-2022-32923.patch
@@ -0,0 +1,435 @@
+CVE: CVE-2022-32923
+Upstream-Status: Backport [https://github.com/WebKit/WebKit/commit/ef76e31]
+
+[1]: https://support.apple.com/en-us/HT213495
+[2]: https://bugs.webkit.org/show_bug.cgi?id=242964
+
+Signed-off-by: Kai Kang
+
+From ef76e31a2a066c3d65a9c94a9e2cd88133260c1f Mon Sep 17 00:00:00 2001
+From: Yusuke Suzuki
+Date: Wed, 20 Jul 2022 19:30:48 -0700
+Subject: [PATCH] [JSC] BakcwardPropagationPhase should carry NaN / Infinity
+ handling https://bugs.webkit.org/show_bug.cgi?id=242964 rdar://96791603
+
+Reviewed by Mark Lam.
+
+For correctness, we should carry NaN / Infinity handling to make it more clear
in the code generation site.
+
+* Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp:
+(JSC::DFG::BackwardsPropagationPhase::propagate):
+* Source/JavaScriptCore/dfg/DFGFixupPhase.cpp:
+(JSC::DFG::FixupPhase::fixupArithDivInt32):
+(JSC::DFG::FixupPhase::fixupArithDiv):
+* Source/JavaScriptCore/dfg/DFGGraph.h:
+* Source/JavaScriptCore/dfg/DFGNode.h:
+* Source/JavaScriptCore/dfg/DFGNodeFlags.cpp:
+(JSC::DFG::dumpNodeFlags):
+* Source/JavaScriptCore/dfg/DFGNodeFlags.h:
+(JSC::DFG::bytecodeCanIgnoreNaNAndInfinity):
+(JSC::DFG::nodeCanSpeculateInt32ForDiv):
+* Source/JavaScriptCore/dfg/DFGNodeType.h:
+
+Canonical link: https://commits.webkit.org/252675@main
+---
+ .../dfg/DFGBackwardsPropagationPhase.cpp | 51 +++
+ Source/JavaScriptCore/dfg/DFGFixupPhase.cpp | 6 ++-
+ Source/JavaScriptCore/dfg/DFGGraph.h | 11
+ Source/JavaScriptCore/dfg/DFGNode.h | 12 +++--
+ Source/JavaScriptCore/dfg/DFGNodeFlags.cpp| 10 ++--
+ Source/JavaScriptCore/dfg/DFGNodeFlags.h | 37 +++---
+ Source/JavaScriptCore/dfg/DFGNodeType.h | 3 +-
+ 7 files changed, 91 insertions(+), 39 deletions(-)
+
+diff --git a/Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
b/Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
+index 306ea5d6b974..83a08aff7c20 100644
+--- a/Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
b/Source/JavaScriptCore/dfg/DFGBackwardsPropagationPhase.cpp
+@@ -272,7 +272,7 @@ private:
+ case ValueBitNot:
+ case ArithBitNot: {
+ flags |= NodeBytecodeUsesAsInt;
+-flags &= ~(NodeBytecodeUsesAsNumber | NodeBytecodeNeedsNegZero |
NodeBytecodeUsesAsOther);
++flags &=
