Date   

[meta-mingw] [PATCH] mingw-libgnurx: Add recipe

Khem Raj
 

This implements glibc regex and will be used by many
packages e.g. flex, therefore add recipe

Signed-off-by: Khem Raj <raj.khem@...>
---
...onor-DESTDIR-variable-during-install.patch | 39 ++++++
.../0002-Add-autotool-files.patch | 125 ++++++++++++++++++
.../mingw-libgnurx/mingw-libgnurx_2.5.1.bb | 20 +++
3 files changed, 184 insertions(+)
create mode 100644 recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
create mode 100644 recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
create mode 100644 recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb

diff --git a/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch b/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
new file mode 100644
index 0000000..ea8d9ed
--- /dev/null
+++ b/recipes-support/mingw-libgnurx/mingw-libgnurx/0001-Honor-DESTDIR-variable-during-install.patch
@@ -0,0 +1,39 @@
+From a9b7e07a8ba9c390d9774daae769748a09d409ce Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Sat, 1 May 2021 14:41:21 -0700
+Subject: [PATCH] Honor DESTDIR variable during install
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ Makefile.in | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/Makefile.in b/Makefile.in
+index 6397bf1..8395d2f 100644
+--- a/Makefile.in
++++ b/Makefile.in
+@@ -78,16 +78,16 @@ gnurx.lib: libgnurx-$(DLLVERSION).dll
+ install: install-dll @install_dev@
+
+ install-dll:
+- mkdir -p ${bindir}
+- cp -p $(BINDIST_FILES) ${bindir}
++ mkdir -p $(DESTDIR)${bindir}
++ cp -p $(BINDIST_FILES) $(DESTDIR)${bindir}
+
+ install-dev:
+- mkdir -p ${includedir} ${libdir}
+- cp -p ${srcdir}/regex.h ${includedir}
+- cp -p $(DEVDIST_FILES) ${libdir}
++ mkdir -p ${includedir} $(DESTDIR)${libdir}
++ cp -p ${srcdir}/regex.h $(DESTDIR)${includedir}
++ cp -p $(DEVDIST_FILES) $(DESTDIR)${libdir}
+ for s in 3 7; do \
+- mkdir -p ${mandir}/man$$s; \
+- gzip -c ${srcdir}/regex.$$s > ${mandir}/man$$s/regex.$$s.gz; \
++ mkdir -p $(DESTDIR)${mandir}/man$$s; \
++ gzip -c ${srcdir}/regex.$$s > $(DESTDIR)${mandir}/man$$s/regex.$$s.gz; \
+ done
+
+ dist: bindist devdist srcdist
diff --git a/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
new file mode 100644
index 0000000..1365f24
--- /dev/null
+++ b/recipes-support/mingw-libgnurx/mingw-libgnurx/0002-Add-autotool-files.patch
@@ -0,0 +1,125 @@
+From 0b74bbc32c4acf5b67d7568a5d1e776fe6578202 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Sat, 1 May 2021 14:53:09 -0700
+Subject: [PATCH] Add autotool files
+
+This helps in reconfiguring the component with autotools on Linux
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ Makefile.am | 7 ++++
+ configure.ac | 90 ++++++----------------------------------------------
+ 2 files changed, 16 insertions(+), 81 deletions(-)
+ create mode 100644 Makefile.am
+
+diff --git a/Makefile.am b/Makefile.am
+new file mode 100644
+index 0000000..be0a797
+--- /dev/null
++++ b/Makefile.am
+@@ -0,0 +1,7 @@
++lib_LTLIBRARIES = libgnurx.la
++
++libgnurx_la_SOURCES = regex.c
++libgnurx_la_includedir = $(includedir)
++libgnurx_la_include_HEADERS = regex.h
++libgnurx_la_CFLAGS = -I$(top_srcdir)
++libgnurx_la_LDFLAGS = -no-undefined -version-info 0:0:0 -export-dynamic
+diff --git a/configure.ac b/configure.ac
+index c97738d..de64f75 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -1,83 +1,11 @@
+ # configure.ac -*- Autoconf -*-
+ # Process this file with autoconf, to generate a configure script.
+-#
+-# $Id: configure.ac,v 1.2 2007/05/03 22:46:09 keithmarshall Exp $
+-#
+-# Copyright (C) 2007, MinGW Project
+-# Written by Keith Marshall <keithmarshall@...>
+-#
+-# Package identification.
+-#
+-# This is configure.ac for the MinGW `libgnurx' package.
+-# BASENAME, VERSION_MAJOR and VERSION_MINOR are required tags;
+-# complete `Value' fields as appropriate.
+-#
+-# Tag Value
+-# --------------- ----------
+- MINGW_AC_DEFINE_PACKAGE_ID([BASENAME], [libgnurx])
+- MINGW_AC_DEFINE_PACKAGE_ID([VERSION_MAJOR], [2])
+- MINGW_AC_DEFINE_PACKAGE_ID([VERSION_MINOR], [5])
+-#
+-# PATCHLEVEL is optional; comment/uncomment and adjust as required.
+-#
+- MINGW_AC_DEFINE_PACKAGE_ID([PATCHLEVEL], [1])
+-#
+-# DLL_VERSION is required; installed DLLs will be versioned, by
+-# appending a hyphen, the specified tag value, and then the `.dll'
+-# file name extension, to the base name of each generated DLL.
+-#
+- MINGW_AC_DEFINE_PACKAGE_ID([DLL_VERSION], [0])
+-#
+-#
+-# libgnurx is an adaptation of Tor Lillqvist's original port of the
+-# regex functions from GNU libc, for use on native Woe32 platforms.
+-#
+-# The original sources, on which this port is based, remain copyright
+-# of their respective authors, or of the Free Software Foundation Inc.,
+-# as indicated in individual file headers; all are redistributed with
+-# permission, as granted by the GNU Lesser General Public License.
+-#
+-# This is free software. It is provided AS IS, in the hope that it may
+-# be useful, but WITHOUT WARRANTY OF ANY KIND, not even an IMPLIED WARRANTY
+-# of MERCHANTABILITY, nor of FITNESS FOR ANY PARTICULAR PURPOSE.
+-#
+-# Permission is granted to redistribute this software, either "as is" or
+-# in modified form, under the terms of the GNU Lesser General Public License,
+-# as published by the Free Software Foundation; either version 2.1, or (at
+-# your option) any later version.
+-#
+-# You should have received a copy of the GNU Lesser General Public License
+-# along with this software; see the file COPYING.LIB. If not, write to the
+-# Free Software Foundation, 51 Franklin St - Fifth Floor, Boston,
+-# MA 02110-1301, USA.
+-
+-# Autoconf initialisation.
+-#
+- AC_PREREQ([2.59])
+- AC_INIT(__MINGW_AC_PACKAGE_IDENTIFICATION__)
+-
+-# Compiler and build tool checks.
+-#
+- AC_PROG_CC
+- MINGW_AC_PROG_CC_OPTIONS([CC_QUALIFIED], [-m], [threads tune=pentium3])
+-
+-# Set the release version for the resultant DLL.
+-#
+- AC_SUBST([DLLVERSION], [__MINGW_AC_PACKAGE_DLL_VERSION__])
+-
+-# User configuration options.
+-#
+- MINGW_AC_DISTRIBUTION_TYPE([tar])
+- MINGW_AC_MSVC_IMPORT_LIBS([GNURX_LIB], [gnurx.lib])
+- MINGW_AC_DEV_INSTALL_OPTION
+-
+-# Configuration output.
+-#
+- AC_SUBST([GNURX_LIB])
+- AC_SUBST([CC_QUALIFIED], ["$CC $CC_QUALIFIED"])
+- LDFLAGS="$LDFLAGS -Wl,--enable-auto-image-base -Wl,--out-implib,libgnurx.dll.a"
+- test -n "${GNURX_LIB}" && LDFLAGS="$LDFLAGS -Wl,--output-def,libgnurx.def"
+- AC_CONFIG_FILES([Makefile])
+- AC_OUTPUT
+-#
+-# $RCSfile: configure.ac,v $Revision: 1.2 $: end of file
++
++AC_INIT(libgnurx, 2.5.1)
++AM_INIT_AUTOMAKE(foreign)
++AC_PROG_INSTALL
++AC_LIBTOOL_DLOPEN
++AC_LIBTOOL_WIN32_DLL
++AC_PROG_LIBTOOL
++
++AC_OUTPUT([Makefile])
diff --git a/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb b/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
new file mode 100644
index 0000000..cb5cd7f
--- /dev/null
+++ b/recipes-support/mingw-libgnurx/mingw-libgnurx_2.5.1.bb
@@ -0,0 +1,20 @@
+# Copyright (C) 2021 Khem Raj <raj.khem@...>
+# Released under the MIT license (see COPYING.MIT for the terms)
+LICENSE = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=bbb461211a33b134d42ed5ee802b37ff"
+
+SRC_URI = "http://download.sourceforge.net/mingw/Other/UserContributed/regex/mingw-regex-${PV}/mingw-libgnurx-${PV}-src.tar.gz \
+ file://0001-Honor-DESTDIR-variable-during-install.patch \
+ file://0002-Add-autotool-files.patch \
+ "
+SRC_URI[sha256sum] = "7147b7f806ec3d007843b38e19f42a5b7c65894a57ffc297a76b0dcd5f675d76"
+
+# NOTE: if this software is not capable of being built in a separate build directory
+# from the source, you should replace autotools with autotools-brokensep in the
+# inherit line
+inherit autotools
+
+# Specify any options you want to pass to the configure script using EXTRA_OECONF:
+EXTRA_OECONF = ""
+
+BBCLASSEXTEND = "nativesdk"
--
2.31.1


Re: Yocto Project Status WW18`21

Alexander Kanavin
 

On Tue, 4 May 2021 at 16:46, Stephen Jolley <sjolley.yp.pm@...> wrote:
We are pleased to announce that our April 2022 release (potentially 3.5) will be the next LTS as per our original two year schedule. If there are features desired in the next LTS, now is the time to get them submitted and stabilized ready.

What will happen to the current LTS at that point? Will support be cut off, will there be a transition window, or is it currently undefined?

Alex


Yocto Project Status WW18`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2.4 is due to build this week which would be the final release in the 3.2 series.
  • We are pleased to announce that our April 2022 release (potentially 3.5) will be the next LTS as per our original two year schedule. If there are features desired in the next LTS, now is the time to get them submitted and stabilized ready.
  • Patches are now flowing into master for 3.4 for M1 which is now undergoing active development.
  • We upgraded to gcc 11, thanks Khem for a lot of work in getting up ready to do that!
  • A couple of key fixes for multiconfig builds were added to bitbake.
  • A new uninative version was released to address issues found in patchelf with some native binaries, particularly when gold was used as a linker due to differing note section alignment values.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You  can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.3.1 build date 2021/05/17
  • YP 3.3.1 release date 2021/05/28
  • YP 3.1.8 build date 2021/05/24
  • YP 3.1.8 release date 2021/06/04
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Criteria for bitbake to skip recipes #bitbake

keydi <krzysztof.dudziak@...>
 

I wonder what are all possible criteria for Bitbake to decide to skip
recipe (please compare to reports delivered by bitbake-layers). Recipe
overlay, recipe version, others? Which knowledge source to find more
details in?
Maybe you can explain why you want to know why bitbake would skip a
recipe and that will help us to help you.

Thanks for input.
In meantime certain time ago, I guess there were different types of bitbake-layers output
(I has short opportunity to analyze) which comment several number of packages/recipes
by "recipe skipped" or something like this.
I like to be able to interpret that information properly, what's behind recipe skipped.

Regards
kd


Re: looking for a bit more info on licensing certain recipe files

Robert P. J. Day
 

On Tue, 4 May 2021, Quentin Schulz wrote:

On Tue, May 04, 2021 at 06:00:10AM -0400, Robert P. J. Day wrote:
On Tue, 4 May 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:

for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

as we established recently, packagegroup files need no
licensing, the obvious observation being that they represent the
collection of licenses that comprise them. however, i notice that
the packagegroup.bbclass file does indeed define a default
license:

LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but
it's conditional suggesting one could give it a different license.
what other licenses would make sense for a packagegroup? I'm
sticking with the default that packagegroup recipe files need no
LICENSE assignment, but now i'm curious as to what other options
there are (or perhaps that that default assignment in
packagegroup.bbclass is obsolete).
Wild guess: all packages need a license. MIT is quite permissive so
safe as a default?
superficially makes sense, except that a packagegroup does not
really define a "package". perhaps all *recipe* files need a license
They do define packages. Empty packages, but still packages. Look into
deploy/ipk and search for *packagegroup*, you'll see some.

It's probably a requirement/feature of package managers, so that you
install one package which has a dependency on many others, and the
latter are just pulled in by the package manager directly.

but, again, it's not clear how a packagegroup license should percolate
down to the packages it contains. or how things would percolate up.
It does not apply to packages it RDEPENDS on, it applies to the packages
created by the packagegroup recipe, each of them then RDEPENDS on other
packages (with potentially (and often) licensed differently).
ah, now it makes sense, thanks.

rday


Re: looking for a bit more info on licensing certain recipe files

Quentin Schulz
 

On Tue, May 04, 2021 at 06:00:10AM -0400, Robert P. J. Day wrote:
On Tue, 4 May 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:

for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

as we established recently, packagegroup files need no
licensing, the obvious observation being that they represent the
collection of licenses that comprise them. however, i notice that
the packagegroup.bbclass file does indeed define a default
license:

LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but
it's conditional suggesting one could give it a different license.
what other licenses would make sense for a packagegroup? I'm
sticking with the default that packagegroup recipe files need no
LICENSE assignment, but now i'm curious as to what other options
there are (or perhaps that that default assignment in
packagegroup.bbclass is obsolete).
Wild guess: all packages need a license. MIT is quite permissive so
safe as a default?
superficially makes sense, except that a packagegroup does not
really define a "package". perhaps all *recipe* files need a license
They do define packages. Empty packages, but still packages. Look into
deploy/ipk and search for *packagegroup*, you'll see some.

It's probably a requirement/feature of package managers, so that you
install one package which has a dependency on many others, and the
latter are just pulled in by the package manager directly.

but, again, it's not clear how a packagegroup license should percolate
down to the packages it contains. or how things would percolate up.
It does not apply to packages it RDEPENDS on, it applies to the packages
created by the packagegroup recipe, each of them then RDEPENDS on other
packages (with potentially (and often) licensed differently).

Cheers,
Quentin


Re: looking for a bit more info on licensing certain recipe files

Robert P. J. Day
 

On Tue, 4 May 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:

for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

as we established recently, packagegroup files need no
licensing, the obvious observation being that they represent the
collection of licenses that comprise them. however, i notice that
the packagegroup.bbclass file does indeed define a default
license:

LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but
it's conditional suggesting one could give it a different license.
what other licenses would make sense for a packagegroup? I'm
sticking with the default that packagegroup recipe files need no
LICENSE assignment, but now i'm curious as to what other options
there are (or perhaps that that default assignment in
packagegroup.bbclass is obsolete).
Wild guess: all packages need a license. MIT is quite permissive so
safe as a default?
superficially makes sense, except that a packagegroup does not
really define a "package". perhaps all *recipe* files need a license
but, again, it's not clear how a packagegroup license should percolate
down to the packages it contains. or how things would percolate up.

suddenly, i want some coffee.

the same sort of question can be asked about image files,
including the generic OE core-image*.bb recipe files. of all those
current core-image files:

core-image-base.bb
core-image-minimal.bb
core-image-minimal-dev.bb
core-image-minimal-initramfs.bb
core-image-minimal-mtdutils.bb
core-image-tiny-initramfs.bb

fail into two camps.

the first sets a license, then inherits core-image:

LICENSE = "MIT"
inherit core-image

the second type simply "require"s one of the other recipe files so it
has no need to set its own license, as in core-image-minimal-dev.bb:

require core-image-minimal.bb

similar to packagegroups, does a core-image recipe really need a
separate LICENSE setting, or could that be added to core-image.bbclass
to centralize it (if it's even needed at all)?
Don't know about this one but I guess it's some rest of the original
implementation where I guess everything needed a LICENSE?

I can only guess, but maybe this'll start a discussion :)

finally, WRT .bbappend files, the original recipes will have
their own licenses and if the .bbappend file is doing nothing but
adding some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE,
that sort of thing), then there should be no need for licensing in
the bbappend file. does all this sound reasonable so far?
I wouldn't expect any bbappend to modify a package/recipe license
without changing the sources (version bump). But not much experience
with that, so might be a valid use case?
i'm not *trying* to be overly pedantic (well, yeah, i am :-), but
given the importance of licensing these days, i want to understand how
they work far more than i do at the moment, especially since my new
co-workers are asking me about them.

rday


Re: looking for a bit more info on licensing certain recipe files

Quentin Schulz
 

Hi Robert,

On Tue, Apr 27, 2021 at 08:41:25AM -0400, Robert P. J. Day wrote:

for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

as we established recently, packagegroup files need no licensing,
the obvious observation being that they represent the collection of
licenses that comprise them. however, i notice that the
packagegroup.bbclass file does indeed define a default license:

LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but it's
conditional suggesting one could give it a different license. what
other licenses would make sense for a packagegroup? I'm sticking with
the default that packagegroup recipe files need no LICENSE assignment,
but now i'm curious as to what other options there are (or perhaps
that that default assignment in packagegroup.bbclass is obsolete).
Wild guess: all packages need a license. MIT is quite permissive so safe
as a default?

the same sort of question can be asked about image files, including
the generic OE core-image*.bb recipe files. of all those current
core-image files:

core-image-base.bb
core-image-minimal.bb
core-image-minimal-dev.bb
core-image-minimal-initramfs.bb
core-image-minimal-mtdutils.bb
core-image-tiny-initramfs.bb

fail into two camps.

the first sets a license, then inherits core-image:

LICENSE = "MIT"
inherit core-image

the second type simply "require"s one of the other recipe files so it
has no need to set its own license, as in core-image-minimal-dev.bb:

require core-image-minimal.bb

similar to packagegroups, does a core-image recipe really need a
separate LICENSE setting, or could that be added to core-image.bbclass
to centralize it (if it's even needed at all)?
Don't know about this one but I guess it's some rest of the original
implementation where I guess everything needed a LICENSE?

I can only guess, but maybe this'll start a discussion :)

finally, WRT .bbappend files, the original recipes will have their
own licenses and if the .bbappend file is doing nothing but adding
some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, that sort
of thing), then there should be no need for licensing in the bbappend
file. does all this sound reasonable so far?
I wouldn't expect any bbappend to modify a package/recipe license
without changing the sources (version bump). But not much experience
with that, so might be a valid use case?

Cheers,
Quentin


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Quentin Schulz
 

On Mon, May 03, 2021 at 11:25:09AM -0700, Sven via lists.yoctoproject.org wrote:
Hi,

I have put together a recipe inheriting from go-mod. This project depends on out-of-repo modules that sit in private repos. As long as the SSH key required to pull the requirements is present as a file (under $HOME/.ssh), everything works fine. However, as soon as the SSH credentials are only available via agent and $SSH_AUTH_SOCK, the do_compile step fails. I have traced this down to the fact that the $SSH_AUTH_SOCK environment variable is not available to do_compile which is when the requirements are pulled. This is the sort of error message I get:
On Ubuntu, when the password for my SSH key is in the gnome keyring, I
run:
eval $(/usr/bin/gnome-keyring-daemon --start --components=pkcs11,secrets,ssh); export SSH_AUTH_SOCK
in the terminal that will run bitbake.

No idea if it's the proper way to make it work, but for the few times I
need to fetch new revisions of private repos, it's been good enough to
me.

Hope this helps,
Cheers,
Quentin


M+ & H bugs with Milestone Movements WW18

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW18 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.3 M4

3.4 M1

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.3 M4

3.4 M1

 

13311

xargs: fdleak.c:396: complain_about_leaky_fds: Assertion `no_leaks' failed.

randy.macleod@...

mingli.yu@...

3.3 M4

3.4 M1

 

13533

Devtool finish on _git package with SRCPV in PV points to wrong WORKDIR

randy.macleod@...

jaewon@...

3.3 M3

3.4 M1

 

13625

test_devtool_add_library fails in multilib setups

randy.macleod@...

bluelightning@...

3.3 M3

3.4 M1

 

13722

Debugging With the GNU Project Debugger enhancements

randy.macleod@...

john.kaldas.enpj@...

3.3 M3

3.4 M1

 

13731

Cross canadian GCC fails to find header files when using tclibc-newlib

randy.macleod@...

alejandro@...

3.3 M3

3.4 M1

 

13888

Toaster is not starting for Django-3

david.reyna@...

david.reyna@...

3.1.7

3.4 M1

 

13919

Multi License GPLv3 -lic cannot be installed into the image because it has incompatible license

timothy.t.orling@...

unassigned@...

3.3 M3

3.4 M1

 

13934

Apparent duplication of libtirpc package causes failure in "bitbake linux-yocto -c menuconfig"

randy.macleod@...

hongxu.jia@...

3.3 M4

3.4 M1

 

14085

Toaster UI should know when bitbake crashed

david.reyna@...

david.reyna@...

3.3 M4

3.4 M1

 

14116

Go cannot compile on target

randy.macleod@...

raj.khem@...

3.3 M3

3.4 M1

 

14125

busybox wget ssl is exposed to MitM attack due to CVE-2018-1000500

randy.macleod@...

shachar@...

3.3 M4

3.4 M1

 

14188

Missing packages on brand new Fedora 33

randy.macleod@...

akuster808@...

3.4

3.4 M1

 

14360

oe-selftest oescripts.OEPybootchartguyTests.test_pybootchartguy* failure,  ZeroDivisionError

richard.purdie@...

richard.purdie@...

3.4 M1

---

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW18!

Stephen Jolley
 

All,

 

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

7

steve@...

1

akuster808@...

1

david.reyna@...

1

michael.opdenacker@...

1

timothy.t.orling@...

1

trevor.gamblin@...

1

Grand Total

13

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

 

Below is the list as of top 50 bug owners as of the end of WW18 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 125 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

richard.purdie@...

30

ross@...

28

david.reyna@...

22

bruce.ashfield@...

20

michael.opdenacker@...

17

trevor.gamblin@...

13

bluelightning@...

12

timothy.t.orling@...

12

akuster808@...

11

randy.macleod@...

11

sakib.sajal@...

10

JPEWhacker@...

10

kai.kang@...

8

hongxu.jia@...

7

raj.khem@...

6

chee.yang.lee@...

6

Qi.Chen@...

6

mingli.yu@...

5

yi.zhao@...

4

saul.wold@...

3

mostthingsweb@...

3

pokylinux@...

2

stacygaikovaia@...

2

ydirson@...

2

nicolas.dechesne@...

2

mshah@...

2

jon.mason@...

2

alejandro@...

2

alexandre.belloni@...

2

jaewon@...

2

yf3yu@...

2

john.kaldas.enpj@...

1

changqing.li@...

1

mhalstead@...

1

open.source@...

1

yoctoproject@...

1

liezhi.yang@...

1

devendra.tewari@...

1

prabin.ca@...

1

shachar@...

1

Martin.Jansa@...

1

mister_rs@...

1

jeanmarie.lemetayer@...

1

victor.kamensky7@...

1

aehs29@...

1

kexin.hao@...

1

matthewzmd@...

1

dl9pf@...

1

naveen.kumar.saini@...

1

diego.sueiro@...

1

Nathan.Dunne@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (5/4) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 9am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Criteria for bitbake to skip recipes #bitbake

Randy MacLeod
 

On 2021-04-26 12:25 p.m., keydi wrote:
I wonder what are all possible criteria for Bitbake to decide to skip recipe (please compare to reports delivered by bitbake-layers). Recipe overlay, recipe version, others? Which knowledge source to find more details in?
I'm not aware of a specific list but two that come to mind are,
(in meta-openembedded):

$ rgrep PNBLACKLIST meta-*| wc -l
10
$ rgrep COMPATIBLE_HOST meta-*| wc -l
115


Maybe you can explain why you want to know why bitbake would skip a
recipe and that will help us to help you.



../Randy




--
# Randy MacLeod
# Wind River Linux


SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi,

I have put together a recipe inheriting from go-mod. This project depends on out-of-repo modules that sit in private repos. As long as the SSH key required to pull the requirements is present as a file (under $HOME/.ssh), everything works fine. However, as soon as the SSH credentials are only available via agent and $SSH_AUTH_SOCK, the do_compile step fails. I have traced this down to the fact that the $SSH_AUTH_SOCK environment variable is not available to do_compile which is when the requirements are pulled. This is the sort of error message I get:

ERROR: mypackage-git-r0 do_compile: Execution of '[...]/mypackage/git-r0/temp/run.do_compile.20076' failed with exit code 1:
# cd .; git ls-remote https://bitbucket.org/myorg/some-requirement
Permission denied (publickey).
fatal: Could not read from remote repository.

Note, that the do_fetch step succeeds in pulling the actual repo. I tried fixing the problem by wrapping the do_compile function and providing $SSH_AUTH_SOCK from the original environment:

def origenv(d, var):
return d.getVar("BB_ORIGENV", False).getVar(var, False)

do_compile() {
if [ -n "${@origenv(d, 'SSH_AUTH_SOCK') or ''}" ]; then
export SSH_AUTH_SOCK="${@origenv(d, 'SSH_AUTH_SOCK')}"
fi
go_do_compile
}

This allows the do_compile step (and all subsequent steps) to finish successfully. However, that way, I get a bunch of errors like this (cleansstate does not help):

ERROR: When reparsing [...]/mypackage_git.bb:do_compile, the basehash value changed from eb51e4ec321c723587cec03bb9b33b94ee43e0b0939eb43b52824e3d5cfebec2 to 2bb034f43856917d6454a56b32946b1c68cf7f286b20fd7a7eaf1bfd2a92d34f. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake mypackage -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake mypackage -cdo_compile -Sprintdiff

Neither command helps to fix this. What can I do? I'm on poky yocto-3.1.5-18-gbb7747497a.

Best regards,
Sven


Re: [meta-gplv2][PATCH] elfutils: ignore format-truncation and stringop-overflow issues to fix build with gcc-11

Khem Raj
 

On 5/2/21 11:41 PM, Martin Jansa wrote:
* works around:
http://errors.yoctoproject.org/Errors/Details/580076/
elfutils-0.148/src/ar.c:1088:56: error: '%-*ld' directive output may be truncated writing between 6 and 10 bytes into a region of size 7 [-Werror=format-truncation=]
1088 | snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
| ^~~~~
elfutils-0.148/src/ar.c:1088:55: note: directive argument in the range [0, 4294967295]
1088 | snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
| ^~~~~~~
http://errors.yoctoproject.org/Errors/Details/580078/
elfutils-0.148/tests/addrcfi.c:90:16: error: 'dwarf_frame_register' accessing 96 bytes in a region of size 64 [-Werror=stringop-overflow=]
90 | int result = dwarf_frame_register (stuff->frame, regno, ops_mem, &ops, &nops);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
looks ok. Thanks for fixing it

Signed-off-by: Martin Jansa <Martin.Jansa@...>
---
recipes-devtools/elfutils/elfutils_0.148.bb | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
index 1f07a28..654a715 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -61,6 +61,14 @@ inherit autotools gettext
# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
CFLAGS += "-Wno-error=missing-attributes"
+# There is a fix in 0.171 version (commit b10d7eb74064c5906f031cd17c0f82041c6a4ca1)
+# but 0.171 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=format-truncation="
+
+# There is a fix in 0.182 version (commit 5621fe5443da23112170235dd5cac161e5c75e65)
+# but 0.182 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=stringop-overflow="
+
EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
EXTRA_OECONF_append_class-native = " --without-bzlib"
EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"


[meta-gplv2][PATCH] elfutils: ignore format-truncation and stringop-overflow issues to fix build with gcc-11

Martin Jansa
 

* works around:
http://errors.yoctoproject.org/Errors/Details/580076/
elfutils-0.148/src/ar.c:1088:56: error: '%-*ld' directive output may be truncated writing between 6 and 10 bytes into a region of size 7 [-Werror=format-truncation=]
1088 | snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
| ^~~~~
elfutils-0.148/src/ar.c:1088:55: note: directive argument in the range [0, 4294967295]
1088 | snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", bufsize, val);
| ^~~~~~~

http://errors.yoctoproject.org/Errors/Details/580078/
elfutils-0.148/tests/addrcfi.c:90:16: error: 'dwarf_frame_register' accessing 96 bytes in a region of size 64 [-Werror=stringop-overflow=]
90 | int result = dwarf_frame_register (stuff->frame, regno, ops_mem, &ops, &nops);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Signed-off-by: Martin Jansa <Martin.Jansa@...>
---
recipes-devtools/elfutils/elfutils_0.148.bb | 8 ++++++++
1 file changed, 8 insertions(+)

diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
index 1f07a28..654a715 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -61,6 +61,14 @@ inherit autotools gettext
# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
CFLAGS += "-Wno-error=missing-attributes"

+# There is a fix in 0.171 version (commit b10d7eb74064c5906f031cd17c0f82041c6a4ca1)
+# but 0.171 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=format-truncation="
+
+# There is a fix in 0.182 version (commit 5621fe5443da23112170235dd5cac161e5c75e65)
+# but 0.182 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=stringop-overflow="
+
EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
EXTRA_OECONF_append_class-native = " --without-bzlib"
EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
--
2.30.2


[meta-selinux] MAINTAINERS: Remove myself.

flihp@...
 

I have been inactive for an extended period.

Signed-off-by: Philip Tricca <flihp@...>
---
MAINTAINERS | 5 -----
1 file changed, 5 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36c451f..3166b32 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -24,11 +24,6 @@ F: conf
F: classes
F: recipes-*
=20
-M: Philip Tricca <flihp@...>
-F: conf
-F: classes
-F: recipes-*
-
COMMON
M: Yi Zhao <yi.zhao@...>
F: conf
--=20
2.20.1


Observed issue regarding hostapd

rohit jadhav
 

Hi
can you please help out with following issue
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['hostapd'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.

Thanks and regards
rohit

4041 - 4060 of 57367