Re: [OE-core] [PATCH 4/8] linux-libc-headers: update to 5.13

[Khem Raj]

On Tue, Jul 6, 2021 at 3:01 PM Khem Raj  wrote:
>
> On Tue, Jul 6, 2021 at 11:03 AM Bruce Ashfield  
> wrote:
> >
> > On Tue, Jul 6, 2021 at 1:43 PM Khem Raj  wrote:
> > >
> > > Hi Bruce
> > >
> > > On Fri, Jul 2, 2021 at 8:14 AM Bruce Ashfield  
> > > wrote:
> > > >
> > > > From: Bruce Ashfield 
> > > >
> > > > Bumping the libc-headers to match the latest OE core reference
> > > > kernel.
> > > >
> > > > We refresh one of the musl patches to udpate to the 5.12+ context of
> > > > the header, but otherwise everything is unchanged.
> > > >
> > >
> > > This is primarily going ok, I see one failure however with keepalived here
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1388
> > >
> >
> > I launched a build for keepalived, I'll see if the issue reproduces here.
> >
> > Were you going to debug, or did you want me to have a look ? (We've
> > both looked at this at the same time in the past, and that's not a
> > great use of time).
> >
> > I'll just start looking at a version bump, since that is the easiest
> > place to start.
>
> thats good. If it does not fail for you, it means its due to glibc
> 2.34 and I can take care of that
>

another failure observed with ltrace/mips
see https://errors.yoctoproject.org/Errors/Details/587409/

> >
> > Bruce
> >
> > >
> > > > Signed-off-by: Bruce Ashfield 
> > > > ---
> > > >  meta/conf/distro/include/tcmode-default.inc  |  2 +-
> > > >  ...3-remove-inclusion-of-sysinfo.h-in-kernel.h.patch | 12 ++--
> > > >  ...bc-headers_5.10.bb => linux-libc-headers_5.13.bb} |  5 ++---
> > > >  3 files changed, 9 insertions(+), 10 deletions(-)
> > > >  rename 
> > > > meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.10.bb => 
> > > > linux-libc-headers_5.13.bb} (80%)
> > > >
> > > > diff --git a/meta/conf/distro/include/tcmode-default.inc 
> > > > b/meta/conf/distro/include/tcmode-default.inc
> > > > index c6e5ac61d7..68e5d848ba 100644
> > > > --- a/meta/conf/distro/include/tcmode-default.inc
> > > > +++ b/meta/conf/distro/include/tcmode-default.inc
> > > > @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
> > > >  BINUVERSION ?= "2.36%"
> > > >  GDBVERSION ?= "10.%"
> > > >  GLIBCVERSION ?= "2.33"
> > > > -LINUXLIBCVERSION ?= "5.10%"
> > > > +LINUXLIBCVERSION ?= "5.13%"
> > > >  QEMUVERSION ?= "6.0%"
> > > >  GOVERSION ?= "1.16%"
> > > >  # This can not use wildcards like 8.0.% since it is also used in mesa 
> > > > to denote
> > > > diff --git 
> > > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > >  
> > > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > > index b5c4e1750e..b0e7014138 100644
> > > > --- 
> > > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > > +++ 
> > > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > > @@ -13,17 +13,17 @@ Upstream-Status: Submitted
> > > >   include/uapi/linux/kernel.h | 2 ++
> > > >   1 file changed, 2 insertions(+)
> > > >
> > > > -Index: linux-4.8-rc4/include/uapi/linux/kernel.h
> > > > +Index: linux-5.12.11/include/uapi/linux/kernel.h
> > > >  ===
> > > >  linux-4.8-rc4.orig/include/uapi/linux/kernel.h
> > > > -+++ linux-4.8-rc4/include/uapi/linux/kernel.h
> > > > -@@ -1,7 +1,9 @@
> > > > +--- linux-5.12.11.orig/include/uapi/linux/kernel.h
> > > >  linux-5.12.11/include/uapi/linux/kernel.h
> > > > +@@ -2,7 +2,9 @@
> > > >   #ifndef _UAPI_LINUX_KERNEL_H
> > > >   #define _UAPI_LINUX_KERNEL_H
> > > >
> > > >  +#ifdef __GLIBC__
> > > >   #include 
> > > > + #include 
> > > >  +#endif
> > > >
> > > > - /*
> > > > -  * 'kernel.h' contains some often-used function prototypes etc
> > > > + #endif /* _UAPI_LINUX_KERNEL_H */
> > > > diff --git 
> > > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb 
> > > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > > similarity index 80%
> > > > rename from 
> > > > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > > > rename to 
> > > > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > > index d6a4d5aa61..251d00440d 100644
> > > > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > > > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > > @@ -14,6 +14,5 @@ SRC_URI_append = "\
> > > >
> > > >  LIC_FILES_CHKSUM = 
> > > > "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
> > > >
> > > > -SRC_URI[md5sum] = "753adc474bf799d569dec4f165ed92c3"
> > > > -SRC_URI[sha256sum] = 
> > > > "dcdf99e43e98330d925016985bfbc7b83c66d367b714b2de0cbbfcbf83d8ca43"
> > > > -
> > > > +SRC_URI[md5sum] = "76c60fb304510a7bbd9c838790bc5fe4"
> > > > +SRC_URI[sha256sum] = 
> > > > 

Re: [OE-core] [PATCH] linux-yocto/5.13: add devupstream support

[Bruce Ashfield]

On Tue, Jul 6, 2021 at 5:48 PM Paul Barker  wrote:
>
> On Tue,  6 Jul 2021 13:58:21 -0400
> "Bruce Ashfield"  wrote:
>
> > From: Bruce Ashfield 
> >
> > We are always getting questions about building -stable, or mainline
> > master. Rather than introducing a separate set of recipes, we can
> > facilitate this sort of testing by using the existing devupstream
> > bbclass support.
> >
> > To build an unpatched or otherwise modifed -stable of 5.13, simply
> > set the linux-yocto preferred version to:
> >
> >   upstream+5.13%
> >
> > And your wish will be granted, as the build will use v5.13/base
> > which matches the main linux-yocto version, simply with no extra
> > changes applied.
> >
> > Signed-off-by: Bruce Ashfield 
>
> This looks like a good thing to have in oe-core, in the basic case of
> just wanting the latest mainline as-is you'd not need to add extra
> layers any longer. meta-linux-mainline would still fill a niche as it
> provides recipes for older stable kernels and supports using mainline &
> newer stable kernels on dunfell & hardknott.

Agreed, since we are still holding to the cadence in master of LTS +
"latest" + dev. So those older -stables are still being updated in the
various linux-yocto branches, but the SRCREV bumps and versioned
recipes are still only in their respective release branches. So someone
that wants those older versions, needs a copy of the recipe, or uses
meta-linux-mainline (as you just said :)

>
> I guess the meta repository (yocto-kernel-cache) would still be cloned
> and the upstream kernel could still be modified by patches or config
> fragments enabled by KERNEL_FEATURES. That may be worth noting in the
> documentation if I'm right. For my use-case where I want to use the
> exact upstream defconfig I would probably need to override this, e.g.
> `KERNEL_FEATURES_forcevariable = ""`, to make use of this.

Right, I want to clear some of the features when this is used, since they aren't
all available. I've run into it a few times myself, and the unconditional append
of some of the features are an issue, not only in this use case but in others
where fragments are supported, but linux-yocto isn't used.  I just need to
detangle things a bit and make their appends be specific to linux-yocto and
skip them for the devupstream variant.

So hopefully once I have this into shape, we won't need to document it, since
it'll be 'fixed' .. but good catch, that is an important point.

>
> I also guess this would also allow you to follow newer kernel releases
> as they're added to linux-yocto recipes by setting the preferred version
> to 'upstream%' (or maybe 'upstream+%' to be more restrictive). That
> would then avoid the build breaking when the 5.13 recipe disappears and
> is replaced by 5.14 or something else later.

Yes. That wasn't something I was thinking about, but you could definitely
do that and have it follow along as the newly versioned recipe is added
(and potentially older ones removed) without needing to explicitly change
your preferred version.

Bruce

>
> Thanks,
>
> --
> Paul Barker
> https://pbarker.dev/



-- 
- 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 (#153630): 
https://lists.openembedded.org/g/openembedded-core/message/153630
Mute This Topic: https://lists.openembedded.org/mt/84026594/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 4/8] linux-libc-headers: update to 5.13

[Khem Raj]

On Tue, Jul 6, 2021 at 11:03 AM Bruce Ashfield  wrote:
>
> On Tue, Jul 6, 2021 at 1:43 PM Khem Raj  wrote:
> >
> > Hi Bruce
> >
> > On Fri, Jul 2, 2021 at 8:14 AM Bruce Ashfield  
> > wrote:
> > >
> > > From: Bruce Ashfield 
> > >
> > > Bumping the libc-headers to match the latest OE core reference
> > > kernel.
> > >
> > > We refresh one of the musl patches to udpate to the 5.12+ context of
> > > the header, but otherwise everything is unchanged.
> > >
> >
> > This is primarily going ok, I see one failure however with keepalived here
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1388
> >
>
> I launched a build for keepalived, I'll see if the issue reproduces here.
>
> Were you going to debug, or did you want me to have a look ? (We've
> both looked at this at the same time in the past, and that's not a
> great use of time).
>
> I'll just start looking at a version bump, since that is the easiest
> place to start.

thats good. If it does not fail for you, it means its due to glibc
2.34 and I can take care of that

>
> Bruce
>
> >
> > > Signed-off-by: Bruce Ashfield 
> > > ---
> > >  meta/conf/distro/include/tcmode-default.inc  |  2 +-
> > >  ...3-remove-inclusion-of-sysinfo.h-in-kernel.h.patch | 12 ++--
> > >  ...bc-headers_5.10.bb => linux-libc-headers_5.13.bb} |  5 ++---
> > >  3 files changed, 9 insertions(+), 10 deletions(-)
> > >  rename 
> > > meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.10.bb => 
> > > linux-libc-headers_5.13.bb} (80%)
> > >
> > > diff --git a/meta/conf/distro/include/tcmode-default.inc 
> > > b/meta/conf/distro/include/tcmode-default.inc
> > > index c6e5ac61d7..68e5d848ba 100644
> > > --- a/meta/conf/distro/include/tcmode-default.inc
> > > +++ b/meta/conf/distro/include/tcmode-default.inc
> > > @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
> > >  BINUVERSION ?= "2.36%"
> > >  GDBVERSION ?= "10.%"
> > >  GLIBCVERSION ?= "2.33"
> > > -LINUXLIBCVERSION ?= "5.10%"
> > > +LINUXLIBCVERSION ?= "5.13%"
> > >  QEMUVERSION ?= "6.0%"
> > >  GOVERSION ?= "1.16%"
> > >  # This can not use wildcards like 8.0.% since it is also used in mesa to 
> > > denote
> > > diff --git 
> > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > >  
> > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > index b5c4e1750e..b0e7014138 100644
> > > --- 
> > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > +++ 
> > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > > @@ -13,17 +13,17 @@ Upstream-Status: Submitted
> > >   include/uapi/linux/kernel.h | 2 ++
> > >   1 file changed, 2 insertions(+)
> > >
> > > -Index: linux-4.8-rc4/include/uapi/linux/kernel.h
> > > +Index: linux-5.12.11/include/uapi/linux/kernel.h
> > >  ===
> > >  linux-4.8-rc4.orig/include/uapi/linux/kernel.h
> > > -+++ linux-4.8-rc4/include/uapi/linux/kernel.h
> > > -@@ -1,7 +1,9 @@
> > > +--- linux-5.12.11.orig/include/uapi/linux/kernel.h
> > >  linux-5.12.11/include/uapi/linux/kernel.h
> > > +@@ -2,7 +2,9 @@
> > >   #ifndef _UAPI_LINUX_KERNEL_H
> > >   #define _UAPI_LINUX_KERNEL_H
> > >
> > >  +#ifdef __GLIBC__
> > >   #include 
> > > + #include 
> > >  +#endif
> > >
> > > - /*
> > > -  * 'kernel.h' contains some often-used function prototypes etc
> > > + #endif /* _UAPI_LINUX_KERNEL_H */
> > > diff --git 
> > > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb 
> > > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > similarity index 80%
> > > rename from 
> > > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > > rename to 
> > > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > index d6a4d5aa61..251d00440d 100644
> > > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > > @@ -14,6 +14,5 @@ SRC_URI_append = "\
> > >
> > >  LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
> > >
> > > -SRC_URI[md5sum] = "753adc474bf799d569dec4f165ed92c3"
> > > -SRC_URI[sha256sum] = 
> > > "dcdf99e43e98330d925016985bfbc7b83c66d367b714b2de0cbbfcbf83d8ca43"
> > > -
> > > +SRC_URI[md5sum] = "76c60fb304510a7bbd9c838790bc5fe4"
> > > +SRC_URI[sha256sum] = 
> > > "3f6baa97f37518439f51df2e4f3d65a822ca5ff016aa8e60d2cc53b95a6c89d9"
> > > --
> > > 2.19.1
> > >
> > >
> > > 
> > >
>
>
>
> --
> - 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 (#153629): 

Re: [OE-core] [PATCH] linux-yocto/5.13: add devupstream support

[Paul Barker]

On Tue,  6 Jul 2021 13:58:21 -0400
"Bruce Ashfield"  wrote:

> From: Bruce Ashfield 
> 
> We are always getting questions about building -stable, or mainline
> master. Rather than introducing a separate set of recipes, we can
> facilitate this sort of testing by using the existing devupstream
> bbclass support.
> 
> To build an unpatched or otherwise modifed -stable of 5.13, simply
> set the linux-yocto preferred version to:
> 
>   upstream+5.13%
> 
> And your wish will be granted, as the build will use v5.13/base
> which matches the main linux-yocto version, simply with no extra
> changes applied.
> 
> Signed-off-by: Bruce Ashfield 

This looks like a good thing to have in oe-core, in the basic case of
just wanting the latest mainline as-is you'd not need to add extra
layers any longer. meta-linux-mainline would still fill a niche as it
provides recipes for older stable kernels and supports using mainline &
newer stable kernels on dunfell & hardknott.

I guess the meta repository (yocto-kernel-cache) would still be cloned
and the upstream kernel could still be modified by patches or config
fragments enabled by KERNEL_FEATURES. That may be worth noting in the
documentation if I'm right. For my use-case where I want to use the
exact upstream defconfig I would probably need to override this, e.g.
`KERNEL_FEATURES_forcevariable = ""`, to make use of this.

I also guess this would also allow you to follow newer kernel releases
as they're added to linux-yocto recipes by setting the preferred version
to 'upstream%' (or maybe 'upstream+%' to be more restrictive). That
would then avoid the build breaking when the 5.13 recipe disappears and
is replaced by 5.14 or something else later.

Thanks,

-- 
Paul Barker
https://pbarker.dev/


pgpYwwMxtWjZZ.pgp
Description: OpenPGP digital signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153628): 
https://lists.openembedded.org/g/openembedded-core/message/153628
Mute This Topic: https://lists.openembedded.org/mt/84026594/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] Revert "libubootenv: inherit uboot-config"

[Otavio Salvador]

Em ter., 6 de jul. de 2021 às 15:39, Peter Bergin 
escreveu:

> Hi Otavio,
> On 2021-07-06 18:56, Otavio Salvador wrote:
>
>
>
> Em ter., 6 de jul. de 2021 às 12:12, Peter Bergin 
> escreveu:
>
>> Then I can correct my earlier statement and a new wisdom that run-time
>> dependecies are scanned already in the early phases. Apparently it is
>> not possible to build libubootenv due to RRECOMMENDS to
>> u-boot-default-env. The build for a 'non-u-boot config' will fail if we
>> add 'inherit uboot-config' and it will fail without. What is the
>> difference for a 'world' build?
>>
>
> The dependency on the default-env seems too strong. It could be relaxed as
> it works without it.
>
> Do we have a run-time dependency that is 'lesser than' RRECOMMENDS? Or do
> you suggest removing the dependency?
>

There is RSUGGESTS but I am unsure package managers handle it properly.
Ideally, we'd have a dummy one which would be replaced by the machine one
if available.



-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153627): 
https://lists.openembedded.org/g/openembedded-core/message/153627
Mute This Topic: https://lists.openembedded.org/mt/83938334/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] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

[Alex Stewart]

On 7/6/21 3:12 PM, Richard Purdie wrote:

Kernel modules can be:

a) not built at all
b) built into the kernel3
c) built as separate packages

For OE, where something needs a kernel module, we suggest people:

RRECOMMEND_XXX += "kernel-module-xxx"

and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*".

 From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC
covers kernel-modules-xxx) and then hands off to the package manager.

In the case it was built in, the Recommends will be passed over by the
package manager since it is just a suggestion. If the module is present,
it would be included in the image.

The issue as described is that if someone has IMAGE_INSTALL containing
kernel-module-xxx *and* some other package in the image RRECOMMENDS that
module, it doesn't error if the package doesn't exist.

I have to admit I don't remember how IMAGE_INSTALL is being passed into
opkg but the change in behaviour due to the addition of a RRECOMMENDS does
not sound right to me. The rpm backend does not do that but errors
consistently.


Yep; I understand all of that and agree. My goal here is just to make 
sure that the bug is filed to the correct location. As it stands, the 
only description of the error is from OE's perspective, and I'd like to 
get some understanding of the interface between OE and opkg, for this 
special case.



It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled
by the Recommends from some sub package dependency.


I know that IMAGE_INSTALL gets consumed into PACKAGE_INSTALL, which gets 
pass off to the PM modules (iirc.) And I also recall there being a 
PACKAGE_INSTALL_ATTEMPTONLY variable[1]. I wonder if RRECOMMENDS are 
being ATTEMPTed (either through that variable, or a similar one), and 
the failed attempt is pre-empting the mandatory install attempt. Worth 
looking into.


[1] 
https://git.openembedded.org/openembedded-core/tree/meta/classes/image.bbclass#n79



If we're driving opkg incorrectly, we should fix that but I'm not sure
where the issue is, I suspect opkg...


Why do you suspect opkg? The situation from its perspective is only that 
`kernel-module-xxx` is recommended by another package, but not available 
in the feeds. There's nothing invalid about that state that would cause 
opkg to throw an error.


Thanks,

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

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153626): 
https://lists.openembedded.org/g/openembedded-core/message/153626
Mute This Topic: https://lists.openembedded.org/mt/83779506/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] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

[Richard Purdie]

On Tue, 2021-07-06 at 14:39 -0500, Alex Stewart wrote:
> Hey Rasmus,
> 
> Sorry for the delay; I was OOO for the holidays and I'm just now working 
> through my inbox.
> 
> On 6/28/21 4:17 AM, Rasmus Villemoes wrote:
> > On 25/06/2021 18.13, Richard Purdie wrote:
> > > That is probably a bug that needs opening against opkg in bugzilla then.
> > > Added Alex to Cc: (opkg maintainer).
> > Indeed, thanks. Alex, do you have enough context from the above, or do I
> > need to do anything explicitly to file a bug?
> > 
> > Rasmus
> 
> Could you expand a bit on how OE is supposed to fail when the kernel 
> module package is unsatisfiable? Does it propagate a opkg satisfaction 
> error, or is the misconfiguration caught in the OE python modules?
> 
> I ask because it seems most likely to me that the inconsistency here is 
> in the OE opkg interface modules, rather than opkg itself - which 
> obviously has no concept of IMAGE_INSTALL or the kernel configuration.
> 
> Can you identify the set of packages that OE is requesting opkg to 
> install, with and without the RRECOMMENDS? That would help to 
> distinguish between an inconsistency in the OE PackageManager modules 
> and a bug in opkg itself.

Kernel modules can be:

a) not built at all
b) built into the kernel
c) built as separate packages

For OE, where something needs a kernel module, we suggest people:

RRECOMMEND_XXX += "kernel-module-xxx"

and the kernel recipe has PACKAGES_DYNAMIC = "kernel-module-*".

>From bitbake's perspective, it builds the kernel (since the PACKAGES_DYNAMIC 
covers kernel-modules-xxx) and then hands off to the package manager.

In the case it was built in, the Recommends will be passed over by the 
package manager since it is just a suggestion. If the module is present,
it would be included in the image.

The issue as described is that if someone has IMAGE_INSTALL containing
kernel-module-xxx *and* some other package in the image RRECOMMENDS that 
module, it doesn't error if the package doesn't exist.

I have to admit I don't remember how IMAGE_INSTALL is being passed into
opkg but the change in behaviour due to the addition of a RRECOMMENDS does
not sound right to me. The rpm backend does not do that but errors 
consistently.

It sounds like the "Depends" from IMAGE_INSTALL is somehow being overruled
by the Recommends from some sub package dependency.

If we're driving opkg incorrectly, we should fix that but I'm not sure
where the issue is, I suspect opkg...

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153625): 
https://lists.openembedded.org/g/openembedded-core/message/153625
Mute This Topic: https://lists.openembedded.org/mt/83779506/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] RRECOMMENDS "masking" unsatisfiable IMAGE_INSTALL

[Alex Stewart]

Hey Rasmus,

Sorry for the delay; I was OOO for the holidays and I'm just now working 
through my inbox.


On 6/28/21 4:17 AM, Rasmus Villemoes wrote:

On 25/06/2021 18.13, Richard Purdie wrote:

That is probably a bug that needs opening against opkg in bugzilla then.
Added Alex to Cc: (opkg maintainer).

Indeed, thanks. Alex, do you have enough context from the above, or do I
need to do anything explicitly to file a bug?

Rasmus


Could you expand a bit on how OE is supposed to fail when the kernel 
module package is unsatisfiable? Does it propagate a opkg satisfaction 
error, or is the misconfiguration caught in the OE python modules?


I ask because it seems most likely to me that the inconsistency here is 
in the OE opkg interface modules, rather than opkg itself - which 
obviously has no concept of IMAGE_INSTALL or the kernel configuration.


Can you identify the set of packages that OE is requesting opkg to 
install, with and without the RRECOMMENDS? That would help to 
distinguish between an inconsistency in the OE PackageManager modules 
and a bug in opkg itself.


Thanks,

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

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153624): 
https://lists.openembedded.org/g/openembedded-core/message/153624
Mute This Topic: https://lists.openembedded.org/mt/83779506/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] Revert "libubootenv: inherit uboot-config"

[Peter Bergin]

Hi Otavio,

On 2021-07-06 18:56, Otavio Salvador wrote:



Em ter., 6 de jul. de 2021 às 12:12, Peter Bergin 
mailto:pe...@berginkonsult.se>> escreveu:


Then I can correct my earlier statement and a new wisdom that
run-time
dependecies are scanned already in the early phases. Apparently it is
not possible to build libubootenv due to RRECOMMENDS to
u-boot-default-env. The build for a 'non-u-boot config' will fail
if we
add 'inherit uboot-config' and it will fail without. What is the
difference for a 'world' build?


The dependency on the default-env seems too strong. It could be 
relaxed as it works without it.


Do we have a run-time dependency that is 'lesser than' RRECOMMENDS? Or 
do you suggest removing the dependency?


/Peter


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

Re: [OE-core] [PATCH 4/8] linux-libc-headers: update to 5.13

[Bruce Ashfield]

On Tue, Jul 6, 2021 at 1:43 PM Khem Raj  wrote:
>
> Hi Bruce
>
> On Fri, Jul 2, 2021 at 8:14 AM Bruce Ashfield  
> wrote:
> >
> > From: Bruce Ashfield 
> >
> > Bumping the libc-headers to match the latest OE core reference
> > kernel.
> >
> > We refresh one of the musl patches to udpate to the 5.12+ context of
> > the header, but otherwise everything is unchanged.
> >
>
> This is primarily going ok, I see one failure however with keepalived here
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1388
>

I launched a build for keepalived, I'll see if the issue reproduces here.

Were you going to debug, or did you want me to have a look ? (We've
both looked at this at the same time in the past, and that's not a
great use of time).

I'll just start looking at a version bump, since that is the easiest
place to start.

Bruce

>
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  meta/conf/distro/include/tcmode-default.inc  |  2 +-
> >  ...3-remove-inclusion-of-sysinfo.h-in-kernel.h.patch | 12 ++--
> >  ...bc-headers_5.10.bb => linux-libc-headers_5.13.bb} |  5 ++---
> >  3 files changed, 9 insertions(+), 10 deletions(-)
> >  rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.10.bb 
> > => linux-libc-headers_5.13.bb} (80%)
> >
> > diff --git a/meta/conf/distro/include/tcmode-default.inc 
> > b/meta/conf/distro/include/tcmode-default.inc
> > index c6e5ac61d7..68e5d848ba 100644
> > --- a/meta/conf/distro/include/tcmode-default.inc
> > +++ b/meta/conf/distro/include/tcmode-default.inc
> > @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
> >  BINUVERSION ?= "2.36%"
> >  GDBVERSION ?= "10.%"
> >  GLIBCVERSION ?= "2.33"
> > -LINUXLIBCVERSION ?= "5.10%"
> > +LINUXLIBCVERSION ?= "5.13%"
> >  QEMUVERSION ?= "6.0%"
> >  GOVERSION ?= "1.16%"
> >  # This can not use wildcards like 8.0.% since it is also used in mesa to 
> > denote
> > diff --git 
> > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> >  
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > index b5c4e1750e..b0e7014138 100644
> > --- 
> > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > +++ 
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> > @@ -13,17 +13,17 @@ Upstream-Status: Submitted
> >   include/uapi/linux/kernel.h | 2 ++
> >   1 file changed, 2 insertions(+)
> >
> > -Index: linux-4.8-rc4/include/uapi/linux/kernel.h
> > +Index: linux-5.12.11/include/uapi/linux/kernel.h
> >  ===
> >  linux-4.8-rc4.orig/include/uapi/linux/kernel.h
> > -+++ linux-4.8-rc4/include/uapi/linux/kernel.h
> > -@@ -1,7 +1,9 @@
> > +--- linux-5.12.11.orig/include/uapi/linux/kernel.h
> >  linux-5.12.11/include/uapi/linux/kernel.h
> > +@@ -2,7 +2,9 @@
> >   #ifndef _UAPI_LINUX_KERNEL_H
> >   #define _UAPI_LINUX_KERNEL_H
> >
> >  +#ifdef __GLIBC__
> >   #include 
> > + #include 
> >  +#endif
> >
> > - /*
> > -  * 'kernel.h' contains some often-used function prototypes etc
> > + #endif /* _UAPI_LINUX_KERNEL_H */
> > diff --git 
> > a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb 
> > b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > similarity index 80%
> > rename from 
> > meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > rename to meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > index d6a4d5aa61..251d00440d 100644
> > --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> > +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> > @@ -14,6 +14,5 @@ SRC_URI_append = "\
> >
> >  LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
> >
> > -SRC_URI[md5sum] = "753adc474bf799d569dec4f165ed92c3"
> > -SRC_URI[sha256sum] = 
> > "dcdf99e43e98330d925016985bfbc7b83c66d367b714b2de0cbbfcbf83d8ca43"
> > -
> > +SRC_URI[md5sum] = "76c60fb304510a7bbd9c838790bc5fe4"
> > +SRC_URI[sha256sum] = 
> > "3f6baa97f37518439f51df2e4f3d65a822ca5ff016aa8e60d2cc53b95a6c89d9"
> > --
> > 2.19.1
> >
> >
> > 
> >



-- 
- 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 (#153622): 
https://lists.openembedded.org/g/openembedded-core/message/153622
Mute This Topic: https://lists.openembedded.org/mt/83942263/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] linux-yocto/5.13: add devupstream support

[Bruce Ashfield]

From: Bruce Ashfield 

We are always getting questions about building -stable, or mainline
master. Rather than introducing a separate set of recipes, we can
facilitate this sort of testing by using the existing devupstream
bbclass support.

To build an unpatched or otherwise modifed -stable of 5.13, simply
set the linux-yocto preferred version to:

  upstream+5.13%

And your wish will be granted, as the build will use v5.13/base
which matches the main linux-yocto version, simply with no extra
changes applied.

Signed-off-by: Bruce Ashfield 
---

Richard,

This is the patch that I was talking about earlier in the yocto dev
meeting.

I personally find this the easiest to maintain, since it is just
a variant of linux-yocto_, and ends up just being a
different branch versus anything radically different.

I am open to making this a different / named recipe to make the
distinction more clear, but I'm worried about the impression
that we were doing extensive testing on the bare -stable branches
when most of the testing (which is transient to the base -stable)
happens on our standard/base branch.

Either way, I'll work on getting this and the -dev tweaks I sent
earlier added to some part of our AB testing to make sure that
they stay in good shape.

Cheers,

Bruce


 meta/recipes-kernel/linux/linux-yocto_5.13.bb | 9 +
 1 file changed, 9 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.13.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.13.bb
index 66384d8f7d..cd51e04b95 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.13.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.13.bb
@@ -25,6 +25,15 @@ SRCREV_machine_qemumips64 ?= 
"b74fe3dcca0653609fcb75aad883b1db07619081"
 SRCREV_machine ?= "b1cead8d98582ca687f93e06438543b97144e5bf"
 SRCREV_meta ?= "ceb5fa598d08902fe2934c041875aa92d9a6fa19"
 
+# set your preferred version of linux-yocto to 'upstream+%', and 
you'll
+# get the /base branch, which is pure upstream -stable, and the same
+# meta SRCREV as the linux-yocto-standard builds
+BBCLASSEXTEND = "devupstream:target"
+DEFAULT_PREFERENCE_class-devupstream = "-1"
+SRCREV_class-devupstream = "62fb9874f5da54fdb243003b386128037319b219"
+PV_class-devupstream = "upstream+${LINUX_VERSION}+git${SRCPV}"
+KBRANCH_class-devupstream = "v5.13/base"
+
 # remap qemuarm to qemuarma15 for the 5.8 kernel
 # KMACHINE_qemuarm ?= "qemuarma15"
 
-- 
2.19.1


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

Re: [OE-core] [PATCH 4/8] linux-libc-headers: update to 5.13

[Khem Raj]

Hi Bruce

On Fri, Jul 2, 2021 at 8:14 AM Bruce Ashfield  wrote:
>
> From: Bruce Ashfield 
>
> Bumping the libc-headers to match the latest OE core reference
> kernel.
>
> We refresh one of the musl patches to udpate to the 5.12+ context of
> the header, but otherwise everything is unchanged.
>

This is primarily going ok, I see one failure however with keepalived here

https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/1388


> Signed-off-by: Bruce Ashfield 
> ---
>  meta/conf/distro/include/tcmode-default.inc  |  2 +-
>  ...3-remove-inclusion-of-sysinfo.h-in-kernel.h.patch | 12 ++--
>  ...bc-headers_5.10.bb => linux-libc-headers_5.13.bb} |  5 ++---
>  3 files changed, 9 insertions(+), 10 deletions(-)
>  rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.10.bb => 
> linux-libc-headers_5.13.bb} (80%)
>
> diff --git a/meta/conf/distro/include/tcmode-default.inc 
> b/meta/conf/distro/include/tcmode-default.inc
> index c6e5ac61d7..68e5d848ba 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
>  BINUVERSION ?= "2.36%"
>  GDBVERSION ?= "10.%"
>  GLIBCVERSION ?= "2.33"
> -LINUXLIBCVERSION ?= "5.10%"
> +LINUXLIBCVERSION ?= "5.13%"
>  QEMUVERSION ?= "6.0%"
>  GOVERSION ?= "1.16%"
>  # This can not use wildcards like 8.0.% since it is also used in mesa to 
> denote
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
>  
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> index b5c4e1750e..b0e7014138 100644
> --- 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> +++ 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers/0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch
> @@ -13,17 +13,17 @@ Upstream-Status: Submitted
>   include/uapi/linux/kernel.h | 2 ++
>   1 file changed, 2 insertions(+)
>
> -Index: linux-4.8-rc4/include/uapi/linux/kernel.h
> +Index: linux-5.12.11/include/uapi/linux/kernel.h
>  ===
>  linux-4.8-rc4.orig/include/uapi/linux/kernel.h
> -+++ linux-4.8-rc4/include/uapi/linux/kernel.h
> -@@ -1,7 +1,9 @@
> +--- linux-5.12.11.orig/include/uapi/linux/kernel.h
>  linux-5.12.11/include/uapi/linux/kernel.h
> +@@ -2,7 +2,9 @@
>   #ifndef _UAPI_LINUX_KERNEL_H
>   #define _UAPI_LINUX_KERNEL_H
>
>  +#ifdef __GLIBC__
>   #include 
> + #include 
>  +#endif
>
> - /*
> -  * 'kernel.h' contains some often-used function prototypes etc
> + #endif /* _UAPI_LINUX_KERNEL_H */
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> similarity index 80%
> rename from meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> rename to meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> index d6a4d5aa61..251d00440d 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.10.bb
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.13.bb
> @@ -14,6 +14,5 @@ SRC_URI_append = "\
>
>  LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
>
> -SRC_URI[md5sum] = "753adc474bf799d569dec4f165ed92c3"
> -SRC_URI[sha256sum] = 
> "dcdf99e43e98330d925016985bfbc7b83c66d367b714b2de0cbbfcbf83d8ca43"
> -
> +SRC_URI[md5sum] = "76c60fb304510a7bbd9c838790bc5fe4"
> +SRC_URI[sha256sum] = 
> "3f6baa97f37518439f51df2e4f3d65a822ca5ff016aa8e60d2cc53b95a6c89d9"
> --
> 2.19.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153620): 
https://lists.openembedded.org/g/openembedded-core/message/153620
Mute This Topic: https://lists.openembedded.org/mt/83942263/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] texinfo: update 6.7 -> 6.8

[Khem Raj]

On Tue, Jul 6, 2021 at 1:39 AM Alexander Kanavin  wrote:
>
> Once again: it was bundled with the initial recipe submission over 10 years 
> ago, without explanation or origin info, and not added later on. There was 
> never any indication anyone finds it useful. Probably someone just took all 
> of Red Hat's patches without reviewing their utility.
>
> I am not porting it forward, the use case is simply not there, what you are 
> saying is utter madness, and we should spend our time on actually useful 
> things, where there is clear evidence they are useful.
>

My consideration was if it was being used for larger distributions
being built using OE they might be using this but then perhaps we do
not have data on someone using it and no one has raised their hand.
 I do not have a direct usecase where info files are shipped on target
either. in that light perhaps its fine to drop it.

> Alex
>
> On Tue, 6 Jul 2021 at 10:29, Khem Raj  wrote:
>>
>> On Tue, Jul 6, 2021 at 12:31 AM Alexander Kanavin
>>  wrote:
>> >
>> > Khem, please. What is the use case you are trying to justify? Who on earth 
>> > would want to install and read .info files on a target device (of the kind 
>> > where saving a few kilobytes matters, no less!), when it's a million times 
>> > more convenient to do that on the host, or just open the same things 
>> > hosted online in a browser?
>> >
>>
>> iff its added I would err on the side that patch is used by users,
>> since adding a patch to implement unused feature would be counter
>> intuitive.
>> This patch has been there for long time in OE, there is not much
>> effort to port it forward as other distros are maintaining this patch
>> too, perhaps its better to carry this on, I would have agreed if it
>> was something that OE was lugging along alone.
>>
>> > Sorry, no.
>>
>> thats fine, drop this upgrade.
>>
>> >
>> > Alex
>> >
>> > On Tue, 6 Jul 2021 at 01:01, Khem Raj  wrote:
>> >>
>> >> On Mon, Jul 5, 2021 at 11:35 AM Alexander Kanavin
>> >>  wrote:
>> >> >
>> >> > Drop texinfo-4.12-zlib.patch as it completely lacks a description,
>> >>
>> >> if it is not described then perhaps adding description to it will make
>> >> things better, the patch is adding gz compressed
>> >> info files which should reduce the size of these files which is quite
>> >> good for embedded systems. Distros like fedora and suse
>> >> are carrying this patch too.
>> >>
>> >> > was added together with the original recipe without an explanation in
>> >> > the commit message, and is difficult to rebase.
>> >> >
>> >>
>> >> Get it from 
>> >> https://src.fedoraproject.org/rpms/texinfo/raw/rawhide/f/texinfo-4.12-zlib.patch
>> >> this time.
>> >>
>> >> > Signed-off-by: Alexander Kanavin 
>> >> > ---
>> >> >  .../texinfo/texinfo/texinfo-4.12-zlib.patch   | 254 --
>> >> >  .../{texinfo_6.7.bb => texinfo_6.8.bb}|   4 +-
>> >> >  2 files changed, 1 insertion(+), 257 deletions(-)
>> >> >  delete mode 100644 
>> >> > meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> >> >  rename meta/recipes-extended/texinfo/{texinfo_6.7.bb => 
>> >> > texinfo_6.8.bb} (94%)
>> >> >
>> >> > diff --git 
>> >> > a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch 
>> >> > b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> >> > deleted file mode 100644
>> >> > index f72097e639..00
>> >> > --- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> >> > +++ /dev/null
>> >> > @@ -1,254 +0,0 @@
>> >> > -From 3d3b66cf398853c666e724c3dbcc37d53a2240d5 Mon Sep 17 00:00:00 2001
>> >> > -From: Edwin Plauchu 
>> >> > -Date: Tue, 29 Nov 2016 12:27:17 -0600
>> >> > -Subject: [PATCH] texinfo-4.12-zlib
>> >> > -
>> >> > -Upstream-Status: Pending
>> >> > -
>> >> > -Signed-off-by: Jussi Kukkonen 
>> >> > -Signed-off-by: Edwin Plauchu 
>> >> > -
>> >> > 
>> >> > - install-info/Makefile.in|  2 +-
>> >> > - install-info/install-info.c | 79 ++---
>> >> > - 2 files changed, 48 insertions(+), 33 deletions(-)
>> >> > -
>> >> > -diff --git a/install-info/Makefile.in b/install-info/Makefile.in
>> >> > -index c924509..746df05 100644
>> >> >  a/install-info/Makefile.in
>> >> > -+++ b/install-info/Makefile.in
>> >> > -@@ -218,7 +218,7 @@ am__installdirs = "$(DESTDIR)$(bindir)" 
>> >> > "$(DESTDIR)$(bindir)"
>> >> > - PROGRAMS = $(bin_PROGRAMS)
>> >> > - am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
>> >> > - ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
>> >> > --ginstall_info_LDADD = $(LDADD)
>> >> > -+ginstall_info_LDADD = $(LDADD) -lz
>> >> > - am__DEPENDENCIES_1 =
>> >> > - ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
>> >> > -   $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
>> >> > -diff --git a/install-info/install-info.c b/install-info/install-info.c
>> >> > -index 21f4fe3..a7aba82 100644
>> >> >  a/install-info/install-info.c
>> >> > -+++ b/install-info/install-info.c
>> >> > -@@ -19,6 +19,7 @@
>> >> 

Re: [OE-core] [PATCH] Revert "libubootenv: inherit uboot-config"

[Otavio Salvador]

Em ter., 6 de jul. de 2021 às 12:12, Peter Bergin 
escreveu:

> Then I can correct my earlier statement and a new wisdom that run-time
> dependecies are scanned already in the early phases. Apparently it is
> not possible to build libubootenv due to RRECOMMENDS to
> u-boot-default-env. The build for a 'non-u-boot config' will fail if we
> add 'inherit uboot-config' and it will fail without. What is the
> difference for a 'world' build?
>

The dependency on the default-env seems too strong. It could be relaxed as
it works without it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

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

[OE-core] [RFC][PATCH] libubootenv: exclude from world build if no u-boot config

[Peter Bergin]

As a fix for failing the world build for targets not using u-boot
as boot loader libubootenv is excluded from world builds if
both UBOOT_MACHINE and UBOOT_CONFIG variables are empty.

Signed-off-by: Peter Bergin 
---
 meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
index 306296922c..6774290ea5 100644
--- a/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.3.2.bb
@@ -28,3 +28,6 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 RRECOMMENDS_${PN}-bin_append_class-target = " u-boot-default-env"
 
 BBCLASSEXTEND = "native"
+
+# Exclude this package from world build if there is no config for u-boot
+EXCLUDE_FROM_WORLD = "${@'1' if not d.getVar('UBOOT_MACHINE') and not 
(d.getVar('UBOOT_CONFIG') or '').split() else '0'}"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153617): 
https://lists.openembedded.org/g/openembedded-core/message/153617
Mute This Topic: https://lists.openembedded.org/mt/84023728/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] tzdata: Allow controlling zoneinfo binary format

[Zoltan Boszormenyi via lists.openembedded.org]

2021. 07. 06. 17:12 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org 
írta:

From: Zoltán Böszörményi 

tzcode 2020b changed the default format from "-b fat" to "-b slim".
Allow external control for the binary format.

Signed-off-by: Zoltán Böszörményi 
---
  meta/recipes-extended/timezone/tzdata.bb | 10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index f8443110d5..09145e1ed0 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -19,13 +19,17 @@ TZONES= "africa antarctica asia australasia europe 
northamerica southamerica  \
  "
  # pacificnew
  
+# "slim" is the default since 2020b

+# "fat" is needed by e.g. MariaDB's mysql_tzinfo_to_sql


FYI, the issue fixed by this change is:
https://jira.mariadb.org/browse/MDEV-26093


+ZIC_FMT ?= "slim"
+
  do_compile () {
  for zone in ${TZONES}; do \
-${STAGING_BINDIR_NATIVE}/zic -d ${WORKDIR}${datadir}/zoneinfo -L 
/dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo -L /dev/null \
  ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
  ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
  ${S}/${zone} ; \
  done
  }








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153616): 
https://lists.openembedded.org/g/openembedded-core/message/153616
Mute This Topic: https://lists.openembedded.org/mt/84022657/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] tzdata: Allow controlling zoneinfo binary format

[Zoltan Boszormenyi via lists.openembedded.org]

From: Zoltán Böszörményi 

tzcode 2020b changed the default format from "-b fat" to "-b slim".
Allow external control for the binary format.

Signed-off-by: Zoltán Böszörményi 
---
 meta/recipes-extended/timezone/tzdata.bb | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-extended/timezone/tzdata.bb 
b/meta/recipes-extended/timezone/tzdata.bb
index f8443110d5..09145e1ed0 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -19,13 +19,17 @@ TZONES= "africa antarctica asia australasia europe 
northamerica southamerica  \
 "
 # pacificnew 
 
+# "slim" is the default since 2020b
+# "fat" is needed by e.g. MariaDB's mysql_tzinfo_to_sql
+ZIC_FMT ?= "slim"
+
 do_compile () {
 for zone in ${TZONES}; do \
-${STAGING_BINDIR_NATIVE}/zic -d ${WORKDIR}${datadir}/zoneinfo -L 
/dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo -L /dev/null \
 ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
 ${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
+${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d 
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
 ${S}/${zone} ; \
 done
 }
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153615): 
https://lists.openembedded.org/g/openembedded-core/message/153615
Mute This Topic: https://lists.openembedded.org/mt/84022657/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] Revert "libubootenv: inherit uboot-config"

[Peter Bergin]

Hi again,

sorry for the noise but did some investigations and was able to 
reproduce


On 2021-07-06 15:42, Peter Bergin wrote:

Hi,

On 2021-07-06 04:44, Anuj Mittal wrote:

Hi Peter,

On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote:

On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin wrote:

On 2021-07-03 16:55, Mittal, Anuj wrote:

On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote:

This reverts commit 10aa1291979fb90bed1beb49be4d406ed0e1e4d5.

As there is no build dependency between libubootenv and the
configuration
of u-boot there is no reason to check for UBOOT_CONFIG or
UBOOT_MACHINE
by adding the class uboot-config. Revert this in order to
remove
useless
workaround in bsp layer (meta-freescale).

This was added to address failures in world builds:

https://lists.openembedded.org/g/openembedded-core/message/141757

If this is not required, then I think we'd need to address those
failures.

Thanks for the pointer about the reason for this patch. I searched
a bit
but could not find it.

Can you please help me define 'world builds'?

"bitbake world"

i.e. build everything


By reading the mail thread my thoughts are that the obvious thing
is
that the build has a bad configuration as u-boot is skipped. This
should
be the thing to solve.

Not every MACHINE will support u-boot or have a configuration for it.

Do you have a fix for this? This patch was applied and now the world
builds for MACHINEs not supporting u-boot are failing. Do you mind if I
send a revert of your patch?



I don't mind but I think it is the wrong thing to do, at least without 
analyzing the failing builds and get to the root of the problem.


My view on this, correct me if I'm wrong here. If you just want to 
build libubootenv you should be able to do it for any machine, with or 
without u-boot support as there is no build dependency between 
libubootenv and u-boot. If you have libubootenv in your image there 
will be a RRECOMMENDS to u-boot-env and in that case you must have 
NO_RECOMMENDATION=0 or a valid u-boot configuration. If the world 
build is failing I guess there is a configuration for a target without 
u-boot that includes libubootenv in an image. Or what is the exact 
failure? Can you send a reference with a log to the failing build?


/Peter




    $ bitbake libubootenv
    Loading cache: 100% 
|##| 
    Time: 0:00:00

    Loaded 3462 entries from dependency cache.
    NOTE: Resolving any missing task queue dependencies
    ERROR: Nothing RPROVIDES 'u-boot-default-env' (but 
meta/recipes-bsp/u-boot/libubootenv_0.3.1.bb RDEPENDS on or otherwise 
requires it)

    NOTE: Runtime target 'u-boot-default-env' is unbuildable, removing...
    Missing or unbuildable dependency chain was: ['u-boot-default-env']
    ERROR: Required build target 'libubootenv' has no buildable providers.
    Missing or unbuildable dependency chain was: ['libubootenv', 
'u-boot-default-env']


    Summary: There was 1 WARNING message shown.
    Summary: There were 2 ERROR messages shown, returning a non-zero 
exit code.


The setup above was to use a machine from (meta-intel) with grub as 
bootloader.


Then I can correct my earlier statement and a new wisdom that run-time 
dependecies are scanned already in the early phases. Apparently it is 
not possible to build libubootenv due to RRECOMMENDS to 
u-boot-default-env. The build for a 'non-u-boot config' will fail if we 
add 'inherit uboot-config' and it will fail without. What is the 
difference for a 'world' build?


/Peter



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153614): 
https://lists.openembedded.org/g/openembedded-core/message/153614
Mute This Topic: https://lists.openembedded.org/mt/83938334/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 2/2] package.bbclass: manage external sources for debug source file packaging

[Frederic Martinsons]

Hello again,

Since my patches doesn't meet the requirements and considering that you
acknowledge the issue (please correct if I mistaken), should I open a bug?

Of course I'll give as many details as I can in this report.

Thanks.

Le lun. 28 juin 2021 à 06:46, Frederic Martinsons via lists.openembedded.org
 a écrit :

> Hello Richard,
>
> First, sorry for the commit message (I gave details in the first patch on
> externalsrc.bbclass but not on this one). I agree with you that it seems an
> hack but I don't know to make package;bbclass find the sources correctly.
> The "culprit" is the following command (
> https://github.com/openembedded/openembedded-core/blob/master/meta/classes/package.bbclass#L591)
> and especially the last part of it:
>
> processdebugsrc += "(cd '%s' ; cpio -pd0mlL --no-preserve-owner '%s%s'
>> 2>/dev/null)"
>
>
> this command explicitely goes into *workparentdir *and wait for the
> sources to be in it thanks to the input list that was calculated as the
> output of dwarfsrcfiles earlier call (with *localsrc_prefix *remove from
> them).
>
> Have you an idea (or even a lead that I can explore) on how make things
> correct here ?
>
> On Mon, 28 Jun 2021 at 00:00, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> On Wed, 2021-06-23 at 15:09 +0200, Frederic Martinsons wrote:
>> > Hello, I would like to add a link to a yocto mail where I expose my
>> problematic that led
>> > to this patch series:
>> >
>> https://lists.yoctoproject.org/g/yocto/topic/83622035?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,83622035
>> >
>> > After further research, I think these patch can be simplified by
>> modified only
>> > WORKDIR variable to be os.path.dirname(EXTERNALSRC) but I fear of
>> consequence
>> > to have WORKDIR outside of TMPDIR so I didn't take this path.
>>
>> Changing WORKDIR would no doubt solve your immediate problem but would
>> create
>> a ton of others :(.
>>
>> The issue is that the class wants to re-declare S but some of our code
>> makes
>> assumptions about the location of WORKDIR with regard to S (and B). There
>> is more inside WORKDIR than just S and EXTERNALSRC does really correspond
>> to S,
>> not WORKDIR...
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
> 
>
>

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

[OE-core] Yocto Project Status WW27`21

[Stephen Jolley]

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday July 8th at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday July 13th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday July 6th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.1.9 was released.
*   The prserv rewrite is still pending on resolving the issues with
python asyncio.
*   Alexandre Belloni/Bootlin have been taking over some of the patch
testing/queuing work over the last couple of weeks, feedback to either
Richard/Alexandre or the TSC on how this is working is welcome.
*   Intermittent autobuilder issues continue to occur, about 50% of the
open issues are now ptest failures, many occurring more frequently on arm
and the rest are various other races or timeouts. 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 have made progress on a couple of the race issues and on one of
the ptest issues (util-linux), some of the ptest issues and the bitbake
server timeout issue are now our most frequently encountered issues.
*   A rootfs license race issue (#
 14123) now has
reproduction steps which should allow a fix to follow.
*   The multiconfig changes in bitbake continue to cause problems, we
still need simpler test cases to reproduce issues rather than huge builds.
The existing patches seem to fix some workloads and break others and current
test cases are very slow to work with.

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.4. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.4_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.4 Milestone Dates:

*   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 (Feature Freeze)
*   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.1.9 is released
*   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:

*   WDD 2668 (last week 2704) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1276 (last week 1279)
*   Patches in the Pending State: 481 (38%) [last week 481 (38%)]

 

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...@gmail.com
 

 


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

[OE-core] 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 357
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...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153611): 
https://lists.openembedded.org/g/openembedded-core/message/153611
Mute This Topic: https://lists.openembedded.org/mt/84021868/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 13/19] pypi: set SRC_URI with _prepend, not with +=

[Steve Sakoman]

On Mon, Jul 5, 2021 at 10:31 PM Martin Jansa  wrote:
>
> Is this one worth backporting? It breaks some recipes in other layers (e.g. 
> podman-compose in meta-virtualization 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=92f976404b7f82c97996ffce94ca2d20be2dcbda)
>  and it's only fixing issue with devtool which imho isn't so important in 
> dunfell compared to master.

Agreed, if this is breaking recipes in other layers, then the downside
outweighs the devtool benefit.  I'll drop this from the pull request.

Thanks for reviewing the patches, I really appreciate it!

Steve


> Regards,
>
> On Tue, Jul 6, 2021 at 12:36 AM Steve Sakoman  wrote:
>>
>> From: Alexander Kanavin 
>>
>> This did not cause problems in builds, but broke some devtool
>> workflows such as version upgrades or checking the latest version
>> from upstream. Tarballs should come first, not the patches.
>>
>> (From OE-Core rev: 5cee50c25197102658e0689f635b2d567a375471)
>>
>> Signed-off-by: Alexander Kanavin 
>> Signed-off-by: Alexandre Belloni 
>> (cherry picked from commit 8f17b8bce85efb0e9a7e15d0b98a5cf7b6bd9750)
>> Signed-off-by: Steve Sakoman 
>> ---
>>  meta/classes/pypi.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
>> index 87b4c85fc0..384a209874 100644
>> --- a/meta/classes/pypi.bbclass
>> +++ b/meta/classes/pypi.bbclass
>> @@ -19,7 +19,7 @@ PYPI_SRC_URI ?= "${@pypi_src_uri(d)}"
>>
>>  HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
>>  SECTION = "devel/python"
>> -SRC_URI += "${PYPI_SRC_URI}"
>> +SRC_URI_prepend = "${PYPI_SRC_URI} "
>>  S = "${WORKDIR}/${PYPI_PACKAGE}-${PV}"
>>
>>  UPSTREAM_CHECK_URI ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
>> --
>> 2.25.1
>>
>>
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153610): 
https://lists.openembedded.org/g/openembedded-core/message/153610
Mute This Topic: https://lists.openembedded.org/mt/84008514/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] Revert "libubootenv: inherit uboot-config"

[Peter Bergin]

Hi,

On 2021-07-06 04:44, Anuj Mittal wrote:

Hi Peter,

On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote:

On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin wrote:

On 2021-07-03 16:55, Mittal, Anuj wrote:

On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote:

This reverts commit 10aa1291979fb90bed1beb49be4d406ed0e1e4d5.

As there is no build dependency between libubootenv and the
configuration
of u-boot there is no reason to check for UBOOT_CONFIG or
UBOOT_MACHINE
by adding the class uboot-config. Revert this in order to
remove
useless
workaround in bsp layer (meta-freescale).

This was added to address failures in world builds:

https://lists.openembedded.org/g/openembedded-core/message/141757

If this is not required, then I think we'd need to address those
failures.

Thanks for the pointer about the reason for this patch. I searched
a bit
but could not find it.

Can you please help me define 'world builds'?

"bitbake world"

i.e. build everything


By reading the mail thread my thoughts are that the obvious thing
is
that the build has a bad configuration as u-boot is skipped. This
should
be the thing to solve.

Not every MACHINE will support u-boot or have a configuration for it.

Do you have a fix for this? This patch was applied and now the world
builds for MACHINEs not supporting u-boot are failing. Do you mind if I
send a revert of your patch?



I don't mind but I think it is the wrong thing to do, at least without 
analyzing the failing builds and get to the root of the problem.


My view on this, correct me if I'm wrong here. If you just want to build 
libubootenv you should be able to do it for any machine, with or without 
u-boot support as there is no build dependency between libubootenv and 
u-boot. If you have libubootenv in your image there will be a 
RRECOMMENDS to u-boot-env and in that case you must have 
NO_RECOMMENDATION=0 or a valid u-boot configuration. If the world build 
is failing I guess there is a configuration for a target without u-boot 
that includes libubootenv in an image. Or what is the exact failure? Can 
you send a reference with a log to the failing build?


/Peter




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153609): 
https://lists.openembedded.org/g/openembedded-core/message/153609
Mute This Topic: https://lists.openembedded.org/mt/83938334/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] Revert "libubootenv: inherit uboot-config"

[Otavio Salvador]

Em ter., 6 de jul. de 2021 às 10:04, Richard Purdie <
richard.pur...@linuxfoundation.org> escreveu:

> On Tue, 2021-07-06 at 02:44 +, Mittal, Anuj wrote:
> > Hi Peter,
> >
> > On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote:
> > > On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin wrote:
> > > > On 2021-07-03 16:55, Mittal, Anuj wrote:
> > > > > On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote:
> > > > > > This reverts commit 10aa1291979fb90bed1beb49be4d406ed0e1e4d5.
> > > > > >
> > > > > > As there is no build dependency between libubootenv and the
> > > > > > configuration
> > > > > > of u-boot there is no reason to check for UBOOT_CONFIG or
> > > > > > UBOOT_MACHINE
> > > > > > by adding the class uboot-config. Revert this in order to
> > > > > > remove
> > > > > > useless
> > > > > > workaround in bsp layer (meta-freescale).
> > > > > This was added to address failures in world builds:
> > > > >
> > > > > https://lists.openembedded.org/g/openembedded-core/message/141757
> > > > >
> > > > > If this is not required, then I think we'd need to address those
> > > > > failures.
> > > >
> > > > Thanks for the pointer about the reason for this patch. I searched
> > > > a bit
> > > > but could not find it.
> > > >
> > > > Can you please help me define 'world builds'?
> > >
> > > "bitbake world"
> > >
> > > i.e. build everything
> > >
> > > > By reading the mail thread my thoughts are that the obvious thing
> > > > is
> > > > that the build has a bad configuration as u-boot is skipped. This
> > > > should
> > > > be the thing to solve.
> > >
> > > Not every MACHINE will support u-boot or have a configuration for it.
> >
> > Do you have a fix for this? This patch was applied and now the world
> > builds for MACHINEs not supporting u-boot are failing. Do you mind if I
> > send a revert of your patch?
>
> I agree with reverting it FWIW.
>

Is there a log somewhere?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153608): 
https://lists.openembedded.org/g/openembedded-core/message/153608
Mute This Topic: https://lists.openembedded.org/mt/83938334/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] Revert "libubootenv: inherit uboot-config"

[Richard Purdie]

On Tue, 2021-07-06 at 02:44 +, Mittal, Anuj wrote:
> Hi Peter,
> 
> On Sun, 2021-07-04 at 10:21 +0100, Richard Purdie wrote:
> > On Sun, 2021-07-04 at 10:59 +0200, Peter Bergin wrote:
> > > On 2021-07-03 16:55, Mittal, Anuj wrote:
> > > > On Fri, 2021-07-02 at 13:59 +0200, Peter Bergin wrote:
> > > > > This reverts commit 10aa1291979fb90bed1beb49be4d406ed0e1e4d5.
> > > > > 
> > > > > As there is no build dependency between libubootenv and the
> > > > > configuration
> > > > > of u-boot there is no reason to check for UBOOT_CONFIG or
> > > > > UBOOT_MACHINE
> > > > > by adding the class uboot-config. Revert this in order to
> > > > > remove
> > > > > useless
> > > > > workaround in bsp layer (meta-freescale).
> > > > This was added to address failures in world builds:
> > > > 
> > > > https://lists.openembedded.org/g/openembedded-core/message/141757
> > > > 
> > > > If this is not required, then I think we'd need to address those
> > > > failures.
> > > 
> > > Thanks for the pointer about the reason for this patch. I searched
> > > a bit 
> > > but could not find it.
> > > 
> > > Can you please help me define 'world builds'?
> > 
> > "bitbake world"
> > 
> > i.e. build everything
> > 
> > > By reading the mail thread my thoughts are that the obvious thing
> > > is 
> > > that the build has a bad configuration as u-boot is skipped. This
> > > should 
> > > be the thing to solve.
> > 
> > Not every MACHINE will support u-boot or have a configuration for it.
> 
> Do you have a fix for this? This patch was applied and now the world
> builds for MACHINEs not supporting u-boot are failing. Do you mind if I
> send a revert of your patch?

I agree with reverting it FWIW.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153607): 
https://lists.openembedded.org/g/openembedded-core/message/153607
Mute This Topic: https://lists.openembedded.org/mt/83938334/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] iputils: Update to 20210202

[Andreas Müller]

On Mon, Jun 28, 2021 at 12:09 AM Changhyeok Bae
 wrote:
>
> Signed-off-by: Changhyeok Bae 
> ---
>  .../iputils/{iputils_s20200821.bb => iputils_20210202.bb}   | 2 +-
By this version went backwards. What is preferred Bump PE or re-add 's'?

Andreas

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153606): 
https://lists.openembedded.org/g/openembedded-core/message/153606
Mute This Topic: https://lists.openembedded.org/mt/83832905/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] oeqa/selftest/multiprocesslauch: Fix test race

[Richard Purdie]

Having two possible failures in multiprocesslauch creates a race where one 
failure
may occur and stop processes being lanuched meaning the second failure may not
be seen. Rather than having periodic races appearing on the autobuilder, only
have one failure, making the test much more deterministic.

[YOCTO #13054]

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/selftest/cases/oelib/utils.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/oelib/utils.py 
b/meta/lib/oeqa/selftest/cases/oelib/utils.py
index a7214beb4c0..bbf67bf9c9b 100644
--- a/meta/lib/oeqa/selftest/cases/oelib/utils.py
+++ b/meta/lib/oeqa/selftest/cases/oelib/utils.py
@@ -64,7 +64,7 @@ class TestMultiprocessLaunch(TestCase):
 import bb
 
 def testfunction(item, d):
-if item == "2" or item == "1":
+if item == "2":
 raise KeyError("Invalid number %s" % item)
 return "Found %s" % item
 
@@ -99,5 +99,4 @@ class TestMultiprocessLaunch(TestCase):
 # Assert the function prints exceptions
 with captured_output() as (out, err):
 self.assertRaises(bb.BBHandledException, multiprocess_launch, 
testfunction, ["1", "2", "3", "4", "5", "6"], d, extraargs=(d,))
-self.assertIn("KeyError: 'Invalid number 1'", out.getvalue())
 self.assertIn("KeyError: 'Invalid number 2'", out.getvalue())
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153605): 
https://lists.openembedded.org/g/openembedded-core/message/153605
Mute This Topic: https://lists.openembedded.org/mt/84017931/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] dwarfsrcfiles: Avoid races over debug-link files

[Richard Purdie]

We use dwarfsrcfiles in package.bbclass to list the source files used by a 
binary.
This is done before they're stripped and linked to debug symbols in separate 
files.

It is possible a binary may already have a link to separate debug symbols, e.g.
some of the test binaries in lttng-tools ptest. In those cases, the linked 
binary
may be changed by package.bbclass code whilst dwarfsrcfiles is reading it. That
would result in a rare SIGBUS race causing the binary to fail.

To avoid this, break the debug file search path so no other binaries are found.

Also fix a segfault if no binary is specified while here.

[YOCTO #14400]

Signed-off-by: Richard Purdie 
---
 .../dwarfsrcfiles/files/dwarfsrcfiles.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c 
b/meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c
index af7af524ebe..9eb5ca807ad 100644
--- a/meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c
+++ b/meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -83,13 +84,15 @@ process_cu (Dwarf_Die *cu_die)
 int
 main (int argc, char **argv)
 {
-  char* args[3];
+  char* args[5];
   int res = 0;
   Dwfl *dwfl;
   Dwarf_Addr bias;
   
-  if (argc != 2)
+  if (argc != 2) {
 fprintf(stderr, "Usage %s ", argv[0]);
+exit(EXIT_FAILURE);
+  }
   
   // Pretend "dwarfsrcfiles -e " was given, so we can use standard
   // dwfl argp parser to open the file for us and get our Dwfl. Useful
@@ -98,8 +101,12 @@ main (int argc, char **argv)
   args[0] = argv[0];
   args[1] = "-e";
   args[2] = argv[1];
+  // We don't want to follow debug linked files due to the way OE processes
+  // files, could race against changes in the linked binary (e.g. objcopy on 
it)
+  args[3] = "--debuginfo-path";
+  args[4] = "/not/exist";
   
-  argp_parse (dwfl_standard_argp (), 3, args, 0, NULL, );
+  argp_parse (dwfl_standard_argp (), 5, args, 0, NULL, );
   
   Dwarf_Die *cu = NULL;
   while ((cu = dwfl_nextcu (dwfl, cu, )) != NULL)
-- 
2.30.2


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

[OE-core] [hardknott][PATCH] perl: correct libpth and glibpth

[Yu, Mingli]

From: Mingli Yu 

Previouly there is a logic as below used to set libpth in config.sh.
libpth='@LIBDIR@ @BASELIBDIR@'

But after the below commits introduced, the above logic is dropped.
52f2828314 perl: add a version that builds the recipe using perl-cross, and 
update to 5.28.1
68552c3532 perl: remove the previous version of the recipe

So correct the value of libpth and glibpth to add the dropped logic
back to avoid confusing.

Before the patch(on 64bits system):
 # perl -V:libpth
 libpth='/usr/lib /lib';

After the patch(on 64bits system):
 # perl -V:libpth
 libpth='/usr/lib64 /lib64';

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/perl/perl_5.32.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb 
b/meta/recipes-devtools/perl/perl_5.32.1.bb
index b28040c7fb..f8893af3e2 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.32.1.bb
@@ -62,6 +62,8 @@ do_configure_class-target() {
 -Dsoname=libperl.so.5 \
 -Dvendorprefix=${prefix} \
 -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
+-Dlibpth='${libdir} ${base_libdir}' \
+-Dglibpth='${libdir} ${base_libdir}' \
 ${PACKAGECONFIG_CONFARGS}
 
 #perl.c uses an ARCHLIB_EXP define to generate compile-time code that
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153603): 
https://lists.openembedded.org/g/openembedded-core/message/153603
Mute This Topic: https://lists.openembedded.org/mt/84016656/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] perl: correct libpth and glibpth

[Yu, Mingli]

From: Mingli Yu 

Previouly there is a logic as below used to set libpth in config.sh.
libpth='@LIBDIR@ @BASELIBDIR@'

But after the below commits introduced, the above logic is dropped.
52f2828314 perl: add a version that builds the recipe using perl-cross, and 
update to 5.28.1
68552c3532 perl: remove the previous version of the recipe

So correct the value of libpth and glibpth to add the dropped logic
back to avoid confusing.

Before the patch(on 64bits system):
 # perl -V:libpth
 libpth='/usr/lib /lib';

After the patch(on 64bits system):
 # perl -V:libpth
 libpth='/usr/lib64 /lib64';

Signed-off-by: Mingli Yu 
---
 meta/recipes-devtools/perl/perl_5.34.0.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/perl/perl_5.34.0.bb 
b/meta/recipes-devtools/perl/perl_5.34.0.bb
index 7935a58723..434535c5ee 100644
--- a/meta/recipes-devtools/perl/perl_5.34.0.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
@@ -53,6 +53,8 @@ do_configure_class-target() {
 -Dsoname=libperl.so.5 \
 -Dvendorprefix=${prefix} \
 -Darchlibexp=${STAGING_LIBDIR}/perl5/${PV}/${TARGET_ARCH}-linux \
+-Dlibpth='${libdir} ${base_libdir}' \
+-Dglibpth='${libdir} ${base_libdir}' \
 ${PACKAGECONFIG_CONFARGS}
 
 #perl.c uses an ARCHLIB_EXP define to generate compile-time code that
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153602): 
https://lists.openembedded.org/g/openembedded-core/message/153602
Mute This Topic: https://lists.openembedded.org/mt/84016455/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 13/19] pypi: set SRC_URI with _prepend, not with +=

[Khem Raj]

On Tue, Jul 6, 2021 at 1:31 AM Martin Jansa  wrote:
>
> Is this one worth backporting? It breaks some recipes in other layers (e.g. 
> podman-compose in meta-virtualization 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=92f976404b7f82c97996ffce94ca2d20be2dcbda)
>  and it's only fixing issue with devtool which imho isn't so important in 
> dunfell compared to master.

I guess it perhaps isnt bad if we can coordinate meta-virtualization
fix along with it. but there is a chance that it might break some
internal cases for users which we can't control

>
> Regards,
>
> On Tue, Jul 6, 2021 at 12:36 AM Steve Sakoman  wrote:
>>
>> From: Alexander Kanavin 
>>
>> This did not cause problems in builds, but broke some devtool
>> workflows such as version upgrades or checking the latest version
>> from upstream. Tarballs should come first, not the patches.
>>
>> (From OE-Core rev: 5cee50c25197102658e0689f635b2d567a375471)
>>
>> Signed-off-by: Alexander Kanavin 
>> Signed-off-by: Alexandre Belloni 
>> (cherry picked from commit 8f17b8bce85efb0e9a7e15d0b98a5cf7b6bd9750)
>> Signed-off-by: Steve Sakoman 
>> ---
>>  meta/classes/pypi.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
>> index 87b4c85fc0..384a209874 100644
>> --- a/meta/classes/pypi.bbclass
>> +++ b/meta/classes/pypi.bbclass
>> @@ -19,7 +19,7 @@ PYPI_SRC_URI ?= "${@pypi_src_uri(d)}"
>>
>>  HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
>>  SECTION = "devel/python"
>> -SRC_URI += "${PYPI_SRC_URI}"
>> +SRC_URI_prepend = "${PYPI_SRC_URI} "
>>  S = "${WORKDIR}/${PYPI_PACKAGE}-${PV}"
>>
>>  UPSTREAM_CHECK_URI ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
>> --
>> 2.25.1
>>
>>
>>
>>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153601): 
https://lists.openembedded.org/g/openembedded-core/message/153601
Mute This Topic: https://lists.openembedded.org/mt/84008514/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] texinfo: update 6.7 -> 6.8

[Alexander Kanavin]

Once again: it was bundled with the initial recipe submission over 10 years
ago, without explanation or origin info, and not added later on. There was
never any indication anyone finds it useful. Probably someone just took all
of Red Hat's patches without reviewing their utility.

I am not porting it forward, the use case is simply not there, what you are
saying is utter madness, and we should spend our time on actually useful
things, where there is clear evidence they are useful.

Alex

On Tue, 6 Jul 2021 at 10:29, Khem Raj  wrote:

> On Tue, Jul 6, 2021 at 12:31 AM Alexander Kanavin
>  wrote:
> >
> > Khem, please. What is the use case you are trying to justify? Who on
> earth would want to install and read .info files on a target device (of the
> kind where saving a few kilobytes matters, no less!), when it's a million
> times more convenient to do that on the host, or just open the same things
> hosted online in a browser?
> >
>
> iff its added I would err on the side that patch is used by users,
> since adding a patch to implement unused feature would be counter
> intuitive.
> This patch has been there for long time in OE, there is not much
> effort to port it forward as other distros are maintaining this patch
> too, perhaps its better to carry this on, I would have agreed if it
> was something that OE was lugging along alone.
>
> > Sorry, no.
>
> thats fine, drop this upgrade.
>
> >
> > Alex
> >
> > On Tue, 6 Jul 2021 at 01:01, Khem Raj  wrote:
> >>
> >> On Mon, Jul 5, 2021 at 11:35 AM Alexander Kanavin
> >>  wrote:
> >> >
> >> > Drop texinfo-4.12-zlib.patch as it completely lacks a description,
> >>
> >> if it is not described then perhaps adding description to it will make
> >> things better, the patch is adding gz compressed
> >> info files which should reduce the size of these files which is quite
> >> good for embedded systems. Distros like fedora and suse
> >> are carrying this patch too.
> >>
> >> > was added together with the original recipe without an explanation in
> >> > the commit message, and is difficult to rebase.
> >> >
> >>
> >> Get it from
> https://src.fedoraproject.org/rpms/texinfo/raw/rawhide/f/texinfo-4.12-zlib.patch
> >> this time.
> >>
> >> > Signed-off-by: Alexander Kanavin 
> >> > ---
> >> >  .../texinfo/texinfo/texinfo-4.12-zlib.patch   | 254
> --
> >> >  .../{texinfo_6.7.bb => texinfo_6.8.bb}|   4 +-
> >> >  2 files changed, 1 insertion(+), 257 deletions(-)
> >> >  delete mode 100644
> meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> >> >  rename meta/recipes-extended/texinfo/{texinfo_6.7.bb =>
> texinfo_6.8.bb} (94%)
> >> >
> >> > diff --git
> a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> >> > deleted file mode 100644
> >> > index f72097e639..00
> >> > --- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> >> > +++ /dev/null
> >> > @@ -1,254 +0,0 @@
> >> > -From 3d3b66cf398853c666e724c3dbcc37d53a2240d5 Mon Sep 17 00:00:00
> 2001
> >> > -From: Edwin Plauchu 
> >> > -Date: Tue, 29 Nov 2016 12:27:17 -0600
> >> > -Subject: [PATCH] texinfo-4.12-zlib
> >> > -
> >> > -Upstream-Status: Pending
> >> > -
> >> > -Signed-off-by: Jussi Kukkonen 
> >> > -Signed-off-by: Edwin Plauchu 
> >> > -
> >> > 
> >> > - install-info/Makefile.in|  2 +-
> >> > - install-info/install-info.c | 79
> ++---
> >> > - 2 files changed, 48 insertions(+), 33 deletions(-)
> >> > -
> >> > -diff --git a/install-info/Makefile.in b/install-info/Makefile.in
> >> > -index c924509..746df05 100644
> >> >  a/install-info/Makefile.in
> >> > -+++ b/install-info/Makefile.in
> >> > -@@ -218,7 +218,7 @@ am__installdirs = "$(DESTDIR)$(bindir)"
> "$(DESTDIR)$(bindir)"
> >> > - PROGRAMS = $(bin_PROGRAMS)
> >> > - am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
> >> > - ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
> >> > --ginstall_info_LDADD = $(LDADD)
> >> > -+ginstall_info_LDADD = $(LDADD) -lz
> >> > - am__DEPENDENCIES_1 =
> >> > - ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
> >> > -   $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
> >> > -diff --git a/install-info/install-info.c
> b/install-info/install-info.c
> >> > -index 21f4fe3..a7aba82 100644
> >> >  a/install-info/install-info.c
> >> > -+++ b/install-info/install-info.c
> >> > -@@ -19,6 +19,7 @@
> >> > - #include 
> >> > - #include 
> >> > - #include 
> >> > -+#include 
> >> > -
> >> > - #define TAB_WIDTH 8
> >> > -
> >> > -@@ -681,15 +682,15 @@ The first time you invoke Info you start off
> looking at this node.\n\
> >> > -
> >> > -Return either stdin reading the file, or a non-stdin pipe reading
> >> > -the output of the compression program.  */
> >> > --FILE *
> >> > -+void *
> >> > - open_possibly_compressed_file (char *filename,
> >> > - void (*create_callback) (char *),
> >> > --char **opened_filename, char 

[OE-core] [hardknott][PATCH 00/22] pull request (cover letter only)

[Anuj Mittal]

Please merge these changes in hardknott.

Thanks,

Anuj

The following changes since commit 61feebd88960eb4e074a80a0e45b36a7a1db869c:

  kernel.bbclass: fix do_sizecheck() comparison (2021-06-22 11:19:38 +0800)

are available in the Git repository at:

  git://push.openembedded.org/openembedded-core-contrib stable/hardknott-next

Alexander Kanavin (2):
  devtool upgrade: rebase override-only patches as well
  libgcrypt: upgrade 1.9.2 -> 1.9.3

Anuj Mittal (1):
  curl: fix build when proxy is not enabled in PACKAGECONFIG

Bruce Ashfield (11):
  linux-yocto/5.10: update to v5.10.42
  linux-yocto/5.10: update to v5.10.43
  linux-yocto/5.10: cgroup1: fix leaked context root causing sporadic
NULL deref in LTP
  linux-yocto/5.10: update to v5.10.46
  linux-yocto/5.10: features/nft_tables: refresh config options
  linux-yocto/5.4: update to v5.4.128
  linux-yocto/5.10: rcu: Fix stall-warning deadlock due to non-release
of rcu_node ->lock
  kern-tools: add dropped options to audit output
  kern-tools: Kconfiglib: add support for bare 'modules' keyword
  kernel-devsrc: adjust NM and OBJTOOL variables for target
  lttng-modules: update to v2.12.6

Michael Ho (1):
  sstate.bbclass: fix errors about read-only sstate mirrors

Ming Liu (1):
  uboot-sign.bbclass: fix some install commands

Richard Purdie (4):
  package_pkgdata: Avoid task hash mismatches for generic task changes
  selftest/fetch: Avoid occasional selftest failure from poor temp file
name choice
  kernel: Fix interaction when packaging disabled
  kernel-devicetree: Fix interaction when packaging disabled

Zqiang (1):
  ifupdown: Skip wrong test item

jbouchard (1):
  Use the label provided when formating a dos partition

 meta/classes/kernel-devicetree.bbclass|  11 +-
 meta/classes/kernel.bbclass   |   2 +
 meta/classes/package_pkgdata.bbclass  |   2 +-
 meta/classes/sstate.bbclass   |   8 +
 meta/classes/uboot-sign.bbclass   |   8 +-
 meta/lib/oeqa/selftest/cases/fetch.py |  27 +-
 .../0001-ifupdown-skip-wrong-test-case.patch  |  32 ++
 .../ifupdown/files/tweak-ptest-script.patch   |  15 +-
 meta/recipes-core/ifupdown/ifupdown_0.8.36.bb |   1 +
 .../kern-tools/kern-tools-native_git.bb   |   2 +-
 meta/recipes-kernel/linux/kernel-devsrc.bb|   2 +
 .../linux/linux-yocto-rt_5.10.bb  |   6 +-
 .../linux/linux-yocto-rt_5.4.bb   |   6 +-
 .../linux/linux-yocto-tiny_5.10.bb|   8 +-
 .../linux/linux-yocto-tiny_5.4.bb |   8 +-
 meta/recipes-kernel/linux/linux-yocto_5.10.bb |  24 +-
 meta/recipes-kernel/linux/linux-yocto_5.4.bb  |  22 +-
 ...01-Fix-memory-leaks-on-event-destroy.patch |  58 
 ...preter-early-exits-on-uninitialized-.patch | 159 -
 ...ecord-slab-name-for-kmem_cache_free-.patch |  91 --
 ...be-null-ptr-deref-on-session-destroy.patch |  41 ---
 ...block-add-a-disk_uevent-helper-v5.12.patch | 305 --
 ...block-add-a-disk_uevent-helper-v5.12.patch |  48 ---
 ...free-event-name-mismatching-with-pro.patch |  71 
 ...ules_2.12.5.bb => lttng-modules_2.12.6.bb} |   9 +-
 .../curl/curl/vtls-fix-addsessionid.patch |  31 ++
 .../curl/curl/vtls-fix-warning.patch  |  40 +++
 meta/recipes-support/curl/curl_7.75.0.bb  |   2 +
 ...{libgcrypt_1.9.2.bb => libgcrypt_1.9.3.bb} |   4 +-
 scripts/lib/devtool/upgrade.py|  29 +-
 .../lib/wic/plugins/source/bootimg-pcbios.py  |   6 +-
 31 files changed, 212 insertions(+), 866 deletions(-)
 create mode 100644 
meta/recipes-core/ifupdown/files/0001-ifupdown-skip-wrong-test-case.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-Fix-memory-leaks-on-event-destroy.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-Fix-filter-interpreter-early-exits-on-uninitialized-.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0003-fix-mm-tracing-record-slab-name-for-kmem_cache_free-.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0004-Fix-kretprobe-null-ptr-deref-on-session-destroy.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0005-fix-block-add-a-disk_uevent-helper-v5.12.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0006-fix-backport-block-add-a-disk_uevent-helper-v5.12.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0007-fix-mm-tracing-kfree-event-name-mismatching-with-pro.patch
 rename meta/recipes-kernel/lttng/{lttng-modules_2.12.5.bb => 
lttng-modules_2.12.6.bb} (71%)
 create mode 100644 meta/recipes-support/curl/curl/vtls-fix-addsessionid.patch
 create mode 100644 meta/recipes-support/curl/curl/vtls-fix-warning.patch
 rename meta/recipes-support/libgcrypt/{libgcrypt_1.9.2.bb => 
libgcrypt_1.9.3.bb} (93%)

-- 
2.31.1


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

Re: [OE-core][dunfell 13/19] pypi: set SRC_URI with _prepend, not with +=

[Martin Jansa]

Is this one worth backporting? It breaks some recipes in other layers (e.g.
podman-compose in meta-virtualization
http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/?id=92f976404b7f82c97996ffce94ca2d20be2dcbda)
and it's only fixing issue with devtool which imho isn't so important in
dunfell compared to master.

Regards,

On Tue, Jul 6, 2021 at 12:36 AM Steve Sakoman  wrote:

> From: Alexander Kanavin 
>
> This did not cause problems in builds, but broke some devtool
> workflows such as version upgrades or checking the latest version
> from upstream. Tarballs should come first, not the patches.
>
> (From OE-Core rev: 5cee50c25197102658e0689f635b2d567a375471)
>
> Signed-off-by: Alexander Kanavin 
> Signed-off-by: Alexandre Belloni 
> (cherry picked from commit 8f17b8bce85efb0e9a7e15d0b98a5cf7b6bd9750)
> Signed-off-by: Steve Sakoman 
> ---
>  meta/classes/pypi.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/pypi.bbclass b/meta/classes/pypi.bbclass
> index 87b4c85fc0..384a209874 100644
> --- a/meta/classes/pypi.bbclass
> +++ b/meta/classes/pypi.bbclass
> @@ -19,7 +19,7 @@ PYPI_SRC_URI ?= "${@pypi_src_uri(d)}"
>
>  HOMEPAGE ?= "https://pypi.python.org/pypi/${PYPI_PACKAGE}/;
>  SECTION = "devel/python"
> -SRC_URI += "${PYPI_SRC_URI}"
> +SRC_URI_prepend = "${PYPI_SRC_URI} "
>  S = "${WORKDIR}/${PYPI_PACKAGE}-${PV}"
>
>  UPSTREAM_CHECK_URI ?= "https://pypi.org/project/${PYPI_PACKAGE}/;
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153598): 
https://lists.openembedded.org/g/openembedded-core/message/153598
Mute This Topic: https://lists.openembedded.org/mt/84008514/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] texinfo: update 6.7 -> 6.8

[Khem Raj]

On Tue, Jul 6, 2021 at 12:31 AM Alexander Kanavin
 wrote:
>
> Khem, please. What is the use case you are trying to justify? Who on earth 
> would want to install and read .info files on a target device (of the kind 
> where saving a few kilobytes matters, no less!), when it's a million times 
> more convenient to do that on the host, or just open the same things hosted 
> online in a browser?
>

iff its added I would err on the side that patch is used by users,
since adding a patch to implement unused feature would be counter
intuitive.
This patch has been there for long time in OE, there is not much
effort to port it forward as other distros are maintaining this patch
too, perhaps its better to carry this on, I would have agreed if it
was something that OE was lugging along alone.

> Sorry, no.

thats fine, drop this upgrade.

>
> Alex
>
> On Tue, 6 Jul 2021 at 01:01, Khem Raj  wrote:
>>
>> On Mon, Jul 5, 2021 at 11:35 AM Alexander Kanavin
>>  wrote:
>> >
>> > Drop texinfo-4.12-zlib.patch as it completely lacks a description,
>>
>> if it is not described then perhaps adding description to it will make
>> things better, the patch is adding gz compressed
>> info files which should reduce the size of these files which is quite
>> good for embedded systems. Distros like fedora and suse
>> are carrying this patch too.
>>
>> > was added together with the original recipe without an explanation in
>> > the commit message, and is difficult to rebase.
>> >
>>
>> Get it from 
>> https://src.fedoraproject.org/rpms/texinfo/raw/rawhide/f/texinfo-4.12-zlib.patch
>> this time.
>>
>> > Signed-off-by: Alexander Kanavin 
>> > ---
>> >  .../texinfo/texinfo/texinfo-4.12-zlib.patch   | 254 --
>> >  .../{texinfo_6.7.bb => texinfo_6.8.bb}|   4 +-
>> >  2 files changed, 1 insertion(+), 257 deletions(-)
>> >  delete mode 100644 
>> > meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> >  rename meta/recipes-extended/texinfo/{texinfo_6.7.bb => texinfo_6.8.bb} 
>> > (94%)
>> >
>> > diff --git a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch 
>> > b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> > deleted file mode 100644
>> > index f72097e639..00
>> > --- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
>> > +++ /dev/null
>> > @@ -1,254 +0,0 @@
>> > -From 3d3b66cf398853c666e724c3dbcc37d53a2240d5 Mon Sep 17 00:00:00 2001
>> > -From: Edwin Plauchu 
>> > -Date: Tue, 29 Nov 2016 12:27:17 -0600
>> > -Subject: [PATCH] texinfo-4.12-zlib
>> > -
>> > -Upstream-Status: Pending
>> > -
>> > -Signed-off-by: Jussi Kukkonen 
>> > -Signed-off-by: Edwin Plauchu 
>> > -
>> > 
>> > - install-info/Makefile.in|  2 +-
>> > - install-info/install-info.c | 79 ++---
>> > - 2 files changed, 48 insertions(+), 33 deletions(-)
>> > -
>> > -diff --git a/install-info/Makefile.in b/install-info/Makefile.in
>> > -index c924509..746df05 100644
>> >  a/install-info/Makefile.in
>> > -+++ b/install-info/Makefile.in
>> > -@@ -218,7 +218,7 @@ am__installdirs = "$(DESTDIR)$(bindir)" 
>> > "$(DESTDIR)$(bindir)"
>> > - PROGRAMS = $(bin_PROGRAMS)
>> > - am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
>> > - ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
>> > --ginstall_info_LDADD = $(LDADD)
>> > -+ginstall_info_LDADD = $(LDADD) -lz
>> > - am__DEPENDENCIES_1 =
>> > - ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
>> > -   $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
>> > -diff --git a/install-info/install-info.c b/install-info/install-info.c
>> > -index 21f4fe3..a7aba82 100644
>> >  a/install-info/install-info.c
>> > -+++ b/install-info/install-info.c
>> > -@@ -19,6 +19,7 @@
>> > - #include 
>> > - #include 
>> > - #include 
>> > -+#include 
>> > -
>> > - #define TAB_WIDTH 8
>> > -
>> > -@@ -681,15 +682,15 @@ The first time you invoke Info you start off 
>> > looking at this node.\n\
>> > -
>> > -Return either stdin reading the file, or a non-stdin pipe reading
>> > -the output of the compression program.  */
>> > --FILE *
>> > -+void *
>> > - open_possibly_compressed_file (char *filename,
>> > - void (*create_callback) (char *),
>> > --char **opened_filename, char **compression_program)
>> > -+char **opened_filename, char **compression_program, int *is_pipe)
>> > - {
>> > -   char *local_opened_filename, *local_compression_program;
>> > -   int nread;
>> > -   char data[13];
>> > --  FILE *f;
>> > -+  gzFile *f;
>> > -
>> > -   /* We let them pass NULL if they don't want this info, but it's easier
>> > -  to always determine it.  */
>> > -@@ -697,48 +698,48 @@ open_possibly_compressed_file (char *filename,
>> > - opened_filename = _opened_filename;
>> > -
>> > -   *opened_filename = filename;
>> > --  f = fopen (*opened_filename, FOPEN_RBIN);
>> > -+  f = gzopen (*opened_filename, FOPEN_RBIN);
>> > -   if (!f)
>> > - {
>> > -   *opened_filename = concat (filename, ".gz", 

[OE-core] [hardknott][PATCH] rxvt-unicode: fix CVE-2021-33477

[kai]

From: Kai Kang 

Backport patch to fix CVE-2021-33477 for rxvt-unicode.

Signed-off-by: Kai Kang 
---
 .../rxvt-unicode-fix-CVE-2021-33477.patch | 33 +++
 .../rxvt-unicode/rxvt-unicode_9.22.bb |  4 ++-
 2 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-sato/rxvt-unicode/rxvt-unicode/rxvt-unicode-fix-CVE-2021-33477.patch

diff --git 
a/meta/recipes-sato/rxvt-unicode/rxvt-unicode/rxvt-unicode-fix-CVE-2021-33477.patch
 
b/meta/recipes-sato/rxvt-unicode/rxvt-unicode/rxvt-unicode-fix-CVE-2021-33477.patch
new file mode 100644
index 00..6c3590c311
--- /dev/null
+++ 
b/meta/recipes-sato/rxvt-unicode/rxvt-unicode/rxvt-unicode-fix-CVE-2021-33477.patch
@@ -0,0 +1,33 @@
+Backport patch to fix CVE-2021-33477.
+
+CVE: CVE-2021-33477
+
+Upstream-Status: Backport 
[http://cvs.schmorp.de/rxvt-unicode/src/command.C?r1=1.582=1.583]
+
+Signed-off-by: Kai Kang 
+---
+ src/command.C | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/command.C b/src/command.C
+index 7b79f51..2f7de60 100644
+--- a/src/command.C
 b/src/command.C
+@@ -2725,7 +2725,7 @@ rxvt_term::process_escape_seq ()
+ /* kidnapped escape sequence: Should be 8.3.48 */
+   case C1_ESA:/* ESC G */
+ // used by original rxvt for rob nations own graphics mode
+-if (cmd_getc () == 'Q')
++if (cmd_getc () == 'Q' && option (Opt_insecure))
+   tt_printf ("\033G0\012");   /* query graphics - no graphics */
+ break;
+ 
+@@ -2944,7 +2944,7 @@ rxvt_term::process_csi_seq ()
+ break;
+ 
+   case CSI_CUB:   /* 8.3.18: (1) CURSOR LEFT */
+-  case CSI_HPB:   /* 8.3.59: (1) CHARACTER POSITION BACKWARD */
++  case CSI_HPB:   /* 8.3.59: (1) CHARACTER POSITION BACKWARD */
+ #ifdef ISO6429
+ arg[0] = -arg[0];
+ #else /* emulate common DEC VTs */
diff --git a/meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.22.bb 
b/meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.22.bb
index 283e8d7751..dee549cc78 100644
--- a/meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.22.bb
+++ b/meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.22.bb
@@ -4,7 +4,9 @@ LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
 
file://src/main.C;beginline=1;endline=31;md5=d3600d7ee1062667fcd1193fbe6485f6"
 
-SRC_URI += "file://0001-libev-remove-deprecated-throw-specification.patch"
+SRC_URI += "file://0001-libev-remove-deprecated-throw-specification.patch \
+file://rxvt-unicode-fix-CVE-2021-33477.patch \
+"
 
 SRC_URI[sha256sum] = 
"e94628e9bcfa0adb1115d83649f898d6edb4baced44f5d5b769c2eeb8b95addd"
 
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#153596): 
https://lists.openembedded.org/g/openembedded-core/message/153596
Mute This Topic: https://lists.openembedded.org/mt/84015698/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] texinfo: update 6.7 -> 6.8

[Alexander Kanavin]

Khem, please. What is the use case you are trying to justify? Who on earth
would want to install and read .info files on a target device (of the kind
where saving a few kilobytes matters, no less!), when it's a million times
more convenient to do that on the host, or just open the same things hosted
online in a browser?

Sorry, no.

Alex

On Tue, 6 Jul 2021 at 01:01, Khem Raj  wrote:

> On Mon, Jul 5, 2021 at 11:35 AM Alexander Kanavin
>  wrote:
> >
> > Drop texinfo-4.12-zlib.patch as it completely lacks a description,
>
> if it is not described then perhaps adding description to it will make
> things better, the patch is adding gz compressed
> info files which should reduce the size of these files which is quite
> good for embedded systems. Distros like fedora and suse
> are carrying this patch too.
>
> > was added together with the original recipe without an explanation in
> > the commit message, and is difficult to rebase.
> >
>
> Get it from
> https://src.fedoraproject.org/rpms/texinfo/raw/rawhide/f/texinfo-4.12-zlib.patch
> this time.
>
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  .../texinfo/texinfo/texinfo-4.12-zlib.patch   | 254 --
> >  .../{texinfo_6.7.bb => texinfo_6.8.bb}|   4 +-
> >  2 files changed, 1 insertion(+), 257 deletions(-)
> >  delete mode 100644
> meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> >  rename meta/recipes-extended/texinfo/{texinfo_6.7.bb => texinfo_6.8.bb}
> (94%)
> >
> > diff --git
> a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> b/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> > deleted file mode 100644
> > index f72097e639..00
> > --- a/meta/recipes-extended/texinfo/texinfo/texinfo-4.12-zlib.patch
> > +++ /dev/null
> > @@ -1,254 +0,0 @@
> > -From 3d3b66cf398853c666e724c3dbcc37d53a2240d5 Mon Sep 17 00:00:00 2001
> > -From: Edwin Plauchu 
> > -Date: Tue, 29 Nov 2016 12:27:17 -0600
> > -Subject: [PATCH] texinfo-4.12-zlib
> > -
> > -Upstream-Status: Pending
> > -
> > -Signed-off-by: Jussi Kukkonen 
> > -Signed-off-by: Edwin Plauchu 
> > -
> > 
> > - install-info/Makefile.in|  2 +-
> > - install-info/install-info.c | 79 ++---
> > - 2 files changed, 48 insertions(+), 33 deletions(-)
> > -
> > -diff --git a/install-info/Makefile.in b/install-info/Makefile.in
> > -index c924509..746df05 100644
> >  a/install-info/Makefile.in
> > -+++ b/install-info/Makefile.in
> > -@@ -218,7 +218,7 @@ am__installdirs = "$(DESTDIR)$(bindir)"
> "$(DESTDIR)$(bindir)"
> > - PROGRAMS = $(bin_PROGRAMS)
> > - am_ginstall_info_OBJECTS = install-info.$(OBJEXT)
> > - ginstall_info_OBJECTS = $(am_ginstall_info_OBJECTS)
> > --ginstall_info_LDADD = $(LDADD)
> > -+ginstall_info_LDADD = $(LDADD) -lz
> > - am__DEPENDENCIES_1 =
> > - ginstall_info_DEPENDENCIES = $(top_builddir)/gnulib/lib/libgnu.a \
> > -   $(am__DEPENDENCIES_1) $(am__DEPENDENCIES_1)
> > -diff --git a/install-info/install-info.c b/install-info/install-info.c
> > -index 21f4fe3..a7aba82 100644
> >  a/install-info/install-info.c
> > -+++ b/install-info/install-info.c
> > -@@ -19,6 +19,7 @@
> > - #include 
> > - #include 
> > - #include 
> > -+#include 
> > -
> > - #define TAB_WIDTH 8
> > -
> > -@@ -681,15 +682,15 @@ The first time you invoke Info you start off
> looking at this node.\n\
> > -
> > -Return either stdin reading the file, or a non-stdin pipe reading
> > -the output of the compression program.  */
> > --FILE *
> > -+void *
> > - open_possibly_compressed_file (char *filename,
> > - void (*create_callback) (char *),
> > --char **opened_filename, char **compression_program)
> > -+char **opened_filename, char **compression_program, int *is_pipe)
> > - {
> > -   char *local_opened_filename, *local_compression_program;
> > -   int nread;
> > -   char data[13];
> > --  FILE *f;
> > -+  gzFile *f;
> > -
> > -   /* We let them pass NULL if they don't want this info, but it's
> easier
> > -  to always determine it.  */
> > -@@ -697,48 +698,48 @@ open_possibly_compressed_file (char *filename,
> > - opened_filename = _opened_filename;
> > -
> > -   *opened_filename = filename;
> > --  f = fopen (*opened_filename, FOPEN_RBIN);
> > -+  f = gzopen (*opened_filename, FOPEN_RBIN);
> > -   if (!f)
> > - {
> > -   *opened_filename = concat (filename, ".gz", "");
> > --  f = fopen (*opened_filename, FOPEN_RBIN);
> > -+  f = gzopen (*opened_filename, FOPEN_RBIN);
> > - }
> > -   if (!f)
> > - {
> > -   free (*opened_filename);
> > -   *opened_filename = concat (filename, ".xz", "");
> > --  f = fopen (*opened_filename, FOPEN_RBIN);
> > -+  f = gzopen (*opened_filename, FOPEN_RBIN);
> > - }
> > -   if (!f)
> > - {
> > -   free (*opened_filename);
> > -   *opened_filename = concat (filename, ".bz2", "");
> > --  f = fopen (*opened_filename, FOPEN_RBIN);
> > -+  f = gzopen (*opened_filename, FOPEN_RBIN);
> > - }
> > -   if