Re: [OE-core] [PATCH] tcf-agent: cleanup patches

2021-12-06 Thread Khem Raj
On Mon, Dec 6, 2021 at 4:47 AM Ross Burton  wrote:
>
> ldflags.patch isn't really suitable for upstream, so mark inappropriate.
>
> fix_ranlib.patch has been rebased into uselessness over time, it's now
> setting RANLIB to just '$@' which expands to '' when called, so is a
> null operation.

this works with gcc-ranlib wrapper only which expands $@ shell array,
but it will fail if RANLIB was set to -ranlib or
-llvn-ranlib has same behaviour
so IMO  this patch should be kept for portability reasons.

>
> Signed-off-by: Ross Burton 
> ---
>  .../tcf-agent/tcf-agent/fix_ranlib.patch| 17 -
>  .../tcf-agent/tcf-agent/ldflags.patch   |  6 +-
>  .../recipes-devtools/tcf-agent/tcf-agent_git.bb |  1 -
>  3 files changed, 5 insertions(+), 19 deletions(-)
>  delete mode 100644 meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
>
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch 
> b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
> deleted file mode 100644
> index abd33babeb..00
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -Actually pass the arguments to RANLIB.
> -
> -Upstream-Status: Pending
> -Signed-off-by: Ross Burton 
> -
> -Index: agent/Makefile.inc
> -===
>  a/Makefile.inc
> -+++ b/Makefile.inc
> -@@ -92,6 +92,7 @@ ifeq ($(OPSYS),GNU/Linux)
> - OPTS += -DUSE_uuid_generate=0
> -   endif
> -   OPTS += -DENABLE_arch_$(shell uname -m)
> -+  RANLIB += $@
> - endif
> -
> - ifneq ($(OPSYS),Windows)
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch 
> b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> index c03c55d22b..dfe492091c 100644
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> +++ b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> @@ -1,4 +1,8 @@
> -Upstream-Status: Pending
> +We need LDFLAGS to be respected otherwise there are QA warnings as the right
> +flags don't get used.
> +
> +Upstream-Status: Inappropriate
> +Signed-off-by: Ross Burton 
>
>  From d92af0483c20365fd0af740d0baef8870b4aa374 Mon Sep 17 00:00:00 2001
>  From: Abdur Rehman 
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
> b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> index d6d563d8e7..0d627f4e23 100644
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> +++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> @@ -11,7 +11,6 @@ PV = "1.7.0+git${SRCPV}"
>
>  UPSTREAM_CHECK_GITTAGREGEX = "(?P(\d+(\.\d+)+))"
>  SRC_URI = 
> "git://git.eclipse.org/r/tcf/org.eclipse.tcf.agent.git;protocol=https;branch=master
>  \
> -   file://fix_ranlib.patch \
> file://ldflags.patch \
> file://tcf-agent.init \
> file://tcf-agent.service \
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159282): 
https://lists.openembedded.org/g/openembedded-core/message/159282
Mute This Topic: https://lists.openembedded.org/mt/87538834/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] tcf-agent: cleanup patches

2021-12-06 Thread Khem Raj
On Mon, Dec 6, 2021 at 4:47 AM Ross Burton  wrote:
>
> ldflags.patch isn't really suitable for upstream, so mark inappropriate.
>
> fix_ranlib.patch has been rebased into uselessness over time, it's now
> setting RANLIB to just '$@' which expands to '' when called, so is a
> null operation.
>

not totally useless. This patch is still useful when using llvm-ar and
llvm-ranlib see
https://errors.yoctoproject.org/Errors/Details/618826/

> Signed-off-by: Ross Burton 
> ---
>  .../tcf-agent/tcf-agent/fix_ranlib.patch| 17 -
>  .../tcf-agent/tcf-agent/ldflags.patch   |  6 +-
>  .../recipes-devtools/tcf-agent/tcf-agent_git.bb |  1 -
>  3 files changed, 5 insertions(+), 19 deletions(-)
>  delete mode 100644 meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
>
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch 
> b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
> deleted file mode 100644
> index abd33babeb..00
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -Actually pass the arguments to RANLIB.
> -
> -Upstream-Status: Pending
> -Signed-off-by: Ross Burton 
> -
> -Index: agent/Makefile.inc
> -===
>  a/Makefile.inc
> -+++ b/Makefile.inc
> -@@ -92,6 +92,7 @@ ifeq ($(OPSYS),GNU/Linux)
> - OPTS += -DUSE_uuid_generate=0
> -   endif
> -   OPTS += -DENABLE_arch_$(shell uname -m)
> -+  RANLIB += $@
> - endif
> -
> - ifneq ($(OPSYS),Windows)
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch 
> b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> index c03c55d22b..dfe492091c 100644
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> +++ b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
> @@ -1,4 +1,8 @@
> -Upstream-Status: Pending
> +We need LDFLAGS to be respected otherwise there are QA warnings as the right
> +flags don't get used.
> +
> +Upstream-Status: Inappropriate
> +Signed-off-by: Ross Burton 
>
>  From d92af0483c20365fd0af740d0baef8870b4aa374 Mon Sep 17 00:00:00 2001
>  From: Abdur Rehman 
> diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
> b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> index d6d563d8e7..0d627f4e23 100644
> --- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> +++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
> @@ -11,7 +11,6 @@ PV = "1.7.0+git${SRCPV}"
>
>  UPSTREAM_CHECK_GITTAGREGEX = "(?P(\d+(\.\d+)+))"
>  SRC_URI = 
> "git://git.eclipse.org/r/tcf/org.eclipse.tcf.agent.git;protocol=https;branch=master
>  \
> -   file://fix_ranlib.patch \
> file://ldflags.patch \
> file://tcf-agent.init \
> file://tcf-agent.service \
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159281): 
https://lists.openembedded.org/g/openembedded-core/message/159281
Mute This Topic: https://lists.openembedded.org/mt/87538834/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/2] glibc: Drop fsqrt implementation patches for fsl ppc

2021-12-06 Thread Khem Raj
On Mon, Dec 6, 2021 at 3:32 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2021-12-06 at 15:28 -0800, Khem Raj wrote:
> >
> >
> > On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie
> >  wrote:
> > > I did test such a patch today as well since we discussed it. I'd
> propose
> > > this
> > > commit message since we need to say why:
> > >
> > > """
> > >
> > > glibc: Drop ppc sqrt optimisations
> > >
> > > OpenEmbedded isn't an upstream or a patch repository. These are
> > > optimisations
> > > which for reasons unknown were never merged into upstream glibc. We
> have no
> > > active ppc maintainers and these patches are at an evolutionary dead
> end.
> > > Since they are optimisations, there may be small performance
> regressions by
> > > removing them but OE can't carry patches like this indefinitely and
> these
> > > appear to have no future.
> > > """
> > >
> >
> >
> > This sounds good to me. I guess will add it to commit or do you want me
> to
> > send v2. This passed my local testing on qemuppc
> >
>
> I can sort if you're ok with it, thanks.


Sounds good


>
> Cheers,
>
> Richard
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159280): 
https://lists.openembedded.org/g/openembedded-core/message/159280
Mute This Topic: https://lists.openembedded.org/mt/87552244/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] Help with Inclusive Language in OpenEmbedded/Yocto Project

2021-12-06 Thread Jon Mason
This email is a follow-up from the session held on Friday at the
OpenEmbedded Developer's Virtual Meeting (see
https://www.openembedded.org/wiki/OEDVM_Nov_2021)

The session was not recorded, but the slides can be found at
https://docs.google.com/presentation/d/146ueVVTMeA8JI43wqv5kFmdYEygqqmfGH0z1VRL2bDA/edit?usp=sharing

The outcome from the discussion was that inclusive language changes
are something that we want to accomplish in the kirkstone release
timeframe (with an exception for the "master" branch name, which will
be handled at a future date).

There has already been a pass at collecting the needed changes at
https://wiki.yoctoproject.org/wiki/Inclusive_language

This is not as simple as a find/replace of offending words.  There is
a desire for backward compatibility or to provide some kind of "you
want X, which is now Y" (which complicates things).

The intention of this email is to see who is interested in helping
out.  Once we know how many people are available and what time frames,
we can plan out a roadmap.  So, please email me (or respond to this
thread publicly) and I'll add you to the list.  There will then be a
follow-up zoom call in the next week or so to plan out the roadmap.

We will document the roadmap and everything else on the YP wiki page above.

Questions and comments are welcome, but not interested in debating the
necessity or timeframe of this task.  It has already been decided.

Thanks,
Jon

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159279): 
https://lists.openembedded.org/g/openembedded-core/message/159279
Mute This Topic: https://lists.openembedded.org/mt/87555754/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/2] glibc: Drop fsqrt implementation patches for fsl ppc

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 15:28 -0800, Khem Raj wrote:
> 
> 
> On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie
>  wrote:
> > I did test such a patch today as well since we discussed it. I'd propose
> > this
> > commit message since we need to say why:
> > 
> > """
> > 
> > glibc: Drop ppc sqrt optimisations
> > 
> > OpenEmbedded isn't an upstream or a patch repository. These are
> > optimisations
> > which for reasons unknown were never merged into upstream glibc. We have no
> > active ppc maintainers and these patches are at an evolutionary dead end.
> > Since they are optimisations, there may be small performance regressions by
> > removing them but OE can't carry patches like this indefinitely and these
> > appear to have no future.
> > """
> > 
> 
> 
> This sounds good to me. I guess will add it to commit or do you want me to
> send v2. This passed my local testing on qemuppc 
> 

I can sort if you're ok with it, thanks.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159278): 
https://lists.openembedded.org/g/openembedded-core/message/159278
Mute This Topic: https://lists.openembedded.org/mt/87552244/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 4/4] core: udev: udev-extraconf: rename mount.blacklist* to mount.blocklist.*

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote:
> blocklist has a more obvious meaning than blacklist and is also not an
> issue wrt inclusivity, so let's use that naming instead.

A "blocklist" with a filesystem is unfortunately confusing (a list of block
numbers on the filesystem?). "ignorelist" or even "ignore-devices" may be
better? (or skip)

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159277): 
https://lists.openembedded.org/g/openembedded-core/message/159277
Mute This Topic: https://lists.openembedded.org/mt/87542276/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/2] glibc: Drop fsqrt implementation patches for fsl ppc

2021-12-06 Thread Khem Raj
On Mon, Dec 6, 2021 at 2:51 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> I did test such a patch today as well since we discussed it. I'd propose
> this
> commit message since we need to say why:
>
> """
>
> glibc: Drop ppc sqrt optimisations
>
> OpenEmbedded isn't an upstream or a patch repository. These are
> optimisations
> which for reasons unknown were never merged into upstream glibc. We have no
> active ppc maintainers and these patches are at an evolutionary dead end.
> Since they are optimisations, there may be small performance regressions by
> removing them but OE can't carry patches like this indefinitely and these
> appear to have no future.
> """


This sounds good to me. I guess will add it to commit or do you want me to
send v2. This passed my local testing on qemuppc

>
>
> Cheers,
>
> Richard
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159276): 
https://lists.openembedded.org/g/openembedded-core/message/159276
Mute This Topic: https://lists.openembedded.org/mt/87552244/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] opkg: upgrade 0.4.5 -> 0.5.0

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 13:13 -0600, Alex Stewart wrote:
> You beat me to posting my own recipe upgrade commit. :)
> 
> Toward the bottom of the opkg_*.bb recipe file is a 
> `package_qa_check_openssl_deprecation` function which I added in the 
> 0.4.5 release to warn BB users when they are building opkg with the 
> openssl options. Could you amend your patchset to remove that function 
> in its entirety, since it is no longer needed.

I added in that tweak since I wanted to get things queued for testing.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159275): 
https://lists.openembedded.org/g/openembedded-core/message/159275
Mute This Topic: https://lists.openembedded.org/mt/87541521/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] glibc: Drop patch for obsolete conflict issue

2021-12-06 Thread Richard Purdie
We're no longer patching files called "libm-test-ulps" so this patch isn't
really needed. Regardless, if we were, we should fix the real issue in the
upstream code which may have already happened. Drop this patch.

Signed-off-by: Richard Purdie 
---
 ...m-err-tab.pl-with-specific-dirs-in-S.patch | 33 ---
 meta/recipes-core/glibc/glibc_2.34.bb |  1 -
 2 files changed, 34 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
 
b/meta/recipes-core/glibc/glibc/0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
deleted file mode 100644
index 474cea5a0de..000
--- 
a/meta/recipes-core/glibc/glibc/0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From c5047b8f7d1a17324cfa02b99f07a70ebcec2cf2 Mon Sep 17 00:00:00 2001
-From: Ting Liu 
-Date: Wed, 19 Dec 2012 04:39:57 -0600
-Subject: [PATCH] eglibc: run libm-err-tab.pl with specific dirs in ${S}
-
-libm-err-tab.pl will parse all the files named "libm-test-ulps"
-in the given dir recursively. To avoid parsing the one in
-${S}/.pc/ (it does exist after eglibc adds aarch64 support,
-${S}/.pc/aarch64-0001-glibc-fsf-v1-eaf6f205.patch/ports/sysdeps/
-aarch64/libm-test-ulps), run libm-err-tab.pl with specific dirs
-in ${S}.
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Ting Liu 

- manual/Makefile | 3 ++-
- 1 file changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/manual/Makefile b/manual/Makefile
-index e83444341e..aa2645bc55 100644
 a/manual/Makefile
-+++ b/manual/Makefile
-@@ -103,7 +103,8 @@ $(objpfx)stamp-libm-err: $(..)math/gen-libm-test.py \
-$(wildcard $(foreach dir,$(sysdirs),\
- $(dir)/libm-test-ulps))
-   pwd=`pwd`; \
--  $(PYTHON) $< -s $$pwd/.. -m $(objpfx)libm-err-tmp
-+  $(PYTHON) $< -s $$pwd/../ports -m $(objpfx)libm-err-tmp
-+  $(PYTHON) $< -s $$pwd/../sysdeps -m $(objpfx)libm-err-tmp
-   $(move-if-change) $(objpfx)libm-err-tmp $(objpfx)libm-err.texi
-   touch $@
- 
diff --git a/meta/recipes-core/glibc/glibc_2.34.bb 
b/meta/recipes-core/glibc/glibc_2.34.bb
index 2f3065484d1..cdce2c4112c 100644
--- a/meta/recipes-core/glibc/glibc_2.34.bb
+++ b/meta/recipes-core/glibc/glibc_2.34.bb
@@ -34,7 +34,6 @@ SRC_URI =  "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://makedbs.sh \
\
${NATIVESDKFIXES} \
-   
file://0013-eglibc-run-libm-err-tab.pl-with-specific-dirs-in-S.patch \

file://0015-sysdeps-gnu-configure.ac-handle-correctly-libc_cv_ro.patch \
file://0016-yes-within-the-path-sets-wrong-config-variables.patch \
file://0017-timezone-re-written-tzselect-as-posix-sh.patch \
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159274): 
https://lists.openembedded.org/g/openembedded-core/message/159274
Mute This Topic: https://lists.openembedded.org/mt/87553806/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 0/4] blacklist/blocklist and master/golden

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote:
> Hi all,
> 
> It seems some changes are not too invasive and can be made to be a bit
> more inclusive, so I'll make the autobuilder try those patches and tell
> me whether I broke something somewhere I wasn't aware of.
> 
> In other words: I did not test those changes.
> 
> Those changes warrant some notes in the migration guide once they
> are merged.
> 
> Cheers,
> Quentin
> 
> Quentin Schulz (4):
>   rename core-image-testmaster* to core-image-testgolden
>   core: initrdscripts: init-install{-efi,}-testfs.sh: rename masterimage
> into goldenimage
>   oeqa: rename masterimage into goldenimage
>   core: udev: udev-extraconf: rename mount.blacklist* to
> mount.blocklist.*

I'm sitting wondering what core-image-testmaster actually is. I don't remember
anything being done with this for a long time so it may be a good candidate for
deletion. I should check with QA but...

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159273): 
https://lists.openembedded.org/g/openembedded-core/message/159273
Mute This Topic: https://lists.openembedded.org/mt/87542271/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/2] glibc: Drop fsqrt implementation patches for fsl ppc

2021-12-06 Thread Richard Purdie
I did test such a patch today as well since we discussed it. I'd propose this
commit message since we need to say why:

"""

glibc: Drop ppc sqrt optimisations

OpenEmbedded isn't an upstream or a patch repository. These are optimisations
which for reasons unknown were never merged into upstream glibc. We have no
active ppc maintainers and these patches are at an evolutionary dead end.
Since they are optimisations, there may be small performance regressions by
removing them but OE can't carry patches like this indefinitely and these
appear to have no future.
"""

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159272): 
https://lists.openembedded.org/g/openembedded-core/message/159272
Mute This Topic: https://lists.openembedded.org/mt/87552244/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/2] glibc: Drop fsqrt implementation patches for fsl ppc

2021-12-06 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...5500-e6500-603e-fsqrt-implementation.patch | 1581 -
 ...undefined-reference-to-__sqrt_finite.patch |  205 ---
 ...-are-now-inline-functions-and-call-o.patch |  384 
 ...-are-now-inline-functions-and-call-o.patch |   58 -
 meta/recipes-core/glibc/glibc_2.34.bb |4 -
 5 files changed, 2232 deletions(-)
 delete mode 100644 
meta/recipes-core/glibc/glibc/0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch
 delete mode 100644 
meta/recipes-core/glibc/glibc/0010-ppc-sqrt-Fix-undefined-reference-to-__sqrt_finite.patch
 delete mode 100644 
meta/recipes-core/glibc/glibc/0011-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch
 delete mode 100644 
meta/recipes-core/glibc/glibc/0014-__ieee754_sqrt-f-are-now-inline-functions-and-call-o.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch
 
b/meta/recipes-core/glibc/glibc/0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch
deleted file mode 100644
index 01de227a023..000
--- 
a/meta/recipes-core/glibc/glibc/0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch
+++ /dev/null
@@ -1,1581 +0,0 @@
-From 74923ca4b1ae0ed5a2478e7d265b37534f6815d7 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 18 Mar 2015 00:01:50 +
-Subject: [PATCH] fsl e500/e5500/e6500/603e fsqrt implementation
-
-Upstream-Status: Pending
-Signed-off-by: Edmar Wienskoski 
-Signed-off-by: Khem Raj 

- sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c   | 134 ++
- sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c  | 101 +
- sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c | 134 ++
- .../powerpc/powerpc32/e500mc/fpu/e_sqrtf.c| 101 +
- sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrt.c  | 134 ++
- sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrtf.c | 101 +
- sysdeps/powerpc/powerpc32/e6500/fpu/e_sqrt.c  | 134 ++
- sysdeps/powerpc/powerpc32/e6500/fpu/e_sqrtf.c | 101 +
- sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c  | 134 ++
- sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c | 101 +
- sysdeps/powerpc/powerpc64/e6500/fpu/e_sqrt.c  | 134 ++
- sysdeps/powerpc/powerpc64/e6500/fpu/e_sqrtf.c | 101 +
- .../linux/powerpc/powerpc32/603e/fpu/Implies  |   1 +
- .../powerpc/powerpc32/e300c3/fpu/Implies  |   2 +
- .../powerpc/powerpc32/e500mc/fpu/Implies  |   1 +
- .../linux/powerpc/powerpc32/e5500/fpu/Implies |   1 +
- .../linux/powerpc/powerpc32/e6500/fpu/Implies |   1 +
- .../linux/powerpc/powerpc64/e5500/fpu/Implies |   1 +
- .../linux/powerpc/powerpc64/e6500/fpu/Implies |   1 +
- 19 files changed, 1418 insertions(+)
- create mode 100644 sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc32/603e/fpu/e_sqrtf.c
- create mode 100644 sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc32/e500mc/fpu/e_sqrtf.c
- create mode 100644 sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc32/e5500/fpu/e_sqrtf.c
- create mode 100644 sysdeps/powerpc/powerpc32/e6500/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc32/e6500/fpu/e_sqrtf.c
- create mode 100644 sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc64/e5500/fpu/e_sqrtf.c
- create mode 100644 sysdeps/powerpc/powerpc64/e6500/fpu/e_sqrt.c
- create mode 100644 sysdeps/powerpc/powerpc64/e6500/fpu/e_sqrtf.c
- create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc32/603e/fpu/Implies
- create mode 100644 
sysdeps/unix/sysv/linux/powerpc/powerpc32/e300c3/fpu/Implies
- create mode 100644 
sysdeps/unix/sysv/linux/powerpc/powerpc32/e500mc/fpu/Implies
- create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc32/e5500/fpu/Implies
- create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc32/e6500/fpu/Implies
- create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/e5500/fpu/Implies
- create mode 100644 sysdeps/unix/sysv/linux/powerpc/powerpc64/e6500/fpu/Implies
-
-diff --git a/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c 
b/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
-new file mode 100644
-index 00..71e516d1c8
 /dev/null
-+++ b/sysdeps/powerpc/powerpc32/603e/fpu/e_sqrt.c
-@@ -0,0 +1,134 @@
-+/* Double-precision floating point square root.
-+   Copyright (C) 2010 Free Software Foundation, Inc.
-+   This file is part of the GNU C Library.
-+
-+   The GNU C Library is free software; you can redistribute it and/or
-+   modify it under the terms of the GNU Lesser General Public
-+   License as published by the Free Software Foundation; either
-+   version 2.1 of the License, or (at your option) any later version.
-+
-+   The GNU C Library is distributed in the hope that it will be useful,
-+   but WITHOUT ANY WARRANTY; without even the implied warranty of
-+   MERCHANTABILITY or FITNESS FOR A PARTICULAR 

[OE-core] [PATCH 2/2] ffmpeg: Fix build on ppc32

2021-12-06 Thread Khem Raj
Fixes
| powerpc-yoe-linux/11.2.0/ld: libavformat/libavformat.so: undefined reference 
to `__atomic_fetch_sub_8'

Signed-off-by: Khem Raj 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb
index 685214a751b..3ba07c31d6b 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_4.4.1.bb
@@ -131,6 +131,7 @@ EXTRA_OECONF:append:mips = " --extra-libs=-latomic 
--disable-mips32r5 --disable-
  --disable-loongson2 --disable-loongson3 
--disable-mmi --disable-msa --disable-msa2"
 EXTRA_OECONF:append:riscv32 = " --extra-libs=-latomic"
 EXTRA_OECONF:append:armv5 = " --extra-libs=-latomic"
+EXTRA_OECONF:append:powerpc = " --extra-libs=-latomic"
 
 # gold crashes on x86, another solution is to --disable-asm but thats more 
hacky
 # ld.gold: internal error in relocate_section, at ../../gold/i386.cc:3684
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159270): 
https://lists.openembedded.org/g/openembedded-core/message/159270
Mute This Topic: https://lists.openembedded.org/mt/87552243/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2021-12-06 Thread Stephen Jolley
All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 395
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.4", "3.5, "3.99" and "Future", the more pressing/urgent issues
being in "3.4" and then "3.5".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159269): 
https://lists.openembedded.org/g/openembedded-core/message/159269
Mute This Topic: https://lists.openembedded.org/mt/87551260/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] opkg-utils: upgrade 0.4.5 -> 0.5.0

2021-12-06 Thread Alex Stewart

Patch looks good to me! ACK all.

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159268): 
https://lists.openembedded.org/g/openembedded-core/message/159268
Mute This Topic: https://lists.openembedded.org/mt/87541534/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] opkg: upgrade 0.4.5 -> 0.5.0

2021-12-06 Thread Alex Stewart

You beat me to posting my own recipe upgrade commit. :)

Toward the bottom of the opkg_*.bb recipe file is a 
`package_qa_check_openssl_deprecation` function which I added in the 
0.4.5 release to warn BB users when they are building opkg with the 
openssl options. Could you amend your patchset to remove that function 
in its entirety, since it is no longer needed.


On 12/6/21 18:05, zhengruoqin wrote:

Remove unsupported openssl and option --disable-pathfinder

Signed-off-by: Zheng Ruoqin 
---
  meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)
  rename meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} (92%)

diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb 
b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
similarity index 92%
rename from meta/recipes-devtools/opkg/opkg_0.4.5.bb
rename to meta/recipes-devtools/opkg/opkg_0.5.0.bb
index 1fe6ed5ecb..bc2ee9728b 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
@@ -18,8 +18,7 @@ SRC_URI = 
"https://urldefense.com/v3/__http://downloads.yoctoproject.org/releases/$*7BBPN*7D/$*7BBPN*7D-$*7BPV*7D.tar.gz__;JSUlJSUl!!FbZ0ZwI3Qg!7tN48q7yAANgWzzpMBAysrcbhsbWEdwp0sXfb2Hl7bFTyNxbtdOuRQFN01Y06ns$
 file://run-ptest \
  "
  
-SRC_URI[md5sum] = "5dc41ad37d88803b5e0f456a9c5a0811"

-SRC_URI[sha256sum] = 
"a1214a75fa34fb9228db8da47308e0e711b1c93fd8938cf164c10fd28eb50f1e"
+SRC_URI[sha256sum] = 
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
  
  # This needs to be before ptest inherit, otherwise all ptest files end packaged

  # in libopkg package if OPKGLIBDIR == libdir, because default
@@ -39,11 +38,9 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
  "
  PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
  PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
-PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
  PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
  PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
  
-EXTRA_OECONF += " --disable-pathfinder"

  EXTRA_OECONF:class-native = 
"--localstatedir=/${@os.path.relpath('${localstatedir}', '${STAGING_DIR_NATIVE}')} 
--sysconfdir=/${@os.path.relpath('${sysconfdir}', '${STAGING_DIR_NATIVE}')}"
  
  do_install:append () {






--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159267): 
https://lists.openembedded.org/g/openembedded-core/message/159267
Mute This Topic: https://lists.openembedded.org/mt/87541521/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/2] repo: Use separate task for patching repo rev

2021-12-06 Thread Jasper Orschulko via lists.openembedded.org
From: Jasper Orschulko 

Using a task instead of a version specific patch for setting the repo
revision within the source code. This drastically decreases the
maintenance burden and easier usage of the OE update helper.

Signed-off-by: Jasper Orschulko 
---
 .../0001-Set-REPO_REV-to-v2.17.3.patch| 35 ---
 meta/recipes-devtools/repo/repo_2.17.3.bb |  9 +++--
 2 files changed, 7 insertions(+), 37 deletions(-)
 delete mode 100644 
meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch

diff --git 
a/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch 
b/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
deleted file mode 100644
index 60f1086b32..00
--- a/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From bdd2a528da59c28db8ae2986834926de7cebf3ab Mon Sep 17 00:00:00 2001
-From: Jasper Orschulko 
-Date: Thu, 4 Nov 2021 16:55:12 +0100
-Subject: [PATCH] Set REPO_REV to v2.17.3
-
-repo is an unusual tool because it downloads all of its own Python modules
-using GPG-signed git tags, and stores those files as part of the project
-that it is working with.
-
-So in order to have a reproducible repo installation within the project
-folders, we hardcode the default REPO_REV to a SHA1 that corresponds to
-the version of the recipe. REPO_REV can still be overwriten by the user,
-by specifying the REPO_REV environment variable.
-
-Upstream-Status: Inappropriate [configuration]
-Signed-off-by: Jasper Orschulko 

- repo | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/repo b/repo
-index 4cddbf1..5c3551f 100755
 a/repo
-+++ b/repo
-@@ -144,7 +144,7 @@ if not REPO_URL:
-   REPO_URL = 'https://gerrit.googlesource.com/git-repo'
- REPO_REV = os.environ.get('REPO_REV')
- if not REPO_REV:
--  REPO_REV = 'stable'
-+  REPO_REV = '11b30b91df1f0e03b53da970ec2588e85817bacc'
- # URL to file bug reports for repo tool issues.
- BUG_URL = 
'https://bugs.chromium.org/p/gerrit/issues/entry?template=Repo+tool+issue'
- 
--- 
-2.34.0
diff --git a/meta/recipes-devtools/repo/repo_2.17.3.bb 
b/meta/recipes-devtools/repo/repo_2.17.3.bb
index f7bbb22964..aeaec13dd7 100644
--- a/meta/recipes-devtools/repo/repo_2.17.3.bb
+++ b/meta/recipes-devtools/repo/repo_2.17.3.bb
@@ -12,13 +12,18 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
 SRC_URI = 
"git://gerrit.googlesource.com/git-repo.git;protocol=https;branch=main"
 SRCREV = "11b30b91df1f0e03b53da970ec2588e85817bacc"
 
-SRC_URI += "file://0001-python3-shebang.patch \
-file://0001-Set-REPO_REV-to-v2.17.3.patch"
+SRC_URI += "file://0001-python3-shebang.patch"
 
 MIRRORS += "git://gerrit.googlesource.com/git-repo.git 
git://github.com/GerritCodeReview/git-repo.git"
 
 S = "${WORKDIR}/git"
 
+do_set_fixed_rev() {
+sed -Ei "s/REPO_REV\s*=\s*('|\")stable('|\")/REPO_REV = '${SRCREV}'/g" 
${S}/repo
+}
+
+do_patch[postfuncs] += "do_set_fixed_rev"
+
 do_install() {
install -D ${WORKDIR}/git/repo ${D}${bindir}/repo
 }
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159266): 
https://lists.openembedded.org/g/openembedded-core/message/159266
Mute This Topic: https://lists.openembedded.org/mt/87546668/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/2] repo: upgrade 2.17.3 -> 2.18

2021-12-06 Thread Jasper Orschulko via lists.openembedded.org
From: Jasper Orschulko 

Signed-off-by: Jasper Orschulko 
---
 meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} (95%)

diff --git a/meta/recipes-devtools/repo/repo_2.17.3.bb 
b/meta/recipes-devtools/repo/repo_2.18.bb
similarity index 95%
rename from meta/recipes-devtools/repo/repo_2.17.3.bb
rename to meta/recipes-devtools/repo/repo_2.18.bb
index aeaec13dd7..bf5e8d0429 100644
--- a/meta/recipes-devtools/repo/repo_2.17.3.bb
+++ b/meta/recipes-devtools/repo/repo_2.18.bb
@@ -10,7 +10,7 @@ LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57"
 
 SRC_URI = 
"git://gerrit.googlesource.com/git-repo.git;protocol=https;branch=main"
-SRCREV = "11b30b91df1f0e03b53da970ec2588e85817bacc"
+SRCREV = "4a478edb443864561089b2699c9e65c85fc5e036"
 
 SRC_URI += "file://0001-python3-shebang.patch"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159265): 
https://lists.openembedded.org/g/openembedded-core/message/159265
Mute This Topic: https://lists.openembedded.org/mt/87546667/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 v2 2/2] vim: set PACKAGECONFIG idiomatically

2021-12-06 Thread Andre McCurdy
On Fri, Dec 3, 2021 at 10:07 AM Andre McCurdy  wrote:
>
> On Fri, Dec 3, 2021 at 2:06 AM Richard Purdie
>  wrote:
> >
> > On Fri, 2021-12-03 at 01:39 -0800, Andre McCurdy wrote:
> > > On Wed, Dec 1, 2021 at 2:33 PM Richard Purdie
> > >  wrote:
> > > >
> > > > On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote:
> > > > > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton  
> > > > > wrote:
> > > > > >
> > > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy  
> > > > > > wrote:
> > > > > > > This isn't equivalent - it will cause a change in behaviour for 
> > > > > > > anyone
> > > > > > > using PACKAGECONFIG += "foo" from a .bbappend.
> > > > > >
> > > > > > Correct, but this is likely the only recipe in the greater ecosystem
> > > > > > which has this behaviour, so I'm not that bothered to be honest. :)
> > > > >
> > > > > The only recipe? There are many recipes which set a default
> > > > > PACKAGECONFIG with ?= and many which set it with ??=. Your change is
> > > > > effectively switching the vim recipe from one approach to the other.
> > > > > The fact that adding PACKAGECONFIG options from a .bbappend with +=
> > > > > sometimes works OK and sometimes not is a source of confusion for new
> > > > > users.
> > > > >
> > > > > You are right that no one seems to care though...
> > > >
> > > > Some of us very much do care, it is actually bothering me a lot and 
> > > > I've posted
> > > > several times on the architecture list about this kind of issue.
> > > >
> > > > We haven't worked out what we can agree to do about it though :(.
> > >
> > > As a first, very easy, step, make a statement here on the mailing list
> > > that all PACKAGECONFIG defaults should be assigned with ?= instead of
> > > ??= and fix the recipes in oe-core accordingly.
> >
> > The question is whether we all agree on that and I'm not sure we all do.
>
> What are the possible objections?

Any more feedback? The misconception that no one cares about improving
this could be because discussions on the topic always seem to peter
out leaving these unanswered questions.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159264): 
https://lists.openembedded.org/g/openembedded-core/message/159264
Mute This Topic: https://lists.openembedded.org/mt/87406894/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 3/4] oeqa: rename masterimage into goldenimage

2021-12-06 Thread Alexander Kanavin
Nevermind ;)

Alex

On Mon, 6 Dec 2021 at 16:35, Quentin Schulz  wrote:

> Golden image has a more explicit meaning than masterimage and is not an
> issue wrt inclusivity.
>
> Signed-off-by: Quentin Schulz 
> ---
>  .../{masterimage.py => goldenimage.py}| 32 +--
>  1 file changed, 16 insertions(+), 16 deletions(-)
>  rename meta/lib/oeqa/controllers/{masterimage.py => goldenimage.py} (91%)
>
> diff --git a/meta/lib/oeqa/controllers/masterimage.py
> b/meta/lib/oeqa/controllers/goldenimage.py
> similarity index 91%
> rename from meta/lib/oeqa/controllers/masterimage.py
> rename to meta/lib/oeqa/controllers/goldenimage.py
> index feb30366323..fb1ac7a53a0 100644
> --- a/meta/lib/oeqa/controllers/masterimage.py
> +++ b/meta/lib/oeqa/controllers/goldenimage.py
> @@ -24,12 +24,12 @@ from oeqa.utils import CommandError
>
>  from abc import ABCMeta, abstractmethod
>
> -class MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget,
> metaclass=ABCMeta):
> +class GoldenImageHardwareTarget(oeqa.targetcontrol.BaseTarget,
> metaclass=ABCMeta):
>
>  supported_image_fstypes = ['tar.gz', 'tar.bz2']
>
>  def __init__(self, d):
> -super(MasterImageHardwareTarget, self).__init__(d)
> +super(GoldenImageHardwareTarget, self).__init__(d)
>
>  # target ip
>  addr = d.getVar("TEST_TARGET_IP") or bb.fatal('Please set
> TEST_TARGET_IP with the IP address of the machine you want to run the tests
> on.')
> @@ -61,8 +61,8 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
>  if not os.path.isfile(self.kernel):
>  bb.fatal("No kernel found. Expected path: %s" % self.kernel)
>
> -# master ssh connection
> -self.master = None
> +# golden ssh connection
> +self.golden = None
>  # if the user knows what they are doing, then by all means...
>  self.user_cmds = d.getVar("TEST_DEPLOY_CMDS")
>  self.deploy_cmds = None
> @@ -119,9 +119,9 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
>
>  def deploy(self):
>  # base class just sets the ssh log file for us
> -super(MasterImageHardwareTarget, self).deploy()
> -self.master = sshcontrol.SSHControl(ip=self.ip,
> logfile=self.sshlog, timeout=600, port=self.port)
> -status, output = self.master.run("cat /etc/goldenimage")
> +super(GoldenImageHardwareTarget, self).deploy()
> +self.golden = sshcontrol.SSHControl(ip=self.ip,
> logfile=self.sshlog, timeout=600, port=self.port)
> +status, output = self.golden.run("cat /etc/goldenimage")
>  if status != 0:
>  # We're not booted into the golden image, so try rebooting
>  bb.plain("%s - booting into the golden image" % self.pn)
> @@ -129,7 +129,7 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
>  self._wait_until_booted()
>
>  bb.plain("%s - deploying image on target" % self.pn)
> -status, output = self.master.run("cat /etc/goldenimage")
> +status, output = self.golden.run("cat /etc/goldenimage")
>  if status != 0:
>  bb.fatal("No ssh connectivity or target isn't running a
> golden image.\n%s" % output)
>  if self.user_cmds:
> @@ -156,10 +156,10 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
>
>  def stop(self):
>  bb.plain("%s - reboot/powercycle target" % self.pn)
> -self.power_cycle(self.master)
> +self.power_cycle(self.golden)
>
>
> -class SystemdbootTarget(MasterImageHardwareTarget):
> +class SystemdbootTarget(GoldenImageHardwareTarget):
>
>  def __init__(self, d):
>  super(SystemdbootTarget, self).__init__(d)
> @@ -184,16 +184,16 @@ class SystemdbootTarget(MasterImageHardwareTarget):
>
>  def _deploy(self):
>  # make sure these aren't mounted
> -self.master.run("umount /boot; umount /mnt/testrootfs; umount
> /sys/firmware/efi/efivars;")
> +self.golden.run("umount /boot; umount /mnt/testrootfs; umount
> /sys/firmware/efi/efivars;")
>  # from now on, every deploy cmd should return 0
>  # else an exception will be thrown by sshcontrol
> -self.master.ignore_status = False
> -self.master.copy_to(self.rootfs, "~/test-rootfs." +
> self.image_fstype)
> -self.master.copy_to(self.kernel, "~/test-kernel")
> +self.golden.ignore_status = False
> +self.golden.copy_to(self.rootfs, "~/test-rootfs." +
> self.image_fstype)
> +self.golden.copy_to(self.kernel, "~/test-kernel")
>  for cmd in self.deploy_cmds:
> -self.master.run(cmd)
> +self.golden.run(cmd)
>
>  def _start(self, params=None):
> -self.power_cycle(self.master)
> +self.power_cycle(self.golden)
>  # there are better ways than a timeout but this should work for
> now
>  

Re: [OE-core] [PATCH 2/4] core: initrdscripts: init-install{-efi,}-testfs.sh: rename masterimage into goldenimage

2021-12-06 Thread Alexander Kanavin
I'd use grep here and (case-insensitively) find all references to
masterimage in poky/. It's likely the file and the class can be renamed as
well without significant damage.

Alex

On Mon, 6 Dec 2021 at 16:35, Quentin Schulz  wrote:

> golden image has a more explicit meaning in addition of not being an
> issue wrt inclusivity.
>
> Signed-off-by: Quentin Schulz 
> ---
>  meta/lib/oeqa/controllers/masterimage.py   | 10 +-
>  meta/lib/oeqa/runtime/cases/ssh.py |  4 ++--
>  .../initrdscripts/files/init-install-efi-testfs.sh |  2 +-
>  .../initrdscripts/files/init-install-testfs.sh |  2 +-
>  4 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/meta/lib/oeqa/controllers/masterimage.py
> b/meta/lib/oeqa/controllers/masterimage.py
> index 2eff6d05ef9..feb30366323 100644
> --- a/meta/lib/oeqa/controllers/masterimage.py
> +++ b/meta/lib/oeqa/controllers/masterimage.py
> @@ -121,17 +121,17 @@ class
> MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
>  # base class just sets the ssh log file for us
>  super(MasterImageHardwareTarget, self).deploy()
>  self.master = sshcontrol.SSHControl(ip=self.ip,
> logfile=self.sshlog, timeout=600, port=self.port)
> -status, output = self.master.run("cat /etc/masterimage")
> +status, output = self.master.run("cat /etc/goldenimage")
>  if status != 0:
> -# We're not booted into the master image, so try rebooting
> -bb.plain("%s - booting into the master image" % self.pn)
> +# We're not booted into the golden image, so try rebooting
> +bb.plain("%s - booting into the golden image" % self.pn)
>  self.power_ctl("cycle")
>  self._wait_until_booted()
>
>  bb.plain("%s - deploying image on target" % self.pn)
> -status, output = self.master.run("cat /etc/masterimage")
> +status, output = self.master.run("cat /etc/goldenimage")
>  if status != 0:
> -bb.fatal("No ssh connectivity or target isn't running a
> master image.\n%s" % output)
> +bb.fatal("No ssh connectivity or target isn't running a
> golden image.\n%s" % output)
>  if self.user_cmds:
>  self.deploy_cmds = self.user_cmds.split("\n")
>  try:
> diff --git a/meta/lib/oeqa/runtime/cases/ssh.py
> b/meta/lib/oeqa/runtime/cases/ssh.py
> index 60a5fbbfbfd..a0bbed0b581 100644
> --- a/meta/lib/oeqa/runtime/cases/ssh.py
> +++ b/meta/lib/oeqa/runtime/cases/ssh.py
> @@ -13,7 +13,7 @@ class SSHTest(OERuntimeTestCase):
>  def test_ssh(self):
>  (status, output) = self.target.run('uname -a')
>  self.assertEqual(status, 0, msg='SSH Test failed: %s' % output)
> -(status, output) = self.target.run('cat /etc/masterimage')
> -msg = "This isn't the right image  - /etc/masterimage " \
> +(status, output) = self.target.run('cat /etc/goldenimage')
> +msg = "This isn't the right image  - /etc/goldenimage " \
>"shouldn't be here %s" % output
>  self.assertEqual(status, 1, msg=msg)
> diff --git
> a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> index b351985a61c..6f554f62967 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> @@ -133,7 +133,7 @@ mount -o rw,loop,noatime,nodiratime /run/media/$1/$2
> /rootmnt
>  echo "Copying rootfs files..."
>  cp -a /rootmnt/* /ssd
>
> -touch /ssd/etc/masterimage
> +touch /ssd/etc/goldenimage
>
>  if [ -d /ssd/etc/ ] ; then
>  # We dont want udev to mount our root device while we're booting...
> diff --git a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
> b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
> index ac621605287..df3a7767319 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
> @@ -158,7 +158,7 @@ mount -o rw,loop,noatime,nodiratime /run/media/$1/$2
> /src_root
>  echo "Copying rootfs files..."
>  cp -a /src_root/* /tgt_root
>
> -touch /tgt_root/etc/masterimage
> +touch /tgt_root/etc/goldenimage
>
>  if [ -d /tgt_root/etc/ ] ; then
>  echo "$bootfs  /bootext3   defaults
> 1  2" >> /tgt_root/etc/fstab
> --
> 2.33.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159262): 
https://lists.openembedded.org/g/openembedded-core/message/159262
Mute This Topic: https://lists.openembedded.org/mt/87542274/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] mesa: upgrade 21.3.0 -> 21.3.1

2021-12-06 Thread Alexander Kanavin
Please do not forget mesa-gl recipe as well.

Alex

On Mon, 6 Dec 2021 at 16:06, zhengruoqin  wrote:

> Changelog from 21.3.0
> =
> Bug fixes:
> GPU Crash in Yuzu 6600xt 5.15
> [spirv-fuzz] lower_trivial_continues_block: Assertion '!first_instr ||
> instr_is_continue(first_instr)' failed.
> [RADV] Crash in Metro Exodus in Caspain chapter and Sam’s Story
> NIR validation failed after nir_copy_prop
> lima: Corrupted Android-12 UI on Allwinner A64
> RADV/ACO: Rendering glitches in Forza Horizon 5 windshields
> dEQP-GLES31.*imulextended* compiling fp64 glsl 4.00 shader
>
> Changes:
> ir3/ra: Consider reg file size when swapping killed sources
> ir3/lower_pcopy: Fix shr.b illegal copy lowering
> ir3/lower_pcopy: Fix bug with “illegal” copies and swaps
> docs: update sha256sum for 21.3.0
> .pick_status.json: Update to 1ba231fb75be5bffd806cbd09ac285d1f8f15e3d
> ci: temporarily disable lima CI
> broadcom/compiler: don’t allow RF writes from signals after thrend
> broadcom/compiler: fix scoreboard locking checks
> broadcom/compiler: don’t move ldvary earlier if current instruction has
> ldunif
> glsl/nir: Don’t build soft float64 when it cannot be used
> intel/nir: also allow unknown format for getting the size of a storage
> image
> iris: Make a helper function for cross-batch dependency flushing
> iris: Check for cross-batch flushing whenever a buffer is newly written.
> iris: Tidy code in iris_use_pinned_bo a bit
> anv: don’t try to close fd = -1
> intel/fs: fix shader call lowering pass
> util/u_trace: refcount payloads
> android: define cpp_rtti=false because libLLVM is built w/o RTTI (v2)
> zink: block suballocator caching for swapchain/dmabuf images
> zink: set suballocator bo size to aligned allocation size
> zink: stop using VK_IMAGE_LAYOUT_PREINITIALIZED for dmabuf
> zink: always set matching resource export type for dmabuf creation
> zink: fix memory availability reporting
> zink: fail context creation more gracefully
> nir: Fix read depth for predecessors
> glx/dri3: fix glXQueryContext does not return GLX_RENDER_TYPE value
> aco/spill: use spills_entry instead of spills_exit to kill linear VGPRs
> spirv: run nir_copy_prop before nir_rematerialize_derefs_in_use_blocks_impl
> nir/dce: fix DCE of loops with a halt or return instruction in the
> pre-header
> aco: don’t create DPP instructions with SGPR operands
> android.mk: Add missing variables to the make target
> radv: disable HTILE for D32S8 format and mipmaps on GFX10
> radv: fix emitting VBO when vertex input dynamic state is used
> radv: add a workaround to fix a segfault with Metro Exodus (Linux native)
> radv: fix resetting the entire vertex input dynamic state
> svga: fix bitwise/logical and mixup
> lima: disasm: use last argument as a filename
>
> Signed-off-by: Zheng Ruoqin 
> ---
>  meta/recipes-graphics/mesa/mesa.inc   | 2 +-
>  meta/recipes-graphics/mesa/{mesa_21.3.0.bb => mesa_21.3.1.bb} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-graphics/mesa/{mesa_21.3.0.bb => mesa_21.3.1.bb}
> (100%)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index ed60d98250..e99ec6961b 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -21,7 +21,7 @@ SRC_URI = "
> https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
>
> file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
> "
>
> -SRC_URI[sha256sum] =
> "a2753c09deef0ba14d35ae8a2ceff3fe5cd13698928c7bb62c2ec8736eb09ce1"
> +SRC_URI[sha256sum] =
> "2b0dc2540cb192525741d00f706dbc4586349185dafc65729c7fda0800cc474d"
>
>  UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"
>
> diff --git a/meta/recipes-graphics/mesa/mesa_21.3.0.bb
> b/meta/recipes-graphics/mesa/mesa_21.3.1.bb
> similarity index 100%
> rename from meta/recipes-graphics/mesa/mesa_21.3.0.bb
> rename to meta/recipes-graphics/mesa/mesa_21.3.1.bb
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159261): 
https://lists.openembedded.org/g/openembedded-core/message/159261
Mute This Topic: https://lists.openembedded.org/mt/87541536/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Alexander Kanavin
Thanks - since there's already documented nomenclature for this situation,
I tweaked the patch to simply use that.

Alex

On Mon, 6 Dec 2021 at 17:47, Konrad Weihmann  wrote:

> To quote the documentation:
>
>Inappropriate [reason]
>- The patch is not appropriate for upstream, include a brief reason
> on the
>  same line enclosed with []
>  reason can be:
> ...
>no upstream (the upstream is no longer available -- dead project)
>
> so I think this is already covered, but I think we need to enforce the
> usage of machine readable reasoning within the square brackets.
>
> And if we need a more fine grained classification here, I would suggest
> to add a new item at Inappropriate
>
> On 06.12.21 17:41, Richard Purdie wrote:
> > On Mon, 2021-12-06 at 16:50 +0100, Alexander Kanavin wrote:
> >> I mean, if you insisit, we can add Upstream-Status: Defunct, but I do
> not
> >> think keeping patches in Pending state when there is no upstream is
> right
> >> either.
> >
> > Maybe we should add an Upstream-Inactive status?
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159260): 
https://lists.openembedded.org/g/openembedded-core/message/159260
Mute This Topic: https://lists.openembedded.org/mt/87494788/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Konrad Weihmann

To quote the documentation:

  Inappropriate [reason]
  - The patch is not appropriate for upstream, include a brief reason 
on the

same line enclosed with []
reason can be:
...
  no upstream (the upstream is no longer available -- dead project)

so I think this is already covered, but I think we need to enforce the 
usage of machine readable reasoning within the square brackets.


And if we need a more fine grained classification here, I would suggest 
to add a new item at Inappropriate


On 06.12.21 17:41, Richard Purdie wrote:

On Mon, 2021-12-06 at 16:50 +0100, Alexander Kanavin wrote:

I mean, if you insisit, we can add Upstream-Status: Defunct, but I do not
think keeping patches in Pending state when there is no upstream is right
either.


Maybe we should add an Upstream-Inactive status?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159259): 
https://lists.openembedded.org/g/openembedded-core/message/159259
Mute This Topic: https://lists.openembedded.org/mt/87494788/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] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Alexander Kanavin
I just sent the proper fix to bitbake-devel :)

Alex

On Mon, 6 Dec 2021 at 17:41, Konrad Weihmann  wrote:

> It's of course *not* the file extension, but the .orig. that is
> confusing the default upstream regex check
>
> This here worked for me
>
> UPSTREAM_CHECK_REGEX = "${BPN}_(?P\d+(\.\d+)+)\.orig\..*"
>
> but surely it can be fine tuned
>
> On 06.12.21 17:30, Konrad Weihmann wrote:
> > I think the answer is that latest release is a bz2, while the older one
> > are gzipped
> >
> >
> http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.7.1.orig.tar.gz
> >
> > vs.
> >
> >
> http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.8.orig.tar.bz2
> >
> > On 06.12.21 16:57, Alexander Kanavin wrote:
> >> This one is odd and it should be working. I'll cherry-pick your update
> >> and get to the bottom of it. This may mean we are missing other
> >> updates that are coming from debian tarballs.
> >>
> >> Alex
> >>
> >> On Mon, 6 Dec 2021 at 14:59, Richard Purdie
> >>  >> > wrote:
> >>
> >> On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
> >>  > Since AUH didn't pick this up, can you run 'devtool
> >> latest-version minicom'
> >>  > with this update, as it probably would report something that
> >> needs fixing via
> >>  > regexp?
> >>
> >> That shows:
> >>
> >> WARNING: latest_versionstring: package minicom_2.8.orig.tar.bz2
> >> don't match pattern
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >>
> >>
> >>
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159258): 
https://lists.openembedded.org/g/openembedded-core/message/159258
Mute This Topic: https://lists.openembedded.org/mt/87539156/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] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Konrad Weihmann
It's of course *not* the file extension, but the .orig. that is 
confusing the default upstream regex check


This here worked for me

UPSTREAM_CHECK_REGEX = "${BPN}_(?P\d+(\.\d+)+)\.orig\..*"

but surely it can be fine tuned

On 06.12.21 17:30, Konrad Weihmann wrote:
I think the answer is that latest release is a bz2, while the older one 
are gzipped


http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.7.1.orig.tar.gz

vs.

http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.8.orig.tar.bz2

On 06.12.21 16:57, Alexander Kanavin wrote:
This one is odd and it should be working. I'll cherry-pick your update 
and get to the bottom of it. This may mean we are missing other 
updates that are coming from debian tarballs.


Alex

On Mon, 6 Dec 2021 at 14:59, Richard Purdie 
> wrote:


    On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
 > Since AUH didn't pick this up, can you run 'devtool
    latest-version minicom'
 > with this update, as it probably would report something that
    needs fixing via
 > regexp?

    That shows:

    WARNING: latest_versionstring: package minicom_2.8.orig.tar.bz2
    don't match pattern

    Cheers,

    Richard











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159257): 
https://lists.openembedded.org/g/openembedded-core/message/159257
Mute This Topic: https://lists.openembedded.org/mt/87539156/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 16:50 +0100, Alexander Kanavin wrote:
> I mean, if you insisit, we can add Upstream-Status: Defunct, but I do not
> think keeping patches in Pending state when there is no upstream is right
> either.

Maybe we should add an Upstream-Inactive status?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159256): 
https://lists.openembedded.org/g/openembedded-core/message/159256
Mute This Topic: https://lists.openembedded.org/mt/87494788/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] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Konrad Weihmann
I think the answer is that latest release is a bz2, while the older one 
are gzipped


http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.7.1.orig.tar.gz

vs.

http://ftp.debian.org/debian/pool/main/m/minicom/minicom_2.8.orig.tar.bz2

On 06.12.21 16:57, Alexander Kanavin wrote:
This one is odd and it should be working. I'll cherry-pick your update 
and get to the bottom of it. This may mean we are missing other updates 
that are coming from debian tarballs.


Alex

On Mon, 6 Dec 2021 at 14:59, Richard Purdie 
> wrote:


On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
 > Since AUH didn't pick this up, can you run 'devtool
latest-version minicom'
 > with this update, as it probably would report something that
needs fixing via
 > regexp?

That shows:

WARNING: latest_versionstring: package minicom_2.8.orig.tar.bz2
don't match pattern

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159255): 
https://lists.openembedded.org/g/openembedded-core/message/159255
Mute This Topic: https://lists.openembedded.org/mt/87539156/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 05/26] python3: drop unneeded multiprocessing module patch

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 17:13, Khem Raj  wrote:

> There is a slightly different explanation here. libpthread was merged into
> libc
>
>> so this fix becomes a null-op on glibc. Not sure if musl has a separate
>> pthread
>> but if so we could/should test that?
>
>
> Musl has always been a single shared object from day one infact glibc is
> now moving in that direction so it will work fine on musl
>

Yep, I just verified this on qemux86 and qemux86-64.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159254): 
https://lists.openembedded.org/g/openembedded-core/message/159254
Mute This Topic: https://lists.openembedded.org/mt/87494766/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 05/26] python3: drop unneeded multiprocessing module patch

2021-12-06 Thread Khem Raj
On Mon, Dec 6, 2021 at 3:07 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Sat, 2021-12-04 at 08:13 +0100, Alexander Kanavin wrote:
> > I ran the reproducing sequence on qemux86, and it went fine:
> >
> > root@qemux86:~# python3
> > Python 3.10.0 (default, Oct  4 2021, 17:55:55) [GCC 11.2.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > > > > import multiprocessing
> > > > > pool_sema = multiprocessing.BoundedSemaphore(value=1)
> > > > > pool_sema.acquire()
> > True
> > > > > pool_sema.release()
> > > > >
> >
> > Additionally AB testing revealed no issues, and the description isn't
> entirely
> > clear about where and how the problem occurs, so I can't submit it
> upsream
> > without having that understanding and how to demonstrate the problem.
> >
> > Signed-off-by: Alexander Kanavin 
> >
>
> There is a slightly different explanation here. libpthread was merged into
> libc
> so this fix becomes a null-op on glibc. Not sure if musl has a separate
> pthread
> but if so we could/should test that?


Musl has always been a single shared object from day one infact glibc is
now moving in that direction so it will work fine on musl

>
>
> Cheers,
>
> Richard
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159253): 
https://lists.openembedded.org/g/openembedded-core/message/159253
Mute This Topic: https://lists.openembedded.org/mt/87494766/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [bitbake-devel] [oe-core][PATCH v5 1/2] repo: Add recipe for 2.17.3

2021-12-06 Thread Jasper Orschulko
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In regards to automatic update patch generation this actually is pretty
useful. I think I'll throw an extra patch on top to integrate this
suggestion.

- -- 
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
jasper.orschu...@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
SchnellerstraĂźe 1-5 | 12439 Berlin

https://iris-sensing.com/





On Thu, 2021-11-11 at 11:00 +, Jose Quaresma wrote:
> 
> Jasper Orschulko via lists.openembedded.org
>  escreveu no dia
> quinta, 11/11/2021 Ă (s) 10:21:
> > From: Jasper Orschulko 
> > 
> > Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
> > 
> > Signed-off-by: Jasper Orschulko 
> > ---
> >  meta/conf/distro/include/maintainers.inc      |  1 +
> >  .../0001-Set-REPO_REV-to-v2.17.3.patch        | 35
> > +++
> >  .../repo/repo/0001-python3-shebang.patch      | 26 ++
> >  meta/recipes-devtools/repo/repo_2.17.3.bb     | 28 +++
> >  4 files changed, 90 insertions(+)
> >  create mode 100644 meta/recipes-devtools/repo/repo-2.17.3/0001-
> > Set-REPO_REV-to-v2.17.3.patch
> >  create mode 100644 meta/recipes-devtools/repo/repo/0001-python3-
> > shebang.patch
> >  create mode 100644 meta/recipes-devtools/repo/repo_2.17.3.bb
> > 
> > diff --git a/meta/conf/distro/include/maintainers.inc
> > b/meta/conf/distro/include/maintainers.inc
> > index f3e0a75d56..58a0a9615f 100644
> > --- a/meta/conf/distro/include/maintainers.inc
> > +++ b/meta/conf/distro/include/maintainers.inc
> > @@ -652,6 +652,7 @@ RECIPE_MAINTAINER:pn-quilt-native = "Robert
> > Yang "
> >  RECIPE_MAINTAINER:pn-quota = "Anuj Mittal "
> >  RECIPE_MAINTAINER:pn-re2c = "Khem Raj "
> >  RECIPE_MAINTAINER:pn-readline = "Hongxu Jia
> > "
> > +RECIPE_MAINTAINER:pn-repo = "Jasper Orschulko
> > "
> >  RECIPE_MAINTAINER:pn-resolvconf = "Chen Qi
> > "
> >  RECIPE_MAINTAINER:pn-rgb = "Unassigned
> > "
> >  RECIPE_MAINTAINER:pn-rpcbind = "Hongxu Jia
> > "
> > diff --git a/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-
> > REPO_REV-to-v2.17.3.patch b/meta/recipes-devtools/repo/repo-
> > 2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
> > new file mode 100644
> > index 00..285b1d3129
> > --- /dev/null
> > +++ b/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-
> > v2.17.3.patch
> > @@ -0,0 +1,35 @@
> > +From bdd2a528da59c28db8ae2986834926de7cebf3ab Mon Sep 17 00:00:00
> > 2001
> > +From: Jasper Orschulko 
> > +Date: Thu, 4 Nov 2021 16:55:12 +0100
> > +Subject: [PATCH] Set REPO_REV to v2.17.3
> > +
> > +repo is an unusual tool because it downloads all of its own Python
> > modules
> > +using GPG-signed git tags, and stores those files as part of the
> > project
> > +that it is working with.
> > +
> > +So in order to have a reproducible repo installation within the
> > project
> > +folders, we hardcode the default REPO_REV to a SHA1 that
> > corresponds to
> > +the version of the recipe. REPO_REV can still be overwriten by the
> > user,
> > +by specifying the REPO_REV environment variable.
> > +
> > +Upstream-Status: Inappropriate [configuration]
> > +Signed-off-by: Jasper Orschulko
> > 
> > +---
> > + repo | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/repo b/repo
> > +index b13e34c..31130e9 100755
> > +--- a/repo
> >  b/repo
> > +@@ -130,7 +130,7 @@ if not REPO_URL:
> > +   REPO_URL = 'https://gerrit.googlesource.com/git-repo'
> > + REPO_REV = os.environ.get('REPO_REV')
> > + if not REPO_REV:
> > +-  REPO_REV = 'stable'
> > ++  REPO_REV = '11b30b91df1f0e03b53da970ec2588e85817bacc'
> > + 
> > + # increment this whenever we make important changes to this
> > script
> > + VERSION = (2, 8)
> > +-- 
> > +2.33.1
> > diff --git a/meta/recipes-devtools/repo/repo/0001-python3-
> > shebang.patch b/meta/recipes-devtools/repo/repo/0001-python3-
> > shebang.patch
> > new file mode 100644
> > index 00..d3888c8bb2
> > --- /dev/null
> > +++ b/meta/recipes-devtools/repo/repo/0001-python3-shebang.patch
> > @@ -0,0 +1,26 @@
> > +From b8e84b202cd302a7c99288d3835dc9c63071f8f2 Mon Sep 17 00:00:00
> > 2001
> > +From: Jasper Orschulko 
> > +Date: Tue, 14 Sep 2021 16:46:51 +0200
> > +Subject: [PATCH] python3 shebang
> > +
> > +Yocto does not symlink from python to python3, thus change the
> > shebang from
> > +python to python3.
> > +
> > +Upstream-Status: Inappropriate [configuration]
> > +Signed-off-by: Jasper Orschulko
> > 
> > +---
> > + repo | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/repo b/repo
> > +index b13e34c..205e0e5 100755
> > +--- a/repo
> >  b/repo
> > +@@ -1,4 +1,4 @@
> > +-#!/usr/bin/env python
> > ++#!/usr/bin/env python3
> > + # -*- coding:utf-8 -*-
> > + #
> > + # Copyright (C) 2008 The Android Open Source Project
> > +--
> > +2.33.0
> > diff --git a/meta/recipes-devtools/repo/repo_2.17.3.bb
> > 

Re: [OE-core] [PATCH] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Alexander Kanavin
This one is odd and it should be working. I'll cherry-pick your update and
get to the bottom of it. This may mean we are missing other updates that
are coming from debian tarballs.

Alex

On Mon, 6 Dec 2021 at 14:59, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
> > Since AUH didn't pick this up, can you run 'devtool latest-version
> minicom'
> > with this update, as it probably would report something that needs
> fixing via
> > regexp?
>
> That shows:
>
> WARNING: latest_versionstring: package minicom_2.8.orig.tar.bz2 don't
> match pattern
>
> Cheers,
>
> Richard
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159251): 
https://lists.openembedded.org/g/openembedded-core/message/159251
Mute This Topic: https://lists.openembedded.org/mt/87539156/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Alexander Kanavin
I mean, if you insisit, we can add Upstream-Status: Defunct, but I do not
think keeping patches in Pending state when there is no upstream is right
either.

Alex

On Mon, 6 Dec 2021 at 16:45, Alexander Kanavin via lists.openembedded.org
 wrote:

> On Mon, 6 Dec 2021 at 15:08, Ross Burton  wrote:
>
>> On Mon, 6 Dec 2021 at 11:03, Alexander Kanavin 
>> wrote:
>> > Presumably, that someone would start updating the repo and making
>> releases, at which point we can reevaluate the situation with the patches.
>> As of today, they are inappropriate.
>>
>> But how, in two years time, would we know to re-evaluate the patches
>> if they're marked as inappropriate for upstream?
>>
>
> We should properly, clearly document the reason why they're inappropriate
> for upstream right now, just above the upstream-status line which is a
> summary. If there is a new release in the future, at that point any upgrade
> activity should re-evaluate all existing patches for the old version
> anyway, even if they're inappropriate, or submitted or anything else - too
> much time would have passed by then.
>
> Alex
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159250): 
https://lists.openembedded.org/g/openembedded-core/message/159250
Mute This Topic: https://lists.openembedded.org/mt/87494788/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 15:08, Ross Burton  wrote:

> On Mon, 6 Dec 2021 at 11:03, Alexander Kanavin 
> wrote:
> > Presumably, that someone would start updating the repo and making
> releases, at which point we can reevaluate the situation with the patches.
> As of today, they are inappropriate.
>
> But how, in two years time, would we know to re-evaluate the patches
> if they're marked as inappropriate for upstream?
>

We should properly, clearly document the reason why they're inappropriate
for upstream right now, just above the upstream-status line which is a
summary. If there is a new release in the future, at that point any upgrade
activity should re-evaluate all existing patches for the old version
anyway, even if they're inappropriate, or submitted or anything else - too
much time would have passed by then.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159249): 
https://lists.openembedded.org/g/openembedded-core/message/159249
Mute This Topic: https://lists.openembedded.org/mt/87494788/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/4] rename core-image-testmaster* to core-image-testgolden

2021-12-06 Thread Joshua Watt
On Mon, Dec 6, 2021 at 9:35 AM Quentin Schulz  wrote:
>
> "golden" has a more explicit meaning than master in addition to not
> being an issue wrt inclusivity.

I don't think "golden" has the same meaning here. Perhaps "controller"
or something similar?

>
> Signed-off-by: Quentin Schulz 
> ---
>  meta/conf/distro/include/distro_alias.inc   | 4 ++--
>  meta/conf/distro/include/maintainers.inc| 4 ++--
>  meta/lib/oeqa/controllers/masterimage.py| 6 +++---
>  ...ster-initramfs.bb => core-image-testgolden-initramfs.bb} | 2 +-
>  .../{core-image-testmaster.bb => core-image-testgolden.bb}  | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
>  rename meta/recipes-extended/images/{core-image-testmaster-initramfs.bb => 
> core-image-testgolden-initramfs.bb} (92%)
>  rename meta/recipes-extended/images/{core-image-testmaster.bb => 
> core-image-testgolden.bb} (80%)
>
> diff --git a/meta/conf/distro/include/distro_alias.inc 
> b/meta/conf/distro/include/distro_alias.inc
> index 44bc3bf1315..2649a21474b 100644
> --- a/meta/conf/distro/include/distro_alias.inc
> +++ b/meta/conf/distro/include/distro_alias.inc
> @@ -42,8 +42,8 @@ DISTRO_PN_ALIAS:pn-core-image-rt-sdk = "OE-Core"
>  DISTRO_PN_ALIAS:pn-core-image-sato = "OE-Core"
>  DISTRO_PN_ALIAS:pn-core-image-sato-dev = "OE-Core"
>  DISTRO_PN_ALIAS:pn-core-image-sato-sdk = "OE-Core"
> -DISTRO_PN_ALIAS:pn-core-image-testmaster = "OE-Core"
> -DISTRO_PN_ALIAS:pn-core-image-testmaster-initramfs = "OE-Core"
> +DISTRO_PN_ALIAS:pn-core-image-testgolden = "OE-Core"
> +DISTRO_PN_ALIAS:pn-core-image-testgolden-initramfs = "OE-Core"
>  DISTRO_PN_ALIAS:pn-core-image-weston = "OE-Core"
>  DISTRO_PN_ALIAS:pn-core-image-x11 = "OE-Core"
>  DISTRO_PN_ALIAS:pn-createrepo-c = "Fedora=createrepo_c Clear=createrepo_c"
> diff --git a/meta/conf/distro/include/maintainers.inc 
> b/meta/conf/distro/include/maintainers.inc
> index 97ba2ce79c8..61572247560 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -112,8 +112,8 @@ RECIPE_MAINTAINER:pn-core-image-ptest-all = "Richard 
> Purdie   RECIPE_MAINTAINER:pn-core-image-ptest-fast = "Richard Purdie 
> "
>  RECIPE_MAINTAINER:pn-core-image-sato = "Richard Purdie 
> "
>  RECIPE_MAINTAINER:pn-core-image-sato-sdk = "Richard Purdie 
> "
> -RECIPE_MAINTAINER:pn-core-image-testmaster-initramfs = "Richard Purdie 
> "
> -RECIPE_MAINTAINER:pn-core-image-testmaster = "Richard Purdie 
> "
> +RECIPE_MAINTAINER:pn-core-image-testgolden-initramfs = "Richard Purdie 
> "
> +RECIPE_MAINTAINER:pn-core-image-testgolden = "Richard Purdie 
> "
>  RECIPE_MAINTAINER:pn-core-image-weston = "Richard Purdie 
> "
>  RECIPE_MAINTAINER:pn-core-image-weston-sdk = "Richard Purdie 
> "
>  RECIPE_MAINTAINER:pn-core-image-x11 = "Richard Purdie 
> "
> diff --git a/meta/lib/oeqa/controllers/masterimage.py 
> b/meta/lib/oeqa/controllers/masterimage.py
> index 0bf5917e481..2eff6d05ef9 100644
> --- a/meta/lib/oeqa/controllers/masterimage.py
> +++ b/meta/lib/oeqa/controllers/masterimage.py
> @@ -3,13 +3,13 @@
>  # SPDX-License-Identifier: MIT
>  #
>  # This module adds support to testimage.bbclass to deploy images and run
> -# tests using a "master image" - this is a "known good" image that is
> +# tests using a "golden image" - this is a "known good" image that is
>  # installed onto the device as part of initial setup and will be booted into
>  # with no interaction; we can then use it to deploy the image to be tested
>  # to a second partition before running the tests.
>  #
> -# For an example master image, see core-image-testmaster
> -# (meta/recipes-extended/images/core-image-testmaster.bb)
> +# For an example golden image, see core-image-testgolden
> +# (meta/recipes-extended/images/core-image-testgolden.bb)
>
>  import os
>  import bb
> diff --git a/meta/recipes-extended/images/core-image-testmaster-initramfs.bb 
> b/meta/recipes-extended/images/core-image-testgolden-initramfs.bb
> similarity index 92%
> rename from meta/recipes-extended/images/core-image-testmaster-initramfs.bb
> rename to meta/recipes-extended/images/core-image-testgolden-initramfs.bb
> index 1a2e0af27ba..5495e3d12e0 100644
> --- a/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
> +++ b/meta/recipes-extended/images/core-image-testgolden-initramfs.bb
> @@ -7,7 +7,7 @@ PACKAGE_INSTALL = "initramfs-live-boot 
> initramfs-live-install-testfs initramfs-l
>  # Do not pollute the initrd image with rootfs features
>  IMAGE_FEATURES = ""
>
> -export IMAGE_BASENAME = "core-image-testmaster-initramfs"
> +export IMAGE_BASENAME = "core-image-testgolden-initramfs"
>  IMAGE_NAME_SUFFIX ?= ""
>  IMAGE_LINGUAS = ""
>
> diff --git a/meta/recipes-extended/images/core-image-testmaster.bb 
> b/meta/recipes-extended/images/core-image-testgolden.bb
> similarity index 80%
> rename from meta/recipes-extended/images/core-image-testmaster.bb
> rename to 

Re: [OE-core] [RFC PATCH] vim: upgrade to 8.2 patch 3752

2021-12-06 Thread Alexander Kanavin
I tend to agree. Vim has a strange release policy where major releases
happen infrequently and allow unfixed issues to pile up, but minor releases
are tagged for every single commit. And so it becomes hard for integrators
to pick an update strategy between those thousands of commits, and even
harder to backport everything if sticking to a current major release.

Alex


On Mon, 6 Dec 2021 at 15:50, Ross Burton  wrote:

> There's a fairly constant flow of CVEs being fixed in Vim, which are
> getting increasing non-trivial to backport.
>
> Instead of trying to backport (and potentially introduce more bugs), or
> just ignoring them entirely, upgrade vim to the latest patch in the hope
> that vim 8.3 will be released before we release Kirkstone.
>
> Signed-off-by: Ross Burton 
> ---
>  ...1-reading-character-past-end-of-line.patch |  62 --
>  ...28-using-freed-memory-when-replacing.patch |  83 ---
>  ...eading-uninitialized-memory-when-giv.patch |  63 --
>  ...rash-when-using-CTRL-W-f-without-fin.patch |  92 
>  ...llegal-memory-access-if-buffer-name-.patch |  86 
>  ...ml_get-error-after-search-with-range.patch |  72 --
>  ...nvalid-memory-access-when-scrolling-.patch |  97 
>  .../vim/files/CVE-2021-3778.patch |  61 --
>  ...1e135a16091c93f6f5f7525a5c58fb7ca9f9.patch | 207 --
>  meta/recipes-support/vim/vim.inc  |  15 +-
>  10 files changed, 4 insertions(+), 834 deletions(-)
>  delete mode 100644
> meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0002-patch-8.2.3582-reading-uninitialized-memory-when-giv.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0002-patch-8.2.3611-crash-when-using-CTRL-W-f-without-fin.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0003-patch-8.2.3487-illegal-memory-access-if-buffer-name-.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0004-patch-8.2.3489-ml_get-error-after-search-with-range.patch
>  delete mode 100644
> meta/recipes-support/vim/files/0005-patch-8.2.3564-invalid-memory-access-when-scrolling-.patch
>  delete mode 100644 meta/recipes-support/vim/files/CVE-2021-3778.patch
>  delete mode 100644
> meta/recipes-support/vim/files/b7081e135a16091c93f6f5f7525a5c58fb7ca9f9.patch
>
> diff --git
> a/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
> b/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
> deleted file mode 100644
> index 28c61cd782..00
> ---
> a/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
> +++ /dev/null
> @@ -1,62 +0,0 @@
> -CVE: CVE-2021-3927
> -Upstream-Status: Backport
> -Signed-off-by: Ross Burton 
> -
> -From 93b427c6e729260d0700c3b2804ec153bc8284fa Mon Sep 17 00:00:00 2001
> -From: Bram Moolenaar 
> -Date: Thu, 4 Nov 2021 15:10:11 +
> -Subject: [PATCH] patch 8.2.3581: reading character past end of line
> -
> -Problem:Reading character past end of line.
> -Solution:   Correct the cursor column.
> 
> - src/ex_docmd.c   |  1 +
> - src/testdir/test_put.vim | 12 
> - src/version.c|  2 ++
> - 3 files changed, 15 insertions(+)
> -
> -diff --git a/src/ex_docmd.c b/src/ex_docmd.c
> -index fde726477..59e245bee 100644
>  a/src/ex_docmd.c
> -+++ b/src/ex_docmd.c
> -@@ -6905,6 +6905,7 @@ ex_put(exarg_T *eap)
> -   eap->forceit = TRUE;
> - }
> - curwin->w_cursor.lnum = eap->line2;
> -+check_cursor_col();
> - do_put(eap->regname, eap->forceit ? BACKWARD : FORWARD, 1L,
> -
> PUT_LINE|PUT_CURSLINE);
> - }
> -diff --git a/src/testdir/test_put.vim b/src/testdir/test_put.vim
> -index 225ebd1f3..922e5b269 100644
>  a/src/testdir/test_put.vim
> -+++ b/src/testdir/test_put.vim
> -@@ -113,3 +113,15 @@ func Test_put_p_indent_visual()
> -   call assert_equal('select that text', getline(2))
> -   bwipe!
> - endfunc
> -+
> -+func Test_put_above_first_line()
> -+  new
> -+  let @" = 'text'
> -+  silent! normal 0o00
> -+  0put
> -+  call assert_equal('text', getline(1))
> -+  bwipe!
> -+endfunc
> -+
> -+
> -+" vim: shiftwidth=2 sts=2 expandtab
> -diff --git a/src/version.c b/src/version.c
> -index a9e8be0e7..df4ec9a47 100644
>  a/src/version.c
> -+++ b/src/version.c
> -@@ -742,6 +742,8 @@ static char *(features[]) =
> -
> - static int included_patches[] =
> - {   /* Add new patch number below this line */
> -+/**/
> -+3581,
> - /**/
> - 3564,
> - /**/
> diff --git
> a/meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
> b/meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
> deleted file mode 100644
> index ecfae0301e..00
> ---
> 

[OE-core] [PATCH 0/4] blacklist/blocklist and master/golden

2021-12-06 Thread Quentin Schulz
Hi all,

It seems some changes are not too invasive and can be made to be a bit
more inclusive, so I'll make the autobuilder try those patches and tell
me whether I broke something somewhere I wasn't aware of.

In other words: I did not test those changes.

Those changes warrant some notes in the migration guide once they
are merged.

Cheers,
Quentin

Quentin Schulz (4):
  rename core-image-testmaster* to core-image-testgolden
  core: initrdscripts: init-install{-efi,}-testfs.sh: rename masterimage
into goldenimage
  oeqa: rename masterimage into goldenimage
  core: udev: udev-extraconf: rename mount.blacklist* to
mount.blocklist.*

 meta/conf/distro/include/distro_alias.inc |  4 +-
 meta/conf/distro/include/maintainers.inc  |  4 +-
 .../{masterimage.py => goldenimage.py}| 44 +--
 meta/lib/oeqa/runtime/cases/ssh.py|  4 +-
 .../files/init-install-efi-testfs.sh  |  4 +-
 .../initrdscripts/files/init-install-efi.sh   |  2 +-
 .../files/init-install-testfs.sh  |  4 +-
 .../initrdscripts/files/init-install.sh   |  2 +-
 .../{mount.blacklist => mount.blocklist}  |  0
 .../recipes-core/udev/udev-extraconf/mount.sh |  4 +-
 meta/recipes-core/udev/udev-extraconf_1.1.bb  | 10 ++---
 bb => core-image-testgolden-initramfs.bb} |  2 +-
 ...testmaster.bb => core-image-testgolden.bb} |  4 +-
 meta/recipes-extended/parted/files/run-ptest  |  6 +--
 14 files changed, 47 insertions(+), 47 deletions(-)
 rename meta/lib/oeqa/controllers/{masterimage.py => goldenimage.py} (87%)
 rename meta/recipes-core/udev/udev-extraconf/{mount.blacklist => 
mount.blocklist} (100%)
 rename meta/recipes-extended/images/{core-image-testmaster-initramfs.bb => 
core-image-testgolden-initramfs.bb} (92%)
 rename meta/recipes-extended/images/{core-image-testmaster.bb => 
core-image-testgolden.bb} (80%)

-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159242): 
https://lists.openembedded.org/g/openembedded-core/message/159242
Mute This Topic: https://lists.openembedded.org/mt/87542271/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 4/4] core: udev: udev-extraconf: rename mount.blacklist* to mount.blocklist.*

2021-12-06 Thread Quentin Schulz
blocklist has a more obvious meaning than blacklist and is also not an
issue wrt inclusivity, so let's use that naming instead.

Signed-off-by: Quentin Schulz 
---
 .../initrdscripts/files/init-install-efi-testfs.sh |  2 +-
 .../initrdscripts/files/init-install-efi.sh|  2 +-
 .../initrdscripts/files/init-install-testfs.sh |  2 +-
 meta/recipes-core/initrdscripts/files/init-install.sh  |  2 +-
 .../{mount.blacklist => mount.blocklist}   |  0
 meta/recipes-core/udev/udev-extraconf/mount.sh |  4 ++--
 meta/recipes-core/udev/udev-extraconf_1.1.bb   | 10 +-
 meta/recipes-extended/parted/files/run-ptest   |  6 +++---
 8 files changed, 14 insertions(+), 14 deletions(-)
 rename meta/recipes-core/udev/udev-extraconf/{mount.blacklist => 
mount.blocklist} (100%)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
index 6f554f62967..9bf32e8cb4e 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
@@ -138,7 +138,7 @@ touch /ssd/etc/goldenimage
 if [ -d /ssd/etc/ ] ; then
 # We dont want udev to mount our root device while we're booting...
 if [ -d /ssd/etc/udev/ ] ; then
-echo "/dev/${device}" >> /ssd/etc/udev/mount.blacklist
+echo "/dev/${device}" >> /ssd/etc/udev/mount.blocklist
 fi
 fi
 
diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index f667518b895..97db4c753b9 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -229,7 +229,7 @@ if [ -d /tgt_root/etc/ ] ; then
 echo "UUID=$boot_uuid  /bootvfat   defaults
  1  2" >> /tgt_root/etc/fstab
 # We dont want udev to mount our root device while we're booting...
 if [ -d /tgt_root/etc/udev/ ] ; then
-echo "${device}" >> /tgt_root/etc/udev/mount.blacklist
+echo "${device}" >> /tgt_root/etc/udev/mount.blocklist
 fi
 fi
 
diff --git a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh 
b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
index df3a7767319..ea74806a7b7 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
@@ -164,7 +164,7 @@ if [ -d /tgt_root/etc/ ] ; then
 echo "$bootfs  /bootext3   defaults
  1  2" >> /tgt_root/etc/fstab
 # We dont want udev to mount our root device while we're booting...
 if [ -d /tgt_root/etc/udev/ ] ; then
-   echo "/dev/${device}" >> /tgt_root/etc/udev/mount.blacklist
+   echo "/dev/${device}" >> /tgt_root/etc/udev/mount.blocklist
 fi
 fi
 umount /tgt_root
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index e71579631b5..1f7dab8a967 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -261,7 +261,7 @@ if [ -d /tgt_root/etc/ ] ; then
 echo "$bootdev  /bootext3   defaults   
   1  2" >> /tgt_root/etc/fstab
 # We dont want udev to mount our root device while we're booting...
 if [ -d /tgt_root/etc/udev/ ] ; then
-echo "${device}" >> /tgt_root/etc/udev/mount.blacklist
+echo "${device}" >> /tgt_root/etc/udev/mount.blocklist
 fi
 fi
 umount /tgt_root
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.blacklist 
b/meta/recipes-core/udev/udev-extraconf/mount.blocklist
similarity index 100%
rename from meta/recipes-core/udev/udev-extraconf/mount.blacklist
rename to meta/recipes-core/udev/udev-extraconf/mount.blocklist
diff --git a/meta/recipes-core/udev/udev-extraconf/mount.sh 
b/meta/recipes-core/udev/udev-extraconf/mount.sh
index b23731870ea..41b7c775c25 100644
--- a/meta/recipes-core/udev/udev-extraconf/mount.sh
+++ b/meta/recipes-core/udev/udev-extraconf/mount.sh
@@ -26,11 +26,11 @@ fi
 
 PMOUNT="/usr/bin/pmount"
 
-for line in `grep -h -v ^# /etc/udev/mount.blacklist 
/etc/udev/mount.blacklist.d/*`
+for line in `grep -h -v ^# /etc/udev/mount.blocklist 
/etc/udev/mount.blocklist.d/*`
 do
if [ ` expr match "$DEVNAME" "$line" ` -gt 0 ];
then
-   logger "udev/mount.sh" "[$DEVNAME] is blacklisted, ignoring"
+   logger "udev/mount.sh" "[$DEVNAME] mounting is blocked, 
ignoring"
exit 0
fi
 done
diff --git a/meta/recipes-core/udev/udev-extraconf_1.1.bb 
b/meta/recipes-core/udev/udev-extraconf_1.1.bb
index 2ba35b0df69..42ba687ed8b 100644
--- a/meta/recipes-core/udev/udev-extraconf_1.1.bb
+++ b/meta/recipes-core/udev/udev-extraconf_1.1.bb
@@ -1,13 +1,13 @@
 SUMMARY = "Extra 

[OE-core] [PATCH 1/4] rename core-image-testmaster* to core-image-testgolden

2021-12-06 Thread Quentin Schulz
"golden" has a more explicit meaning than master in addition to not
being an issue wrt inclusivity.

Signed-off-by: Quentin Schulz 
---
 meta/conf/distro/include/distro_alias.inc   | 4 ++--
 meta/conf/distro/include/maintainers.inc| 4 ++--
 meta/lib/oeqa/controllers/masterimage.py| 6 +++---
 ...ster-initramfs.bb => core-image-testgolden-initramfs.bb} | 2 +-
 .../{core-image-testmaster.bb => core-image-testgolden.bb}  | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)
 rename meta/recipes-extended/images/{core-image-testmaster-initramfs.bb => 
core-image-testgolden-initramfs.bb} (92%)
 rename meta/recipes-extended/images/{core-image-testmaster.bb => 
core-image-testgolden.bb} (80%)

diff --git a/meta/conf/distro/include/distro_alias.inc 
b/meta/conf/distro/include/distro_alias.inc
index 44bc3bf1315..2649a21474b 100644
--- a/meta/conf/distro/include/distro_alias.inc
+++ b/meta/conf/distro/include/distro_alias.inc
@@ -42,8 +42,8 @@ DISTRO_PN_ALIAS:pn-core-image-rt-sdk = "OE-Core"
 DISTRO_PN_ALIAS:pn-core-image-sato = "OE-Core"
 DISTRO_PN_ALIAS:pn-core-image-sato-dev = "OE-Core"
 DISTRO_PN_ALIAS:pn-core-image-sato-sdk = "OE-Core"
-DISTRO_PN_ALIAS:pn-core-image-testmaster = "OE-Core"
-DISTRO_PN_ALIAS:pn-core-image-testmaster-initramfs = "OE-Core"
+DISTRO_PN_ALIAS:pn-core-image-testgolden = "OE-Core"
+DISTRO_PN_ALIAS:pn-core-image-testgolden-initramfs = "OE-Core"
 DISTRO_PN_ALIAS:pn-core-image-weston = "OE-Core"
 DISTRO_PN_ALIAS:pn-core-image-x11 = "OE-Core"
 DISTRO_PN_ALIAS:pn-createrepo-c = "Fedora=createrepo_c Clear=createrepo_c"
diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 97ba2ce79c8..61572247560 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -112,8 +112,8 @@ RECIPE_MAINTAINER:pn-core-image-ptest-all = "Richard Purdie 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159243): 
https://lists.openembedded.org/g/openembedded-core/message/159243
Mute This Topic: https://lists.openembedded.org/mt/87542272/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/4] core: initrdscripts: init-install{-efi,}-testfs.sh: rename masterimage into goldenimage

2021-12-06 Thread Quentin Schulz
golden image has a more explicit meaning in addition of not being an
issue wrt inclusivity.

Signed-off-by: Quentin Schulz 
---
 meta/lib/oeqa/controllers/masterimage.py   | 10 +-
 meta/lib/oeqa/runtime/cases/ssh.py |  4 ++--
 .../initrdscripts/files/init-install-efi-testfs.sh |  2 +-
 .../initrdscripts/files/init-install-testfs.sh |  2 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/meta/lib/oeqa/controllers/masterimage.py 
b/meta/lib/oeqa/controllers/masterimage.py
index 2eff6d05ef9..feb30366323 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -121,17 +121,17 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 # base class just sets the ssh log file for us
 super(MasterImageHardwareTarget, self).deploy()
 self.master = sshcontrol.SSHControl(ip=self.ip, logfile=self.sshlog, 
timeout=600, port=self.port)
-status, output = self.master.run("cat /etc/masterimage")
+status, output = self.master.run("cat /etc/goldenimage")
 if status != 0:
-# We're not booted into the master image, so try rebooting
-bb.plain("%s - booting into the master image" % self.pn)
+# We're not booted into the golden image, so try rebooting
+bb.plain("%s - booting into the golden image" % self.pn)
 self.power_ctl("cycle")
 self._wait_until_booted()
 
 bb.plain("%s - deploying image on target" % self.pn)
-status, output = self.master.run("cat /etc/masterimage")
+status, output = self.master.run("cat /etc/goldenimage")
 if status != 0:
-bb.fatal("No ssh connectivity or target isn't running a master 
image.\n%s" % output)
+bb.fatal("No ssh connectivity or target isn't running a golden 
image.\n%s" % output)
 if self.user_cmds:
 self.deploy_cmds = self.user_cmds.split("\n")
 try:
diff --git a/meta/lib/oeqa/runtime/cases/ssh.py 
b/meta/lib/oeqa/runtime/cases/ssh.py
index 60a5fbbfbfd..a0bbed0b581 100644
--- a/meta/lib/oeqa/runtime/cases/ssh.py
+++ b/meta/lib/oeqa/runtime/cases/ssh.py
@@ -13,7 +13,7 @@ class SSHTest(OERuntimeTestCase):
 def test_ssh(self):
 (status, output) = self.target.run('uname -a')
 self.assertEqual(status, 0, msg='SSH Test failed: %s' % output)
-(status, output) = self.target.run('cat /etc/masterimage')
-msg = "This isn't the right image  - /etc/masterimage " \
+(status, output) = self.target.run('cat /etc/goldenimage')
+msg = "This isn't the right image  - /etc/goldenimage " \
   "shouldn't be here %s" % output
 self.assertEqual(status, 1, msg=msg)
diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
index b351985a61c..6f554f62967 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
@@ -133,7 +133,7 @@ mount -o rw,loop,noatime,nodiratime /run/media/$1/$2 
/rootmnt
 echo "Copying rootfs files..."
 cp -a /rootmnt/* /ssd
 
-touch /ssd/etc/masterimage
+touch /ssd/etc/goldenimage
 
 if [ -d /ssd/etc/ ] ; then
 # We dont want udev to mount our root device while we're booting...
diff --git a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh 
b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
index ac621605287..df3a7767319 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-testfs.sh
@@ -158,7 +158,7 @@ mount -o rw,loop,noatime,nodiratime /run/media/$1/$2 
/src_root
 echo "Copying rootfs files..."
 cp -a /src_root/* /tgt_root
 
-touch /tgt_root/etc/masterimage
+touch /tgt_root/etc/goldenimage
 
 if [ -d /tgt_root/etc/ ] ; then
 echo "$bootfs  /bootext3   defaults
  1  2" >> /tgt_root/etc/fstab
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159244): 
https://lists.openembedded.org/g/openembedded-core/message/159244
Mute This Topic: https://lists.openembedded.org/mt/87542274/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/4] oeqa: rename masterimage into goldenimage

2021-12-06 Thread Quentin Schulz
Golden image has a more explicit meaning than masterimage and is not an
issue wrt inclusivity.

Signed-off-by: Quentin Schulz 
---
 .../{masterimage.py => goldenimage.py}| 32 +--
 1 file changed, 16 insertions(+), 16 deletions(-)
 rename meta/lib/oeqa/controllers/{masterimage.py => goldenimage.py} (91%)

diff --git a/meta/lib/oeqa/controllers/masterimage.py 
b/meta/lib/oeqa/controllers/goldenimage.py
similarity index 91%
rename from meta/lib/oeqa/controllers/masterimage.py
rename to meta/lib/oeqa/controllers/goldenimage.py
index feb30366323..fb1ac7a53a0 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/goldenimage.py
@@ -24,12 +24,12 @@ from oeqa.utils import CommandError
 
 from abc import ABCMeta, abstractmethod
 
-class MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, 
metaclass=ABCMeta):
+class GoldenImageHardwareTarget(oeqa.targetcontrol.BaseTarget, 
metaclass=ABCMeta):
 
 supported_image_fstypes = ['tar.gz', 'tar.bz2']
 
 def __init__(self, d):
-super(MasterImageHardwareTarget, self).__init__(d)
+super(GoldenImageHardwareTarget, self).__init__(d)
 
 # target ip
 addr = d.getVar("TEST_TARGET_IP") or bb.fatal('Please set 
TEST_TARGET_IP with the IP address of the machine you want to run the tests 
on.')
@@ -61,8 +61,8 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 if not os.path.isfile(self.kernel):
 bb.fatal("No kernel found. Expected path: %s" % self.kernel)
 
-# master ssh connection
-self.master = None
+# golden ssh connection
+self.golden = None
 # if the user knows what they are doing, then by all means...
 self.user_cmds = d.getVar("TEST_DEPLOY_CMDS")
 self.deploy_cmds = None
@@ -119,9 +119,9 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 
 def deploy(self):
 # base class just sets the ssh log file for us
-super(MasterImageHardwareTarget, self).deploy()
-self.master = sshcontrol.SSHControl(ip=self.ip, logfile=self.sshlog, 
timeout=600, port=self.port)
-status, output = self.master.run("cat /etc/goldenimage")
+super(GoldenImageHardwareTarget, self).deploy()
+self.golden = sshcontrol.SSHControl(ip=self.ip, logfile=self.sshlog, 
timeout=600, port=self.port)
+status, output = self.golden.run("cat /etc/goldenimage")
 if status != 0:
 # We're not booted into the golden image, so try rebooting
 bb.plain("%s - booting into the golden image" % self.pn)
@@ -129,7 +129,7 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 self._wait_until_booted()
 
 bb.plain("%s - deploying image on target" % self.pn)
-status, output = self.master.run("cat /etc/goldenimage")
+status, output = self.golden.run("cat /etc/goldenimage")
 if status != 0:
 bb.fatal("No ssh connectivity or target isn't running a golden 
image.\n%s" % output)
 if self.user_cmds:
@@ -156,10 +156,10 @@ class 
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 
 def stop(self):
 bb.plain("%s - reboot/powercycle target" % self.pn)
-self.power_cycle(self.master)
+self.power_cycle(self.golden)
 
 
-class SystemdbootTarget(MasterImageHardwareTarget):
+class SystemdbootTarget(GoldenImageHardwareTarget):
 
 def __init__(self, d):
 super(SystemdbootTarget, self).__init__(d)
@@ -184,16 +184,16 @@ class SystemdbootTarget(MasterImageHardwareTarget):
 
 def _deploy(self):
 # make sure these aren't mounted
-self.master.run("umount /boot; umount /mnt/testrootfs; umount 
/sys/firmware/efi/efivars;")
+self.golden.run("umount /boot; umount /mnt/testrootfs; umount 
/sys/firmware/efi/efivars;")
 # from now on, every deploy cmd should return 0
 # else an exception will be thrown by sshcontrol
-self.master.ignore_status = False
-self.master.copy_to(self.rootfs, "~/test-rootfs." + self.image_fstype)
-self.master.copy_to(self.kernel, "~/test-kernel")
+self.golden.ignore_status = False
+self.golden.copy_to(self.rootfs, "~/test-rootfs." + self.image_fstype)
+self.golden.copy_to(self.kernel, "~/test-kernel")
 for cmd in self.deploy_cmds:
-self.master.run(cmd)
+self.golden.run(cmd)
 
 def _start(self, params=None):
-self.power_cycle(self.master)
+self.power_cycle(self.golden)
 # there are better ways than a timeout but this should work for now
 time.sleep(120)
-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159245): 
https://lists.openembedded.org/g/openembedded-core/message/159245
Mute This Topic: https://lists.openembedded.org/mt/87542275/21656

[OE-core] [PATCH] vala: upgrade 0.54.3 -> 0.54.4

2021-12-06 Thread wangmy
Changelog:
===
 * Various improvements and bug fixes:
  - codegen:
+ Use CCodeConstant for member access of constant symbol
+ Emit constants without initializer list in defines section [#440]
+ Add and use CCodeConstantIdentifier for accessing constants
+ Check required length of enum type name for GType support
+ Add missing check while overriding virtual async interface methods [#852]
+ Drop inconsistent space for ObjectType parameters
+ Accept CCode.type attribute on parameters [#876]
+ Fix CCodeUnaryExpression.write() for PREFIX_INCREMENT/PREFIX_DECREMENT
  - vala:
+ Improve error message for invalid handler of dynamic signal
+ Using SignalHandler.disconnect() is required for dynamic signals
+ Check for unavailable value-type of variable initializer [#1253]
+ Add [Profile] as known attribute for methods
+ Report error on missing gio-2.0 package for async constructors
+ Fix signals with generic return
+ parser: Split out Parser.parse_switch_section_statement()
+ parser: Better handling of misplaced switch sections [#1246]
  - genie:
+ Amend text of indent and dedent for error messages [#497]
+ Accept INTERR token before type arguments when parsing type [#1245]
+ Properly handle plain "get" or "set" property accessors [#1248]
+ "exception" is the expected string for TokenType.ERRORDOMAIN
+ Accept accessibility/async modifiers on "construct" creation methods 
[#1235]
  - girparser: Accept "sealed" for transformed records and compact classes
  - gtkmodule: Improve error message for invalid signal element in ui-file
  - build: Add "test-update" which passed UPDATE_EXPECTED=1 to refresh 
c-expected
  - tests: Rename colliding test cases to avoid conflicts

 * Bindings:
  - alsa: Add more API and fix a few things
  - gnome-desktop-3.0: Some parameter fixes
  - gstreamer: Cherry-pick bindings fixes from 0.56
  - gstreamer-base-1.0: Some parameter fixes [#1255]
  - gtk4: Update to 4.5.0~cd9b7307
  - pango: Cherry-pick bindings fixes from 0.56

Signed-off-by: Wang Mingyu 
---
 meta/recipes-devtools/vala/{vala_0.54.3.bb => vala_0.54.4.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/vala/{vala_0.54.3.bb => vala_0.54.4.bb} (50%)

diff --git a/meta/recipes-devtools/vala/vala_0.54.3.bb 
b/meta/recipes-devtools/vala/vala_0.54.4.bb
similarity index 50%
rename from meta/recipes-devtools/vala/vala_0.54.3.bb
rename to meta/recipes-devtools/vala/vala_0.54.4.bb
index d3390b2ea8..695f64e336 100644
--- a/meta/recipes-devtools/vala/vala_0.54.3.bb
+++ b/meta/recipes-devtools/vala/vala_0.54.4.bb
@@ -2,4 +2,4 @@ require ${BPN}.inc
 
 SRC_URI += " file://0001-vapigen.m4-use-PKG_CONFIG_SYSROOT_DIR.patch"
 
-SRC_URI[sha256sum] = 
"ed1d5fe4cbc0cd2845d0de4f1ffefb15afb06892d230c7cca695781672e8fb60"
+SRC_URI[sha256sum] = 
"6051270a2fc30de023c88562566f2f6043e67beb4da4b799c14cdf12048eb40c"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159239): 
https://lists.openembedded.org/g/openembedded-core/message/159239
Mute This Topic: https://lists.openembedded.org/mt/87541915/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] xauth: upgrade 1.1 -> 1.1.1

2021-12-06 Thread wangmy
Signed-off-by: Wang Mingyu 
---
 .../recipes-graphics/xorg-app/{xauth_1.1.bb => xauth_1.1.1.bb} | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-graphics/xorg-app/{xauth_1.1.bb => xauth_1.1.1.bb} (75%)

diff --git a/meta/recipes-graphics/xorg-app/xauth_1.1.bb 
b/meta/recipes-graphics/xorg-app/xauth_1.1.1.bb
similarity index 75%
rename from meta/recipes-graphics/xorg-app/xauth_1.1.bb
rename to meta/recipes-graphics/xorg-app/xauth_1.1.1.bb
index 24ad9606ec..48259a69ff 100644
--- a/meta/recipes-graphics/xorg-app/xauth_1.1.bb
+++ b/meta/recipes-graphics/xorg-app/xauth_1.1.1.bb
@@ -8,8 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=5ec74dd7ea4d10c4715a7c44f159a40b"
 DEPENDS += "libxau libxext libxmu"
 PE = "1"
 
-SRC_URI[md5sum] = "e50587c1bb832aafd1a19d91a0890a0b"
-SRC_URI[sha256sum] = 
"6d1dd1b79dd185107c5b0fdd22d1d791ad749ad6e288d0cdf80964c4ffa7530c"
+SRC_URI[sha256sum] = 
"164ea0a29137b284a47b886ef2affcb0a74733bf3aad04f9b106b1a6c82ebd92"
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)}"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159241): 
https://lists.openembedded.org/g/openembedded-core/message/159241
Mute This Topic: https://lists.openembedded.org/mt/87541917/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] sysstat: upgrade 12.4.3 -> 12.4.4

2021-12-06 Thread wangmy
Changelog:
===
* iostat: Always display persistent names with option -j.
* iostat: Fix how device mapper names are taken into account when
  entered on the command line.
* mpstat: Don't display offline CPU.
* mpstat: Fix values displayed when an offline CPU goes back online.
* mpstat: Fix untrusted loop bound.
* mpstat: Update non regression tests.
* Use 'grep -E' instead of deprecated 'egrep'.
* Spelling and grammar fixes.
* Update man pages with correct spelling of "JavaScript".

Signed-off-by: Wang Mingyu 
---
 .../sysstat/{sysstat_12.4.3.bb => sysstat_12.4.4.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/sysstat/{sysstat_12.4.3.bb => sysstat_12.4.4.bb} 
(65%)

diff --git a/meta/recipes-extended/sysstat/sysstat_12.4.3.bb 
b/meta/recipes-extended/sysstat/sysstat_12.4.4.bb
similarity index 65%
rename from meta/recipes-extended/sysstat/sysstat_12.4.3.bb
rename to meta/recipes-extended/sysstat/sysstat_12.4.4.bb
index 5a27de439f..d635650a1f 100644
--- a/meta/recipes-extended/sysstat/sysstat_12.4.3.bb
+++ b/meta/recipes-extended/sysstat/sysstat_12.4.4.bb
@@ -4,4 +4,4 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a23a74b3f4caf9616230789d94217acb"
 
 SRC_URI += "file://0001-configure.in-remove-check-for-chkconfig.patch"
 
-SRC_URI[sha256sum] = 
"ae432431f45aacbcabacfbbe129e2505e215cafa9ce996d7550c6091a46f0bfd"
+SRC_URI[sha256sum] = 
"9512e7479e04f92e251c5c6b4bd94b8f643d212bd0e986a8ea4d147a6e943d24"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159240): 
https://lists.openembedded.org/g/openembedded-core/message/159240
Mute This Topic: https://lists.openembedded.org/mt/87541916/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] pango: upgrade 1.48.10 -> 1.50.0

2021-12-06 Thread wangmy
Signed-off-by: Wang Mingyu 
---
 .../pango/{pango_1.48.10.bb => pango_1.50.0.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/pango/{pango_1.48.10.bb => pango_1.50.0.bb} (94%)

diff --git a/meta/recipes-graphics/pango/pango_1.48.10.bb 
b/meta/recipes-graphics/pango/pango_1.50.0.bb
similarity index 94%
rename from meta/recipes-graphics/pango/pango_1.48.10.bb
rename to meta/recipes-graphics/pango/pango_1.50.0.bb
index 40df7042e6..db17158d20 100644
--- a/meta/recipes-graphics/pango/pango_1.48.10.bb
+++ b/meta/recipes-graphics/pango/pango_1.50.0.bb
@@ -20,7 +20,7 @@ GIR_MESON_DISABLE_FLAG = "disabled"
 
 SRC_URI += "file://run-ptest"
 
-SRC_URI[archive.sha256sum] = 
"21e1f5798bcdfda75eabc4280514b0896ab56f656d4e7e66030b9a2535ecdc98"
+SRC_URI[archive.sha256sum] = 
"dba8b62ddf86e10f73f93c3d2256b73238b2bcaf87037ca229b40bdc040eb3f3"
 
 DEPENDS = "glib-2.0 glib-2.0-native fontconfig freetype virtual/libiconv cairo 
harfbuzz fribidi"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159238): 
https://lists.openembedded.org/g/openembedded-core/message/159238
Mute This Topic: https://lists.openembedded.org/mt/87541909/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] mesa: upgrade 21.3.0 -> 21.3.1

2021-12-06 Thread zhengruoqin
Changelog from 21.3.0
=
Bug fixes:
GPU Crash in Yuzu 6600xt 5.15
[spirv-fuzz] lower_trivial_continues_block: Assertion '!first_instr || 
instr_is_continue(first_instr)' failed.
[RADV] Crash in Metro Exodus in Caspain chapter and Sam???s Story
NIR validation failed after nir_copy_prop
lima: Corrupted Android-12 UI on Allwinner A64
RADV/ACO: Rendering glitches in Forza Horizon 5 windshields
dEQP-GLES31.*imulextended* compiling fp64 glsl 4.00 shader

Changes:
ir3/ra: Consider reg file size when swapping killed sources
ir3/lower_pcopy: Fix shr.b illegal copy lowering
ir3/lower_pcopy: Fix bug with ???illegal??? copies and swaps
docs: update sha256sum for 21.3.0
.pick_status.json: Update to 1ba231fb75be5bffd806cbd09ac285d1f8f15e3d
ci: temporarily disable lima CI
broadcom/compiler: don???t allow RF writes from signals after thrend
broadcom/compiler: fix scoreboard locking checks
broadcom/compiler: don???t move ldvary earlier if current instruction has ldunif
glsl/nir: Don???t build soft float64 when it cannot be used
intel/nir: also allow unknown format for getting the size of a storage image
iris: Make a helper function for cross-batch dependency flushing
iris: Check for cross-batch flushing whenever a buffer is newly written.
iris: Tidy code in iris_use_pinned_bo a bit
anv: don???t try to close fd = -1
intel/fs: fix shader call lowering pass
util/u_trace: refcount payloads
android: define cpp_rtti=false because libLLVM is built w/o RTTI (v2)
zink: block suballocator caching for swapchain/dmabuf images
zink: set suballocator bo size to aligned allocation size
zink: stop using VK_IMAGE_LAYOUT_PREINITIALIZED for dmabuf
zink: always set matching resource export type for dmabuf creation
zink: fix memory availability reporting
zink: fail context creation more gracefully
nir: Fix read depth for predecessors
glx/dri3: fix glXQueryContext does not return GLX_RENDER_TYPE value
aco/spill: use spills_entry instead of spills_exit to kill linear VGPRs
spirv: run nir_copy_prop before nir_rematerialize_derefs_in_use_blocks_impl
nir/dce: fix DCE of loops with a halt or return instruction in the pre-header
aco: don???t create DPP instructions with SGPR operands
android.mk: Add missing variables to the make target
radv: disable HTILE for D32S8 format and mipmaps on GFX10
radv: fix emitting VBO when vertex input dynamic state is used
radv: add a workaround to fix a segfault with Metro Exodus (Linux native)
radv: fix resetting the entire vertex input dynamic state
svga: fix bitwise/logical and mixup
lima: disasm: use last argument as a filename

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-graphics/mesa/mesa.inc   | 2 +-
 meta/recipes-graphics/mesa/{mesa_21.3.0.bb => mesa_21.3.1.bb} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/mesa/{mesa_21.3.0.bb => mesa_21.3.1.bb} (100%)

diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index ed60d98250..e99ec6961b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -21,7 +21,7 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
"

-SRC_URI[sha256sum] = 
"a2753c09deef0ba14d35ae8a2ceff3fe5cd13698928c7bb62c2ec8736eb09ce1"
+SRC_URI[sha256sum] = 
"2b0dc2540cb192525741d00f706dbc4586349185dafc65729c7fda0800cc474d"

 UPSTREAM_CHECK_GITTAGREGEX = "mesa-(?P\d+(\.\d+)+)"

diff --git a/meta/recipes-graphics/mesa/mesa_21.3.0.bb 
b/meta/recipes-graphics/mesa/mesa_21.3.1.bb
similarity index 100%
rename from meta/recipes-graphics/mesa/mesa_21.3.0.bb
rename to meta/recipes-graphics/mesa/mesa_21.3.1.bb
--
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159237): 
https://lists.openembedded.org/g/openembedded-core/message/159237
Mute This Topic: https://lists.openembedded.org/mt/87541536/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] opkg-utils: upgrade 0.4.5 -> 0.5.0

2021-12-06 Thread zhengruoqin
Signed-off-by: Zheng Ruoqin 
---
 .../opkg-utils/{opkg-utils_0.4.5.bb => opkg-utils_0.5.0.bb}| 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-devtools/opkg-utils/{opkg-utils_0.4.5.bb => 
opkg-utils_0.5.0.bb} (94%)

diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
similarity index 94%
rename from meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb
rename to meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
index a2bcc7f661..21678a27b2 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.5.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
@@ -12,8 +12,7 @@ SRC_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV
"
 UPSTREAM_CHECK_URI = 
"http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/refs/;
 
-SRC_URI[md5sum] = "025b19744e5c7fc1c8380e17df1fcc64"
-SRC_URI[sha256sum] = 
"528635e674addea5c2b3a3268404ad04a952c4f410d17c3d754f5dd5529770c9"
+SRC_URI[sha256sum] = 
"55733c0f8ffde2bb4f9593cfd66a1f68e6a2f814e8e62f6fd78472911c818c32"
 
 TARGET_CC_ARCH += "${LDFLAGS}"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159236): 
https://lists.openembedded.org/g/openembedded-core/message/159236
Mute This Topic: https://lists.openembedded.org/mt/87541534/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] lighttpd: upgrade 1.4.61 -> 1.4.63

2021-12-06 Thread zhengruoqin
refresh 0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch

Changelog from 1.4.61:

Important changes:
support pcre2; HTTP Digest auth userhash

bugfixes:
[mod_alias] fix use-after-free bug (fixes #3114)
[core] clean up fdlog_st and log_error_st decls
[core] 'struct log_error_st'->'log_error_st'
[core] remove redundant asserts
[core] explicitly include sys/cdefs.h
[tests] t/test_mod_ssi
[core] fdevent_socket_nb_cloexec_init()
[core] fdevent_impl.c separate from fdevent.c
[core] merge fdevent impls into fdevent_impl.c
[core] fdevent_fdnode.c separate from fdevent.c
[core] close backend socket fds more quickly
[core] use TCP_CORK w/ TLS if cq length > 16k
[core] warn if dynamic modules before mod_auth
[mod_cgi] check fd-to-cgi not -1 before close
[core] libev EV_ERROR conflicts with kqueue
[tests] disable test_mod_ssi in cmake (temporary)
[tests] disable test_mod_ssi in cmake (temporary)
[tests] reenable test_mod_ssi in cmake
[core] run plugin cleanup hooks in reverse
[core] fix removal of server.pid-file when testing (fixes #3115)
[doc] improve sample configs
[doc] expand vhosts.template
[doc] improve sample configs
[core] use ck_assert() in vector.[ch]
[tests] mod_ssi tests moved to src/t/test_mod_ssi
[mod_ssi] 0-init ssi_val_t in ssi_ctx_t
[mod_ssi] fix ancient bugs; replace cond parser
[mod_ssi] remove mod_ssi parser generator file
[mod_ssi] merge mod_ssi_expr.c into mod_ssi.c
[core] uint_fast32_t tweaks
[core] better asm for binary num to ascii string
[tests] t/test_mod now runs all t/test_mod_*.c
[tests] t/test_mod_alias.c
[tests] remove unused mod from tests/lighttpd.conf
[mod_evasive] smaller funcs for testing
[tests] t/test_mod_evasive.c
[mod_evasive] update comment to add references
[tests] combine tests into test_common.c
[core] get_http_method_key() tweak
[mod_dirlisting] check for disabled cache at start
[core] buffer_append_string_encoded_json()
[mod_dirlisting] (experimental) json (disabled)
[tests] t/test_mod needs -ldl on Debian
[core] save config regex captures only if used
[core] save pcre result state in config_pcre_match
[core] use stack w/ pcre_exec unless save captures
[core] extend pcre_keyvalue_ctx to pass more state
[core] pcre2 support (???with-pcre2)
[core] allocate one fewer cond_match_t, if needed
[core] allocate pcre output vector on demand
[build] configure.ac with AC_PROG_CC_C99 (fixes #3116)
[build] CI builds now use pcre2 (upgrade pcre)
[core] fix compiler warning in 32-bit build
[build] fix CMake pcre2 detection
[mod_auth] RFC7616 HTTP Digest username* userhash
[mod_dirlisting] fix bug not showing HEADER.txt
[tests] t/test_mod_ssi adjust to follow symlinks
[mod_auth] quiet coverity warning
[doc] refresh/update dependency lists in doc
[core] fix crash when using lighttpd -1 with pipes (fixes #3117)
[core] import xxHash v0.8.1
[core] isolate use of sys/filio.h
[core] fix reqpool mem corruption in 1.4.62 (fixes #3118)

Signed-off-by: Zheng Ruoqin 
---
 ...or-pcre-dependency-instead-of-config.patch | 25 ++-
 ...{lighttpd_1.4.61.bb => lighttpd_1.4.63.bb} |  2 +-
 2 files changed, 14 insertions(+), 13 deletions(-)
 rename meta/recipes-extended/lighttpd/{lighttpd_1.4.61.bb => 
lighttpd_1.4.63.bb} (97%)

diff --git 
a/meta/recipes-extended/lighttpd/lighttpd/0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
 
b/meta/recipes-extended/lighttpd/lighttpd/0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
index f17bdce2c0..b60102ecc1 100644
--- 
a/meta/recipes-extended/lighttpd/lighttpd/0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
+++ 
b/meta/recipes-extended/lighttpd/lighttpd/0001-Use-pkg-config-for-pcre-dependency-instead-of-config.patch
@@ -6,28 +6,29 @@ Subject: [PATCH] Use pkg-config for pcre dependency instead 
of -config script.
 RP 2014/5/22
 Upstream-Status: Pending
 Signed-off-by: Alexander Kanavin 
+
 ---
  configure.ac | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

 diff --git a/configure.ac b/configure.ac
-index 5383cec..c29a902 100644
+index 806347b..81a7997 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -651,10 +651,18 @@ AC_ARG_WITH([pcre],
+@@ -913,10 +913,18 @@ AC_ARG_WITH([pcre2],
  )
- AC_MSG_RESULT([$WITH_PCRE])
+ AC_MSG_RESULT([$WITH_PCRE2])

--if test "$WITH_PCRE" != no; then
--  if test "$WITH_PCRE" != yes; then
--PCRE_LIB="-L$WITH_PCRE/lib -lpcre"
+-if test "$WITH_PCRE2" != no; then
+-  if test "$WITH_PCRE2" != yes; then
+-PCRE_LIB="-L$WITH_PCRE2/lib -lpcre2-8"
 -CPPFLAGS="$CPPFLAGS -I$WITH_PCRE/include"
 +if test "$WITH_PCRE" != "no"; then
 +  PKG_CHECK_MODULES(PCREPKG, [libpcre], [
-+  PCRE_LIB=${PCREPKG_LIBS}
-+  CPPFLAGS="$CPPFLAGS ${PCREPKG_CFLAGS}"
++   PCRE_LIB=${PCREPKG_LIBS}
++   CPPFLAGS="$CPPFLAGS ${PCREPKG_CFLAGS}"
 +  ], [
-+  AC_MSG_ERROR([pcre pkgconfig 

[OE-core] [PATCH] opkg: upgrade 0.4.5 -> 0.5.0

2021-12-06 Thread zhengruoqin
Remove unsupported openssl and option --disable-pathfinder

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)
 rename meta/recipes-devtools/opkg/{opkg_0.4.5.bb => opkg_0.5.0.bb} (92%)

diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb 
b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
similarity index 92%
rename from meta/recipes-devtools/opkg/opkg_0.4.5.bb
rename to meta/recipes-devtools/opkg/opkg_0.5.0.bb
index 1fe6ed5ecb..bc2ee9728b 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.5.0.bb
@@ -18,8 +18,7 @@ SRC_URI = 
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://run-ptest \
 "
 
-SRC_URI[md5sum] = "5dc41ad37d88803b5e0f456a9c5a0811"
-SRC_URI[sha256sum] = 
"a1214a75fa34fb9228db8da47308e0e711b1c93fd8938cf164c10fd28eb50f1e"
+SRC_URI[sha256sum] = 
"559c3e1b893abaa1dd473ce3a9a5f7dd3f60ceb6cd14caaef76ddf0f7721ad1c"
 
 # This needs to be before ptest inherit, otherwise all ptest files end packaged
 # in libopkg package if OPKGLIBDIR == libdir, because default
@@ -39,11 +38,9 @@ PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
 "
 PACKAGECONFIG[curl] = "--enable-curl,--disable-curl,curl"
 PACKAGECONFIG[ssl-curl] = "--enable-ssl-curl,--disable-ssl-curl,curl openssl"
-PACKAGECONFIG[openssl] = "--enable-openssl,--disable-openssl,openssl"
 PACKAGECONFIG[sha256] = "--enable-sha256,--disable-sha256"
 PACKAGECONFIG[libsolv] = "--with-libsolv,--without-libsolv,libsolv"
 
-EXTRA_OECONF += " --disable-pathfinder"
 EXTRA_OECONF:class-native = 
"--localstatedir=/${@os.path.relpath('${localstatedir}', 
'${STAGING_DIR_NATIVE}')} --sysconfdir=/${@os.path.relpath('${sysconfdir}', 
'${STAGING_DIR_NATIVE}')}"
 
 do_install:append () {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159234): 
https://lists.openembedded.org/g/openembedded-core/message/159234
Mute This Topic: https://lists.openembedded.org/mt/87541521/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] libsdl2: upgrade 2.0.16 -> 2.0.18

2021-12-06 Thread zhengruoqin
Remove unsupported option "--enable-sdl-dlopen".

Changelog:
===

General:

The SDL wiki documentation and development headers are automatically kept in 
sync
Each function has information about in which version of SDL it was introduced
SDL-specific CMake options are now prefixed with 'SDL_'. Be sure to update your 
CMake build scripts accordingly!
Added the hint SDL_HINT_APP_NAME to let SDL know the name of your application 
for various places it might show up in system information
Added SDL_RenderGeometry() and SDL_RenderGeometryRaw() to allow rendering of 
arbitrary shapes using the SDL 2D render API
Added SDL_SetTextureUserData() and SDL_GetTextureUserData() to associate 
application data with an SDL texture
Added SDL_RenderWindowToLogical() and SDL_RenderLogicalToWindow() to convert 
between window coordinates and logical render coordinates
Added SDL_RenderSetVSync() to change whether a renderer present is synchronized 
with vblank at runtime
Added SDL_PremultiplyAlpha() to premultiply alpha on a block of 
SDL_PIXELFORMAT_ARGB pixels
Added a window event SDL_WINDOWEVENT_DISPLAY_CHANGED which is sent when a 
window changes what display it's centered on
Added SDL_GetWindowICCProfile() to query a window's ICC profile, and a window 
event SDL_WINDOWEVENT_ICCPROF_CHANGED that is sent when it changes
Added the hint SDL_HINT_VIDEO_EGL_ALLOW_TRANSPARENCY to allow EGL windows to be 
transparent instead of opaque
SDL_WaitEvent() has been redesigned to use less CPU in most cases
Added SDL_SetWindowMouseRect() and SDL_GetWindowMouseRect() to confine the 
mouse cursor to an area of a window
You can now read precise mouse wheel motion using 'preciseX' and 'preciseY' 
event fields
Added SDL_GameControllerHasRumble() and SDL_GameControllerHasRumbleTriggers() 
to query whether a game controller supports rumble
Added SDL_JoystickHasRumble() and SDL_JoystickHasRumbleTriggers() to query 
whether a joystick supports rumble
SDL's hidapi implementation is now available as a public API in SDL_hidapi.h
Windows:

Improved relative mouse motion over Windows Remote Desktop
Added the hint SDL_HINT_IME_SHOW_UI to show native UI components instead of 
hiding them (defaults off)
Windows/UWP:

WGI is used instead of XInput for better controller support in UWP apps
Linux:

Added the hint SDL_HINT_SCREENSAVER_INHIBIT_ACTIVITY_NAME to set the activity 
that's displayed by the system when the screensaver is disabled
Added the hint SDL_HINT_LINUX_JOYSTICK_CLASSIC to control whether 
/dev/input/js* or /dev/input/event* are used as joystick devices
Added the hint SDL_HINT_JOYSTICK_DEVICE to allow the user to specify devices 
that will be opened in addition to the normal joystick detection
Added SDL_LinuxSetThreadPriorityAndPolicy() for more control over a thread 
priority on Linux
Android:

Added support for audio output and capture using AAudio on Android 8.1 and newer
Steam Controller support is disabled by default, and can be enabled by setting 
the hint SDL_HINT_JOYSTICK_HIDAPI_STEAM to "1" before calling SDL_Init()
Apple Arcade:

Added SDL_GameControllerGetAppleSFSymbolsNameForButton() and 
SDL_GameControllerGetAppleSFSymbolsNameForAxis() to support Apple Arcade titles
iOS:

Added documentation that the UIApplicationSupportsIndirectInputEvents key must 
be set to true in your application's Info.plist in order to get real Bluetooth 
mouse events.
Steam Controller support is disabled by default, and can be enabled by setting 
the hint SDL_HINT_JOYSTICK_HIDAPI_STEAM to "1" before calling SDL_Init()

Signed-off-by: Zheng Ruoqin 
---
 .../libsdl2/{libsdl2_2.0.16.bb => libsdl2_2.0.18.bb}   | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
 rename meta/recipes-graphics/libsdl2/{libsdl2_2.0.16.bb => libsdl2_2.0.18.bb} 
(96%)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.16.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.0.18.bb
similarity index 96%
rename from meta/recipes-graphics/libsdl2/libsdl2_2.0.16.bb
rename to meta/recipes-graphics/libsdl2/libsdl2_2.0.18.bb
index bd7dea275e..5e645b443c 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.16.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.18.bb
@@ -22,7 +22,7 @@ SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz \
 
 S = "${WORKDIR}/SDL2-${PV}"
 
-SRC_URI[sha256sum] = 
"65be9ff6004034b5b2ce9927b5a4db1814930f169c4b2dae0a1e4697075f287b"
+SRC_URI[sha256sum] = 
"94d40cd73dbfa10bb6eadfbc28f355992bb2d6ef6761ad9d4074eff95ee5711c"
 
 inherit autotools lib_package binconfig-disabled pkgconfig
 
@@ -35,7 +35,6 @@ EXTRA_OECONF = "--disable-oss --disable-esd --disable-arts \
 --disable-video-dummy \
 --disable-video-rpi \
 --enable-pthreads \
---enable-sdl-dlopen \
 --disable-rpath \
 --disable-sndio \
 --disable-fcitx --disable-ibus \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

[OE-core] [RFC PATCH] vim: upgrade to 8.2 patch 3752

2021-12-06 Thread Ross Burton
There's a fairly constant flow of CVEs being fixed in Vim, which are
getting increasing non-trivial to backport.

Instead of trying to backport (and potentially introduce more bugs), or
just ignoring them entirely, upgrade vim to the latest patch in the hope
that vim 8.3 will be released before we release Kirkstone.

Signed-off-by: Ross Burton 
---
 ...1-reading-character-past-end-of-line.patch |  62 --
 ...28-using-freed-memory-when-replacing.patch |  83 ---
 ...eading-uninitialized-memory-when-giv.patch |  63 --
 ...rash-when-using-CTRL-W-f-without-fin.patch |  92 
 ...llegal-memory-access-if-buffer-name-.patch |  86 
 ...ml_get-error-after-search-with-range.patch |  72 --
 ...nvalid-memory-access-when-scrolling-.patch |  97 
 .../vim/files/CVE-2021-3778.patch |  61 --
 ...1e135a16091c93f6f5f7525a5c58fb7ca9f9.patch | 207 --
 meta/recipes-support/vim/vim.inc  |  15 +-
 10 files changed, 4 insertions(+), 834 deletions(-)
 delete mode 100644 
meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
 delete mode 100644 
meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
 delete mode 100644 
meta/recipes-support/vim/files/0002-patch-8.2.3582-reading-uninitialized-memory-when-giv.patch
 delete mode 100644 
meta/recipes-support/vim/files/0002-patch-8.2.3611-crash-when-using-CTRL-W-f-without-fin.patch
 delete mode 100644 
meta/recipes-support/vim/files/0003-patch-8.2.3487-illegal-memory-access-if-buffer-name-.patch
 delete mode 100644 
meta/recipes-support/vim/files/0004-patch-8.2.3489-ml_get-error-after-search-with-range.patch
 delete mode 100644 
meta/recipes-support/vim/files/0005-patch-8.2.3564-invalid-memory-access-when-scrolling-.patch
 delete mode 100644 meta/recipes-support/vim/files/CVE-2021-3778.patch
 delete mode 100644 
meta/recipes-support/vim/files/b7081e135a16091c93f6f5f7525a5c58fb7ca9f9.patch

diff --git 
a/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
 
b/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
deleted file mode 100644
index 28c61cd782..00
--- 
a/meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-CVE: CVE-2021-3927
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 93b427c6e729260d0700c3b2804ec153bc8284fa Mon Sep 17 00:00:00 2001
-From: Bram Moolenaar 
-Date: Thu, 4 Nov 2021 15:10:11 +
-Subject: [PATCH] patch 8.2.3581: reading character past end of line
-
-Problem:Reading character past end of line.
-Solution:   Correct the cursor column.

- src/ex_docmd.c   |  1 +
- src/testdir/test_put.vim | 12 
- src/version.c|  2 ++
- 3 files changed, 15 insertions(+)
-
-diff --git a/src/ex_docmd.c b/src/ex_docmd.c
-index fde726477..59e245bee 100644
 a/src/ex_docmd.c
-+++ b/src/ex_docmd.c
-@@ -6905,6 +6905,7 @@ ex_put(exarg_T *eap)
-   eap->forceit = TRUE;
- }
- curwin->w_cursor.lnum = eap->line2;
-+check_cursor_col();
- do_put(eap->regname, eap->forceit ? BACKWARD : FORWARD, 1L,
-  PUT_LINE|PUT_CURSLINE);
- }
-diff --git a/src/testdir/test_put.vim b/src/testdir/test_put.vim
-index 225ebd1f3..922e5b269 100644
 a/src/testdir/test_put.vim
-+++ b/src/testdir/test_put.vim
-@@ -113,3 +113,15 @@ func Test_put_p_indent_visual()
-   call assert_equal('select that text', getline(2))
-   bwipe!
- endfunc
-+
-+func Test_put_above_first_line()
-+  new
-+  let @" = 'text'
-+  silent! normal 0o00
-+  0put
-+  call assert_equal('text', getline(1))
-+  bwipe!
-+endfunc
-+
-+
-+" vim: shiftwidth=2 sts=2 expandtab
-diff --git a/src/version.c b/src/version.c
-index a9e8be0e7..df4ec9a47 100644
 a/src/version.c
-+++ b/src/version.c
-@@ -742,6 +742,8 @@ static char *(features[]) =
- 
- static int included_patches[] =
- {   /* Add new patch number below this line */
-+/**/
-+3581,
- /**/
- 3564,
- /**/
diff --git 
a/meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
 
b/meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
deleted file mode 100644
index ecfae0301e..00
--- 
a/meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
+++ /dev/null
@@ -1,83 +0,0 @@
-CVE: CVE-2021-3796
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 1160e5f74b229336502fc376416f21108d36cfc2 Mon Sep 17 00:00:00 2001
-From: Bram Moolenaar 
-Date: Sat, 11 Sep 2021 21:14:20 +0200
-Subject: [PATCH] patch 8.2.3428: using freed memory when replacing
-
-Problem:Using freed memory when replacing. (Dhiraj Mishra)
-Solution:   Get the line pointer after calling ins_copychar().

- src/normal.c  | 10 +++---
- 

Re: [OE-core] [RFC PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 12:37 +0100, Alexander Kanavin wrote:
> On Mon, 6 Dec 2021 at 12:29, Richard Purdie
>  wrote:
> > Ross has a point here. If we go this route we'll just push people to mark
> > patches as Inappropriate instead. People will know Pending isn't acceptable
> > so
> > they'll just use Inappropriate and we'll lose the ability to see things
> > which
> > may be discussed with upstream and those which realistically never can.
> > We'll
> > have to review patches marked as Inappropriate even more carefully.
> 
> Right, but what can we do then to make it more clear that new Pending patches
> aren't welcome? I don't want them to keep slipping through into master, and I
> certainly do not want to argue with what is essentially laziness on the part
> of the submitter. I guess a mailing list nag-bot that spots those submissions
> could help here.

First, we should ask if we have a problem. Ross had some metrics/graphs which he
was kind enough to find and update:

http://www.burtonini.com/yoctometrics/

Whilst there are blips, it does clearly show that our number of patches in OE-
Core has steadily decreased over the last 5 years (~1900 -> 1266). Also, the
number in pending status had dropped from 816 to ~490 recently and thanks to the
recent push, 374 (and likely less again when more merges).

I have pushed occasionally to get things cleaned up and we are slowly winning as
the trend is downwards. I believe I have pushed back on Pending patches a bit
more over time and I think it is working. As we lower the numbers, it becomes
harder for people to justify adding them too.

Reproducibility did add to the patch backlog and we sometimes trade features for
patch overhead, it is all an inexact science but I think the overall picture is
promising.

We've also some known problem areas. I've long felt guilty about the state of
the libtool and gcc patchsets. Those are in a bit better state now and I know
many other areas are thanks to your work.

Finally, I'd add that the "pending" legacy was there from when we first started
to mark up the patches and their status as we simply couldn't handle every patch
when we started marking up patches. Many of the pending ones are old and badly
documented, we have significantly increased the patch documentation requirement
since then based upon experience. This should make it hard to end up in such a
mess again.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159231): 
https://lists.openembedded.org/g/openembedded-core/message/159231
Mute This Topic: https://lists.openembedded.org/mt/87536259/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Ross Burton
On Mon, 6 Dec 2021 at 11:03, Alexander Kanavin  wrote:
> Presumably, that someone would start updating the repo and making releases, 
> at which point we can reevaluate the situation with the patches. As of today, 
> they are inappropriate.

But how, in two years time, would we know to re-evaluate the patches
if they're marked as inappropriate for upstream?

They're not inappropriate for upstream, we just can't submit them to a
meaningful upstream.  There's a big difference.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159230): 
https://lists.openembedded.org/g/openembedded-core/message/159230
Mute This Topic: https://lists.openembedded.org/mt/87494788/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] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 14:43 +0100, Alexander Kanavin wrote:
> Since AUH didn't pick this up, can you run 'devtool latest-version minicom'
> with this update, as it probably would report something that needs fixing via
> regexp?

That shows:

WARNING: latest_versionstring: package minicom_2.8.orig.tar.bz2 don't match 
pattern

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159229): 
https://lists.openembedded.org/g/openembedded-core/message/159229
Mute This Topic: https://lists.openembedded.org/mt/87539156/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] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Alexander Kanavin
Since AUH didn't pick this up, can you run 'devtool latest-version minicom'
with this update, as it probably would report something that needs fixing
via regexp?

Alex

On Mon, 6 Dec 2021 at 14:06, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> * Update the url to use .bz2 instead of .gz compression.
> * Drop three patches merged upstream
> * Submit two patches upstream
> * Drop the musl patch since half was already applied upstream and
>   musl now builds fine without the other piece
>
> Signed-off-by: Richard Purdie 
> ---
>  ...Fix-build-issus-surfaced-due-to-musl.patch | 47 ---
>  ...ix-minicom-h-v-return-value-is-not-0.patch | 32 ++---
>  .../minicom/allow.to.disable.lockdev.patch| 17 +--
>  .../{minicom_2.7.1.bb => minicom_2.8.bb}  | 11 ++---
>  4 files changed, 31 insertions(+), 76 deletions(-)
>  delete mode 100644
> meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
>  rename meta/recipes-extended/minicom/{minicom_2.7.1.bb => minicom_2.8.bb}
> (68%)
>
> diff --git
> a/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
> b/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
> deleted file mode 100644
> index fec67fdd3fd..000
> ---
> a/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -From d62a5862e26ed3fc58d789efe9c40ca6c911d36b Mon Sep 17 00:00:00 2001
> -From: Khem Raj 
> -Date: Mon, 31 Aug 2015 22:35:31 +
> -Subject: [PATCH] Fix build issus surfaced due to musl
> -
> -src/getsdir.h:28:14: error: 'MAXNAMLEN' undeclared here (not in a
> function)
> -   char fname[MAXNAMLEN + 1];  /* filename + terminating null */
> -
> -src/dial.c:352:22: error: 'KIOCSOUND' undeclared (first use in this
> function)
> -|  ioctl(consolefd, KIOCSOUND, k);
> -
> -Signed-off-by: Khem Raj 
> 
> -Upstream-Status: Pending
> -
> - src/dial.c| 2 +-
> - src/getsdir.c | 1 +
> - 2 files changed, 2 insertions(+), 1 deletion(-)
> -
> -diff --git a/src/dial.c b/src/dial.c
> -index a90c1d2..bf02574 100644
>  a/src/dial.c
> -+++ b/src/dial.c
> -@@ -39,7 +39,7 @@
> - #include "intl.h"
> -
> - #ifdef VC_MUSIC
> --#  if defined(__GLIBC__)
> -+#  if defined(__GLIBC__) || defined(__linux__)
> - #include 
> - #include 
> - #include 
> -diff --git a/src/getsdir.c b/src/getsdir.c
> -index 2195b27..b61a361 100644
>  a/src/getsdir.c
> -+++ b/src/getsdir.c
> -@@ -30,6 +30,7 @@
> - #include 
> - #include 
> - #include 
> -+#include 
> - #include 
> -
> - #include "getsdir.h"
> ---
> -2.5.1
> -
> diff --git
> a/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
> b/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
> index bd8261c979d..9e67126f3e1 100644
> ---
> a/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
> +++
> b/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
> @@ -1,35 +1,33 @@
> -Subject: [PATCH] fix minicom -h/-v return value is not 0
> +Exit normally for help/verison options
>
> -Upstream-Status: Pending
> -
> -Signed-off-by: Lu Chong 
> +If -v or -h is used for the help/version information, it is a normal exit
> situation,
> +not an error condition. Sometimes these are used as a simple operation
> test of the
> +resulting binary so the exit code does matter.
>
> +Signed-off-by: Richard Purdie 
> +Upstream-Status: Submitted [
> https://salsa.debian.org/minicom-team/minicom/-/merge_requests/14]
>  ---
>   src/minicom.c |6 ++
>   1 file changed, 2 insertions(+), 4 deletions(-)
>
> -diff --git a/src/minicom.c b/src/minicom.c
> -index e1a557b..730da7c 100644
>  a/src/minicom.c
> -+++ b/src/minicom.c
> -@@ -1166,15 +1166,13 @@ int main(int argc, char **argv)
> -"modify it under the terms of the GNU General Public
> License\n"
> +Index: minicom-2.8/src/minicom.c
> +===
> +--- minicom-2.8.orig/src/minicom.c
>  minicom-2.8/src/minicom.c
> +@@ -1257,14 +1257,14 @@ int main(int argc, char **argv)
> +  "modify it under the terms of the GNU General Public
> License\n"
>"as published by the Free Software Foundation; either
> version\n"
> -  "2 of the License, or (at your option) any later
> version.\n\n");
> +  "2 of the License, or (at your option) any later
> version.\n\n"));
>  -  exit(1);
> --  break;
>  +  exit(0);
> +   break;
>   case 's': /* setup mode */
> dosetup = 1;
> break;
>   case 'h':
> helpthem();
>  -  exit(1);
> --  break;
>  +  exit(0);
> +   break;
>   case 'p': /* Pseudo terminal to use. */
> if (strncmp(optarg, 

[OE-core] [PATCH] minicom: Upgrade 2.7.1 -> 2.8

2021-12-06 Thread Richard Purdie
* Update the url to use .bz2 instead of .gz compression.
* Drop three patches merged upstream
* Submit two patches upstream
* Drop the musl patch since half was already applied upstream and
  musl now builds fine without the other piece

Signed-off-by: Richard Purdie 
---
 ...Fix-build-issus-surfaced-due-to-musl.patch | 47 ---
 ...ix-minicom-h-v-return-value-is-not-0.patch | 32 ++---
 .../minicom/allow.to.disable.lockdev.patch| 17 +--
 .../{minicom_2.7.1.bb => minicom_2.8.bb}  | 11 ++---
 4 files changed, 31 insertions(+), 76 deletions(-)
 delete mode 100644 
meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
 rename meta/recipes-extended/minicom/{minicom_2.7.1.bb => minicom_2.8.bb} (68%)

diff --git 
a/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
 
b/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
deleted file mode 100644
index fec67fdd3fd..000
--- 
a/meta/recipes-extended/minicom/minicom/0001-Fix-build-issus-surfaced-due-to-musl.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From d62a5862e26ed3fc58d789efe9c40ca6c911d36b Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Mon, 31 Aug 2015 22:35:31 +
-Subject: [PATCH] Fix build issus surfaced due to musl
-
-src/getsdir.h:28:14: error: 'MAXNAMLEN' undeclared here (not in a function)
-   char fname[MAXNAMLEN + 1];  /* filename + terminating null */
-
-src/dial.c:352:22: error: 'KIOCSOUND' undeclared (first use in this function)
-|  ioctl(consolefd, KIOCSOUND, k);
-
-Signed-off-by: Khem Raj 

-Upstream-Status: Pending
-
- src/dial.c| 2 +-
- src/getsdir.c | 1 +
- 2 files changed, 2 insertions(+), 1 deletion(-)
-
-diff --git a/src/dial.c b/src/dial.c
-index a90c1d2..bf02574 100644
 a/src/dial.c
-+++ b/src/dial.c
-@@ -39,7 +39,7 @@
- #include "intl.h"
- 
- #ifdef VC_MUSIC
--#  if defined(__GLIBC__)
-+#  if defined(__GLIBC__) || defined(__linux__)
- #include 
- #include 
- #include 
-diff --git a/src/getsdir.c b/src/getsdir.c
-index 2195b27..b61a361 100644
 a/src/getsdir.c
-+++ b/src/getsdir.c
-@@ -30,6 +30,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include 
- 
- #include "getsdir.h"
--- 
-2.5.1
-
diff --git 
a/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
 
b/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
index bd8261c979d..9e67126f3e1 100644
--- 
a/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
+++ 
b/meta/recipes-extended/minicom/minicom/0001-fix-minicom-h-v-return-value-is-not-0.patch
@@ -1,35 +1,33 @@
-Subject: [PATCH] fix minicom -h/-v return value is not 0
+Exit normally for help/verison options
 
-Upstream-Status: Pending
-
-Signed-off-by: Lu Chong 
+If -v or -h is used for the help/version information, it is a normal exit 
situation,
+not an error condition. Sometimes these are used as a simple operation test of 
the
+resulting binary so the exit code does matter.
 
+Signed-off-by: Richard Purdie 
+Upstream-Status: Submitted 
[https://salsa.debian.org/minicom-team/minicom/-/merge_requests/14]
 ---
  src/minicom.c |6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)
 
-diff --git a/src/minicom.c b/src/minicom.c
-index e1a557b..730da7c 100644
 a/src/minicom.c
-+++ b/src/minicom.c
-@@ -1166,15 +1166,13 @@ int main(int argc, char **argv)
-"modify it under the terms of the GNU General Public License\n"
+Index: minicom-2.8/src/minicom.c
+===
+--- minicom-2.8.orig/src/minicom.c
 minicom-2.8/src/minicom.c
+@@ -1257,14 +1257,14 @@ int main(int argc, char **argv)
+  "modify it under the terms of the GNU General Public 
License\n"
   "as published by the Free Software Foundation; either 
version\n"
-  "2 of the License, or (at your option) any later 
version.\n\n");
+  "2 of the License, or (at your option) any later 
version.\n\n"));
 -  exit(1);
--  break;
 +  exit(0);
+   break;
  case 's': /* setup mode */
dosetup = 1;
break;
  case 'h':
helpthem();
 -  exit(1);
--  break;
 +  exit(0);
+   break;
  case 'p': /* Pseudo terminal to use. */
if (strncmp(optarg, "/dev/", 5) == 0)
- optarg += 5;
--- 
-1.7.9.5
-
diff --git 
a/meta/recipes-extended/minicom/minicom/allow.to.disable.lockdev.patch 
b/meta/recipes-extended/minicom/minicom/allow.to.disable.lockdev.patch
index f5c08896ff5..39dc5c04925 100644
--- a/meta/recipes-extended/minicom/minicom/allow.to.disable.lockdev.patch
+++ b/meta/recipes-extended/minicom/minicom/allow.to.disable.lockdev.patch
@@ -1,10 +1,19 @@
-Upstream-Status: Pending
+configure: Allow lockdev to be disabled
+
+When the 

[OE-core] [PATCH] tcf-agent: cleanup patches

2021-12-06 Thread Ross Burton
ldflags.patch isn't really suitable for upstream, so mark inappropriate.

fix_ranlib.patch has been rebased into uselessness over time, it's now
setting RANLIB to just '$@' which expands to '' when called, so is a
null operation.

Signed-off-by: Ross Burton 
---
 .../tcf-agent/tcf-agent/fix_ranlib.patch| 17 -
 .../tcf-agent/tcf-agent/ldflags.patch   |  6 +-
 .../recipes-devtools/tcf-agent/tcf-agent_git.bb |  1 -
 3 files changed, 5 insertions(+), 19 deletions(-)
 delete mode 100644 meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch

diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch 
b/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
deleted file mode 100644
index abd33babeb..00
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/fix_ranlib.patch
+++ /dev/null
@@ -1,17 +0,0 @@
-Actually pass the arguments to RANLIB.
-
-Upstream-Status: Pending
-Signed-off-by: Ross Burton 
-
-Index: agent/Makefile.inc
-===
 a/Makefile.inc
-+++ b/Makefile.inc
-@@ -92,6 +92,7 @@ ifeq ($(OPSYS),GNU/Linux)
- OPTS += -DUSE_uuid_generate=0
-   endif
-   OPTS += -DENABLE_arch_$(shell uname -m)
-+  RANLIB += $@
- endif
-
- ifneq ($(OPSYS),Windows)
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch 
b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
index c03c55d22b..dfe492091c 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent/ldflags.patch
@@ -1,4 +1,8 @@
-Upstream-Status: Pending
+We need LDFLAGS to be respected otherwise there are QA warnings as the right
+flags don't get used.
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton 
 
 From d92af0483c20365fd0af740d0baef8870b4aa374 Mon Sep 17 00:00:00 2001
 From: Abdur Rehman 
diff --git a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb 
b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
index d6d563d8e7..0d627f4e23 100644
--- a/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
+++ b/meta/recipes-devtools/tcf-agent/tcf-agent_git.bb
@@ -11,7 +11,6 @@ PV = "1.7.0+git${SRCPV}"
 
 UPSTREAM_CHECK_GITTAGREGEX = "(?P(\d+(\.\d+)+))"
 SRC_URI = 
"git://git.eclipse.org/r/tcf/org.eclipse.tcf.agent.git;protocol=https;branch=master
 \
-   file://fix_ranlib.patch \
file://ldflags.patch \
file://tcf-agent.init \
file://tcf-agent.service \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159226): 
https://lists.openembedded.org/g/openembedded-core/message/159226
Mute This Topic: https://lists.openembedded.org/mt/87538834/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] minicom: Mark patches as backports

2021-12-06 Thread Richard Purdie
These three patches are backports from upstream, mark as such.

Signed-off-by: Richard Purdie 
---
 .../0001-Drop-superfluous-global-variable-definitions.patch | 2 +-
 .../0002-Drop-superfluous-global-variable-definitions.patch | 2 +-
 .../0003-Drop-superfluous-global-variable-definitions.patch | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/meta/recipes-extended/minicom/minicom/0001-Drop-superfluous-global-variable-definitions.patch
 
b/meta/recipes-extended/minicom/minicom/0001-Drop-superfluous-global-variable-definitions.patch
index 4c6e2493155..01b23898e71 100644
--- 
a/meta/recipes-extended/minicom/minicom/0001-Drop-superfluous-global-variable-definitions.patch
+++ 
b/meta/recipes-extended/minicom/minicom/0001-Drop-superfluous-global-variable-definitions.patch
@@ -11,7 +11,7 @@ can be dropped.
 This fixes linking with gcc 10 which uses -fno-common by default,
 disallowing multiple global variable definitions.
 
-Upstream-Status: Pending
+Upstream-Status: Backport 
[https://salsa.debian.org/minicom-team/minicom/-/commit/db269bba2a68fde03f5df45ac8372a8f1248ca96]
 Signed-off-by: Khem Raj 
 ---
  src/dial.c | 2 --
diff --git 
a/meta/recipes-extended/minicom/minicom/0002-Drop-superfluous-global-variable-definitions.patch
 
b/meta/recipes-extended/minicom/minicom/0002-Drop-superfluous-global-variable-definitions.patch
index 1740051e0a5..e86b470b7e1 100644
--- 
a/meta/recipes-extended/minicom/minicom/0002-Drop-superfluous-global-variable-definitions.patch
+++ 
b/meta/recipes-extended/minicom/minicom/0002-Drop-superfluous-global-variable-definitions.patch
@@ -13,7 +13,7 @@ variables in minicom.c and only declare them in the minicom.h 
header.
 This fixes linking with gcc 10 which uses -fno-common by default,
 disallowing multiple global variable definitions.
 
-Upstream-Status: Pending
+Upstream-Status: Backport 
[https://salsa.debian.org/minicom-team/minicom/-/commit/c69cad5b5dda85d361a3a0c1fddc65e933f26d11]
 Signed-off-by: Khem Raj 
 ---
  src/minicom.h | 2 +-
diff --git 
a/meta/recipes-extended/minicom/minicom/0003-Drop-superfluous-global-variable-definitions.patch
 
b/meta/recipes-extended/minicom/minicom/0003-Drop-superfluous-global-variable-definitions.patch
index 58cd58eda8b..3225a0c32af 100644
--- 
a/meta/recipes-extended/minicom/minicom/0003-Drop-superfluous-global-variable-definitions.patch
+++ 
b/meta/recipes-extended/minicom/minicom/0003-Drop-superfluous-global-variable-definitions.patch
@@ -14,7 +14,7 @@ and only declare the variables in the minicom.h header.
 This fixes linking with gcc 10 which uses -fno-common by default,
 disallowing multiple global variable definitions.
 
-Upstream-Status: Pending
+Upstream-Status: Backport 
[https://salsa.debian.org/minicom-team/minicom/-/commit/c8382374c5d340aa4115d527aed76e876ee5456b]
 Signed-off-by: Khem Raj 
 ---
  src/minicom.h | 6 +++---
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159225): 
https://lists.openembedded.org/g/openembedded-core/message/159225
Mute This Topic: https://lists.openembedded.org/mt/87538102/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 PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 12:29, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> Ross has a point here. If we go this route we'll just push people to mark
> patches as Inappropriate instead. People will know Pending isn't
> acceptable so
> they'll just use Inappropriate and we'll lose the ability to see things
> which
> may be discussed with upstream and those which realistically never can.
> We'll
> have to review patches marked as Inappropriate even more carefully.
>

Right, but what can we do then to make it more clear that new Pending
patches aren't welcome? I don't want them to keep slipping through into
master, and I certainly do not want to argue with what is essentially
laziness on the part of the submitter. I guess a mailing list nag-bot that
spots those submissions could help here.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159224): 
https://lists.openembedded.org/g/openembedded-core/message/159224
Mute This Topic: https://lists.openembedded.org/mt/87536259/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 PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Richard Purdie
On Mon, 2021-12-06 at 12:21 +0100, Alexander Kanavin wrote:
> On Mon, 6 Dec 2021 at 12:15, Alexander Kanavin via lists.openembedded.org
>  wrote:
> > On Mon, 6 Dec 2021 at 11:24, Ross Burton  wrote:
> > > 
> > > As much as I hate pending patches, and I really do hate patches that
> > > sit in pending, there are situations where you know the problem, can
> > > work around it, but still want to push it upstream at some point
> > > pending further discussion.
> > > 
> > 
> > 
> > These situations are rare and you know it. Almost all of the time it's
> > laziness and abuse of pending so that submission can be avoided altogether
> > or pushed onto maintainers, e.g. me, not a 'need for further discussion'. 
> > 
> 
> 
> I want to add something: if there's truly a need for further discussion, that
> need is typically with upstream, and so the patch can be marked as
> Inappropriate [link to upstream discussion]. If the patch isn't that good,
> file a ticket instead and link to it.

Ross has a point here. If we go this route we'll just push people to mark
patches as Inappropriate instead. People will know Pending isn't acceptable so
they'll just use Inappropriate and we'll lose the ability to see things which
may be discussed with upstream and those which realistically never can. We'll
have to review patches marked as Inappropriate even more carefully.

We don't just want to reduce our Pending patches, my own aim is to reduce the
total of patches we have.

Backported patches eventually fall out the system so those don't worry me.
Submitted stand some chance. Pending are the unknowns but a high number of
Inappropriate will be the next issue.

We need to keep the end goal in sight here - not to carry patches at all
ideally.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159223): 
https://lists.openembedded.org/g/openembedded-core/message/159223
Mute This Topic: https://lists.openembedded.org/mt/87536259/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 PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 12:15, Alexander Kanavin via lists.openembedded.org
 wrote:

> On Mon, 6 Dec 2021 at 11:24, Ross Burton  wrote:
>
>>
>> As much as I hate pending patches, and I really do hate patches that
>> sit in pending, there are situations where you know the problem, can
>> work around it, but still want to push it upstream at some point
>> pending further discussion.
>>
>
> These situations are rare and you know it. Almost all of the time it's
> laziness and abuse of pending so that submission can be avoided altogether
> or pushed onto maintainers, e.g. me, not a 'need for further discussion'.
>

I want to add something: if there's truly a need for further discussion,
that need is typically with upstream, and so the patch can be marked as
Inappropriate [link to upstream discussion]. If the patch isn't that good,
file a ticket instead and link to it.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159221): 
https://lists.openembedded.org/g/openembedded-core/message/159221
Mute This Topic: https://lists.openembedded.org/mt/87536259/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] gcc: Update patch status submitted->backport

2021-12-06 Thread Richard Purdie
Patch was merged to upstream gcc, update status.

Signed-off-by: Richard Purdie 
---
 .../gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch 
b/meta/recipes-devtools/gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch
index 6b6925735d2..ebee30bbd62 100644
--- 
a/meta/recipes-devtools/gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch
+++ 
b/meta/recipes-devtools/gcc/gcc/0012-gcc-Fix-argument-list-too-long-error.patch
@@ -17,7 +17,8 @@ gcc/ChangeLog:
 
 Signed-off-by: Richard Purdie 
 
-Upstream-Status: Submitted 
[https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582722.html]
+Submitted [https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582722.html]
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=66e157188bd2f789809e17e85f917534c9381599]
 ---
  gcc/Makefile.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159222): 
https://lists.openembedded.org/g/openembedded-core/message/159222
Mute This Topic: https://lists.openembedded.org/mt/87537868/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 PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 11:24, Ross Burton  wrote:

>
> As much as I hate pending patches, and I really do hate patches that
> sit in pending, there are situations where you know the problem, can
> work around it, but still want to push it upstream at some point
> pending further discussion.
>

These situations are rare and you know it. Almost all of the time it's
laziness and abuse of pending so that submission can be avoided altogether
or pushed onto maintainers, e.g. me, not a 'need for further discussion'.


> Yes, we should push back, and if a new patch is added with Pending
> status that is clearly good for upstream we should be asking the
> submitter to do that.  But I don't think that effectively banning
> Pending patches in core is the right way forwards.
>

But this doesn't ban them completely. If someone has a genuine reason to
not submit yet, they can add the patch to lockdown list, and provide a
better explanation for why it should be there. Almost all of the time when
someone submits a Pending patch, they do not bother to explain why it isn't
yet submitted, and no one has time or willpower to argue with it.
Conversely, from the submitter's perspective, it's a lot harder to argue
with an error message that sets policy than it is to argue with core
maintainers expressing opinion.  I do think the lockdown shifts the balance
towards a more disciplined approach.


Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159220): 
https://lists.openembedded.org/g/openembedded-core/message/159220
Mute This Topic: https://lists.openembedded.org/mt/87536259/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 05/26] python3: drop unneeded multiprocessing module patch

2021-12-06 Thread Richard Purdie
On Sat, 2021-12-04 at 08:13 +0100, Alexander Kanavin wrote:
> I ran the reproducing sequence on qemux86, and it went fine:
> 
> root@qemux86:~# python3
> Python 3.10.0 (default, Oct  4 2021, 17:55:55) [GCC 11.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> > > > import multiprocessing
> > > > pool_sema = multiprocessing.BoundedSemaphore(value=1)
> > > > pool_sema.acquire()
> True
> > > > pool_sema.release()
> > > > 
> 
> Additionally AB testing revealed no issues, and the description isn't entirely
> clear about where and how the problem occurs, so I can't submit it upsream
> without having that understanding and how to demonstrate the problem.
> 
> Signed-off-by: Alexander Kanavin 
> 

There is a slightly different explanation here. libpthread was merged into libc
so this fix becomes a null-op on glibc. Not sure if musl has a separate pthread
but if so we could/should test that?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159219): 
https://lists.openembedded.org/g/openembedded-core/message/159219
Mute This Topic: https://lists.openembedded.org/mt/87494766/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 11:25, Ross Burton  wrote:

> On Sat, 4 Dec 2021 at 07:13, Alexander Kanavin 
> wrote:
> > -Upstream-Status: Pending
> > +Upstream-Status: Inappropriate [last release in 2015, last commit in
> 2019]
>
> If someone picked up Serf maintainership tomorrow, would these patches
> be suitable upstream?  If so, then they're not Inappropriate.
>

Presumably, that someone would start updating the repo and making releases,
at which point we can reevaluate the situation with the patches. As of
today, they are inappropriate.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159218): 
https://lists.openembedded.org/g/openembedded-core/message/159218
Mute This Topic: https://lists.openembedded.org/mt/87494788/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.1.rc1)

2021-12-06 Thread Teoh, Jay Shen
Hello everyone,

This is the full report for yocto-3.4.1.rc1:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

=== Summary 
No high milestone defects. 

new issue found 

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case 
failure
   
=== Bugs 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622

Thanks,
Jay

>-Original Message-
>From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Richard Purdie
>Sent: Wednesday, 1 December, 2021 3:06 AM
>To:  
>Cc: qa-build-notification 
>Subject: [qa-build-notification] QA notification for completed autobuilder 
>build
>(yocto-3.4.1.rc1)
>
>A build flagged for QA (yocto-3.4.1.rc1) was completed on the autobuilder and 
>is
>available at:
>
>
>https://autobuilder.yocto.io/pub/releases/yocto-3.4.1.rc1
>
>
>Build hash information:
>
>bitbake: 44a83b373e1fc34c93cd4a6c6cf8b73b230c1520
>meta-agl: 83c5764a38902c6d17f106ea545533192ebd46fe
>meta-arm: 55ae0eb1a6c210e6e87f5a553a1ebbb7dcc7a725
>meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
>meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
>meta-intel: d0f1c1ebfd9b7fe8d22c6a62208f78bccc6f3bf6
>meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
>meta-openembedded: f31b9854b13e46cb74569538a33c36730c00c695
>oecore: 70384dd958c57d1da924a66cffa35f80eb60d4b0
>poky: b53230c08d9f02ecaf35b4f0b70512abbf10ae11
>
>
>
>This is an automated message from the Yocto Project Autobuilder
>Git: git://git.yoctoproject.org/yocto-autobuilder2
>Email: richard.pur...@linuxfoundation.org
>
>
>
>
>
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159217): 
https://lists.openembedded.org/g/openembedded-core/message/159217
Mute This Topic: https://lists.openembedded.org/mt/87422769/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 3/6] libxkbcommon: allow building of API documentation

2021-12-06 Thread Ross Burton
On Sun, 5 Dec 2021 at 01:24, Peter Kjellerstedt
 wrote:
> > stdio: ERROR: Nothing PROVIDES 'doxygen-native' (but 
> > /home/pokybuild/yocto-worker/qemux86-world-alt/build/meta/recipes-graphics/xorg-lib/libxkbcommon_1.3.1.bb,
> > virtual:multilib:lib32:/home/pokybuild/yocto-worker/qemux86-world-alt/build/meta/recipes-graphics/xorg-lib/libxkbcommon_1.3.1.bb
> >  DEPENDS on
> > or otherwise requires it). Close matches:
> >
> > Not quite sure what is going on there yet, seems a little strange.
>
> Not very strange when you consider that the doxygen recipe is in meta-oe

Whoops.  I honestly thought it was in core!

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159216): 
https://lists.openembedded.org/g/openembedded-core/message/159216
Mute This Topic: https://lists.openembedded.org/mt/87480939/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 26/26] serf: mark patches as inappropriate for upstream submission

2021-12-06 Thread Ross Burton
On Sat, 4 Dec 2021 at 07:13, Alexander Kanavin  wrote:
> -Upstream-Status: Pending
> +Upstream-Status: Inappropriate [last release in 2015, last commit in 2019]

If someone picked up Serf maintainership tomorrow, would these patches
be suitable upstream?  If so, then they're not Inappropriate.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159215): 
https://lists.openembedded.org/g/openembedded-core/message/159215
Mute This Topic: https://lists.openembedded.org/mt/87494788/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 PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Ross Burton
On Mon, 6 Dec 2021 at 08:36, Alexander Kanavin  wrote:
> Misuse of 'Pending' patch status has been a problem for a long time;
> let's disallow that in any newly added patches. Please do the upsream
> submission at the same time as you submit the patch to oe-core.

As much as I hate pending patches, and I really do hate patches that
sit in pending, there are situations where you know the problem, can
work around it, but still want to push it upstream at some point
pending further discussion.

"Inappropriate" would mean the patch wouldn't be looked at again,
"Submitted" means an upstreamable solution has been formulated, and
"Pending" is that middle ground.

Yes, we should push back, and if a new patch is added with Pending
status that is clearly good for upstream we should be asking the
submitter to do that.  But I don't think that effectively banning
Pending patches in core is the right way forwards.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159214): 
https://lists.openembedded.org/g/openembedded-core/message/159214
Mute This Topic: https://lists.openembedded.org/mt/87536259/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [RFC PATCH] insane.bbclass: lock down pending patches

2021-12-06 Thread Alexander Kanavin
Misuse of 'Pending' patch status has been a problem for a long time;
let's disallow that in any newly added patches. Please do the upsream
submission at the same time as you submit the patch to oe-core.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/insane.bbclass |  11 +
 meta/files/pending-patches-lockdown.txt | 368 
 2 files changed, 379 insertions(+)
 create mode 100644 meta/files/pending-patches-lockdown.txt

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 8a47da5a09..8dcf98aba8 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1172,6 +1172,10 @@ python do_qa_patch() {
 import re
 from oe import patch
 
+locked_pending = []
+for locked_p in 
open(os.path.join(d.getVar('COREBASE'),'meta/files/pending-patches-lockdown.txt')).readlines():
+locked_pending.append(os.path.join(d.getVar('COREBASE'), 
locked_p.split()[0]))
+
 for url in patch.src_patches(d):
(_, _, fullpath, _, _, _) = bb.fetch.decodeurl(url)
 
@@ -1184,10 +1188,17 @@ python do_qa_patch() {
content = open(fullpath, encoding='utf-8', errors='ignore').read()
kinda_status_re = re.compile(r"^.*upstream.*status.*$", re.IGNORECASE | 
re.MULTILINE)
strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport)( .+)?$", 
re.MULTILINE)
+   pending_status_re = re.compile(r"^Upstream-Status: Pending( .+)?$", 
re.MULTILINE)
match_kinda = kinda_status_re.search(content)
match_strict = strict_status_re.search(content)
+   match_pending = pending_status_re.search(content)
guidelines = 
"https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status;
 
+   if match_pending and not fullpath in locked_pending:
+   bb.error("Pending status is not allowed in patch\n%s\nPlease submit 
the patch upstream or otherwise set the status according to %s ." % (fullpath, 
guidelines))
+   if not match_pending and fullpath in locked_pending:
+   bb.error("Please delete patch\n%s\n from 
meta/files/pending-patches-lockdown.txt" % (fullpath))
+
if not match_strict:
if match_kinda:
bb.error("Malformed Upstream-Status in patch\n%s\nPlease 
correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
diff --git a/meta/files/pending-patches-lockdown.txt 
b/meta/files/pending-patches-lockdown.txt
new file mode 100644
index 00..f196fe98b7
--- /dev/null
+++ b/meta/files/pending-patches-lockdown.txt
@@ -0,0 +1,368 @@
+meta/recipes-bsp/apmd/apmd/libtool.patch Scott Garman 

+meta/recipes-bsp/apmd/apmd/linkage.patch Ross Burton 
+meta/recipes-bsp/apmd/apmd/unlinux.patch Scott Garman 

+meta/recipes-bsp/apmd/apmd/wexitcode.patch Khem Raj 
+meta/recipes-bsp/efivar/efivar/determinism.patch Richard Purdie 

+meta/recipes-bsp/gnu-efi/gnu-efi/lib-Makefile-fix-parallel-issue.patch Robert 
Yang 
+meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch Saul Wold 

+meta/recipes-bsp/grub/files/0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch
 Khem Raj 
+meta/recipes-bsp/grub/files/determinism.patch Naveen Saini 

+meta/recipes-bsp/grub/files/grub-module-explicitly-keeps-symbole-.module_license.patch
 Hongxu Jia 
+meta/recipes-bsp/libacpi/files/0001-libacpi-Fix-build-witth-fno-commom.patch 
Khem Raj 
+meta/recipes-bsp/libacpi/files/libacpi_fix_for_x32.patch Nitin A Kamble 
 2011/12/05
+meta/recipes-bsp/libacpi/files/makefile-fix.patch unknown 
+meta/recipes-bsp/libacpi/files/use_correct_strip_in_cross_environment.patch 
Nitin A Kamble  2011/12/07
+meta/recipes-bsp/setserial/setserial/add_stdlib.patch unknown 
+meta/recipes-bsp/setserial/setserial/ldflags.patch Christopher Larson 

+meta/recipes-bsp/v86d/v86d/ar-from-env.patch Jason Wessel 

+meta/recipes-bsp/v86d/v86d/Support-for-cross-compilation.patch Serhey Popovych 

+meta/recipes-connectivity/avahi/files/initscript.patch unknown 
+meta/recipes-connectivity/bind/bind-9.16.23/0001-avoid-start-failure-with-bind-user.patch
 Chen Qi 
+meta/recipes-connectivity/connman/connman/0001-plugin.h-Change-visibility-to-default-for-debug-symb.patch
 Khem Raj 
+meta/recipes-connectivity/connman/connman/0002-resolve-musl-does-not-implement-res_ninit.patch
 Khem Raj 
+meta/recipes-connectivity/connman/connman-gnome/0001-Removed-icon-from-connman-gnome-about-applet.patch
 Andrei Dinu 
+meta/recipes-connectivity/connman/connman-gnome/null_check_for_ipv4_config.patch
 Emilia Ciobanu 
+meta/recipes-connectivity/dhcpcd/files/0001-remove-INCLUDEDIR-to-prevent-build-issues.patch
 Stefano Cappa 
+meta/recipes-connectivity/inetutils/inetutils/0001-ftpd-telnetd-Fix-multiple-definitions-of-errcatch-an.patch
 Khem Raj 
+meta/recipes-connectivity/inetutils/inetutils/fix-disable-ipv6.patch Jackie 
Huang 

Re: [OE-core] [PATCH] Build libstd-rs in release mode to compile mozjs

2021-12-06 Thread Alexander Kanavin
On Mon, 6 Dec 2021 at 06:45, pgowda  wrote:

> When mozjs in firefox is built with DEBUG_BUILD = "1"
> in local.conf, it will fail with the following error:
>rustc-1.56.0-src/vendor/compiler_builtins/src/int/specialized_div_rem
> /asymmetric.rs:57:
>more undefined references to `core::panicking::panic' follow
>
> Switch to building libstd-rs in "release" mode as that works
> around the issue and builds mozjs successfully. This is a
> work-around that can be used until the root cause of the debug
> build error is resolved.
>

Thank you, but I think the problem needs to be properly understood before
any fix to oe-core is merged. Can you keep the workaround as a bbappend
until then?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159212): 
https://lists.openembedded.org/g/openembedded-core/message/159212
Mute This Topic: https://lists.openembedded.org/mt/87534858/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 4/4] selftest: devtool: Separate common functions and devtool sstate setup into two classes

2021-12-06 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

The selftest recipetool base class reuse the selftest devtool base
class. Thereby the selftest devtool base class setup its own devtool
sstate and the selftest recipetool classes trigger the build of recipes.
This leads to the problem that the build artifacts doesn't reach the
persistent sstate cache and rebuild on every selftest run.

Move the common selftest devtool functions into its own class and use
the sstate cache in the recipetool tests.

Signed-off-by: Stefan Herbrechtsmeier 

---

 meta/lib/oeqa/selftest/cases/devtool.py| 45 +-
 meta/lib/oeqa/selftest/cases/recipetool.py |  4 +-
 2 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index d2b31af80e..96f40ac9a0 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -80,32 +80,15 @@ def tearDownModule():
 bb.utils.edit_bblayers_conf(bblayers_conf, None, None, 
bblayers_edit_cb)
 shutil.rmtree(templayerdir)
 
-class DevtoolBase(OESelftestTestCase):
-
-@classmethod
-def setUpClass(cls):
-super(DevtoolBase, cls).setUpClass()
-bb_vars = get_bb_vars(['TOPDIR', 'SSTATE_DIR'])
-cls.original_sstate = bb_vars['SSTATE_DIR']
-cls.devtool_sstate = os.path.join(bb_vars['TOPDIR'], 'sstate_devtool')
-cls.sstate_conf  = 'SSTATE_DIR = "%s"\n' % cls.devtool_sstate
-cls.sstate_conf += ('SSTATE_MIRRORS += "file://.* file:///%s/PATH"\n'
-% cls.original_sstate)
-
-@classmethod
-def tearDownClass(cls):
-cls.logger.debug('Deleting devtool sstate cache on %s' % 
cls.devtool_sstate)
-runCmd('rm -rf %s' % cls.devtool_sstate)
-super(DevtoolBase, cls).tearDownClass()
+class DevtoolTestCase(OESelftestTestCase):
 
 def setUp(self):
 """Test case setup function"""
-super(DevtoolBase, self).setUp()
+super(DevtoolTestCase, self).setUp()
 self.workspacedir = os.path.join(self.builddir, 'workspace')
 self.assertTrue(not os.path.exists(self.workspacedir),
 'This test cannot be run with a workspace directory '
 'under the build directory')
-self.append_config(self.sstate_conf)
 
 def _check_src_repo(self, repo_dir):
 """Check srctree git repository"""
@@ -236,6 +219,30 @@ class DevtoolBase(OESelftestTestCase):
 return filelist
 
 
+class DevtoolBase(DevtoolTestCase):
+
+@classmethod
+def setUpClass(cls):
+super(DevtoolBase, cls).setUpClass()
+bb_vars = get_bb_vars(['TOPDIR', 'SSTATE_DIR'])
+cls.original_sstate = bb_vars['SSTATE_DIR']
+cls.devtool_sstate = os.path.join(bb_vars['TOPDIR'], 'sstate_devtool')
+cls.sstate_conf  = 'SSTATE_DIR = "%s"\n' % cls.devtool_sstate
+cls.sstate_conf += ('SSTATE_MIRRORS += "file://.* file:///%s/PATH"\n'
+% cls.original_sstate)
+
+@classmethod
+def tearDownClass(cls):
+cls.logger.debug('Deleting devtool sstate cache on %s' % 
cls.devtool_sstate)
+runCmd('rm -rf %s' % cls.devtool_sstate)
+super(DevtoolBase, cls).tearDownClass()
+
+def setUp(self):
+"""Test case setup function"""
+super(DevtoolBase, self).setUp()
+self.append_config(self.sstate_conf)
+
+
 class DevtoolTests(DevtoolBase):
 
 def test_create_workspace(self):
diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index b77a2712f5..439e41597c 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -25,7 +25,7 @@ def tearDownModule():
 runCmd('rm -rf %s' % templayerdir)
 
 
-class RecipetoolBase(devtool.DevtoolBase):
+class RecipetoolBase(devtool.DevtoolTestCase):
 
 def setUpLocal(self):
 super(RecipetoolBase, self).setUpLocal()
@@ -72,7 +72,7 @@ class RecipetoolAppendTests(RecipetoolBase):
 
 @classmethod
 def setUpClass(cls):
-super(RecipetoolTests, cls).setUpClass()
+super(RecipetoolAppendTests, cls).setUpClass()
 # Ensure we have the right data in shlibs/pkgdata
 cls.logger.info('Running bitbake to generate pkgdata')
 bitbake('-c packagedata base-files coreutils busybox 
selftest-recipetool-appendfile')
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159211): 
https://lists.openembedded.org/g/openembedded-core/message/159211
Mute This Topic: https://lists.openembedded.org/mt/87536004/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/4] selftest/recipetool: Add tests for branch parameter and srcbranch option

2021-12-06 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

The recipetool support two ways to pass a branch and fallback to master
if no branch is defined. Add tests for default branch, branch parameter
and srcbranch option.

Signed-off-by: Stefan Herbrechtsmeier 
---
This commit changes the test repository from matchbox-terminal to
matchbox-keyboard because matchbox-terminal has only one master branch.
Maybe the test should use a special test repository.

 meta/lib/oeqa/selftest/cases/recipetool.py | 38 +++---
 1 file changed, 27 insertions(+), 11 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 1aedc02b99..b77a2712f5 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -350,7 +350,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 checkvars['SRC_URI[sha256sum]'] = 
'2e6a401cac9024db2288297e3be1a8ab60e7401ba8e91225218aaf4a27e82a07'
 self._test_recipe_contents(recipefile, checkvars, [])
 
-def test_recipetool_create_git(self):
+def test_recipetool_create_autotools(self):
 if 'x11' not in get_bb_var('DISTRO_FEATURES'):
 self.skipTest('Test requires x11 as distro feature')
 # Ensure we have the right data in shlibs/pkgdata
@@ -359,7 +359,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 tempsrc = os.path.join(self.tempdir, 'srctree')
 os.makedirs(tempsrc)
 recipefile = os.path.join(self.tempdir, 'libmatchbox.bb')
-srcuri = 'git://git.yoctoproject.org/libmatchbox;branch=master'
+srcuri = 'git://git.yoctoproject.org/libmatchbox'
 result = runCmd(['recipetool', 'create', '-o', recipefile, srcuri + 
";rev=9f7cf8895ae2d39c465c04cc78e918c157420269", '-x', tempsrc])
 self.assertTrue(os.path.isfile(recipefile), 'recipetool did not create 
recipe file; output:\n%s' % result.output)
 checkvars = {}
@@ -367,7 +367,7 @@ class RecipetoolCreateTests(RecipetoolBase):
 checkvars['LIC_FILES_CHKSUM'] = 
'file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34'
 checkvars['S'] = '${WORKDIR}/git'
 checkvars['PV'] = '1.11+git${SRCPV}'
-checkvars['SRC_URI'] = srcuri
+checkvars['SRC_URI'] = srcuri + ';branch=master'
 checkvars['DEPENDS'] = set(['libcheck', 'libjpeg-turbo', 'libpng', 
'libx11', 'libxext', 'pango'])
 inherits = ['autotools', 'pkgconfig']
 self._test_recipe_contents(recipefile, checkvars, inherits)
@@ -506,19 +506,35 @@ class RecipetoolCreateTests(RecipetoolBase):
 inherits = ['setuptools3']
 self._test_recipe_contents(recipefile, checkvars, inherits)
 
-def test_recipetool_create_git_http(self):
+def _test_recipetool_create_git(self, srcuri, branch=None):
 # Basic test to check http git URL mangling works
 temprecipe = os.path.join(self.tempdir, 'recipe')
 os.makedirs(temprecipe)
-recipefile = os.path.join(temprecipe, 'matchbox-terminal_git.bb')
-srcuri = 'http://git.yoctoproject.org/git/matchbox-terminal'
-result = runCmd('recipetool create -o %s %s' % (temprecipe, srcuri))
+name = srcuri.split(';')[0].split('/')[-1]
+recipefile = os.path.join(temprecipe, name + '_git.bb')
+options = ' -B %s' % branch if branch else ''
+result = runCmd('recipetool create -o %s%s "%s"' % (temprecipe, 
options, srcuri))
 self.assertTrue(os.path.isfile(recipefile))
 checkvars = {}
-checkvars['LICENSE'] = set(['GPLv2'])
-checkvars['SRC_URI'] = 
'git://git.yoctoproject.org/git/matchbox-terminal;protocol=http;branch=master'
-inherits = ['pkgconfig', 'autotools']
-self._test_recipe_contents(recipefile, checkvars, inherits)
+checkvars['SRC_URI'] = srcuri
+for scheme in ['http', 'https']:
+if srcuri.startswith(scheme + ":"):
+checkvars['SRC_URI'] = 'git%s;protocol=%s' % 
(srcuri[len(scheme):], scheme)
+if ';branch=' not in srcuri:
+checkvars['SRC_URI'] += ';branch=' + (branch or 'master')
+self._test_recipe_contents(recipefile, checkvars, [])
+
+def test_recipetool_create_git_http(self):
+
self._test_recipetool_create_git('http://git.yoctoproject.org/git/matchbox-keyboard')
+
+def test_recipetool_create_git_srcuri_master(self):
+
self._test_recipetool_create_git('git://git.yoctoproject.org/matchbox-keyboard;branch=master')
+
+def test_recipetool_create_git_srcuri_branch(self):
+
self._test_recipetool_create_git('git://git.yoctoproject.org/matchbox-keyboard;branch=matchbox-keyboard-0-1')
+
+def test_recipetool_create_git_srcbranch(self):
+
self._test_recipetool_create_git('git://git.yoctoproject.org/matchbox-keyboard',
 'matchbox-keyboard-0-1')
 
 
 class RecipetoolTests(RecipetoolBase):
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply 

[OE-core] [PATCH 2/4] selftest/recipetool: Split tests into separate test classes

2021-12-06 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

Split tests into separate test classes to speed up individual test runs
by reducing the test setup to a minimum.

The pkgdata generation is only needed for the append tests and slow down
the other tests.

Signed-off-by: Stefan Herbrechtsmeier 
---

 meta/lib/oeqa/selftest/cases/recipetool.py | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 8dc00ac10e..1aedc02b99 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -68,7 +68,7 @@ class RecipetoolBase(devtool.DevtoolBase):
 return bbappendfile, result.output
 
 
-class RecipetoolTests(RecipetoolBase):
+class RecipetoolAppendTests(RecipetoolBase):
 
 @classmethod
 def setUpClass(cls):
@@ -76,9 +76,8 @@ class RecipetoolTests(RecipetoolBase):
 # Ensure we have the right data in shlibs/pkgdata
 cls.logger.info('Running bitbake to generate pkgdata')
 bitbake('-c packagedata base-files coreutils busybox 
selftest-recipetool-appendfile')
-bb_vars = get_bb_vars(['COREBASE', 'BBPATH'])
+bb_vars = get_bb_vars(['COREBASE'])
 cls.corebase = bb_vars['COREBASE']
-cls.bbpath = bb_vars['BBPATH']
 
 def _try_recipetool_appendfile(self, testrecipe, destfile, newfile, 
options, expectedlines, expectedfiles):
 cmd = 'recipetool appendfile %s %s %s %s' % (self.templayerdir, 
destfile, newfile, options)
@@ -332,6 +331,9 @@ class RecipetoolTests(RecipetoolBase):
 filename = try_appendfile_wc('-w')
 self.assertEqual(filename, recipefn.split('_')[0] + '_%.bbappend')
 
+
+class RecipetoolCreateTests(RecipetoolBase):
+
 def test_recipetool_create(self):
 # Try adding a recipe
 tempsrc = os.path.join(self.tempdir, 'srctree')
@@ -518,6 +520,15 @@ class RecipetoolTests(RecipetoolBase):
 inherits = ['pkgconfig', 'autotools']
 self._test_recipe_contents(recipefile, checkvars, inherits)
 
+
+class RecipetoolTests(RecipetoolBase):
+
+@classmethod
+def setUpClass(cls):
+super(RecipetoolTests, cls).setUpClass()
+bb_vars = get_bb_vars(['BBPATH'])
+cls.bbpath = bb_vars['BBPATH']
+
 def _copy_file_with_cleanup(self, srcfile, basedstdir, *paths):
 dstdir = basedstdir
 self.assertTrue(os.path.exists(dstdir))
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159209): 
https://lists.openembedded.org/g/openembedded-core/message/159209
Mute This Topic: https://lists.openembedded.org/mt/87536001/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/4] recipetool: Set master branch only as fallback

2021-12-06 Thread Stefan Herbrechtsmeier
From: Stefan Herbrechtsmeier 

The commit 'meta/scripts: Manual git url branch additions (dc53fe75cc)'
sets the branch= parameter too early to master and thereby breaks the
-B/--srcbranch option.

ERROR: branch= parameter and -B/--srcbranch option cannot both be specified - 
use one or the other

Signed-off-by: Stefan Herbrechtsmeier 
---

 scripts/lib/recipetool/create.py | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 4f6e01c639..406c97f1c5 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -389,9 +389,6 @@ def reformat_git_uri(uri):
 parms.update({('protocol', 'ssh')})
 elif (scheme == "http" or scheme == 'https' or scheme == 'ssh') and 
not ('protocol' in parms):
 parms.update({('protocol', scheme)})
-# We assume 'master' branch if not set
-if not 'branch' in parms:
-parms.update({('branch', 'master')})
 # Always append 'git://'
 fUrl = bb.fetch2.encodeurl(('git', host, path, user, pswd, parms))
 return fUrl
@@ -481,6 +478,9 @@ def create_recipe(args):
 storeTagName = params['tag']
 params['nobranch'] = '1'
 del params['tag']
+# Assume 'master' branch if not set
+if scheme in ['git', 'gitsm'] and 'branch' not in params and 
'nobranch' not in params:
+params['branch'] = 'master'
 fetchuri = bb.fetch2.encodeurl((scheme, network, path, user, passwd, 
params))
 
 tmpparent = tinfoil.config_data.getVar('BASE_WORKDIR')
@@ -530,10 +530,9 @@ def create_recipe(args):
 # Remove HEAD reference point and drop remote prefix
 get_branch = [x.split('/', 1)[1] for x in get_branch if not 
x.startswith('origin/HEAD')]
 if 'master' in get_branch:
-# If it is master, we do not need to append 'branch=master' as 
this is default.
 # Even with the case where get_branch has multiple objects, if 
'master' is one
 # of them, we should default take from 'master'
-srcbranch = ''
+srcbranch = 'master'
 elif len(get_branch) == 1:
 # If 'master' isn't in get_branch and get_branch contains only 
ONE object, then store result into 'srcbranch'
 srcbranch = get_branch[0]
@@ -546,8 +545,8 @@ def create_recipe(args):
 # Since we might have a value in srcbranch, we need to
 # recontruct the srcuri to include 'branch' in params.
 scheme, network, path, user, passwd, params = 
bb.fetch2.decodeurl(srcuri)
-if srcbranch:
-params['branch'] = srcbranch
+if scheme in ['git', 'gitsm']:
+params['branch'] = srcbranch or 'master'
 
 if storeTagName and scheme in ['git', 'gitsm']:
 # Check srcrev using tag and check validity of the tag
@@ -606,7 +605,7 @@ def create_recipe(args):
 splitline = line.split()
 if len(splitline) > 1:
 if splitline[0] == 'origin' and 
scriptutils.is_src_url(splitline[1]):
-srcuri = reformat_git_uri(splitline[1])
+srcuri = reformat_git_uri(splitline[1]) + 
';branch=master'
 srcsubdir = 'git'
 break
 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159208): 
https://lists.openembedded.org/g/openembedded-core/message/159208
Mute This Topic: https://lists.openembedded.org/mt/87536000/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-