(Attention jwb ..)

Interestingly we do build them on all architectures already, but I guess
we must filter them out at the release engineering stage.

I have no particular objection to shipping them on all architectures, since
it won't require any more maintenance work, and it makes all the arches
similar which is generally useful.  It'll also be easier than trying to
build them again in EPEL, if that's even possible.

Josh, what would we need to do here?

Orion, can you help us understand the use here a bit?  What packages need mingw{32,64}-gcc-c++ on e.g. s390x and ppc64le?  It seems odd that one would be building a toolchain that targets Windows from those architectures.

I am no mingw export or particularly involved in mingw packaging, I'm just trying to get deps into EPEL9.  I'm sure Richard knows much more than me.

Fedora seems to build mingw packages on all arches by default so it's easiest from a packaging standpoint to keep that in place.  Now, while the mingw32/64-gcc packages are arch specific, the resulting mingw32/64- packages from libraries (and apps?) are built as "noarch" packages.  Presumably this allows one to build Windows applications on a number of different host machines.  I think mingw is more of a cross-build environment than a native build environment?

Now perhaps it would make more sense to only build the mingw libraries on a single architecture.  If Fedora was interested in standardizing on a particular config in that way with helper macros that might be a way forward.  But at the moment we're faced with something like:

%if 0%{?rhel} >= 9
%ifarch x86_64
%bcond_without mingw
%else
%bcond_with mingw
%endif
%else
%bcond_withtout mingw
%endif

and a bunch of:

%if %{with mingw}
%endif

conditionals sprinkled through combined native/mingw packages which is pretty ugly.

The packages are a mix of noarch and arch-ful.  The noarch packages
(eg mingw64-glib2-2.66.7-3.el9.noarch.rpm) contain Windows libraries.  The
arch-ful packages (eg mingw64-gcc-12.0.1-11.1.el9.x86_64.rpm) contain
the cross-compiler components that you have to run to cross-compile
your source code and link it to the Windows libraries to form a final .exe

Anyway I was looking at what we actually ship across architectures on
C9S, and it's an odd mixture.  On x86_64 we ship everything:

http://mirror.stream.centos.org/9-stream/CRB/x86_64/os/Packages/

On ppc64le we ship most bits of mingw* but miss out mingw*-gcc,
and mingw*-glib2.  On the other hand we do ship mingw*-binutils.
This makes no sense to me at all:

http://mirror.stream.centos.org/9-stream/CRB/ppc64le/os/Packages/

Note that all of these arch-ful packages are actually built in Koji,
eg for mingw-gcc:

https://kojihub.stream.rdu2.redhat.com/koji/buildinfo?buildID=18446

We just seem to be dropping random packages between Koji and the mirrors.
I don't really understand why we miss out some packages but not others,
even though we build everything.

I agree that we should just ship everything the same on all architectures
as much as possible.  It makes everyone's lives easier.  Making EPEL
conditionalize spec files to deal with this is silly.

Any progress/decisions here?  It would be a great help with EPEL packaging and we're trying to move forward with more packages.  Thanks.

(In reply to Orion Poplawski from comment #8)
> Any progress/decisions here?  It would be a great help with EPEL packaging
> and we're trying to move forward with more packages.  Thanks.

I don't mind having these packages shipped on all arches, but at
the same time I have no idea how that could be done.  Best to hope
Red Hat release engineering team are able to do something.

So contrary to my previous comment, rel-eng have actually supplied the method
which I'll try to make work ...

Tingting, could you look at QA ACK here?  The only requirement is to check
that the mingw-gcc* packages are being shipped on all architectures.
There is no need to test that they work.

Business justification: We should ship the same set of packages on all architectures
to help EPEL, which is an important adjunct repository for RHEL users.

(In reply to Richard W.M. Jones from comment #12)
> Tingting, could you look at QA ACK here?  The only requirement is to check
> that the mingw-gcc* packages are being shipped on all architectures.
> There is no need to test that they work.

Done.

https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/merge_requests/268

I'm not certain when this change will take effect, possibly after 9.1 is
released or maybe sooner.

(In reply to Richard W.M. Jones from comment #16)
> https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/
> merge_requests/268
> 
> I'm not certain when this change will take effect, possibly after 9.1 is
> released or maybe sooner.

It should be reflected in a CentOS Stream compose in the next couple of weeks.

Note to the reporter, if you look in the comps file:
https://gitlab.com/redhat/centos-stream/release-engineering/comps/-/blob/main/comps-centos-stream-9.xml.in
you'll see there are quite a few other packages that have the
presumably unwanted arch="x86_64" attribute.  If those packages
are wrong you will need to file new bugs for each incorrect source
package.

https://gitlab.com/redhat/centos-stream/rpms/mingw-gcc/-/merge_requests/5

Tested the bug with:
http://download.eng.pek2.redhat.com//rhel-9/nightly/RHEL-9/RHEL-9.1.0-20220721.1

I can find mingw*-gcc packages in CRB compose for all arches.

For mingw*-glib2 mentioned in comment 6, do we need it for all arches, now I can only find it under X86_64.

This bug is only about mingw-gcc* packages.  As noted in comment 19
if other mingw* packages have the same problem, new bugs must be
filed by the reporter.  I don't see any new bugs so far, so I assume
that's not a problem.

(In reply to Richard W.M. Jones from comment #22)
> This bug is only about mingw-gcc* packages.  As noted in comment 19
> if other mingw* packages have the same problem, new bugs must be
> filed by the reporter.  I don't see any new bugs so far, so I assume
> that's not a problem.

Thanks, mark the bug as Tested.

Checked latest RHEL9.1 compose, mingw*-gcc packages have been added in CRB compose for all arches.

Based on the comments, move the bug to VERIFIED.

Thank you everyone.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Low: mingw-gcc security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:8415