On 14.03.22 14:13, Daniel P. Berrangé wrote:

On Mon, Mar 14, 2022 at 01:06:34PM +0000, Daniel P. Berrangé wrote:

...

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:

...

Hi

Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:

Thanks for driving this idea forward, I think it'll be very good for maintainers in the long run.

...

I'm performing test builds here [1]. Once I've got them all building there, if there are no objections, I plan to push to F37 and retire all the corresponding mingw repos.

Sandro

[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/

Seems to be a 404 - is it marked private perhaps ?

Never mind, I was blinded by the other response into thinking this was a new thread, where as the orignal mail was actually weeks old.

Right, I already went ahead and merged the work ;) So far I've not seen any side-effects directly related to unifying the two builds.

Sandro

On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé berrange@redhat.com wrote:

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:

...

Hi

Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:

I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs:

libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc

I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages.

Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing.

IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging.

Sounds great. The Packaging Committee is looking forward to your PR ;)

Fabio

I noticed this thread, I develop a personal project where I use about 10 C libraries, I noticed that "glfw", "libsodium" and "libevent" do not have their corresponding mingw packages. I was considering trying to package them but unifying them with the native packages would be better. Of course, this would put more pressure on the maintainers.

I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration?

On 24. 8. 2022 16:00, Daniel P. Berrangé wrote:

On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote:

...

On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé berrange@redhat.com wrote:

...

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:

...

Hi

Following recent discussions and to reduce the maintenance burden, I'm planning to start merging native and mingw packages. Initially, I'll be looking at these packages where I maintain both variants:

I've done the same with all the mingw packages I maintained just before Fedora 37 branched. So the following native packages now just contain mingw sub-RPMs:

libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc

I'm so happy to have reduced this maint burden. I see a few new mingw packages pending in package review and think it'd be nice to first ask the native maintainer to consider unified package, before we approve any new separate mingw packages.

Our Mingw packaging guidelines, however, exclusively describe fully separated mingw packages. So if I suggest this to a native package maintainer who is not already familiar with mingw, they would be right to question whether this is a desirable thing.

IOW, I think we need to look at getting the mingw packaging docs updated to promote unified packaging as an officially supported (and even preferred) option, alongside separate packaging.

Sounds great. The Packaging Committee is looking forward to your PR ;)

I don't want to rush into doing that myself in case someone else reading along is very enthusiastic to do the work themselves ;-P

With regards, Daniel

On 8/25/22 1:33 AM, Marián Konček wrote:

I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration?

FAudio vkd3d

On Thu, Aug 25, 2022 at 06:42:52PM +0200, Sandro Mani wrote:

On 25.08.22 18:40, Michael Cronenworth wrote:

...

On 8/25/22 1:33 AM, Marián Konček wrote:

...

I could however open a PR to add them to the native packages. Do we have some libraries where this unification is already finished so that I could take inspiration?

FAudio vkd3d

You might also want to add the mingw debuginfo packages to those.

Also if the package is used in RHEL, it may be desirable to make the mingw sub-packages conditional, so that they don't get enabled when the Fedora spec is later rebuilt in a RHEL build root.

I've got an example here which is fairly simple, for an app using meson:

https://src.fedoraproject.org/rpms/libosinfo/c/c567145568cb401ce5143e5829f1d...

If the app uses autotools still it is a little more complex, as you'll need to make the native build use builddir != srcdir before adding the mingw bits. Unfortunately %configure doesn't do this by default, while meson does (and cmake does too iirc). To adapt autotools based app native build use something approximately like this:

%define _configure ../configure

mkdir build_native cd build_native

%configure ...args... %make_build

cd ..

and similar during install phase

cd build_native %make_install cd ..

With regards, Daniel

On 26.08.22 05:30, Michael Cronenworth wrote:

On 8/25/22 11:42 AM, Sandro Mani wrote:

...

You might also want to add the mingw debuginfo packages to those.

Ah, thanks. I'm used to the debuginfo packages being automatically added thanks to %{mingw_package_header}.

I wonder if we could have the install macros updated to handle this in a native package scenario.

Would be nice, it's IMO the only "ugly" part of unification that remains.

Sandro

On 01.09.22 17:18, Richard Shaw wrote:

I'd like to unify fltk but there are a couple of things I'm still unclear about...

1. If I build the x86_64 package locally via fedpkg or mock, will it

build both the linux and mingw artifacts by default?

Unless you have any specific %ifarch etc, yes.

2. Since mingw packages are considered "noarch" in infrastructure, I

assume there's some magic to prevent arches other than x86_64 from attempting to build the mingw packages?

Not really, but if builders on separate arches produce different artifacts for the noarch packages, the build will fail with a corresponding message like "package XXX built differently on arches YYY"

I would like some clear documentation, that if I'm troubleshooting either the x86_64 or mingw builds, that it's trivial to disable the one I'm not working on to speed up build iterations.

You can add

%bcond_without mingw

wrap the %package, %files, and portions inside %build and %install with

%if %{with mingw} ... %endif

and if you'd like to disable the mingw build, just change the bcond to

%bcond_with mingw

HTH Sandro

On 9/1/22 4:25 PM, Richard Shaw wrote:

Let me rephrase, is the mingw package going to be built on ALL arches with the expectation that they are the same (like -data packages)? If so, that seems like a huge waste of resources.

The MinGW packages would build on all arches. I believe the original designation of 'noarch' is due to the cross-compile aspect as you can build these on any arch and that end users would only use them for development and not runtime. That has changed recently now that Wine builds most of itself as Windows PE binaries and depends on .dll files from mingw32/64 packages.

If you want this to change then you'll need to start with the Packaging Guidelines. Sandro may have his own opinion on it, too.

On Thu, Sep 01, 2022 at 04:25:28PM -0500, Richard Shaw wrote:

On Thu, Sep 1, 2022 at 12:38 PM Sandro Mani manisandro@gmail.com wrote:

...

On 01.09.22 17:18, Richard Shaw wrote:

...

I'd like to unify fltk but there are a couple of things I'm still unclear about...

1. If I build the x86_64 package locally via fedpkg or mock, will it

build both the linux and mingw artifacts by default?

Unless you have any specific %ifarch etc, yes.

...

2. Since mingw packages are considered "noarch" in infrastructure, I

assume there's some magic to prevent arches other than x86_64 from attempting to build the mingw packages?

Not really, but if builders on separate arches produce different artifacts for the noarch packages, the build will fail with a corresponding message like "package XXX built differently on arches YYY"

Let me rephrase, is the mingw package going to be built on ALL arches with the expectation that they are the same (like -data packages)? If so, that seems like a huge waste of resources.

If looking at a single package in isolation it may look wasteful, but from the POV of the distro as a whole packages with potential mingw sub-RPMs are a small subset of what goes through koji every day.

With regards, Daniel

On 02.09.22 13:43, Richard Shaw wrote:

On Fri, Sep 2, 2022 at 3:45 AM Daniel P. Berrangé berrange@redhat.com wrote:

On Thu, Sep 01, 2022 at 04:25:28PM -0500, Richard Shaw wrote:
> On Thu, Sep 1, 2022 at 12:38 PM Sandro Mani
<manisandro@gmail.com> wrote:
>
> >
> > On 01.09.22 17:18, Richard Shaw wrote:
> > > I'd like to unify fltk but there are a couple of things I'm
still
> > > unclear about...
> > >
> > > 1. If I build the x86_64 package locally via fedpkg or mock,
will it
> > > build both the linux and mingw artifacts by default?
> > Unless you have any specific %ifarch etc, yes.
> > > 2. Since mingw packages are considered "noarch" in
infrastructure, I
> > > assume there's some magic to prevent arches other than
x86_64 from
> > > attempting to build the mingw packages?
> > Not really, but if builders on separate arches produce different
> > artifacts for the noarch packages, the build will fail with a
> > corresponding message like "package XXX built differently on
arches YYY"
> >
>
> Let me rephrase, is the mingw package going to be built on ALL
arches with
> the expectation that they are the same (like -data packages)? If
so, that
> seems like a huge waste of resources.

If looking at a single package in isolation it may look wasteful,
but from
the POV of the distro as a whole packages with potential mingw
sub-RPMs
are a small subset of what goes through koji every day.

Perhaps, but the engineer in me finds this very distasteful :)

It would probably be too much work but it would be useful to have a pseudo-arch "mingw" which would just build on the first available "noarch" builder.

The same problem regarding builder resource usage actually applies to any noarch package which may be non-trivial to generate (also just some complex documentation). But if one really wanted to do that, I guess the only way would be to have

%build %build_noarch

%install %install_noarch

and then a noarch builder which builds just the noarch-sections resp and produces packages marked as BuildArch: noarch.

Sandro

On 9/2/22 5:07 AM, Fabio Valentini wrote:

On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw hobbes1069@gmail.com wrote:

...

...

If looking at a single package in isolation it may look wasteful, but from the POV of the distro as a whole packages with potential mingw sub-RPMs are a small subset of what goes through koji every day.

Perhaps, but the engineer in me finds this very distasteful :)

It would probably be too much work but it would be useful to have a pseudo-arch "mingw" which would just build on the first available "noarch" builder.

Building noarch subpackages on multiple architectures actually provides some benefits, even if some - or all - of the output is thrown away:

• architecture-specific bugs that result in generation of different

"noarch" subpackages get caught (which they wouldn't be if the "noarch" subpackage were only ever built once)

• you can run tests for the functionality that's provided by the

"noarch" subpackages on different architectures

• etc.

For example, all Rust library packages build only "noarch" subpackages, but the packages themselves are built on *all* architectures, because we want to know whether the shipped code actually *compiles* and tests *succeed* on all supported architectures. If we didn't do that, catching architecture-specific bugs would be much harder, and would only result in random problems, or build failures in leaf *application* packages instead of in the package that actually has the problem.

Well since you mention Rust, I'll also counterpoint that I do have the toolchain configured to only use x86_64 to build wasm/mingw noarch subpackages of the standard library.

The reason is that they include a crate "disambiguator" hash which does end up capturing host differences as well, so each host arch would end up with different hashes in the target libs. But that doesn't actually matter when other host toolchains just *use* those libs in cross-compilation, so it's fine to ship that noarch everywhere.

But the standard library is a little special in that regard, at least until the dynamic -Zbuild-std option may be stabilized. As you say, for most Rust libraries we only ship noarch sources, and it totally makes sense to still build and test those on each host individually.

On 03.09.22 17:10, Richard Shaw wrote:

I'm trying to migrate fltk right now and running into an issue:

Processing files: fltk-debugsource-1.3.8-4.fc38.x86_64

RPM build warnings:

RPM build errors: error: Could not open %files file /builddir/build/BUILD/fltk-1.3.8/debugsourcefiles.list: No such file or directory

Building the mingw packages seems to be interfering with the native build.

Can you point to the SPEC?

Sandro