[OE-core] [PATCH] sysklogd: upgrade 2.2.2 -> 2.2.3

[zhengruoqin]

Signed-off-by: Zheng Ruoqin 
---
 .../sysklogd/{sysklogd_2.2.2.bb => sysklogd_2.2.3.bb}   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/sysklogd/{sysklogd_2.2.2.bb => sysklogd_2.2.3.bb} 
(96%)

diff --git a/meta/recipes-extended/sysklogd/sysklogd_2.2.2.bb 
b/meta/recipes-extended/sysklogd/sysklogd_2.2.3.bb
similarity index 96%
rename from meta/recipes-extended/sysklogd/sysklogd_2.2.2.bb
rename to meta/recipes-extended/sysklogd/sysklogd_2.2.3.bb
index 5dfeca5326..be34ec7b38 100644
--- a/meta/recipes-extended/sysklogd/sysklogd_2.2.2.bb
+++ b/meta/recipes-extended/sysklogd/sysklogd_2.2.3.bb
@@ -14,7 +14,7 @@ SRC_URI = "git://github.com/troglobit/sysklogd.git;nobranch=1 
\
file://sysklogd \
"
 
-SRCREV = "f507ed8ff3f1e9d71bb6f85acbf5d14b2fa4e5f7"
+SRCREV = "17b68ca89ab814bb623b615c4e7088d619ed8829"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


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

[zhengruoqin]

refresh rpcbind_add_option_to_fix_port_number.patch

Signed-off-by: Zheng Ruoqin 
---
 ...pcbind_add_option_to_fix_port_number.patch | 58 +--
 .../{rpcbind_1.2.5.bb => rpcbind_1.2.6.bb}|  4 +-
 2 files changed, 31 insertions(+), 31 deletions(-)
 rename meta/recipes-extended/rpcbind/{rpcbind_1.2.5.bb => rpcbind_1.2.6.bb} 
(93%)

diff --git 
a/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch
 
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch
index 434b6b1c4c..535f9ce20d 100644
--- 
a/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch
+++ 
b/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch
@@ -15,7 +15,7 @@ Signed-off-by: Yi Zhao 
  3 files changed, 26 insertions(+), 3 deletions(-)
 
 diff --git a/man/rpcbind.8 b/man/rpcbind.8
-index af6200f..2e6146b 100644
+index fbf0ace..66f7c08 100644
 --- a/man/rpcbind.8
 +++ b/man/rpcbind.8
 @@ -11,7 +11,7 @@
@@ -27,17 +27,17 @@ index af6200f..2e6146b 100644
  .Sh DESCRIPTION
  The
  .Nm
-@@ -107,6 +107,8 @@ will automatically add
+@@ -96,6 +96,8 @@ will automatically add
  and if IPv6 is enabled,
  .Li ::1
  to the list.
 +.It Fl p
 +Bind for fixed UDP port number
- .It Fl i
- .Dq Insecure
- mode.
+ If no
+ .Fl h
+ option is specified,
 diff --git a/src/rpcb_svc_com.c b/src/rpcb_svc_com.c
-index 8aef9e5..c2632a4 100644
+index 1743dad..07a1c75 100644
 --- a/src/rpcb_svc_com.c
 +++ b/src/rpcb_svc_com.c
 @@ -48,6 +48,7 @@
@@ -60,8 +60,8 @@ index 8aef9e5..c2632a4 100644
int fd;
struct rmtcallfd_list *rmt;
SVCXPRT *xprt;
-+  struct __rpc_sockinfo si;
-+  struct t_bind taddr;
++struct __rpc_sockinfo si;
++struct t_bind taddr;
  
if ((fd = __rpc_nconf2fd(nconf)) == -1) {
if (debugging)
@@ -70,23 +70,23 @@ index 8aef9e5..c2632a4 100644
return (-1);
}
 +
-+  if (fixed_port) {
-+  __rpc_fd2sockinfo(fd, );
-+  memset(, 0, sizeof(taddr));
-+  taddr.addr.maxlen = taddr.addr.len = si.si_alen;
-+  taddr.addr.buf = malloc(si.si_alen);
-+  if (taddr.addr.buf == NULL) {
-+  return -1;
-+  }
-+  *(unsigned short *)(&(taddr.addr.buf[0])) = si.si_af;
-+  *(unsigned short *)(&(taddr.addr.buf[2])) = htons(fixed_port);
-+  xprt = svc_tli_create(fd, nconf, , RPC_MAXDATASIZE, 
RPC_MAXDATASIZE);
-+  } else
++if (fixed_port) {
++__rpc_fd2sockinfo(fd, );
++memset(, 0, sizeof(taddr));
++taddr.addr.maxlen = taddr.addr.len = si.si_alen;
++taddr.addr.buf = malloc(si.si_alen);
++if (taddr.addr.buf == NULL) {
++return -1;
++}
++*(unsigned short *)(&(taddr.addr.buf[0])) = si.si_af;
++*(unsigned short *)(&(taddr.addr.buf[2])) = htons(fixed_port);
++xprt = svc_tli_create(fd, nconf, , RPC_MAXDATASIZE, 
RPC_MAXDATASIZE);
++} else
xprt = svc_tli_create(fd, 0, (struct t_bind *) 0, 0, 0);
if (xprt == NULL) {
if (debugging)
 diff --git a/src/rpcbind.c b/src/rpcbind.c
-index 137011b..dc3d2d6 100644
+index 25d8a90..36a95b9 100644
 --- a/src/rpcbind.c
 +++ b/src/rpcbind.c
 @@ -111,6 +111,7 @@ int runasdaemon = 0;
@@ -97,7 +97,7 @@ index 137011b..dc3d2d6 100644
  
  char **hosts = NULL;
  int nhosts = 0;
-@@ -869,7 +870,7 @@ parseargs(int argc, char *argv[])
+@@ -884,7 +885,7 @@ parseargs(int argc, char *argv[])
  {
int c;
oldstyle_local = 1;
@@ -106,25 +106,25 @@ index 137011b..dc3d2d6 100644
switch (c) {
case 'a':
doabort = 1;/* when debugging, do an abort on */
-@@ -887,6 +888,9 @@ parseargs(int argc, char *argv[])
+@@ -902,6 +903,9 @@ parseargs(int argc, char *argv[])
if (hosts[nhosts - 1] == NULL)
errx(1, "Out of memory");
break;
-+  case 'p':
-+  fixed_port = atoi(optarg);
-+  break;
++case 'p':
++fixed_port = atoi(optarg);
++break;
case 'i':
insecure = 1;
break;
-@@ -905,7 +909,7 @@ parseargs(int argc, char *argv[])
+@@ -920,7 +924,7 @@ parseargs(int argc, char *argv[])
break;
  #endif
default:/* error */
 -  fprintf(stderr, "usage: rpcbind [-adhilswf]\n");
-+  fprintf(stderr, "usage: rpcbind [-adhpilswf]\n");
++  fprintf(stderr, "usage: rpcbind [-adhpilswf]\n");
exit (1);
}
}
 -- 
-1.9.1
+2.25.1
 
diff --git 

[OE-core] [PATCH] rng-tools: upgrade 6.11 -> 6.12

[zhengruoqin]

Signed-off-by: Zheng Ruoqin 
---
 .../rng-tools/{rng-tools_6.11.bb => rng-tools_6.12.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/rng-tools/{rng-tools_6.11.bb => rng-tools_6.12.bb} 
(97%)

diff --git a/meta/recipes-support/rng-tools/rng-tools_6.11.bb 
b/meta/recipes-support/rng-tools/rng-tools_6.12.bb
similarity index 97%
rename from meta/recipes-support/rng-tools/rng-tools_6.11.bb
rename to meta/recipes-support/rng-tools/rng-tools_6.12.bb
index 61a0cef2e0..9673700981 100644
--- a/meta/recipes-support/rng-tools/rng-tools_6.11.bb
+++ b/meta/recipes-support/rng-tools/rng-tools_6.12.bb
@@ -14,7 +14,7 @@ SRC_URI = "\
 file://default \
 file://rngd.service \
 "
-SRCREV = "2ea13473fd5bfea3c861dc0e23bd65e2afe8007b"
+SRCREV = "a2cd12bc253a014328b87137559fd4e1ab296d9b"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151751): 
https://lists.openembedded.org/g/openembedded-core/message/151751
Mute This Topic: https://lists.openembedded.org/mt/82815423/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] vulkan-tools: upgrade 1.2.170.0 -> 1.2.176.0

[wangmy]

Signed-off-by: Wang Mingyu 
---
 .../{vulkan-tools_1.2.170.0.bb => vulkan-tools_1.2.176.0.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/vulkan/{vulkan-tools_1.2.170.0.bb => 
vulkan-tools_1.2.176.0.bb} (94%)

diff --git a/meta/recipes-graphics/vulkan/vulkan-tools_1.2.170.0.bb 
b/meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
similarity index 94%
rename from meta/recipes-graphics/vulkan/vulkan-tools_1.2.170.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
index 0c8bcaa085..10fa0fdb3a 100644
--- a/meta/recipes-graphics/vulkan/vulkan-tools_1.2.170.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-tools_1.2.176.0.bb
@@ -6,8 +6,8 @@ SECTION = "libs"
 
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=3b83ef96387f14655fc854ddc3c6bd57"
-SRC_URI = "git://github.com/KhronosGroup/Vulkan-Tools.git;branch=sdk-1.2.170"
-SRCREV = "88ea55de928a08ba5c5f65a93d1e7c8f666fc43f"
+SRC_URI = "git://github.com/KhronosGroup/Vulkan-Tools.git;branch=sdk-1.2.176"
+SRCREV = "eb3d67bd17ee433e2b0a8e56a7249bd83908812e"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151750): 
https://lists.openembedded.org/g/openembedded-core/message/151750
Mute This Topic: https://lists.openembedded.org/mt/82814717/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] vulkan-headers: upgrade 1.2.170.0 -> 1.2.176.0

[wangmy]

Signed-off-by: Wang Mingyu 
---
 ...{vulkan-headers_1.2.170.0.bb => vulkan-headers_1.2.176.0.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/vulkan/{vulkan-headers_1.2.170.0.bb => 
vulkan-headers_1.2.176.0.bb} (93%)

diff --git a/meta/recipes-graphics/vulkan/vulkan-headers_1.2.170.0.bb 
b/meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
similarity index 93%
rename from meta/recipes-graphics/vulkan/vulkan-headers_1.2.170.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
index 4c9c94f3d2..cff654a06c 100644
--- a/meta/recipes-graphics/vulkan/vulkan-headers_1.2.170.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-headers_1.2.176.0.bb
@@ -11,7 +11,7 @@ LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=3b83ef96387f14655fc854ddc3c6bd57"
 SRC_URI = "git://github.com/KhronosGroup/Vulkan-Headers.git;branch=master"
 
-SRCREV = "1d99b835ec3cd5a7fb2f2a2dd9a615ee2d1f0101"
+SRCREV = "074fa3055cfee530992bcbfa0fcb23106a82c1ab"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151748): 
https://lists.openembedded.org/g/openembedded-core/message/151748
Mute This Topic: https://lists.openembedded.org/mt/82814715/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] vulkan-loader: upgrade 1.2.170.0 -> 1.2.176.0

[wangmy]

Signed-off-by: Wang Mingyu 
---
 .../{vulkan-loader_1.2.170.0.bb => vulkan-loader_1.2.176.0.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/vulkan/{vulkan-loader_1.2.170.0.bb => 
vulkan-loader_1.2.176.0.bb} (96%)

diff --git a/meta/recipes-graphics/vulkan/vulkan-loader_1.2.170.0.bb 
b/meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
similarity index 96%
rename from meta/recipes-graphics/vulkan/vulkan-loader_1.2.170.0.bb
rename to meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
index 6b6ed06dbb..e241a2f156 100644
--- a/meta/recipes-graphics/vulkan/vulkan-loader_1.2.170.0.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-loader_1.2.176.0.bb
@@ -11,7 +11,7 @@ LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=7dbefed23242760aa3475ee42801c5ac"
 SRC_URI = "git://github.com/KhronosGroup/Vulkan-Loader.git \
"
-SRCREV = "c5678a03db383fd0dc5bfb8e9a383043bdbcb57b"
+SRCREV = "eb6d6f95dff809d66e95b903105da6424e75862f"
 
 S = "${WORKDIR}/git"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151749): 
https://lists.openembedded.org/g/openembedded-core/message/151749
Mute This Topic: https://lists.openembedded.org/mt/82814716/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] vulkan-samples: update to latest revision

[wangmy]

Signed-off-by: Wang Mingyu 
---
 meta/recipes-graphics/vulkan/vulkan-samples_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb 
b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
index 32502a1f7a..e89f75baac 100644
--- a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
@@ -11,7 +11,7 @@ SRC_URI = "gitsm://github.com/KhronosGroup/Vulkan-Samples.git 
\
"
 
 UPSTREAM_CHECK_COMMITS = "1"
-SRCREV = "a2c02a074ba3f71ea89a53fb2e2d189c87cc4af8"
+SRCREV = "5646820bdd46365183adc2b326556c5bf7d8db76"
 
 UPSTREAM_CHECK_GITTAGREGEX = "These are not the releases you're looking for"
 S = "${WORKDIR}/git"
-- 
2.25.1


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

[OE-core] [PATCH] python3-six: upgrade 1.15.0 -> 1.16.0

[wangmy]

Signed-off-by: Wang Mingyu 
---
 meta/recipes-devtools/python/python3-six_1.15.0.bb | 5 -
 meta/recipes-devtools/python/python3-six_1.16.0.bb | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)
 delete mode 100644 meta/recipes-devtools/python/python3-six_1.15.0.bb
 create mode 100644 meta/recipes-devtools/python/python3-six_1.16.0.bb

diff --git a/meta/recipes-devtools/python/python3-six_1.15.0.bb 
b/meta/recipes-devtools/python/python3-six_1.15.0.bb
deleted file mode 100644
index 6c6f3f9629..00
--- a/meta/recipes-devtools/python/python3-six_1.15.0.bb
+++ /dev/null
@@ -1,5 +0,0 @@
-inherit setuptools3
-require python-six.inc
-
-SRC_URI[md5sum] = "9f90a0eaa0ea7747fda01ca79d21ebcb"
-SRC_URI[sha256sum] = 
"30639c035cdb23534cd4aa2dd52c3bf48f06e5f4a941509c8bafd8ce11080259"
diff --git a/meta/recipes-devtools/python/python3-six_1.16.0.bb 
b/meta/recipes-devtools/python/python3-six_1.16.0.bb
new file mode 100644
index 00..ce5b10c42e
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-six_1.16.0.bb
@@ -0,0 +1,5 @@
+inherit setuptools3
+require python-six.inc
+
+SRC_URI[md5sum] = "a7c927740e4964dd29b72cebfc1429bb"
+SRC_URI[sha256sum] = 
"1e61c37477a1626458e36f7b1d82aa5c9b094fa4802892072e49de9c60c4c926"
-- 
2.25.1


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

[OE-core] [PATCH] python3-attrs: upgrade 20.3.0 -> 21.2.0

[wangmy]

Signed-off-by: Wang Mingyu 
---
 .../{python3-attrs_20.3.0.bb => python3-attrs_21.2.0.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-attrs_20.3.0.bb => 
python3-attrs_21.2.0.bb} (74%)

diff --git a/meta/recipes-devtools/python/python3-attrs_20.3.0.bb 
b/meta/recipes-devtools/python/python3-attrs_21.2.0.bb
similarity index 74%
rename from meta/recipes-devtools/python/python3-attrs_20.3.0.bb
rename to meta/recipes-devtools/python/python3-attrs_21.2.0.bb
index 55cfda7180..f8ae2d2b98 100644
--- a/meta/recipes-devtools/python/python3-attrs_20.3.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_21.2.0.bb
@@ -3,8 +3,8 @@ HOMEPAGE = "http://www.attrs.org/;
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=d4ab25949a73fe7d4fdee93bcbdbf8ff"
 
-SRC_URI[sha256sum] = 
"832aa3cde19744e49938b91fea06d69ecb9e649c93ba974535d08ad92164f700"
-SRC_URI[md5sum] = "4fe38f89297b2b446d83190fce189f29"
+SRC_URI[sha256sum] = 
"ef6aaac3ca6cd92904cdd0d83f629a15f18053ec84e6432106f7a4d04ae4f5fb"
+SRC_URI[md5sum] = "06af884070d9180694becdb106e5cd65"
 
 inherit pypi setuptools3
 
-- 
2.25.1


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

[OE-core] Layer list's certificate expired

[Andreas Müller]

Hi,

On opening OE-layers browsers complain that certificate has expired
yesterday 13.th of May. Just wanted to let you know.

Cheers,

Andreas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151744): 
https://lists.openembedded.org/g/openembedded-core/message/151744
Mute This Topic: https://lists.openembedded.org/mt/82812746/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] master/main branch renaming and bitbake

[Richard Purdie]

On Thu, 2021-05-13 at 17:33 -0400, colin walters wrote:
> 
> On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
> > 
> > The advice to anyone hitting this issue is to add in the correct branch
> > to the SRC_URI. It is simple and easy to do, can be in bbappends 
> > or even changed via anonymous python and similar if necessary. We've already
> > found the issue with several core recipes, we simply updated them and most 
> > users didn't notice. I would even likely take that kind of change into older
> > otherwise unmaintained branches and I think I did so in at least one case in
> > the past.
> 
> What I am uncertain about is: how quickly does that translate into us being 
> able to remove the old branch?

My personal opinion is see the patches updating the SRC_URIs make the branches
given we know about this one and then do it.

> We're not the first project to do this and we won't be the last, so having a 
> solution here will be good.

I'm suggesting people update the recipes.

> Hmm actually I notice systemd upstream did the rename a while ago and they're 
> not carrying a `master` branch.  What's the difference between systemd and 
> ostree here?
> 
> Is it the use of `SRCREV`?  Or no, in the systemd case is it because it's set 
> to a tag?
> https://github.com/openembedded/openembedded-core/blob/2621dbbc1181808f18ca4ae79408d0d5b557670f/meta/recipes-core/systemd/systemd.inc#L18
> ostree is also using tags, is the recipe just broken in not using tags?

No:

SRCBRANCH = "v247-stable"
SRC_URI = 
"git://github.com/systemd/systemd-stable.git;protocol=git;branch=${SRCBRANCH}

i.e. there is a specific branch specified.

> > I appreciate the tooling could do all kinds of magic things. I have a strong
> > preference for not adding magic into it, or over complicating it, it is 
> > already
> > horrendously complicated and a nightmare to test. I appreciate nobody 
> > believes
> > me, I only do my best to maintain it. The code is here for anyone 
> > interested:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py
> 
> Yeah, understood.
> 
> > I'd also note you can add ;nobranch=1 to the urls or ;usehead=1. Those do
> > have side effects, I will not recommend them, or accept them for general use
> > in layers I maintain, they're considered developer options. I was reminded
> > recently that we have seen bugs the branch parameter has caught where a 
> > revision was not where we thought it was so these do catch real world 
> > issues.
> 
> Well I hope the result of this discussion is a recommended best practice at 
> least.
> If recommending using a tag works, that seems good to me.

People should add/update the branch in SRC_URI.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151743): 
https://lists.openembedded.org/g/openembedded-core/message/151743
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] gstreamer1.0-libav: remove explicit LICENSE_FLAGS

[Khem Raj]

From: Yann Dirson 

This flag does not describe the gst-libav package, but ffmpeg instead.
It gets in the way of using finer-grained LICENSE_FLAGS in ffmpeg.

It is above all not needed, the real problem is even more clear without it:

 ffmpeg was skipped: because it has a restricted license 'commercial'. Which is 
not whitelisted in LICENSE_FLAGS_WHITELIST
 ERROR: Required build target 'gstreamer1.0-libav' has no buildable providers.
 Missing or unbuildable dependency chain was: ['gstreamer1.0-libav', 'ffmpeg']

Signed-off-by: Yann Dirson 
Signed-off-by: Khem Raj 
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
index 7c39e7da37..d5b38f77c5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
@@ -4,9 +4,6 @@ muxers, and demuxers provided by FFmpeg."
 HOMEPAGE = "http://gstreamer.freedesktop.org/;
 SECTION = "multimedia"
 
-# ffmpeg has comercial license flags so add it as we need ffmpeg as a 
dependency
-LICENSE_FLAGS = "commercial"
-
 LICENSE = "LGPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
 
file://ext/libav/gstav.h;beginline=1;endline=18;md5=a752c35267d8276fd9ca3db6994fca9c
 \
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151742): 
https://lists.openembedded.org/g/openembedded-core/message/151742
Mute This Topic: https://lists.openembedded.org/mt/82811767/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] gst-examples,gstreamer1.0-libav: Add option to exclude from world build

[Khem Raj]

When LICENSE_FLAGS_WHITELIST does not have commercial in it then the
the dependencies like ffmpeg will become invisible and render these
packages unbuildable, therefore world build will report parse issues

its better to exclude them from world build in such cases

Signed-off-by: Khem Raj 
Cc: Yann Dirson 
---
 meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb   | 2 ++
 meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb 
b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
index 4670ab34db..196258e00f 100644
--- a/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb
@@ -33,3 +33,5 @@ RRECOMMENDS_${PN} = "gstreamer1.0-plugins-base-meta \
   ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
"commercial", "gstreamer1.0-libav", "", d)} \
  ${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
"commercial", "gstreamer1.0-plugins-ugly-meta", "", d)}"
 RPROVIDES_${PN} += "gst-player gst-player-bin"
+
+EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
"commercial", "0", "1", d)}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
index 6a84f92f31..7c39e7da37 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb
@@ -6,6 +6,7 @@ SECTION = "multimedia"
 
 # ffmpeg has comercial license flags so add it as we need ffmpeg as a 
dependency
 LICENSE_FLAGS = "commercial"
+
 LICENSE = "LGPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6762ed442b3822387a51c92d928ead0d \
 
file://ext/libav/gstav.h;beginline=1;endline=18;md5=a752c35267d8276fd9ca3db6994fca9c
 \
@@ -22,3 +23,5 @@ inherit meson pkgconfig upstream-version-is-even
 
 FILES_${PN} += "${libdir}/gstreamer-1.0/*.so"
 FILES_${PN}-staticdev += "${libdir}/gstreamer-1.0/*.a"
+
+EXCLUDE_FROM_WORLD = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", 
"commercial", "0", "1", d)}"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151741): 
https://lists.openembedded.org/g/openembedded-core/message/151741
Mute This Topic: https://lists.openembedded.org/mt/82811766/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] couple questions about creating companion debug filesystem

[Andre McCurdy]

On Thu, May 13, 2021 at 3:36 AM Robert P. J. Day  wrote:
>
>   couple colleagues asked me about the details of how the debug
> filesystem is created, and since i wasn't entirely clear on the
> mechanics of it myself, i thought i'd dig into it, so a couple
> preliminary questions to make sure i'm on the right track.
>
>   trivially, if you want that companion debugfs, you need only:
>
>   IMAGE_GEN_DEBUGFS = '1'
>
> at which point what kicks in is the current value of
> IMAGE_FSTYPES_DEBUGFS to determine what forms of the debugfs you want.
> by default, that's conditionally set to "tar.gz" in bitbake.conf so,
> unless you mess with it, the end result is a debugfs tarball under
> deploy/images. so far, so good.
>
>   now, if you (for no good reason) also set:
>
>   IMAGE_FSTYPES_DEBUGFS = ''
>
> in your local.conf, then even though you *claim* you want the debugfs,
> you're not going to get one since the build process has no idea what
> archive type you want. i believe this is the result of this snippet in
> image.bbclass in the anonymous python routine (line 369):
>
> if d.getVar('IMAGE_GEN_DEBUGFS') == "1":
> debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS').split()
> for t in debugfs_fstypes:
> alltypes.append("debugfs_" + t)
>
> which makes sense. however, even if you don't get the final debugfs
> tarball under deploy, i see that the *contents* of the debugfs are
> still generated under WORKDIR for the image (in my case,
> core-image-minimal), since i see both:
>
>   rootfs/
>   rootfs-dbg/
>
> and following the trail of bread crumbs to see where that came from, i
> ended up in meta/lib/oe/rootfs.py:
>
> def _setup_dbg_rootfs(self, dirs):
> gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
> if gen_debugfs != '1':
>return
>
> bb.note("  Renaming the original rootfs...")
> try:
> shutil.rmtree(self.image_rootfs + '-orig')
> except:
> pass
> bb.utils.rename(self.image_rootfs, self.image_rootfs + '-orig')
>
> ... and so on and so on ...
>
> which clearly(?) does all that work, even if, in the end, the result
> is not packaged as a tarball, which is part of what muh colleagues
> were asking about -- where can they see *exactly* how that debugfs
> content is collected?
>
>   is all this reasonably accurate so far?

Yes, I think so. Creation of the debugfs tar file uses a lot of the
same logic as creation of the rootfs image(s) so is controlled by
similar variables (e.g. IMAGE_FSTYPES_DEBUGFS is the equivalent of
IMAGE_FSTYPES). In theory you could change IMAGE_GEN_DEBUGFS to create
(for example) a squashfs image containing the debug symbols, but since
the debug symbols are going to be used on the host (and not copied
into Flash on the target etc) it doesn't make much sense to do so. In
practice the only reason you might want to change the default value of
IMAGE_GEN_DEBUGFS would be if you prefer .tar.bz2 etc over .tar.gz.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151740): 
https://lists.openembedded.org/g/openembedded-core/message/151740
Mute This Topic: https://lists.openembedded.org/mt/82795751/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] master/main branch renaming and bitbake

[colin walters]

On Thu, May 13, 2021, at 4:08 PM, Richard Purdie wrote:
>
> The advice to anyone hitting this issue is to add in the correct branch
> to the SRC_URI. It is simple and easy to do, can be in bbappends 
> or even changed via anonymous python and similar if necessary. We've already
> found the issue with several core recipes, we simply updated them and most 
> users didn't notice. I would even likely take that kind of change into older
> otherwise unmaintained branches and I think I did so in at least one case in
> the past.

What I am uncertain about is: how quickly does that translate into us being 
able to remove the old branch?

We're not the first project to do this and we won't be the last, so having a 
solution here will be good.

Hmm actually I notice systemd upstream did the rename a while ago and they're 
not carrying a `master` branch.  What's the difference between systemd and 
ostree here?

Is it the use of `SRCREV`?  Or no, in the systemd case is it because it's set 
to a tag?
https://github.com/openembedded/openembedded-core/blob/2621dbbc1181808f18ca4ae79408d0d5b557670f/meta/recipes-core/systemd/systemd.inc#L18

ostree is also using tags, is the recipe just broken in not using tags?

> I appreciate the tooling could do all kinds of magic things. I have a strong
> preference for not adding magic into it, or over complicating it, it is 
> already
> horrendously complicated and a nightmare to test. I appreciate nobody believes
> me, I only do my best to maintain it. The code is here for anyone interested:
> 
> http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py

Yeah, understood.

> I'd also note you can add ;nobranch=1 to the urls or ;usehead=1. Those do
> have side effects, I will not recommend them, or accept them for general use
> in layers I maintain, they're considered developer options. I was reminded
> recently that we have seen bugs the branch parameter has caught where a 
> revision was not where we thought it was so these do catch real world issues.

Well I hope the result of this discussion is a recommended best practice at 
least.
If recommending using a tag works, that seems good to me.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151739): 
https://lists.openembedded.org/g/openembedded-core/message/151739
Mute This Topic: https://lists.openembedded.org/mt/82782995/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][dunfell 00/25] Pull request (cover letter only)

[Richard Purdie]

On Wed, 2021-05-12 at 04:47 -1000, Steve Sakoman wrote:
> The following changes since commit 834a8e357bc999a0163e7c5bafbcc1a8816448d4:
> 
>   license_image.bbclass: Fix symlink to generic license files (2021-05-03 
> 04:56:23 -1000)
> 
> are available in the Git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
>   
> http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next
> 
> Alexander Kanavin (5):
>   diffoscope: add native libraries to LD_LIBRARY_PATH
>   Revert "oeqa: Set LD_LIBRARY_PATH when executing native commands"
>   ovmf: update to 202002
>   ovmf: update to 202005
>   ovmf: update edk2-stable202005 -> edk2-stable202008
> 
> Anatol Belski (1):
>   tar: Fix CVE-2021-20193
> 
> Bruce Ashfield (4):
>   linux-yocto/5.4: update to v5.4.114
>   linux-yocto/5.4: update to v5.4.116
>   perf: fix python-audit RDEPENDS
>   make-mod-scripts: add HOSTCXX definitions and gmp-native dependency
> 
> Christophe Chapuis (1):
>   rootfs.py: find .ko.gz and .ko.xz kernel modules as well
> 
> Jose Quaresma (1):
>   ptest-runner: libgcc must be installed for pthread_cancel to work
> 
> Joshua Watt (1):
>   classes/image: Use xargs to set file timestamps
> 
> Kai Uwe Broulik (1):
>   gstreamer1.0-plugins-good: on wayland qt5 needs qtwayland
> 
> Khem Raj (1):
>   cml1.bbclass: Return sorted list of cfg files
> 
> Lee Chee Yang (1):
>   binutils: fix CVE-2021-3487
> 
> Mark Hatle (1):
>   kernel.bbclass: Remove do_install[prefunc] no longer needed
> 
> Michael Opdenacker (1):
>   sanity.bbclass: mention CONNECTIVITY_CHECK_URIS in network failure
> message
> 
> Richard Purdie (3):
>   yocto-uninative: Update to 3.1 which includes a patchelf fix
>   pybootchart/draw: Avoid divide by zero error
>   oeqa/qemurunner: Improve logging thread exit handling for qemu
> shutdown test

I merged this branch apart from this last patch above as the author of the 
patch messed up and you'd need the subsequent fixes too ;-) It can come
together, later.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151738): 
https://lists.openembedded.org/g/openembedded-core/message/151738
Mute This Topic: https://lists.openembedded.org/mt/82773972/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] master/main branch renaming and bitbake

[Alexander Kanavin]

On Thu, 13 May 2021 at 22:34, Benjamin Gilbert 
wrote:

> Tarballs, commits on published branches, and annotated tags are all
> supposed to be stable artifacts.  But I don't know of any general
> expectation that a specific branch continues to exist, other than the one
> created by Bitbake.  GitHub's branch rename tool doesn't leave the old
> branch behind, not even a symref, so I don't think this is a fringe
> viewpoint.  And as I said, automated builds usually only care about tags,
> commits, and the default branch.
>

Just wanted to add that there's a reason Yocto doesn't use tags alone: they
can and do move from one commit to another, and to the best of my knowledge
there only way to tie them to a commit is to specify the commit too.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151737): 
https://lists.openembedded.org/g/openembedded-core/message/151737
Mute This Topic: https://lists.openembedded.org/mt/82782995/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 8/8] qemu: backport a patch to fix meson 0.58 builds

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 ...igure-fix-detection-of-gdbus-codegen.patch | 53 +++
 2 files changed, 54 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-configure-fix-detection-of-gdbus-codegen.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 82d1cb5566..74c53c6309 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -57,6 +57,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2020-27821.patch \
file://CVE-2021-20263.patch \
file://CVE-2021-3392.patch \
+   file://0001-configure-fix-detection-of-gdbus-codegen.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-configure-fix-detection-of-gdbus-codegen.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-configure-fix-detection-of-gdbus-codegen.patch
new file mode 100644
index 00..1f20077883
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-configure-fix-detection-of-gdbus-codegen.patch
@@ -0,0 +1,53 @@
+From 464cfc64201b21386030b8f353fe9724a3413a85 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini 
+Date: Wed, 5 May 2021 10:15:34 -0400
+Subject: [PATCH] configure: fix detection of gdbus-codegen
+
+"pkg-config --variable=gdbus_codegen gio-2.0" returns "gdbus-codegen",
+and it does not pass test -x (which does not walk the path).
+
+Meson 0.58.0 notices that something is iffy, as the dbus_vmstate1
+assignment in tests/qtest/meson.build uses an empty string as the
+command, and fails very eloquently:
+
+../tests/qtest/meson.build:92:2: ERROR: No program name specified.
+
+Use the "has" function instead of test -x, and fix the generation
+of config-host.mak since meson.build expects that GDBUS_CODEGEN
+is absent, rather than empty, if the tool is unavailable.
+
+Reported-by: Sebastian Mitterle 
+Fixes: #178
+Signed-off-by: Paolo Bonzini 
+Upstream-Status: Backport 
[https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5ecfb76ccc056eb6127e44268e475827ae73b9e0]
+(not in 6.0.0, should be kept when upgrading)
+Signed-off-by: Alexander Kanavin 
+---
+ configure | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/configure b/configure
+index 18c26e0389..4c36e221d3 100755
+--- a/configure
 b/configure
+@@ -3496,7 +3496,7 @@ if $pkg_config --atleast-version=$glib_req_ver gio-2.0; 
then
+ gio_cflags=$($pkg_config --cflags gio-2.0)
+ gio_libs=$($pkg_config --libs gio-2.0)
+ gdbus_codegen=$($pkg_config --variable=gdbus_codegen gio-2.0)
+-if [ ! -x "$gdbus_codegen" ]; then
++if ! has "$gdbus_codegen"; then
+ gdbus_codegen=
+ fi
+ # Check that the libraries actually work -- Ubuntu 18.04 ships
+@@ -6172,6 +6172,8 @@ if test "$gio" = "yes" ; then
+ echo "CONFIG_GIO=y" >> $config_host_mak
+ echo "GIO_CFLAGS=$gio_cflags" >> $config_host_mak
+ echo "GIO_LIBS=$gio_libs" >> $config_host_mak
++fi
++if test "$gdbus_codegen" != "" ; then
+ echo "GDBUS_CODEGEN=$gdbus_codegen" >> $config_host_mak
+ fi
+ echo "CONFIG_TLS_PRIORITY=\"$tls_priority\"" >> $config_host_mak
+-- 
+2.24.0
+
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151736): 
https://lists.openembedded.org/g/openembedded-core/message/151736
Mute This Topic: https://lists.openembedded.org/mt/82809623/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 7/8] gstreamer1.0-plugins-base: backport a patch to fix meson 0.58 builds

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 ...c91697a141fea7317aff7f0f28e5a861db99.patch | 50 +++
 .../gstreamer1.0-plugins-base_1.18.4.bb   |  1 +
 2 files changed, 51 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/4ef5c91697a141fea7317aff7f0f28e5a861db99.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/4ef5c91697a141fea7317aff7f0f28e5a861db99.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/4ef5c91697a141fea7317aff7f0f28e5a861db99.patch
new file mode 100644
index 00..a2f5dff5e9
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/4ef5c91697a141fea7317aff7f0f28e5a861db99.patch
@@ -0,0 +1,50 @@
+From 4ef5c91697a141fea7317aff7f0f28e5a861db99 Mon Sep 17 00:00:00 2001
+From: Xavier Claessens 
+Date: Mon, 26 Apr 2021 14:25:03 -0400
+Subject: [PATCH] gstgl: Fix build when Meson >= 0.58.0rc1
+
+"implicit_include_directories: false" now also means that current build
+directory is not added to include paths by default any more. We have to
+add it manually because we have some custom_target() that generate
+headers in current build directory.
+
+See https://github.com/mesonbuild/meson/issues/8700.
+
+Part-of: 

+Upstream-Status: Backport
+Signed-off-by: Alexander Kanavin 
+---
+ gst-libs/gst/gl/meson.build | 15 ---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/gst-libs/gst/gl/meson.build b/gst-libs/gst/gl/meson.build
+index 8644e..53891625a 100644
+--- a/gst-libs/gst/gl/meson.build
 b/gst-libs/gst/gl/meson.build
+@@ -1004,11 +1004,20 @@ if build_gstgl
+ command : [mkenums, glib_mkenums, '@OUTPUT@', '@INPUT@'])
+   gen_sources = [gl_enumtypes_h]
+ 
++  common_args = gst_plugins_base_args + gl_cpp_args + ['-DBUILDING_GST_GL']
++
++  # We have custom_target() that generate headers in the current build dir,
++  # but with implicit_include_directories: false, meson >= 0.58.0 won't 
include
++  # it by default. We cannot use include_directories('.') here because it 
would
++  # also include current source dir which is what we want to avoid because
++  # case-insensitive FS would include gst-libs/gl/egl/egl.h as EGL/egl.h.
++  common_args += '-I@0@'.format(meson.current_build_dir())
++
+   gstgl = library('gstgl-' + api_version,
+ gl_sources, gl_egl_sources, gl_x11_sources, gl_wayland_sources, 
gl_priv_sources, gl_enumtypes_c, gl_enumtypes_h,
+-c_args : gst_plugins_base_args + gl_cpp_args + ['-DBUILDING_GST_GL'],
+-cpp_args : gst_plugins_base_args + gl_cpp_args + ['-DBUILDING_GST_GL'],
+-objc_args : gst_plugins_base_args + gl_cpp_args + gl_objc_args + 
['-DBUILDING_GST_GL'],
++c_args : common_args,
++cpp_args : common_args,
++objc_args : common_args + gl_objc_args,
+ include_directories : [configinc, libsinc, gl_includes],
+ version : libversion,
+ soversion : soversion,
+-- 
+GitLab
+
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.4.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.4.bb
index beddfb0386..73b433ab91 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.4.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.18.4.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"https://gstreamer.freedesktop.org/src/gst-plugins-base/gst-plugins-ba
file://0003-viv-fb-Make-sure-config.h-is-included.patch \
file://0002-ssaparse-enhance-SSA-text-lines-parsing.patch \
file://0004-glimagesink-Downrank-to-marginal.patch \
+   file://4ef5c91697a141fea7317aff7f0f28e5a861db99.patch \
"
 SRC_URI[sha256sum] = 
"29e53229a84d01d722f6f6db13087231cdf6113dd85c25746b9b58c3d68e8323"
 
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151735): 
https://lists.openembedded.org/g/openembedded-core/message/151735
Mute This Topic: https://lists.openembedded.org/mt/82809621/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/8] meson: update 0.57.2 -> 0.58.0

[Alexander Kanavin]

Rebase patches; dropped chunks (and cross-prop-default.patch)
have been removed upstream.

Move native-only patches to all-patches, as they're a pain to rebase
separately.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/meson/meson.inc |  11 +-
 .../0001-Make-CPU-family-warnings-fatal.patch |  18 +-
 ...sues-that-arise-when-cross-compiling.patch |   8 +-
 ...-not-manipulate-the-environment-when.patch |  14 +-
 ...pport-building-allarch-recipes-again.patch |  10 +-
 .../meson/meson/0003-native_bindir.patch  |  58 +--
 ...2c19e693a69b0650ce6c8a8903163c959996.patch | 412 ++
 .../meson/meson/cross-prop-default.patch  |  23 -
 .../{meson_0.57.2.bb => meson_0.58.0.bb}  |   0
 ...on_0.57.2.bb => nativesdk-meson_0.58.0.bb} |   0
 10 files changed, 456 insertions(+), 98 deletions(-)
 create mode 100644 
meta/recipes-devtools/meson/meson/4e312c19e693a69b0650ce6c8a8903163c959996.patch
 delete mode 100644 meta/recipes-devtools/meson/meson/cross-prop-default.patch
 rename meta/recipes-devtools/meson/{meson_0.57.2.bb => meson_0.58.0.bb} (100%)
 rename meta/recipes-devtools/meson/{nativesdk-meson_0.57.2.bb => 
nativesdk-meson_0.58.0.bb} (100%)

diff --git a/meta/recipes-devtools/meson/meson.inc 
b/meta/recipes-devtools/meson/meson.inc
index 10e7d8a1ce..f60381453b 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -12,16 +12,13 @@ SRC_URI = 
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://0003-native_bindir.patch \

file://0001-python-module-do-not-manipulate-the-environment-when.patch \
file://disable-rpath-handling.patch \
-   file://cross-prop-default.patch \

file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
file://gi-target-dep.patch \
+   file://0001-Make-CPU-family-warnings-fatal.patch \
+   file://0002-Support-building-allarch-recipes-again.patch \
+   file://4e312c19e693a69b0650ce6c8a8903163c959996.patch \
"
-SRC_URI[sha256sum] = 
"3a83e7b1c5de94fa991ec34d9b198d94f38ed699d3524cb0fdf3b99fd23d4cc5"
-
-SRC_URI_append_class-native = " \
-file://0001-Make-CPU-family-warnings-fatal.patch \
-file://0002-Support-building-allarch-recipes-again.patch \
-"
+SRC_URI[sha256sum] = 
"f4820df0bc969c99019fd4af8ca5f136ee94c63d8a5ad67e7eb73bdbc9182fdd"
 
 UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases;
 UPSTREAM_CHECK_REGEX = "meson-(?P\d+(\.\d+)+)\.tar"
diff --git 
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch 
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
index 300797f9ee..bcccfabd17 100644
--- 
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
+++ 
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
@@ -1,34 +1,33 @@
-From 198e2de24adf5845e3ba389b533cf43440ee8acb Mon Sep 17 00:00:00 2001
+From b64032a2eb1fb760f4ffd5b4b666e2433cf80d39 Mon Sep 17 00:00:00 2001
 From: Ross Burton 
 Date: Tue, 3 Jul 2018 13:59:09 +0100
-Subject: [PATCH] Make CPU family warnings fatal
+Subject: [PATCH 1/2] Make CPU family warnings fatal
 
 Upstream-Status: Inappropriate [OE specific]
 Signed-off-by: Ross Burton 
-
 ---
  mesonbuild/envconfig.py   | 2 +-
  mesonbuild/environment.py | 4 +---
  2 files changed, 2 insertions(+), 4 deletions(-)
 
 diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
-index ba35d16..2d3c34c 100644
+index c6a4df3..4d58c91 100644
 --- a/mesonbuild/envconfig.py
 +++ b/mesonbuild/envconfig.py
-@@ -262,7 +262,7 @@ class MachineInfo:
+@@ -266,7 +266,7 @@ class MachineInfo:
  
  cpu_family = literal['cpu_family']
  if cpu_family not in known_cpu_families:
--mlog.warning('Unknown CPU family {}, please report this at 
https://github.com/mesonbuild/meson/issues/new'.format(cpu_family))
+-mlog.warning(f'Unknown CPU family {cpu_family}, please report 
this at https://github.com/mesonbuild/meson/issues/new')
 +raise EnvironmentException('Unknown CPU family {}, see 
https://wiki.yoctoproject.org/wiki/Meson/UnknownCPU for 
directions.'.format(cpu_family))
  
  endian = literal['endian']
  if endian not in ('little', 'big'):
 diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
-index 756dd81..4d2c2b6 100644
+index fc9b703..eea8345 100644
 --- a/mesonbuild/environment.py
 +++ b/mesonbuild/environment.py
-@@ -434,9 +434,7 @@ def detect_cpu_family(compilers: CompilersDict) -> str:
+@@ -436,9 +436,7 @@ def detect_cpu_family(compilers: CompilersDict) -> str:
  trial = 'ppc64'
  
  if trial not in known_cpu_families:
@@ -39,3 +38,6 @@ index 756dd81..4d2c2b6 100644
  
  return trial
  
+-- 
+2.24.0
+
diff --git 
a/meta/recipes-devtools/meson/meson/0001-gtkdoc-fix-issues-that-arise-when-cross-compiling.patch
 

[OE-core] [PATCH 6/8] nativesdk-meson: correctly set cpu_family

[Alexander Kanavin]

This was a warning before, but with the patch
that turns it into an error, it needs to be properly addressed.

Signed-off-by: Alexander Kanavin 
---
 .../meson/nativesdk-meson_0.58.0.bb| 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-devtools/meson/nativesdk-meson_0.58.0.bb 
b/meta/recipes-devtools/meson/nativesdk-meson_0.58.0.bb
index 8778cab124..74e1a7104a 100644
--- a/meta/recipes-devtools/meson/nativesdk-meson_0.58.0.bb
+++ b/meta/recipes-devtools/meson/nativesdk-meson_0.58.0.bb
@@ -1,21 +1,11 @@
 include meson.inc
 
-inherit siteinfo
+inherit meson-routines
 inherit nativesdk
 
 SRC_URI += "file://meson-setup.py \
 file://meson-wrapper"
 
-def meson_endian(prefix, d):
-arch, os = d.getVar(prefix + "_ARCH"), d.getVar(prefix + "_OS")
-sitedata = siteinfo_data_for_machine(arch, os, d)
-if "endian-little" in sitedata:
-return "little"
-elif "endian-big" in sitedata:
-return "big"
-else:
-bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
-
 # The cross file logic is similar but not identical to that in meson.bbclass,
 # since it's generating for an SDK rather than a cross-compile. Important
 # differences are:
@@ -44,7 +34,7 @@ sys_root = @OECORE_TARGET_SYSROOT
 
 [host_machine]
 system = '${SDK_OS}'
-cpu_family = '${SDK_ARCH}'
+cpu_family = '${@meson_cpu_family("SDK_ARCH", d)}'
 cpu = '${SDK_ARCH}'
 endian = '${@meson_endian("SDK", d)}'
 EOF
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151734): 
https://lists.openembedded.org/g/openembedded-core/message/151734
Mute This Topic: https://lists.openembedded.org/mt/82809620/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 5/8] meson.bbclass: split python routines into a separate class

[Alexander Kanavin]

This allows reusing them in nativesdk-meson without copy-pasting code.

Signed-off-by: Alexander Kanavin 
---
 meta/classes/meson-routines.bbclass | 51 
 meta/classes/meson.bbclass  | 52 +
 2 files changed, 52 insertions(+), 51 deletions(-)
 create mode 100644 meta/classes/meson-routines.bbclass

diff --git a/meta/classes/meson-routines.bbclass 
b/meta/classes/meson-routines.bbclass
new file mode 100644
index 00..be3aeedeba
--- /dev/null
+++ b/meta/classes/meson-routines.bbclass
@@ -0,0 +1,51 @@
+inherit siteinfo
+
+def meson_array(var, d):
+items = d.getVar(var).split()
+return repr(items[0] if len(items) == 1 else items)
+
+# Map our ARCH values to what Meson expects:
+# http://mesonbuild.com/Reference-tables.html#cpu-families
+def meson_cpu_family(var, d):
+import re
+arch = d.getVar(var)
+if arch == 'powerpc':
+return 'ppc'
+elif arch == 'powerpc64' or arch == 'powerpc64le':
+return 'ppc64'
+elif arch == 'armeb':
+return 'arm'
+elif arch == 'aarch64_be':
+return 'aarch64'
+elif arch == 'mipsel':
+return 'mips'
+elif arch == 'mips64el':
+return 'mips64'
+elif re.match(r"i[3-6]86", arch):
+return "x86"
+elif arch == "microblazeel":
+return "microblaze"
+else:
+return arch
+
+# Map our OS values to what Meson expects:
+# https://mesonbuild.com/Reference-tables.html#operating-system-names
+def meson_operating_system(var, d):
+os = d.getVar(var)
+if "mingw" in os:
+return "windows"
+# avoid e.g 'linux-gnueabi'
+elif "linux" in os:
+return "linux"
+else:
+return os
+
+def meson_endian(prefix, d):
+arch, os = d.getVar(prefix + "_ARCH"), d.getVar(prefix + "_OS")
+sitedata = siteinfo_data_for_machine(arch, os, d)
+if "endian-little" in sitedata:
+return "little"
+elif "endian-big" in sitedata:
+return "big"
+else:
+bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index bf9b02e06e..8ae0285f72 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -1,4 +1,4 @@
-inherit siteinfo python3native
+inherit python3native meson-routines
 
 DEPENDS_append = " meson-native ninja-native"
 
@@ -35,56 +35,6 @@ MESON_CROSS_FILE = ""
 MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
 MESON_CROSS_FILE_class-nativesdk = "--cross-file ${WORKDIR}/meson.cross"
 
-def meson_array(var, d):
-items = d.getVar(var).split()
-return repr(items[0] if len(items) == 1 else items)
-
-# Map our ARCH values to what Meson expects:
-# http://mesonbuild.com/Reference-tables.html#cpu-families
-def meson_cpu_family(var, d):
-import re
-arch = d.getVar(var)
-if arch == 'powerpc':
-return 'ppc'
-elif arch == 'powerpc64' or arch == 'powerpc64le':
-return 'ppc64'
-elif arch == 'armeb':
-return 'arm'
-elif arch == 'aarch64_be':
-return 'aarch64'
-elif arch == 'mipsel':
-return 'mips'
-elif arch == 'mips64el':
-return 'mips64'
-elif re.match(r"i[3-6]86", arch):
-return "x86"
-elif arch == "microblazeel":
-return "microblaze"
-else:
-return arch
-
-# Map our OS values to what Meson expects:
-# https://mesonbuild.com/Reference-tables.html#operating-system-names
-def meson_operating_system(var, d):
-os = d.getVar(var)
-if "mingw" in os:
-return "windows"
-# avoid e.g 'linux-gnueabi'
-elif "linux" in os:
-return "linux"
-else:
-return os
-
-def meson_endian(prefix, d):
-arch, os = d.getVar(prefix + "_ARCH"), d.getVar(prefix + "_OS")
-sitedata = siteinfo_data_for_machine(arch, os, d)
-if "endian-little" in sitedata:
-return "little"
-elif "endian-big" in sitedata:
-return "big"
-else:
-bb.fatal("Cannot determine endianism for %s-%s" % (arch, os))
-
 addtask write_config before do_configure
 do_write_config[vardeps] += "CC CXX LD AR NM STRIP READELF CFLAGS CXXFLAGS 
LDFLAGS"
 do_write_config() {
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151733): 
https://lists.openembedded.org/g/openembedded-core/message/151733
Mute This Topic: https://lists.openembedded.org/mt/82809619/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/8] expat: upgrade 2.2.10 -> 2.3.0

[Alexander Kanavin]

Drop 0001-Add-output-of-tests-result.patch
(difficult to rebase). I have verified that ptests
still pass, and print PASS for every test. If they
start failing we can revisit what kind of output would
be beneficial.

Signed-off-by: Alexander Kanavin 
---
 .../0001-Add-output-of-tests-result.patch | 83 ---
 meta/recipes-core/expat/expat/run-ptest   |  4 +-
 .../expat/{expat_2.2.10.bb => expat_2.3.0.bb} |  7 +-
 3 files changed, 5 insertions(+), 89 deletions(-)
 delete mode 100644 
meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch
 rename meta/recipes-core/expat/{expat_2.2.10.bb => expat_2.3.0.bb} (81%)

diff --git 
a/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch 
b/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch
deleted file mode 100644
index c5c18ead74..00
--- a/meta/recipes-core/expat/expat/0001-Add-output-of-tests-result.patch
+++ /dev/null
@@ -1,83 +0,0 @@
-From aa84835a00bfd65e784d58411e76f60658e939dc Mon Sep 17 00:00:00 2001
-From: Oleksandr Popovych 
-Date: Tue, 18 Feb 2020 19:04:55 +0200
-Subject: [PATCH] Add output of tests result
-
-Added console output of testing results in form 'RESULT: TEST_NAME'.
-
-Changed verbose mode of test application set by '-v' ('--verbose')
-argument to CK_NORMAL.
-Added new supported argument '-vv' ('--extra-verbose') that changes
-verbose mode of test application to CK_VERBOSE. Results of each test
-are shown in output only if this mode is set.
-
-Upstream-Status: Denied
-
-This patch changes potentially deprecated feature that shoud be changed
-in upstream. [https://github.com/libexpat/libexpat/issues/382]
-
-Signed-off-by: Oleksandr Popovych 

- tests/minicheck.c | 10 +-
- tests/runtests.c  |  4 +++-
- 2 files changed, 12 insertions(+), 2 deletions(-)
-
-diff --git a/expat/tests/minicheck.c b/expat/tests/minicheck.c
-index a5a1efb..94fa412 100644
 a/tests/minicheck.c
-+++ b/tests/minicheck.c
-@@ -164,6 +164,8 @@ srunner_run_all(SRunner *runner, int verbosity) {
-   if (tc->setup != NULL) {
- /* setup */
- if (setjmp(env)) {
-+  if (verbosity >= CK_VERBOSE)
-+printf("SKIP: %s\n", _check_current_function);
-   add_failure(runner, verbosity);
-   continue;
- }
-@@ -171,6 +173,8 @@ srunner_run_all(SRunner *runner, int verbosity) {
-   }
-   /* test */
-   if (setjmp(env)) {
-+if (verbosity >= CK_VERBOSE)
-+  printf("FAIL: %s\n", _check_current_function);
- add_failure(runner, verbosity);
- continue;
-   }
-@@ -178,12 +182,16 @@ srunner_run_all(SRunner *runner, int verbosity) {
-
-   /* teardown */
-   if (tc->teardown != NULL) {
--if (setjmp(env)) {
-+if (setjmp(env)) {
-+  if (verbosity >= CK_VERBOSE)
-+   printf("PASS: %s\n", _check_current_function);
-   add_failure(runner, verbosity);
-   continue;
- }
- tc->teardown();
-   }
-+  if (verbosity >= CK_VERBOSE)
-+printf("PASS: %s\n", _check_current_function);
- }
- tc = tc->next_tcase;
-   }
-diff --git a/tests/runtests.c b/expat/tests/runtests.c
-index 7791fe0..75724e5 100644
 a/tests/runtests.c
-+++ b/tests/runtests.c
-@@ -11619,9 +11619,11 @@ main(int argc, char *argv[]) {
-   for (i = 1; i < argc; ++i) {
- char *opt = argv[i];
- if (strcmp(opt, "-v") == 0 || strcmp(opt, "--verbose") == 0)
--  verbosity = CK_VERBOSE;
-+  verbosity = CK_NORMAL;
- else if (strcmp(opt, "-q") == 0 || strcmp(opt, "--quiet") == 0)
-   verbosity = CK_SILENT;
-+else if (strcmp(opt, "-vv") == 0 || strcmp(opt, "--extra-verbose") == 0)
-+  verbosity = CK_VERBOSE;
- else {
-   fprintf(stderr, "runtests: unknown option '%s'\n", opt);
-   return 2;
---
-2.17.1
diff --git a/meta/recipes-core/expat/expat/run-ptest 
b/meta/recipes-core/expat/expat/run-ptest
index 1b39cec8e5..59d8ab57e3 100644
--- a/meta/recipes-core/expat/expat/run-ptest
+++ b/meta/recipes-core/expat/expat/run-ptest
@@ -18,6 +18,6 @@ TIME=$(which time)
 
 echo "Architecture: $(uname -m)" > ${output}
 echo "Image: $(uname -sr)" >> ${output}
-${TIME} -f 'Execution time: %e s' bash -c "testCheck runtests -vv" |& tee -a 
${output}
-${TIME} -f 'Execution time: %e s' bash -c "testCheck runtestspp -vv" |& tee -a 
${output}
+${TIME} -f 'Execution time: %e s' bash -c "testCheck runtests -v" |& tee -a 
${output}
+${TIME} -f 'Execution time: %e s' bash -c "testCheck runtestspp -v" |& tee -a 
${output}
 echo
diff --git a/meta/recipes-core/expat/expat_2.2.10.bb 
b/meta/recipes-core/expat/expat_2.3.0.bb
similarity index 81%
rename from meta/recipes-core/expat/expat_2.2.10.bb
rename to meta/recipes-core/expat/expat_2.3.0.bb
index fa263775b3..14d2855df3 100644
--- a/meta/recipes-core/expat/expat_2.2.10.bb
+++ b/meta/recipes-core/expat/expat_2.3.0.bb
@@ -8,11 +8,10 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=9e2ce3b3c4c0f2670883a23bbd7c37a9"
 

[OE-core] [PATCH 2/8] gnome: drop upstream even condition from a few recipes

[Alexander Kanavin]

They have adopted the new gnome version scheme where the distinction
is no longer:
https://lwn.net/Articles/831746/

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-gnome/epiphany/epiphany_40.1.bb| 2 +-
 meta/recipes-gnome/gnome/adwaita-icon-theme_3.34.3.bb   | 2 +-
 meta/recipes-gnome/gnome/adwaita-icon-theme_3.38.0.bb   | 2 +-
 .../gsettings-desktop-schemas_3.38.0.bb | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-gnome/epiphany/epiphany_40.1.bb 
b/meta/recipes-gnome/epiphany/epiphany_40.1.bb
index e1e3ad7868..2242e9d010 100644
--- a/meta/recipes-gnome/epiphany/epiphany_40.1.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_40.1.bb
@@ -12,7 +12,7 @@ DEPENDS = "libsoup-2.4 webkitgtk gtk+3 iso-codes avahi 
libnotify gcr gnutls \
   libarchive"
 
 GNOMEBASEBUILDCLASS = "meson"
-inherit gnomebase gsettings features_check upstream-version-is-even gettext 
mime-xdg
+inherit gnomebase gsettings features_check gettext mime-xdg
 REQUIRED_DISTRO_FEATURES = "x11 opengl"
 
 SRC_URI = "${GNOME_MIRROR}/${GNOMEBN}/${@oe.utils.trim_version("${PV}", 
1)}/${GNOMEBN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive \
diff --git a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.34.3.bb 
b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.34.3.bb
index 6cde6fffa3..61927c0dd1 100644
--- a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.34.3.bb
+++ b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.34.3.bb
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=c84cac88e46fc07647ea07e6c24eeb7c \
 
file://COPYING_CCBYSA3;md5=96143d33de3a79321b1006c4e8ed07e7 \
 file://COPYING_LGPL;md5=e6a600fd5e1d9cbde2d983680233ad02"
 
-inherit allarch autotools pkgconfig gettext gtk-icon-cache 
upstream-version-is-even
+inherit allarch autotools pkgconfig gettext gtk-icon-cache
 
 MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
diff --git a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.38.0.bb 
b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.38.0.bb
index a36a2b113c..672fbd2b07 100644
--- a/meta/recipes-gnome/gnome/adwaita-icon-theme_3.38.0.bb
+++ b/meta/recipes-gnome/gnome/adwaita-icon-theme_3.38.0.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=c84cac88e46fc07647ea07e6c24eeb7c \
 
file://COPYING_CCBYSA3;md5=96143d33de3a79321b1006c4e8ed07e7 \
 file://COPYING_LGPL;md5=e6a600fd5e1d9cbde2d983680233ad02"
 
-inherit allarch autotools pkgconfig gettext gtk-icon-cache 
upstream-version-is-even
+inherit allarch autotools pkgconfig gettext gtk-icon-cache
 
 MAJ_VER = "${@oe.utils.trim_version("${PV}", 2)}"
 SRC_URI = "${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \
diff --git 
a/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.38.0.bb
 
b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.38.0.bb
index 34681197d8..cf06af57d6 100644
--- 
a/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.38.0.bb
+++ 
b/meta/recipes-gnome/gsettings-desktop-schemas/gsettings-desktop-schemas_3.38.0.bb
@@ -11,6 +11,6 @@ DEPENDS = "glib-2.0"
 
 GNOMEBASEBUILDCLASS = "meson"
 
-inherit gnomebase gsettings gobject-introspection gettext 
upstream-version-is-even
+inherit gnomebase gsettings gobject-introspection gettext
 
 SRC_URI[archive.sha256sum] = 
"5704c8266004b296036671f223c705dc046aa694a1b1abb87c67e7d2747a8c67"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151730): 
https://lists.openembedded.org/g/openembedded-core/message/151730
Mute This Topic: https://lists.openembedded.org/mt/82809615/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/8] gdk-pixbuf: rewrite the cross-build support for tests

[Alexander Kanavin]

It was scattered over four different patches, and wasn't guarded
by a configuration option. Hopefully the new patch is acceptable
to upstream.

Signed-off-by: Alexander Kanavin 
---
 .../0001-Add-use_prebuilt_tools-option.patch  | 171 ++
 ...f-decisions-around-cross-compilation.patch |  38 
 ...bnailer-and-pixdata-cross-compile-fa.patch |  95 --
 ...nd-thumbnailer-cross-compile-failure.patch |  28 ---
 ...ailer-and-tests-also-in-cross-builds.patch |  29 ---
 .../gdk-pixbuf/gdk-pixbuf_2.42.6.bb   |   9 +-
 6 files changed, 176 insertions(+), 194 deletions(-)
 create mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Add-use_prebuilt_tools-option.patch
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Fix-a-couple-of-decisions-around-cross-compilation.patch
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Work-around-thumbnailer-and-pixdata-cross-compile-fa.patch
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Work-around-thumbnailer-cross-compile-failure.patch
 delete mode 100644 
meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0006-Build-thumbnailer-and-tests-also-in-cross-builds.patch

diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Add-use_prebuilt_tools-option.patch
 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Add-use_prebuilt_tools-option.patch
new file mode 100644
index 00..dc8d6ce724
--- /dev/null
+++ 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-Add-use_prebuilt_tools-option.patch
@@ -0,0 +1,171 @@
+From ba73bb0f3d2023839bc3b681c49b7ec1192cceb4 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Sat, 8 May 2021 21:58:54 +0200
+Subject: [PATCH] Add use_prebuilt_tools option
+
+This allows using the gdk-pixbuf tools from the host to
+build and install tests in a cross-compile scenarion.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+
+---
+ gdk-pixbuf/meson.build  | 11 +--
+ meson.build |  6 +++---
+ meson_options.txt   |  4 
+ tests/meson.build   | 16 
+ thumbnailer/meson.build | 24 ++--
+ 5 files changed, 42 insertions(+), 19 deletions(-)
+
+diff --git a/gdk-pixbuf/meson.build b/gdk-pixbuf/meson.build
+index 8b0590b..7331491 100644
+--- a/gdk-pixbuf/meson.build
 b/gdk-pixbuf/meson.build
+@@ -342,13 +342,20 @@ foreach bin: gdkpixbuf_bin
+include_directories: [ root_inc, gdk_pixbuf_inc ],
+c_args: common_cflags + gdk_pixbuf_cflags,
+install: true)
+-  meson.override_find_program(bin_name, bin)
++  if not get_option('use_prebuilt_tools')
++  meson.override_find_program(bin_name, bin)
++  endif
+ 
+   # Used in tests
+   set_variable(bin_name.underscorify(), bin)
+ endforeach
+ 
+-if not meson.is_cross_build()
++if get_option('use_prebuilt_tools')
++gdk_pixbuf_query_loaders = find_program('gdk-pixbuf-query-loaders', 
required: true)
++gdk_pixbuf_pixdata = find_program('gdk-pixbuf-pixdata', required: true)
++endif
++
++if not meson.is_cross_build() or get_option('use_prebuilt_tools')
+   # The 'loaders.cache' used for testing, so we don't accidentally
+   # load the installed cache; we always build it by default
+   loaders_cache = custom_target('loaders.cache',
+diff --git a/meson.build b/meson.build
+index 7a1409b..0bc73eb 100644
+--- a/meson.build
 b/meson.build
+@@ -403,16 +403,16 @@ subdir('gdk-pixbuf')
+ # i18n
+ subdir('po')
+ 
+-if not meson.is_cross_build()
++if not meson.is_cross_build() or get_option('use_prebuilt_tools')
+   subdir('tests')
+-  subdir('thumbnailer')
+ endif
++subdir('thumbnailer')
+ 
+ # Documentation
+ build_docs = get_option('gtk_doc') or get_option('docs')
+ subdir('docs')
+ 
+-if not meson.is_cross_build()
++if not meson.is_cross_build() or get_option('use_prebuilt_tools')
+   meson.add_install_script('build-aux/post-install.py',
+ gdk_pixbuf_bindir,
+ gdk_pixbuf_libdir,
+diff --git a/meson_options.txt b/meson_options.txt
+index 0ee6718..cc29855 100644
+--- a/meson_options.txt
 b/meson_options.txt
+@@ -49,4 +49,8 @@ option('gio_sniffing',
+description: 'Perform file type detection using GIO (Unused on MacOS 
and Windows)',
+type: 'boolean',
+value: true)
++option('use_prebuilt_tools',
++   description: 'Use prebuilt gdk-pixbuf tools from the host for 
cross-compilation',
++   type: 'boolean',
++   value: false)
+ 
+diff --git a/tests/meson.build b/tests/meson.build
+index 7c6cb11..1029e6a 100644
+--- a/tests/meson.build
 b/tests/meson.build
+@@ -5,6 +5,12 @@
+ # $PATH. Ideally we should use gnome.compile_resources() and let Meson deal 
with
+ # this problem: See https://github.com/mesonbuild/meson/issues/8266.
+ if enabled_loaders.contains('png') and host_system != 'windows'
++
++  resources_deps = [loaders_cache,]
++  if not get_option('use_prebuilt_tools')
++resources_deps += [gdk_pixbuf_pixdata,]
++  endif
++
+   # Resources; we 

Re: [OE-core] master/main branch renaming and bitbake

[Benjamin Gilbert]

On Thu, May 13, 2021 at 01:09 PM, Richard Purdie wrote:

> 
> Some of our users have complained, yes. That isn't a conscious decision on
> 
> "our" part, just a rather unfortunate and unplanned consequence of the
> fact
> we're pretty strict about declaring where we get our sources.
> 
> The advice to anyone hitting this issue is to add in the correct branch
> to the SRC_URI. It is simple and easy to do, can be in bbappends
> or even changed via anonymous python and similar if necessary. We've
> already
> found the issue with several core recipes, we simply updated them and most
> 
> users didn't notice. I would even likely take that kind of change into
> older
> otherwise unmaintained branches and I think I did so in at least one case
> in
> the past.
> 
> There is no intent to peanlize or complain, my intent is just to deal with
> 
> it like any other upstream source change, these things happen all the
> time.
> I am stating that here for any other maintainers to read and suggest they
> follow oe-core's lead.

Whoops, just saw this.  Thanks for the position statement, Richard; very much 
appreciated.

Best,
--Benjamin Gilbert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151728): 
https://lists.openembedded.org/g/openembedded-core/message/151728
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Benjamin Gilbert]

On Thu, May 13, 2021 at 01:07 PM, Alexander Kanavin wrote:

> 
> It's not that different from deleting or archiving old tarball downloads -
> yes it keeps things clean and tidy for upstream, but it will break
> someone's automated build that way, no matter how obsolete the code being
> downloaded.
> 

Tarballs, commits on published branches, and annotated tags are all supposed to 
be stable artifacts.  But I don't know of any general expectation that a 
specific branch continues to exist, other than the one created by Bitbake.  
GitHub's branch rename tool doesn't leave the old branch behind, not even a 
symref, so I don't think this is a fringe viewpoint.  And as I said, automated 
builds usually only care about tags, commits, and the default branch.

I genuinely appreciate the discussion, all.  In the two upstream projects I 
mentioned, I'm going to recommend that we re-delete the master branches after a 
reasonable migration period has elapsed.

Best,
--Benjamin Gilbert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151727): 
https://lists.openembedded.org/g/openembedded-core/message/151727
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Richard Purdie]

On Thu, 2021-05-13 at 14:25 +, Peter Kjellerstedt wrote:
> > Another reason we have the branch name is so that we can ls-remote the
> > repo
> > when using AUTOREV for SRCREV. We've tried to make it so that once a url
> > is established in SRC_URI, you can make it use AUTOREV without changes to
> > the url itself. The AUTOREV code path is in parsing which does mean we
> > need to be efficient about the revision resolution.
> 
> Wouldn't using "HEAD" instead still maintain the same properties as using 
> "master", but with the added benefit that it just works for repositories 
> that decide to use some other branch than "master" as their main branch?
> E.g., using `git clone --single-branch` (without -b) fetches HEAD and 
> whatever branch it references, which is what we want, is it not?
> > 

See the ;usehead=1 uri option.

> > 
> One problem I have with the way the branch is specified is that it is a 
> URL parameter. This means that when I want to add a bbappend to specify 
> another SRCREV, it becomes problematic if that SRCREV is on a different 
> branch than what the base recipe uses. It basically means one has to 
> use SRC_URI_remove to remove the original URL for the repository, and 
> then add a new version of the URL with SRC_URI_prepend. This obviously 
> is unrelated to the discussion about main vs. master, but I would very 
> much like to see a new variable, e.g., SRC_BRANCH, being added to 
> complement SRCREV. There is an edge case for recipes that use multiple 
> Git URLs in the SRC_URI, but they are rare, so having to specify the 
> branch using the branch= parameter in the unlikely event that those 
> repositories need different branches should be acceptable.

This is getting a little sidetracked from the original discussion. I believe
anyone changing branch urls like that can probably parameterise the url
themselves and there isn't generic demand to add more complexity...

What I do suspect we need is the ability to change url parameters in 
mirroring url mappings, which could possibly help for a few of these 
cases too. There is an open bug for that, I keep meaning to try and sort
it out.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151726): 
https://lists.openembedded.org/g/openembedded-core/message/151726
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Richard Purdie]

On Thu, 2021-05-13 at 09:27 -0400, colin walters wrote:
> 
> On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
> > 
> > I had a look at the code to try and remind myself why it is doing this. 
> 
> Thanks!
> 
> > The best answer I found is that it does support filtered fetching of 
> > remotes, i.e. it can and will only pull the branch it wants/needs rather
> > than a full repo clone. In the case of a small repo, it doesn't matter
> > much. For a large repo it can make a significant difference to the speed.
> 
> This is with `git clone --single-branch`?  Makes sense.
> 
> > We also don't run "test" commands against the remote repo, we figure out
> > what we want and then get it with small numbers of commands.
> 
> I think what I'd argue is that in the case where the remote branch is deleted,
> the tooling should fall back to listing remote branches, sort by
> most recently updated, and try finding the commit on that.
> And in practice, explicitly using `main` first in that list would make sense.
> 
> > Is explicitly specifying the branch along with the repo url such a big 
> > problem? We already have to provide the url, it isn't like we guess that
> > too.
> 
> The problem is that your build system is penalizing upstream projects that 
> are trying to migrate to using `main`.

Some of our users have complained, yes. That isn't a conscious decision on 
"our" part, just a rather unfortunate and unplanned consequence of the fact
we're pretty strict about declaring where we get our sources.

The advice to anyone hitting this issue is to add in the correct branch
to the SRC_URI. It is simple and easy to do, can be in bbappends 
or even changed via anonymous python and similar if necessary. We've already
found the issue with several core recipes, we simply updated them and most 
users didn't notice. I would even likely take that kind of change into older
otherwise unmaintained branches and I think I did so in at least one case in
the past.

There is no intent to peanlize or complain, my intent is just to deal with
it like any other upstream source change, these things happen all the time. 
I am stating that here for any other maintainers to read and suggest they 
follow oe-core's lead.

I appreciate the tooling could do all kinds of magic things. I have a strong
preference for not adding magic into it, or over complicating it, it is already
horrendously complicated and a nightmare to test. I appreciate nobody believes
me, I only do my best to maintain it. The code is here for anyone interested:

http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/git.py

I'd also note you can add ;nobranch=1 to the urls or ;usehead=1. Those do
have side effects, I will not recommend them, or accept them for general use
in layers I maintain, they're considered developer options. I was reminded
recently that we have seen bugs the branch parameter has caught where a 
revision was not where we thought it was so these do catch real world issues.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151725): 
https://lists.openembedded.org/g/openembedded-core/message/151725
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Alexander Kanavin]

On Thu, 13 May 2021 at 21:54, Benjamin Gilbert 
wrote:

> They're not useless though. As a layer maintainer I absolutely want those
> checks, as I want to be aware of any branch configuration changes upstream,
> and to ensure I'm not accepting a change in source revision that points to
> an unattached commit, or one from a branch that's not supposed to be used
> at all.
>
> Yup, if downstream packagers want to manually review such cases, no
> objection from me.  My concern is upstream getting bug reports that say
> "please reinstate this branch and never delete it again or you'll break our
> builds".  See https://github.com/ostreedev/ostree/issues/2360 and
> https://github.com/coreos/go-systemd/issues/371 for examples.
>

It's not that different from deleting or archiving old tarball downloads -
yes it keeps things clean and tidy for upstream, but it will break
someone's automated build that way, no matter how obsolete the code being
downloaded.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151724): 
https://lists.openembedded.org/g/openembedded-core/message/151724
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Konrad Weihmann]

On 13.05.21 21:54, Benjamin Gilbert wrote:

On Thu, May 13, 2021 at 12:36 PM, Alexander Kanavin wrote:

They're not useless though. As a layer maintainer I absolutely want
those checks, as I want to be aware of any branch configuration
changes upstream, and to ensure I'm not accepting a change in source
revision that points to an unattached commit, or one from a branch
that's not supposed to be used at all.

Yup, if downstream packagers want to manually review such cases, no 
objection from me.  My concern is upstream getting bug reports that say 
"please reinstate this branch and never delete it again or you'll break 
our builds".  See https://github.com/ostreedev/ostree/issues/2360 
 and 
https://github.com/coreos/go-systemd/issues/371 
 for examples.


But the genie has been out of the bottle already - revision x was 
published on branch y - so for me changing the (branch, revision) tuple 
is as suspicious as a forced rewrite.




Best,
--Benjamin Gilbert





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151723): 
https://lists.openembedded.org/g/openembedded-core/message/151723
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Benjamin Gilbert]

On Thu, May 13, 2021 at 12:36 PM, Alexander Kanavin wrote:

> 
> They're not useless though. As a layer maintainer I absolutely want those
> checks, as I want to be aware of any branch configuration changes
> upstream, and to ensure I'm not accepting a change in source revision that
> points to an unattached commit, or one from a branch that's not supposed
> to be used at all.
> 

Yup, if downstream packagers want to manually review such cases, no objection 
from me.  My concern is upstream getting bug reports that say "please reinstate 
this branch and never delete it again or you'll break our builds".  See 
https://github.com/ostreedev/ostree/issues/2360 and 
https://github.com/coreos/go-systemd/issues/371 for examples.

Best,
--Benjamin Gilbert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151722): 
https://lists.openembedded.org/g/openembedded-core/message/151722
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Konrad Weihmann]

And IMHO deleting branches upstream is just bad practice. From a 
Yocto/OE perspective I have to consider that people might want to build 
stuff in 5yrs or even 10yrs from now.
a more reasonable pattern would be to branch off from master to main, 
make main the new default but leave master untouched.


But this hard renaming of branches causes headaches when maintaining layers.

Also I'd like to point out that there are plenty of examples where it's 
just not the master>main transition, but projects deleting whole release 
branches without a trace - so for me these extra security measures do 
make sense and are really welcome.


On 13.05.21 21:36, Alexander Kanavin wrote:
On Thu, 13 May 2021 at 21:25, Benjamin Gilbert > wrote:


Deleting the branch normally affects people who are in the project's
developer community and pay attention to its announcements.  Those
folks can then simply update their local checkouts and move on with
their lives.  Everyone else just clones the default branch and maybe
checks out a particular tag or commit before building a package. 
That workflow still works after the default branch is renamed. 
Bitbake's additional checks are unusual, and impose a long-term

compatibility constraint on upstream projects that they didn't sign
up for.


They're not useless though. As a layer maintainer I absolutely want 
those checks, as I want to be aware of any branch configuration changes 
upstream, and to ensure I'm not accepting a change in source revision 
that points to an unattached commit, or one from a branch that's not 
supposed to be used at all.


Alex





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151721): 
https://lists.openembedded.org/g/openembedded-core/message/151721
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Alexander Kanavin]

On Thu, 13 May 2021 at 21:25, Benjamin Gilbert 
wrote:

> Deleting the branch normally affects people who are in the project's
> developer community and pay attention to its announcements.  Those folks
> can then simply update their local checkouts and move on with their lives.
> Everyone else just clones the default branch and maybe checks out a
> particular tag or commit before building a package.  That workflow still
> works after the default branch is renamed.  Bitbake's additional checks are
> unusual, and impose a long-term compatibility constraint on upstream
> projects that they didn't sign up for.
>

They're not useless though. As a layer maintainer I absolutely want those
checks, as I want to be aware of any branch configuration changes upstream,
and to ensure I'm not accepting a change in source revision that points to
an unattached commit, or one from a branch that's not supposed to be used
at all.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151720): 
https://lists.openembedded.org/g/openembedded-core/message/151720
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Bruce Ashfield]

On Thu, May 13, 2021 at 3:25 PM Benjamin Gilbert  wrote:
>
> On Thu, May 13, 2021 at 12:04 PM, Bruce Ashfield wrote:
>
> Deleting the branch penalizes existing developers, which projects might be 
> willing to do. Git branch names don't usually have any effect on users.
>
> I'm not sure I see the distinction you are trying to draw.
>
> Deleting the branch normally affects people who are in the project's 
> developer community and pay attention to its announcements.  Those folks can 
> then simply update their local checkouts and move on with their lives.  
> Everyone else just clones the default branch and maybe checks out a 
> particular tag or commit before building a package.  That workflow still 
> works after the default branch is renamed.  Bitbake's additional checks are 
> unusual, and impose a long-term compatibility constraint on upstream projects 
> that they didn't sign up for.

By "user",  I simply meant consumer. (I'm aware of what a developer is
and how they typically work).

We'll agree to disagree on the finer points, since arguing semantics
of good repository management/behaviour is not a good use of time.

Cheers,

Bruce

>
> --Benjamin Gilbert
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151719): 
https://lists.openembedded.org/g/openembedded-core/message/151719
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Benjamin Gilbert]

On Thu, May 13, 2021 at 12:04 PM, Bruce Ashfield wrote:

> 
> 
>> Deleting the branch penalizes existing developers, which projects might be
>> willing to do. Git branch names don't usually have any effect on users.
> 
> I'm not sure I see the distinction you are trying to draw.

Deleting the branch normally affects people who are in the project's developer 
community and pay attention to its announcements.  Those folks can then simply 
update their local checkouts and move on with their lives.  Everyone else just 
clones the default branch and maybe checks out a particular tag or commit 
before building a package.  That workflow still works after the default branch 
is renamed.  Bitbake's additional checks are unusual, and impose a long-term 
compatibility constraint on upstream projects that they didn't sign up for.

--Benjamin Gilbert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151718): 
https://lists.openembedded.org/g/openembedded-core/message/151718
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Bruce Ashfield]

On Thu, May 13, 2021 at 3:02 PM Benjamin Gilbert  wrote:
>
> On Thu, May 13, 2021 at 06:36 AM, Bruce Ashfield wrote:
>
> The problem is that your build system is penalizing upstream projects that 
> are trying to migrate
> to using `main`.
>
> Similarly those same projects are completely deleting those branches,
> versus no longer making them the default. Which is penalizing the
> existing users.
>
> Deleting the branch penalizes existing developers, which projects might be 
> willing to do.  Git branch names don't usually have any effect on users.
>

I'm not sure I see the distinction you are trying to draw.

We are somewhere between developers and users, but again .. it's not
really a relevant distinction.

Bruce

> --Benjamin Gilbert
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151717): 
https://lists.openembedded.org/g/openembedded-core/message/151717
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[Benjamin Gilbert]

On Thu, May 13, 2021 at 06:36 AM, Bruce Ashfield wrote:

> 
> 
>> The problem is that your build system is penalizing upstream projects that
>> are trying to migrate
>> to using `main`.
> 
> Similarly those same projects are completely deleting those branches,
> versus no longer making them the default. Which is penalizing the
> existing users.

Deleting the branch penalizes existing developers, which projects might be 
willing to do.  Git branch names don't usually have any effect on users.

--Benjamin Gilbert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151716): 
https://lists.openembedded.org/g/openembedded-core/message/151716
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] libnotify: Make gtk+3 dependency optional

[Khem Raj]

On Thu, May 13, 2021 at 9:15 AM Mike Crowe via lists.openembedded.org
 wrote:
>
> libnotify only requires gtk+3 for its tests. Let's disable them by
> default.
>
> Signed-off-by: Mike Crowe 
> ---
>  meta/recipes-gnome/libnotify/libnotify_0.7.9.bb | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb 
> b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
> index bbbd72193e..0dc3dc3a3c 100644
> --- a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
> +++ b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
> @@ -9,15 +9,16 @@ SECTION = "libs"
>  LICENSE = "LGPLv2.1"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
>
> -DEPENDS = "dbus gtk+3 glib-2.0"
> +DEPENDS = "dbus glib-2.0 gdk-pixbuf"
> +
> +PACKAGECONFIG ?= ""
> +PACKAGECONFIG[gtk+] = "-Dtests=true,-Dtests=false,gtk+3"
>
perhaps knob should be called 'tests'

>  GNOMEBASEBUILDCLASS = "meson"
>  GTKDOC_MESON_OPTION = "gtk_doc"
>  GIR_MESON_ENABLE_FLAG = "enabled"
>  GIR_MESON_DISABLE_FLAG = "disabled"
>  inherit gnomebase gtk-doc features_check gobject-introspection
> -# depends on gtk+3
> -ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
>

do we need to check for them when tests are enabled ?

>  SRC_URI[archive.md5sum] = "ccd9c53364174cc8d13e18a1988faa76"
>  SRC_URI[archive.sha256sum] = 
> "66c0517ed16df7af258e83208faaf5069727dfd66995c4bbc51c16954d674761"
> --
> 2.30.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151715): 
https://lists.openembedded.org/g/openembedded-core/message/151715
Mute This Topic: https://lists.openembedded.org/mt/82803205/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] ovmf: Disable lto to aid reproducibility

[Khem Raj]

On Wed, May 12, 2021 at 4:12 PM Richard Purdie
 wrote:
>
> On Wed, 2021-05-12 at 16:04 -0700, Khem Raj wrote:
> > On Wed, May 12, 2021 at 2:32 PM Richard Purdie
> >  wrote:
> > >
> > > lto tends to break reproducibility and makes ovmf near impossible to debug
> > > reproducibility issues in. Disable it and supress the warnings that then
> > > generates from Werror.
> > >
> > > Signed-off-by: Richard Purdie 
> > > ---
> > >  meta/recipes-core/ovmf/ovmf_git.bb | 9 -
> > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/ovmf/ovmf_git.bb 
> > > b/meta/recipes-core/ovmf/ovmf_git.bb
> > > index 1fe01146d6b..ef5545bf705 100644
> > > --- a/meta/recipes-core/ovmf/ovmf_git.bb
> > > +++ b/meta/recipes-core/ovmf/ovmf_git.bb
> > > @@ -102,15 +102,22 @@ fix_toolchain_append_class-native() {
> > >  # to make ovmf-native reusable across distros.
> > >  sed -i \
> > >  -e 's#^\(DEFINE GCC.*DLINK.*FLAGS  *=\)#\1 -fuse-ld=bfd#' \
> > > +-e 's#-flto#-fno-lto#g' \
> > > +-e 's#-DUSING_LTO##g' \
> > >  ${S}/BaseTools/Conf/tools_def.template
> > >  }
> > >
> > > +# We disable lto above since the results are not reproducible and make 
> > > it hard to compare
> > > +# binary build aretfacts to debug reproducibility problems.
> > > +# Surprisingly, if you disable lto, you see compiler warnings which are 
> > > fatal. We therefore
> > > +# have to hack warnings overrides into GCC_PREFIX_MAP to allow it to 
> > > build.
> > > +
> >
> > could lto piece be turned into a packageconfig,as I think LTO usage
> > will only grow in coming future
> > some distros may prefer LTO over reproducibility for performance reasons.
>
> If someone wants to do it, sure. I've had enough problems with this horrid 
> build
> system already today. You don't want to know how many hours the 
> reproducibility
> fixes have taken :(.
>

I guess defer it to LTO times as it does not seem straight forward to
turn into knob as I see it in your patch

> Cheers,
>
> Richard
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151714): 
https://lists.openembedded.org/g/openembedded-core/message/151714
Mute This Topic: https://lists.openembedded.org/mt/82784424/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 v2] libnotify: Make gtk+3 dependency optional

[Mike Crowe via lists.openembedded.org]

libnotify only requires gtk+3 for its tests. Let's disable them by
default.

Signed-off-by: Mike Crowe 
---
 meta/recipes-gnome/libnotify/libnotify_0.7.9.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb 
b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
index bbbd72193e..0dc3dc3a3c 100644
--- a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
+++ b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
@@ -9,15 +9,16 @@ SECTION = "libs"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
 
-DEPENDS = "dbus gtk+3 glib-2.0"
+DEPENDS = "dbus glib-2.0 gdk-pixbuf"
+
+PACKAGECONFIG ?= ""
+PACKAGECONFIG[gtk+] = "-Dtests=true,-Dtests=false,gtk+3"
 
 GNOMEBASEBUILDCLASS = "meson"
 GTKDOC_MESON_OPTION = "gtk_doc"
 GIR_MESON_ENABLE_FLAG = "enabled"
 GIR_MESON_DISABLE_FLAG = "disabled"
 inherit gnomebase gtk-doc features_check gobject-introspection
-# depends on gtk+3
-ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 
 SRC_URI[archive.md5sum] = "ccd9c53364174cc8d13e18a1988faa76"
 SRC_URI[archive.sha256sum] = 
"66c0517ed16df7af258e83208faaf5069727dfd66995c4bbc51c16954d674761"
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151713): 
https://lists.openembedded.org/g/openembedded-core/message/151713
Mute This Topic: https://lists.openembedded.org/mt/82803205/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] libnotify: Make gtk+3 dependency optional

[Mike Crowe via lists.openembedded.org]

On Thursday 13 May 2021 at 17:06:23 +0100, Richard Purdie wrote:
> On Thu, 2021-05-13 at 16:43 +0200, Alexander Kanavin wrote:
> > On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org <
> > yocto=mac.mcrowe@lists.openembedded.org> wrote:
> > > +PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
> > > 
> > 
> > 
> > Was the --enable-tests scenario tested? Specifying gtk+3 after two ,,s 
> > seems weird.
> 
> It means to add a runtime (RDEPENDS) rather than DEPENDS. There are 
> options for positions 5 and 6 too if I remember rightly.

Yes, but it should have been a build dependency. :( Alexander was correct
to draw attention to it. It turns out that the whole line is wrong because
I failed to spot that master is now using Meson too. :(

A better patch will be arriving shortly.

Thanks.

Mike.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151712): 
https://lists.openembedded.org/g/openembedded-core/message/151712
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] libnotify: Make gtk+3 dependency optional

[Richard Purdie]

On Thu, 2021-05-13 at 16:43 +0200, Alexander Kanavin wrote:
> On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org <
> yocto=mac.mcrowe@lists.openembedded.org> wrote:
> > +PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
> > 
> 
> 
> Was the --enable-tests scenario tested? Specifying gtk+3 after two ,,s seems 
> weird.

It means to add a runtime (RDEPENDS) rather than DEPENDS. There are 
options for positions 5 and 6 too if I remember rightly.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151711): 
https://lists.openembedded.org/g/openembedded-core/message/151711
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] rng-tools: disable the CPU affinity mask

[Joshua Watt]

On Mon, May 10, 2021 at 8:23 AM Jack Mitchell  wrote:
>
> On 10/05/2021 10:48, Richard Purdie wrote:
> > On Mon, 2021-05-10 at 10:33 +0800, Yu, Mingli wrote:
> >> From: Mingli Yu 
> >>
> >> For the jitter entropy source, each task thread will create an internal
> >> counter timer thread when the system clock resolution is under 5MHz.
> >>
> >> But it will introduce high cpu usage for a long time and also make random
> >> data generate too slow if sets the CPU affinity mask of the internal 
> >> counter
> >> timer thread.
> >>
> >> There is no solution until now and the Upstream recommends to disable
> >> the internal timer and think Jitter RNG will not work due to the coarse
> >> timer. Check [1] and [2] for more details.
> >>
> >> So disable the CPU affinity mask as a workaround to avoid lots of context
> >> switch and too high cpu load for a long time.
> >>
> >> [1] https://github.com/smuellerDD/jitterentropy-library/issues/37
> >> [2] https://github.com/nhorman/rng-tools/pull/123
> >>
> >> Signed-off-by: Mingli Yu 
> >> ---
> >>  ...tter.c-disable-the-CPU-affinity-mask.patch | 48 +++
> >>  .../rng-tools/rng-tools_6.11.bb   |  1 +
> >>  2 files changed, 49 insertions(+)
> >>  create mode 100644 
> >> meta/recipes-support/rng-tools/rng-tools/0001-rngd_jitter.c-disable-the-CPU-affinity-mask.patch
> >
> > Thanks for investigating this upstream. From an OE-Core perspective, I've 
> > very
> > reluctant to take what looks like a very board specific change which the 
> > upstream
> > is advising against. The issue is that this will affect all hardware, not 
> > just
> > the hardware which has the issue. I think we need to find a better solution.
> >
> > Cheers,
> >
> > Richard
> >
>
> FWIW I forcefully have to ensure nothing pulls in rng-tools in my builds
> which are for two different Rockchip chipsets (armv7 and armv8) as the
> rng-tools binary pegs the CPU at 100% for minutes after boot, every
> boot. It's particularly annoying as openssh brings it in by default
> which I've unsuccessfully argued is wrong before. I believe the problem
> is probably fairly widespread but just unnoticed.

Is the reason for the CPU being pegged because of the jitter entropy
source? If so, perhaps you can disable libjitterentropy in rng-tools
packageconfig. We might also be able to make that packageconfig option
more "automatic" by basing it on some high precision timer
MACHINE_FEATURE instead of always being included.

>
> Regards,
>
> --
> Jack Mitchell, Consultant
> https://www.tuxable.co.uk
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151710): 
https://lists.openembedded.org/g/openembedded-core/message/151710
Mute This Topic: https://lists.openembedded.org/mt/82711446/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] libnotify: Make gtk+3 dependency optional

[Khem Raj]

On 5/13/21 7:43 AM, Alexander Kanavin wrote:
On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org 
 
> wrote:


+PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"


Was the --enable-tests scenario tested? Specifying gtk+3 after two ,,s 
seems weird.


it is valid if tests need gtk+3 at runtime, but not during build time, 
in that case you only create rdep as above.




Alex





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151709): 
https://lists.openembedded.org/g/openembedded-core/message/151709
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] libnotify: Make gtk+3 dependency optional

[Mike Crowe via lists.openembedded.org]

On Thursday 13 May 2021 at 16:43:15 +0200, Alexander Kanavin wrote:
> On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org  mac.mcrowe@lists.openembedded.org> wrote:
> 
> > +PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
> >
> 
> Was the --enable-tests scenario tested? Specifying gtk+3 after two ,,s
> seems weird.

You're right. That does look odd. This is actually an old patch I hoovered
up after upgrading and didn't retest it. I'll do some more testing...

Mike.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151708): 
https://lists.openembedded.org/g/openembedded-core/message/151708
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] libnotify: Make gtk+3 dependency optional

[Alexander Kanavin]

On Thu, 13 May 2021 at 16:36, Mike Crowe via lists.openembedded.org  wrote:

> +PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
>

Was the --enable-tests scenario tested? Specifying gtk+3 after two ,,s
seems weird.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151707): 
https://lists.openembedded.org/g/openembedded-core/message/151707
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] libnotify: Make gtk+3 dependency optional

[Mike Crowe via lists.openembedded.org]

libnotify only requires gtk+3 for its tests. Let's disable them by
default.

Signed-off-by: Mike Crowe 
---
 meta/recipes-gnome/libnotify/libnotify_0.7.9.bb | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb 
b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
index bbbd72193e..819cb304f7 100644
--- a/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
+++ b/meta/recipes-gnome/libnotify/libnotify_0.7.9.bb
@@ -9,15 +9,16 @@ SECTION = "libs"
 LICENSE = "LGPLv2.1"
 LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
 
-DEPENDS = "dbus gtk+3 glib-2.0"
+DEPENDS = "dbus glib-2.0 gdk-pixbuf"
+
+PACKAGECONFIG ?= ""
+PACKAGECONFIG[gtk+] = "--enable-tests,--disable-tests,,gtk+3"
 
 GNOMEBASEBUILDCLASS = "meson"
 GTKDOC_MESON_OPTION = "gtk_doc"
 GIR_MESON_ENABLE_FLAG = "enabled"
 GIR_MESON_DISABLE_FLAG = "disabled"
 inherit gnomebase gtk-doc features_check gobject-introspection
-# depends on gtk+3
-ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
 
 SRC_URI[archive.md5sum] = "ccd9c53364174cc8d13e18a1988faa76"
 SRC_URI[archive.sha256sum] = 
"66c0517ed16df7af258e83208faaf5069727dfd66995c4bbc51c16954d674761"
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151706): 
https://lists.openembedded.org/g/openembedded-core/message/151706
Mute This Topic: https://lists.openembedded.org/mt/82800551/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] master/main branch renaming and bitbake

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Richard Purdie
> Sent: den 13 maj 2021 09:09
> To: Andre McCurdy ; Alexander Kanavin
> 
> Cc: Colin Walters ; OE-core  c...@lists.openembedded.org>
> Subject: Re: [OE-core] master/main branch renaming and bitbake
> 
> On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote:
> > On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
> >  wrote:
> > >
> > > And by the way, another reason to check that revision is linked to a
> > > branch is when SRCREV is updated - we need some reassurance that the
> > > updated SRCREV comes from the same branch as previous SRCREV, or that
> > > if the branch has changed, it's explicitly visible in the diff and
> explained in the commit message.
> >
> > None of the answers given so far seem very convincing...
> 
> I had a look at the code to try and remind myself why it is doing this.
> The best answer I found is that it does support filtered fetching of
> remotes, i.e. it can and will only pull the branch it wants/needs rather
> than a full repo clone. In the case of a small repo, it doesn't matter
> much. For a large repo it can make a significant difference to the speed.
> We also don't run "test" commands against the remote repo, we figure out
> what we want and then get it with small numbers of commands.
> 
> Another reason we have the branch name is so that we can ls-remote the
> repo
> when using AUTOREV for SRCREV. We've tried to make it so that once a url
> is established in SRC_URI, you can make it use AUTOREV without changes to
> the url itself. The AUTOREV code path is in parsing which does mean we
> need to be efficient about the revision resolution.

Wouldn't using "HEAD" instead still maintain the same properties as using 
"master", but with the added benefit that it just works for repositories 
that decide to use some other branch than "master" as their main branch?
E.g., using `git clone --single-branch` (without -b) fetches HEAD and 
whatever branch it references, which is what we want, is it not?

> > If the git revision that a recipe wants is available on an unexpected
> > branch in the upstream repo then it's not really different from a tar
> > file being fetched from a mirror rather than whatever is in SRC_URI.
> > If we want the fetcher to fail as an indication that an upstream git
> > repo has renamed branches then don't we also want it to fail if a tar
> > file disappears from an upstream server? It seems odd that one should
> > be a fatal error and the other to be something we try to cover up and
> > hide from the end user.
> 
> The fetcher is consistent. It will fail in both cases unless a source
> mirror is available with the sources in. If a source mirror is available,
> it should work.
> 
> > Anyway, for recipes which don't explicitly specify a branch in SRC_URI
> > it would seem quite reasonable for the fetcher to check what the
> > default branch is set to in the upstream repo and search for the
> > required git revision in that branch (rather than rely on a hardcoded
> > default of "master" as we do now). Going forward, there's going to be
> > less standardisation on what upstream repos call their default branch,
> > so we're either going to have to explicitly specify a branch in more
> > and more recipes or teach the fetcher to automatically figure out what
> > the default branch in the upstream repo is.
> 
> Is explicitly specifying the branch along with the repo url such a big
> problem? We already have to provide the url, it isn't like we guess that
> too.

One problem I have with the way the branch is specified is that it is a 
URL parameter. This means that when I want to add a bbappend to specify 
another SRCREV, it becomes problematic if that SRCREV is on a different 
branch than what the base recipe uses. It basically means one has to 
use SRC_URI_remove to remove the original URL for the repository, and 
then add a new version of the URL with SRC_URI_prepend. This obviously 
is unrelated to the discussion about main vs. master, but I would very 
much like to see a new variable, e.g., SRC_BRANCH, being added to 
complement SRCREV. There is an edge case for recipes that use multiple 
Git URLs in the SRC_URI, but they are rare, so having to specify the 
branch using the branch= parameter in the unlikely event that those 
repositories need different branches should be acceptable.

> Cheers,
> 
> Richard

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151705): 
https://lists.openembedded.org/g/openembedded-core/message/151705
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] npm.bbclass: Allow nodedir to be overridden by NPM_NODEDIR

[Mike Crowe via lists.openembedded.org]

Node modules may need to be built against multiple Node
versions. Setting nodedir in the NPM configuration stops older ways of
doing this, such as setting npm_config_target and npm_config_disturl,
from working.

Signed-off-by: Mike Crowe 
---
 meta/classes/npm.bbclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 55a6985fb0..8f8712a024 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -247,8 +247,10 @@ python npm_do_compile() {
 # Add node-gyp configuration
 configs.append(("arch", d.getVar("NPM_ARCH")))
 configs.append(("release", "true"))
-sysroot = d.getVar("RECIPE_SYSROOT_NATIVE")
-nodedir = os.path.join(sysroot, d.getVar("prefix_native").strip("/"))
+nodedir = d.getVar("NPM_NODEDIR")
+if not nodedir:
+sysroot = d.getVar("RECIPE_SYSROOT_NATIVE")
+nodedir = os.path.join(sysroot, 
d.getVar("prefix_native").strip("/"))
 configs.append(("nodedir", nodedir))
 configs.append(("python", d.getVar("PYTHON")))
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151704): 
https://lists.openembedded.org/g/openembedded-core/message/151704
Mute This Topic: https://lists.openembedded.org/mt/82800205/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] master/main branch renaming and bitbake

[Bruce Ashfield]

On Thu, May 13, 2021 at 9:27 AM colin walters  wrote:
>
>
>
> On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
> >
> > I had a look at the code to try and remind myself why it is doing this.
>
> Thanks!
>
> > The best answer I found is that it does support filtered fetching of
> > remotes, i.e. it can and will only pull the branch it wants/needs rather
> > than a full repo clone. In the case of a small repo, it doesn't matter
> > much. For a large repo it can make a significant difference to the speed.
>
> This is with `git clone --single-branch`?  Makes sense.
>
> > We also don't run "test" commands against the remote repo, we figure out
> > what we want and then get it with small numbers of commands.
>
> I think what I'd argue is that in the case where the remote branch is deleted,
> the tooling should fall back to listing remote branches, sort by
> most recently updated, and try finding the commit on that.
> And in practice, explicitly using `main` first in that list would make sense.

The tools really shouldn't be making decisions like this on a recipes'
behalf. It is complex and just doesn't need to exist when we can
simply specify the branch.

>
> > Is explicitly specifying the branch along with the repo url such a big
> > problem? We already have to provide the url, it isn't like we guess that
> > too.
>
> The problem is that your build system is penalizing upstream projects that 
> are trying to migrate
> to using `main`.
>

Similarly those same projects are completely deleting those branches,
versus no longer making them the default. Which is penalizing the
existing users.

Bruce



>
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151703): 
https://lists.openembedded.org/g/openembedded-core/message/151703
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] master/main branch renaming and bitbake

[colin walters]

On Thu, May 13, 2021, at 3:08 AM, Richard Purdie wrote:
>
> I had a look at the code to try and remind myself why it is doing this. 

Thanks!

> The best answer I found is that it does support filtered fetching of 
> remotes, i.e. it can and will only pull the branch it wants/needs rather
> than a full repo clone. In the case of a small repo, it doesn't matter
> much. For a large repo it can make a significant difference to the speed.

This is with `git clone --single-branch`?  Makes sense.

> We also don't run "test" commands against the remote repo, we figure out
> what we want and then get it with small numbers of commands.

I think what I'd argue is that in the case where the remote branch is deleted,
the tooling should fall back to listing remote branches, sort by
most recently updated, and try finding the commit on that.
And in practice, explicitly using `main` first in that list would make sense.

> Is explicitly specifying the branch along with the repo url such a big 
> problem? We already have to provide the url, it isn't like we guess that
> too.

The problem is that your build system is penalizing upstream projects that are 
trying to migrate
to using `main`.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151702): 
https://lists.openembedded.org/g/openembedded-core/message/151702
Mute This Topic: https://lists.openembedded.org/mt/82782995/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] meta/lib/oe/rootfs.py: "Restoreing" -> "Restoring"

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 4b48cdbb65..ad9fd77c8b 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -167,7 +167,7 @@ class Rootfs(object, metaclass=ABCMeta):
 pass
 bb.utils.rename(self.image_rootfs, self.image_rootfs + '-dbg')

-bb.note("  Restoreing original rootfs...")
+bb.note("  Restoring original rootfs...")
 bb.utils.rename(self.image_rootfs + '-orig', self.image_rootfs)

 def _exec_shell_cmd(self, cmd):

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
 http://crashcourse.ca

LinkedIn:   http://ca.linkedin.com/in/rpjday


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

[OE-core] couple questions about creating companion debug filesystem

[Robert P. J. Day]

  couple colleagues asked me about the details of how the debug
filesystem is created, and since i wasn't entirely clear on the
mechanics of it myself, i thought i'd dig into it, so a couple
preliminary questions to make sure i'm on the right track.

  trivially, if you want that companion debugfs, you need only:

  IMAGE_GEN_DEBUGFS = '1'

at which point what kicks in is the current value of
IMAGE_FSTYPES_DEBUGFS to determine what forms of the debugfs you want.
by default, that's conditionally set to "tar.gz" in bitbake.conf so,
unless you mess with it, the end result is a debugfs tarball under
deploy/images. so far, so good.

  now, if you (for no good reason) also set:

  IMAGE_FSTYPES_DEBUGFS = ''

in your local.conf, then even though you *claim* you want the debugfs,
you're not going to get one since the build process has no idea what
archive type you want. i believe this is the result of this snippet in
image.bbclass in the anonymous python routine (line 369):

if d.getVar('IMAGE_GEN_DEBUGFS') == "1":
debugfs_fstypes = d.getVar('IMAGE_FSTYPES_DEBUGFS').split()
for t in debugfs_fstypes:
alltypes.append("debugfs_" + t)

which makes sense. however, even if you don't get the final debugfs
tarball under deploy, i see that the *contents* of the debugfs are
still generated under WORKDIR for the image (in my case,
core-image-minimal), since i see both:

  rootfs/
  rootfs-dbg/

and following the trail of bread crumbs to see where that came from, i
ended up in meta/lib/oe/rootfs.py:

def _setup_dbg_rootfs(self, dirs):
gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
if gen_debugfs != '1':
   return

bb.note("  Renaming the original rootfs...")
try:
shutil.rmtree(self.image_rootfs + '-orig')
except:
pass
bb.utils.rename(self.image_rootfs, self.image_rootfs + '-orig')

... and so on and so on ...

which clearly(?) does all that work, even if, in the end, the result
is not packaged as a tarball, which is part of what muh colleagues
were asking about -- where can they see *exactly* how that debugfs
content is collected?

  is all this reasonably accurate so far?

rday


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151700): 
https://lists.openembedded.org/g/openembedded-core/message/151700
Mute This Topic: https://lists.openembedded.org/mt/82795751/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] image.bbclass: fix comment "pacackages" -> "packages"

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 353cc67175..67603d958d 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -38,7 +38,7 @@ IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs 
read-only-rootfs-de
 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"

-# These pacackages will be installed as additional into debug rootfs
+# These packages will be installed as additional into debug rootfs
 IMAGE_INSTALL_DEBUGFS ?= ""

 # These packages will be removed from a read-only rootfs after all other


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

[wangmy]

Signed-off-by: Wang Mingyu 
---
 meta/recipes-devtools/go/{go-1.16.3.inc => go-1.16.4.inc} | 4 ++--
 ...{go-binary-native_1.16.3.bb => go-binary-native_1.16.4.bb} | 4 ++--
 ...o-cross-canadian_1.16.3.bb => go-cross-canadian_1.16.4.bb} | 0
 .../go/{go-cross_1.16.3.bb => go-cross_1.16.4.bb} | 0
 .../go/{go-crosssdk_1.16.3.bb => go-crosssdk_1.16.4.bb}   | 0
 .../go/{go-native_1.16.3.bb => go-native_1.16.4.bb}   | 0
 .../go/{go-runtime_1.16.3.bb => go-runtime_1.16.4.bb} | 0
 meta/recipes-devtools/go/{go_1.16.3.bb => go_1.16.4.bb}   | 0
 8 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/go/{go-1.16.3.inc => go-1.16.4.inc} (88%)
 rename meta/recipes-devtools/go/{go-binary-native_1.16.3.bb => 
go-binary-native_1.16.4.bb} (83%)
 rename meta/recipes-devtools/go/{go-cross-canadian_1.16.3.bb => 
go-cross-canadian_1.16.4.bb} (100%)
 rename meta/recipes-devtools/go/{go-cross_1.16.3.bb => go-cross_1.16.4.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-crosssdk_1.16.3.bb => 
go-crosssdk_1.16.4.bb} (100%)
 rename meta/recipes-devtools/go/{go-native_1.16.3.bb => go-native_1.16.4.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-runtime_1.16.3.bb => go-runtime_1.16.4.bb} 
(100%)
 rename meta/recipes-devtools/go/{go_1.16.3.bb => go_1.16.4.bb} (100%)

diff --git a/meta/recipes-devtools/go/go-1.16.3.inc 
b/meta/recipes-devtools/go/go-1.16.4.inc
similarity index 88%
rename from meta/recipes-devtools/go/go-1.16.3.inc
rename to meta/recipes-devtools/go/go-1.16.4.inc
index ebd25a5eaa..71c17de310 100644
--- a/meta/recipes-devtools/go/go-1.16.3.inc
+++ b/meta/recipes-devtools/go/go-1.16.4.inc
@@ -1,7 +1,7 @@
 require go-common.inc
 
 GO_BASEVERSION = "1.16"
-PV = "1.16.3"
+PV = "1.16.4"
 FILESEXTRAPATHS_prepend := "${FILE_DIRNAME}/go-${GO_BASEVERSION}:"
 
 LIC_FILES_CHKSUM = "file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
@@ -17,4 +17,4 @@ SRC_URI += "\
 file://0008-use-GOBUILDMODE-to-set-buildmode.patch \
 file://0009-Revert-cmd-go-make-sure-CC-and-CXX-are-absolute.patch \
 "
-SRC_URI[main.sha256sum] = 
"b298d29de9236ca47a023e382313bcc2d2eed31dfa706b60a04103ce83a71a25"
+SRC_URI[main.sha256sum] = 
"ae4f6b6e2a1677d31817984655a762074b5356da50fb58722b99104870d43503"
diff --git a/meta/recipes-devtools/go/go-binary-native_1.16.3.bb 
b/meta/recipes-devtools/go/go-binary-native_1.16.4.bb
similarity index 83%
rename from meta/recipes-devtools/go/go-binary-native_1.16.3.bb
rename to meta/recipes-devtools/go/go-binary-native_1.16.4.bb
index d01a2bd8f1..8c046e8e53 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.16.3.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.16.4.bb
@@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=5d4950ecb7b26d2c5e4e7b4e0dd74707"
 PROVIDES = "go-native"
 
 SRC_URI = 
"https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE};
-SRC_URI[go_linux_amd64.sha256sum] = 
"951a3c7c6ce4e56ad883f97d9db74d3d6d80d5fec77455c6ada6c1f7ac4776d2"
-SRC_URI[go_linux_arm64.sha256sum] = 
"566b1d6f17d2bc4ad5f81486f0df44f3088c3ed47a3bec4099d8ed9939e90d5d"
+SRC_URI[go_linux_amd64.sha256sum] = 
"7154e88f5a8047aad4b80ebace58a059e36e7e2e4eb3b383127a28c711b4ff59"
+SRC_URI[go_linux_arm64.sha256sum] = 
"8b18eb05ddda2652d69ab1b1dd1f40dd731799f43c6a58b512ad01ae5b5bba21"
 
 UPSTREAM_CHECK_URI = "https://golang.org/dl/;
 UPSTREAM_CHECK_REGEX = "go(?P\d+(\.\d+)+)\.linux"
diff --git a/meta/recipes-devtools/go/go-cross-canadian_1.16.3.bb 
b/meta/recipes-devtools/go/go-cross-canadian_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross-canadian_1.16.3.bb
rename to meta/recipes-devtools/go/go-cross-canadian_1.16.4.bb
diff --git a/meta/recipes-devtools/go/go-cross_1.16.3.bb 
b/meta/recipes-devtools/go/go-cross_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross_1.16.3.bb
rename to meta/recipes-devtools/go/go-cross_1.16.4.bb
diff --git a/meta/recipes-devtools/go/go-crosssdk_1.16.3.bb 
b/meta/recipes-devtools/go/go-crosssdk_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-crosssdk_1.16.3.bb
rename to meta/recipes-devtools/go/go-crosssdk_1.16.4.bb
diff --git a/meta/recipes-devtools/go/go-native_1.16.3.bb 
b/meta/recipes-devtools/go/go-native_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-native_1.16.3.bb
rename to meta/recipes-devtools/go/go-native_1.16.4.bb
diff --git a/meta/recipes-devtools/go/go-runtime_1.16.3.bb 
b/meta/recipes-devtools/go/go-runtime_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-runtime_1.16.3.bb
rename to meta/recipes-devtools/go/go-runtime_1.16.4.bb
diff --git a/meta/recipes-devtools/go/go_1.16.3.bb 
b/meta/recipes-devtools/go/go_1.16.4.bb
similarity index 100%
rename from meta/recipes-devtools/go/go_1.16.3.bb
rename to meta/recipes-devtools/go/go_1.16.4.bb
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#151698): 

Re: [OE-core] [PATCH 7/8] meson: update 0.57.2 -> 0.58.0

[Alexander Kanavin]

I'm addressing that as well, thanks for notifying.

Alex

On Thu, 13 May 2021 at 07:44, Lee, Chee Yang 
wrote:

>
> I think these error is related to this patch or the gdk-pixbuf patch in
> this series .
> meson
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/2089/steps/14/logs/stdio
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/1635/steps/11/logs/stdio
> gdk-pixbuf
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/119/builds/271/steps/12/logs/stdio
>
>
>
>
> *From:* Alexander Kanavin 
> *Sent:* Thursday, 13 May, 2021 1:04 AM
> *To:* Lee, Chee Yang 
> *Cc:* openembedded-core@lists.openembedded.org
> *Subject:* Re: [OE-core] [PATCH 7/8] meson: update 0.57.2 -> 0.58.0
>
>
>
> Thank you, I will look into it.
>
>
>
> Alex
>
>
>
> On Wed, 12 May 2021 at 13:26, Lee, Chee Yang 
> wrote:
>
> Looks like this patch failed buildepoxy.EpoxyTest.test_epoxy test
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/3417/steps/12/logs/stdio
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3416/steps/12/logs/stdio
>
>
>
> >-Original Message-
> >From: openembedded-core@lists.openembedded.org  >c...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> >Sent: Monday, 10 May, 2021 9:01 PM
> >To: openembedded-core@lists.openembedded.org
> >Cc: Alexander Kanavin 
> >Subject: [OE-core] [PATCH 7/8] meson: update 0.57.2 -> 0.58.0
> >
> >Rebase patches; dropped chunks (and cross-prop-default.patch) have been
> >removed upstream.
> >
> >Move native-only patches to all-patches, as they're a pain to rebase
> >separately.
> >
> >Signed-off-by: Alexander Kanavin 
> >---
> > meta/recipes-devtools/meson/meson.inc | 10 +---
> > .../0001-Make-CPU-family-warnings-fatal.patch | 18 +++---
> ...sues-that-arise-
> >when-cross-compiling.patch |  8 +--  ...-not-manipulate-the-environment-
> >when.patch | 14 ++---  ...pport-building-allarch-recipes-again.patch | 10
> ++--
> > .../meson/meson/0003-native_bindir.patch  | 58 +--
> > .../meson/meson/cross-prop-default.patch  | 23 
> > .../{meson_0.57.2.bb => meson_0.58.0.bb}  |  0
> > ...on_0.57.2.bb => nativesdk-meson_0.58.0.bb} |  0
> > 9 files changed, 43 insertions(+), 98 deletions(-)  delete mode 100644
> >meta/recipes-devtools/meson/meson/cross-prop-default.patch
> > rename meta/recipes-devtools/meson/{meson_0.57.2.bb =>
> >meson_0.58.0.bb} (100%)  rename meta/recipes-devtools/meson/{nativesdk-
> >meson_0.57.2.bb => nativesdk-meson_0.58.0.bb} (100%)
> >
> >diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-
> >devtools/meson/meson.inc
> >index 10e7d8a1ce..12a48fc992 100644
> >--- a/meta/recipes-devtools/meson/meson.inc
> >+++ b/meta/recipes-devtools/meson/meson.inc
> >@@ -12,16 +12,12 @@ SRC_URI =
> >"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-
> >${P
> >file://0003-native_bindir.patch \
> >file://0001-python-module-do-not-manipulate-the-environment-
> >when.patch \
> >file://disable-rpath-handling.patch \
> >-   file://cross-prop-default.patch \
> >file://0001-modules-python.py-do-not-substitute-python-s-
> >install.patch \
> >file://gi-target-dep.patch \
> >+   file://0001-Make-CPU-family-warnings-fatal.patch \
> >+   file://0002-Support-building-allarch-recipes-again.patch \
> >"
> >-SRC_URI[sha256sum] =
> >"3a83e7b1c5de94fa991ec34d9b198d94f38ed699d3524cb0fdf3b99fd23d4cc5"
> >-
> >-SRC_URI_append_class-native = " \
> >-file://0001-Make-CPU-family-warnings-fatal.patch \
> >-file://0002-Support-building-allarch-recipes-again.patch \
> >-"
> >+SRC_URI[sha256sum] =
> >"f4820df0bc969c99019fd4af8ca5f136ee94c63d8a5ad67e7eb73bdbc9182fdd"
> >
> > UPSTREAM_CHECK_URI = "https://github.com/mesonbuild/meson/releases;
> > UPSTREAM_CHECK_REGEX = "meson-(?P\d+(\.\d+)+)\.tar"
> >diff --git a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> >warnings-fatal.patch b/meta/recipes-devtools/meson/meson/0001-Make-
> >CPU-family-warnings-fatal.patch
> >index 300797f9ee..bcccfabd17 100644
> >--- a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> >warnings-fatal.patch
> >+++ b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> >warnings-fa
> >+++ tal.patch
> >@@ -1,34 +1,33 @@
> >-From 198e2de24adf5845e3ba389b533cf43440ee8acb Mon Sep 17 00:00:00
> >2001
> >+From b64032a2eb1fb760f4ffd5b4b666e2433cf80d39 Mon Sep 17 00:00:00
> >2001
> > From: Ross Burton 
> > Date: Tue, 3 Jul 2018 13:59:09 +0100
> >-Subject: [PATCH] Make CPU family warnings fatal
> >+Subject: [PATCH 1/2] Make CPU family warnings fatal
> >
> > Upstream-Status: Inappropriate [OE specific]
> > Signed-off-by: Ross Burton 
> >-
> > ---
> >  mesonbuild/envconfig.py   | 2 +-
> >  mesonbuild/environment.py | 4 +---
> >  2 files changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py -index
> 

Re: [OE-core] master/main branch renaming and bitbake

[Richard Purdie]

On Wed, 2021-05-12 at 17:11 -0700, Andre McCurdy wrote:
> On Wed, May 12, 2021 at 2:23 PM Alexander Kanavin
>  wrote:
> > 
> > And by the way, another reason to check that revision is linked to a 
> > branch is when SRCREV is updated - we need some reassurance that the 
> > updated SRCREV comes from the same branch as previous SRCREV, or that
> > if the branch has changed, it's explicitly visible in the diff and 
> > explained in the commit message.
> 
> None of the answers given so far seem very convincing...

I had a look at the code to try and remind myself why it is doing this. 
The best answer I found is that it does support filtered fetching of 
remotes, i.e. it can and will only pull the branch it wants/needs rather
than a full repo clone. In the case of a small repo, it doesn't matter
much. For a large repo it can make a significant difference to the speed.
We also don't run "test" commands against the remote repo, we figure out
what we want and then get it with small numbers of commands.

Another reason we have the branch name is so that we can ls-remote the repo
when using AUTOREV for SRCREV. We've tried to make it so that once a url
is established in SRC_URI, you can make it use AUTOREV without changes to 
the url itself. The AUTOREV code path is in parsing which does mean we
need to be efficient about the revision resolution.

> If the git revision that a recipe wants is available on an unexpected
> branch in the upstream repo then it's not really different from a tar
> file being fetched from a mirror rather than whatever is in SRC_URI.
> If we want the fetcher to fail as an indication that an upstream git
> repo has renamed branches then don't we also want it to fail if a tar
> file disappears from an upstream server? It seems odd that one should
> be a fatal error and the other to be something we try to cover up and
> hide from the end user.

The fetcher is consistent. It will fail in both cases unless a source
mirror is available with the sources in. If a source mirror is available,
it should work.

> Anyway, for recipes which don't explicitly specify a branch in SRC_URI
> it would seem quite reasonable for the fetcher to check what the
> default branch is set to in the upstream repo and search for the
> required git revision in that branch (rather than rely on a hardcoded
> default of "master" as we do now). Going forward, there's going to be
> less standardisation on what upstream repos call their default branch,
> so we're either going to have to explicitly specify a branch in more
> and more recipes or teach the fetcher to automatically figure out what
> the default branch in the upstream repo is.

Is explicitly specifying the branch along with the repo url such a big 
problem? We already have to provide the url, it isn't like we guess that
too.

Cheers,

Richard


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