[PATCH][warrior] pseudo: Fix enum typedef

[PATCH][warrior] pseudo: Fix enum typedef

[Andreas Müller]

From: Jacob Kroon <jacob.kroon@gmail.com>

'pseudo_access_t' is a type, so use typedef.

Fixes building pseudo with gcc 10 where -fno-common is the default.

(Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)

Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 .../0001-pseudo_ipc.h-Fix-enum-typedef.patch  | 31 +++++++++++++++++++
 meta/recipes-devtools/pseudo/pseudo_git.bb    |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch

diff --git a/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch b/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch
new file mode 100644
index 00000000000..33d4ef3b2fa
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/files/0001-pseudo_ipc.h-Fix-enum-typedef.patch
@@ -0,0 +1,31 @@
+From a491aececfedf7313d29b80d626e0964fb533548 Mon Sep 17 00:00:00 2001
+From: Jacob Kroon <jacob.kroon@gmail.com>
+Date: Sun, 3 May 2020 06:24:03 +0200
+Subject: [PATCH] pseudo_ipc.h: Fix enum typedef
+
+'pseudo_access_t' is a type, so use typedef.
+
+Fixes building pseudo with gcc 10 where -fno-common is the default.
+
+Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
+Upstream-Status: Submitted [https://lists.openembedded.org/g/openembedded-core/message/137758]
+---
+ pseudo_ipc.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pseudo_ipc.h b/pseudo_ipc.h
+index caeae5c..d945257 100644
+--- a/pseudo_ipc.h
++++ b/pseudo_ipc.h
+@@ -29,7 +29,7 @@ typedef struct {
+ 	char path[];
+ } pseudo_msg_t;
+ 
+-enum {
++typedef enum {
+ 	PSA_EXEC = 1,
+ 	PSA_WRITE = (PSA_EXEC << 1),
+ 	PSA_READ = (PSA_WRITE << 1),
+-- 
+2.26.2
+
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 7db5bafd174..8ff003d9024 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -7,6 +7,7 @@ SRC_URI = "git://git.yoctoproject.org/pseudo \
            file://moreretries.patch \
            file://toomanyfiles.patch \
            file://0001-Add-statx.patch \
+           file://0001-pseudo_ipc.h-Fix-enum-typedef.patch \
            "
 
 SRCREV = "060058bb29f70b244e685b3c704eb0641b736f73"
-- 
2.21.3

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> From: Jacob Kroon <jacob.kroon@gmail.com>
> 
> 'pseudo_access_t' is a type, so use typedef.
> 
> Fixes building pseudo with gcc 10 where -fno-common is the default.
> 
> (Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)
> 
> Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>

Does warrior otherwise work on gcc10 hosts?

Cheers,

Richard

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Andreas Müller]

On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > From: Jacob Kroon <jacob.kroon@gmail.com>
> >
> > 'pseudo_access_t' is a type, so use typedef.
> >
> > Fixes building pseudo with gcc 10 where -fno-common is the default.
> >
> > (Backport of OE-Core rev: a7d519f742aadc9110c2401f359254210a784f6b)
> >
> > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
>
> Does warrior otherwise work on gcc10 hosts?
Not yet but I am working on it.

Andreas
>
> Cheers,
>
> Richard
>

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > 
> > > 'pseudo_access_t' is a type, so use typedef.
> > > 
> > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > default.
> > > 
> > > (Backport of OE-Core rev:
> > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > 
> > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > > >
> > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > 
> > Does warrior otherwise work on gcc10 hosts?
> Not yet but I am working on it.

I think to make a decision on whether we plan to support gcc10 or not
we'll need to know the scope of the changes. I'm starting to worry this
would be a bit too invasive, particularly as warrior is about to enter
community support or EOL depending on whether there is a maintainer.

Cheers,

Richard

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Andreas Müller]

On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > >
> > > > 'pseudo_access_t' is a type, so use typedef.
> > > >
> > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > default.
> > > >
> > > > (Backport of OE-Core rev:
> > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > >
> > > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > > > >
> > > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > >
> > > Does warrior otherwise work on gcc10 hosts?
> > Not yet but I am working on it.
>
> I think to make a decision on whether we plan to support gcc10 or not
> we'll need to know the scope of the changes. I'm starting to worry this
> would be a bit too invasive, particularly as warrior is about to enter
> community support or EOL depending on whether there is a maintainer.
>
I see. Problems for me - job's hat on - are:

1. we're close to release a product based on warrior (and a new
colleague of mine has just installed Fedora 32 with gcc 10 - that's
why I ask for it)
2. my tests with dunfell were - hmm - not running out of the box exactly.

So we should decide to upgrade to dunfell. That is what I use for
private raspi-images an am very close to happy.

Thanks for 'warning' me

Andreas

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Quentin Schulz]

On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > > >
> > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > >
> > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > default.
> > > > >
> > > > > (Backport of OE-Core rev:
> > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > >
> > > > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > > > > >
> > > > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > > >
> > > > Does warrior otherwise work on gcc10 hosts?
> > > Not yet but I am working on it.
> >
> > I think to make a decision on whether we plan to support gcc10 or not
> > we'll need to know the scope of the changes. I'm starting to worry this
> > would be a bit too invasive, particularly as warrior is about to enter
> > community support or EOL depending on whether there is a maintainer.
> >
> I see. Problems for me - job's hat on - are:
> 
> 1. we're close to release a product based on warrior (and a new
> colleague of mine has just installed Fedora 32 with gcc 10 - that's
> why I ask for it)
> 2. my tests with dunfell were - hmm - not running out of the box exactly.
> 
> So we should decide to upgrade to dunfell. That is what I use for
> private raspi-images an am very close to happy.
> 

Dang, I was silently but closely following the discussion hoping to be
able to apply more or less the same patches on top of thud. Same issue
as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
docker time :/ (there'll always be that one client that will not want to
upgrade to newer releases).

Or maybe we can support gcc10 on the community branch once it's EOL (or
doing the job ourselves..). What seems to be the big worry about
supporting gcc10 on warrior/thud? Just so I can explain why we should go
the docker route instead of spending time on making thud (and we still
have krogoth for some...) build with gcc10 and maybe start working on
upgrading those we can to newer releases. Basically what are the
expected big hurdles on the way?

Cheers,
Quentin

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3820 bytes --]

Maybe I'm reading RP's reply differently, but I think he just asked to
collect all necessary changes for warrior to support newer host, before
they are accepted.

It doesn't help much when only one smaller issue is fixed and the rest
still needs to be figured out locally and the commit message might even
mislead people in assuming that gcc-10 on host is now supported in
warrior/thud.

FWIW: I've built some smaller thud based images on 20.04 with only small
modifications, e.g. fix for qemu:
https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/thud&id=68475d0255c4089538886d1ee2cab6b6efd62ce1
there aren't probably many issues left, so it just needs someone to test it
more properly and collect all needed fixes to apply them at the same time
or give up if it shows too many difficult to solve issues (I doubt that).

In worst case they might be rejected, but then it would be still useful to
have them in one pull request and share them with other interested parties.

Cheers,

On Thu, Jun 4, 2020 at 3:58 PM Quentin Schulz <
quentin.schulz@streamunlimited.com> wrote:

> On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > >
> > > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > >
> > > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > > >
> > > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > > default.
> > > > > >
> > > > > > (Backport of OE-Core rev:
> > > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > > >
> > > > > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > > Signed-off-by: Richard Purdie <
> richard.purdie@linuxfoundation.org
> > > > > > >
> > > > > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > > > >
> > > > > Does warrior otherwise work on gcc10 hosts?
> > > > Not yet but I am working on it.
> > >
> > > I think to make a decision on whether we plan to support gcc10 or not
> > > we'll need to know the scope of the changes. I'm starting to worry this
> > > would be a bit too invasive, particularly as warrior is about to enter
> > > community support or EOL depending on whether there is a maintainer.
> > >
> > I see. Problems for me - job's hat on - are:
> >
> > 1. we're close to release a product based on warrior (and a new
> > colleague of mine has just installed Fedora 32 with gcc 10 - that's
> > why I ask for it)
> > 2. my tests with dunfell were - hmm - not running out of the box exactly.
> >
> > So we should decide to upgrade to dunfell. That is what I use for
> > private raspi-images an am very close to happy.
> >
>
> Dang, I was silently but closely following the discussion hoping to be
> able to apply more or less the same patches on top of thud. Same issue
> as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
> docker time :/ (there'll always be that one client that will not want to
> upgrade to newer releases).
>
> Or maybe we can support gcc10 on the community branch once it's EOL (or
> doing the job ourselves..). What seems to be the big worry about
> supporting gcc10 on warrior/thud? Just so I can explain why we should go
> the docker route instead of spending time on making thud (and we still
> have krogoth for some...) build with gcc10 and maybe start working on
> upgrading those we can to newer releases. Basically what are the
> expected big hurdles on the way?
>
> Cheers,
> Quentin
> 
>

[-- Attachment #2: Type: text/html, Size: 5317 bytes --]

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Richard Purdie]

On Thu, 2020-06-04 at 15:57 +0200, Quentin Schulz wrote:
> On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:
> > On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:
> > > > On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie
> > > > <richard.purdie@linuxfoundation.org> wrote:
> > > > > On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:
> > > > > > From: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > > 
> > > > > > 'pseudo_access_t' is a type, so use typedef.
> > > > > > 
> > > > > > Fixes building pseudo with gcc 10 where -fno-common is the
> > > > > > default.
> > > > > > 
> > > > > > (Backport of OE-Core rev:
> > > > > > a7d519f742aadc9110c2401f359254210a784f6b)
> > > > > > 
> > > > > > Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
> > > > > > Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> > > > > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > > > > 
> > > > > Does warrior otherwise work on gcc10 hosts?
> > > > Not yet but I am working on it.
> > > 
> > > I think to make a decision on whether we plan to support gcc10 or not
> > > we'll need to know the scope of the changes. I'm starting to worry this
> > > would be a bit too invasive, particularly as warrior is about to enter
> > > community support or EOL depending on whether there is a maintainer.
> > > 
> > I see. Problems for me - job's hat on - are:
> > 
> > 1. we're close to release a product based on warrior (and a new
> > colleague of mine has just installed Fedora 32 with gcc 10 - that's
> > why I ask for it)
> > 2. my tests with dunfell were - hmm - not running out of the box exactly.
> > 
> > So we should decide to upgrade to dunfell. That is what I use for
> > private raspi-images an am very close to happy.
> > 
> 
> Dang, I was silently but closely following the discussion hoping to be
> able to apply more or less the same patches on top of thud. Same issue
> as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's
> docker time :/ (there'll always be that one client that will not want to
> upgrade to newer releases).
> 
> Or maybe we can support gcc10 on the community branch once it's EOL (or
> doing the job ourselves..). What seems to be the big worry about
> supporting gcc10 on warrior/thud? Just so I can explain why we should go
> the docker route instead of spending time on making thud (and we still
> have krogoth for some...) build with gcc10 and maybe start working on
> upgrading those we can to newer releases. Basically what are the
> expected big hurdles on the way?

Your other option would be buildtools tarball for the f32/ubuntu2004
systems.

I could see a case for backporting the buildtools tarball
installer/wrapper for those older releases as a way of fixing these
issues.

Cheers,

Richard

Re: [OE-core] [PATCH][warrior] pseudo: Fix enum typedef

[Ernst Sj?strand]

[-- Attachment #1: Type: text/plain, Size: 3231 bytes --]

Ubuntu 20.04 doesn't have gcc 10 as default, it's still 9. So I guess that's different from Fedora 32
that someone mentioned.

Regards
//Ernst

Thu 2020-06-04 klockan 15:06 +0100 skrev Richard Purdie:

On Thu, 2020-06-04 at 15:57 +0200, Quentin Schulz wrote:

On Thu, Jun 04, 2020 at 03:49:28PM +0200, Andreas Müller wrote:

On Thu, Jun 4, 2020 at 2:47 PM Richard Purdie

<

<mailto:richard.purdie@linuxfoundation.org>

richard.purdie@linuxfoundation.org

> wrote:

On Thu, 2020-06-04 at 14:18 +0200, Andreas Müller wrote:

On Thu, Jun 4, 2020 at 2:11 PM Richard Purdie

<

<mailto:richard.purdie@linuxfoundation.org>

richard.purdie@linuxfoundation.org

> wrote:

On Thu, 2020-06-04 at 14:03 +0200, Andreas Müller wrote:

From: Jacob Kroon <

<mailto:jacob.kroon@gmail.com>

jacob.kroon@gmail.com

>


'pseudo_access_t' is a type, so use typedef.


Fixes building pseudo with gcc 10 where -fno-common is the

default.


(Backport of OE-Core rev:

a7d519f742aadc9110c2401f359254210a784f6b)


Signed-off-by: Jacob Kroon <

<mailto:jacob.kroon@gmail.com>

jacob.kroon@gmail.com

>

Signed-off-by: Richard Purdie <

<mailto:richard.purdie@linuxfoundation.org>

richard.purdie@linuxfoundation.org


Signed-off-by: Andreas Müller <

<mailto:schnitzeltony@gmail.com>

schnitzeltony@gmail.com

>


Does warrior otherwise work on gcc10 hosts?

Not yet but I am working on it.


I think to make a decision on whether we plan to support gcc10 or not

we'll need to know the scope of the changes. I'm starting to worry this

would be a bit too invasive, particularly as warrior is about to enter

community support or EOL depending on whether there is a maintainer.


I see. Problems for me - job's hat on - are:


1. we're close to release a product based on warrior (and a new

colleague of mine has just installed Fedora 32 with gcc 10 - that's

why I ask for it)

2. my tests with dunfell were - hmm - not running out of the box exactly.


So we should decide to upgrade to dunfell. That is what I use for

private raspi-images an am very close to happy.



Dang, I was silently but closely following the discussion hoping to be

able to apply more or less the same patches on top of thud. Same issue

as yours, colleagues moving to Ubuntu 20.04 with gcc 10+. I guess it's

docker time :/ (there'll always be that one client that will not want to

upgrade to newer releases).


Or maybe we can support gcc10 on the community branch once it's EOL (or

doing the job ourselves..). What seems to be the big worry about

supporting gcc10 on warrior/thud? Just so I can explain why we should go

the docker route instead of spending time on making thud (and we still

have krogoth for some...) build with gcc10 and maybe start working on

upgrading those we can to newer releases. Basically what are the

expected big hurdles on the way?


Your other option would be buildtools tarball for the f32/ubuntu2004

systems.


I could see a case for backporting the buildtools tarball

installer/wrapper for those older releases as a way of fixing these

issues.


Cheers,


Richard




[-- Attachment #2: Type: text/html, Size: 5249 bytes --]