On 14.03.22 14:02, Michael Cronenworth wrote: As far as I can judge, I don't see any problem. Sandro

On Mon, Mar 14, 2022 at 01:06:34PM +0000, Daniel P. Berrangé wrote: 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote: 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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote: 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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On 25.08.22 08:33, Marián Konček wrote: Yes, quite a few actually, to list the ones I adapted: eigen3 enchant2 freeimage gdal GeographicLib geos giflib gtkspell3 gtkspellmm30 jxrlib leptonica libgeotiff libimagequant libkml librttopo libspatialite libwebp openjpeg2 OpenSceneGraph osgearth podofo proj python-pillow qtspell shapelib svg2svgt tesseract uriparser Sandro

On 25.08.22 18:40, Michael Cronenworth wrote: You might also want to add the mingw debuginfo packages to those. Sandro

On 8/25/22 11:42 AM, Sandro Mani wrote: 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.

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? 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? 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. Thanks, Richard

On Thu, Sep 1, 2022 at 12:38 PM Sandro Mani <manisandro(a)gmail.com&gt; 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. Thanks, Richard

On Thu, Sep 01, 2022 at 04:57:52PM -0500, Michael Cronenworth wrote: The distinction 'development' vs 'runtime' is rather ill-defined, since development includes running tests which is "runtime" usage. Even before Wine was using the DLLs itself, apps could run their own tests inside Wine, or inside a real Windows virtual machine, at their choice. It is still reasonable to have the mingw packages noarch, as for example, people could be using a aarch64 host, doing windows cross-builds for compile only testing and so need the mingw packages installed. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Fri, Sep 2, 2022 at 3:45 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote: 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. Thanks, Richard

On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw <hobbes1069(a)gmail.com&gt; wrote: 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. I might remember wrong, but doing the same for Python packages was thought about a few years ago to catch architecture-specific issues more consistently (and not only iff the noarch python package happens to randomly be built on the failing architecture every now and then). Fabio

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. Thanks, Richard

On Wed, Aug 24, 2022 at 03:00:06PM +0100, Daniel P. Berrangé wrote: Fast forward 6 months and evidentally no one else was enthusiastic about updating the MinGW packaging guidelines, so I've taken on that task myself :-) I have not yet submitted to the Packaging Committee for approval. The first draft of updated guidelines I have is here: https://berrange.fedorapeople.org/mingw-integrated/packaging-guidelines/M... To see the precise 'diff' of new/old guidelines https://pagure.io/fork/berrange/packaging-committee/c/286537d0905835c7931... As noted in the commit message, this new packaging approach has already been put into practice for a large number of packages, where the same maintainer owned both the native and MinGW components. The packaging guidelines update aims to make this practice official, so that it can be promoted more widely, in cases where the native maintainer is different from the mingw maintainer. Our goal is to strongly encourage the use of integrated mingw packaging, but still allow native package maintainers the discretion to opt-out of this if they feel strongly against handling mingw themselves. The keys terms of the updated guidelines are this paragraph: [quote] * Where the same Fedora contributors intend to maintain both the native and MinGW builds of a package, they **MUST** use the integrated packaging approach. * Where the upstream project supports the Windows platform as an official build target and has automated CI, contributors **SHOULD** prefer the integrated MinGW packaging approach. While native package maintainers are encouraged to accept this, they may decline this suggestion at their discretion. * Where the upstream project does not have automated testing of Windows builds, the MinGW package support **MAY** use the integrated packaging approach, subject to agreement of the native package maintainer. * Where the upstream project only supports Windows builds, the separate packaging approach **MUST** be used. There will be no corresponding native package in Fedora expected. This situation is rare. * When a contributor proposes a new native package to Fedora that provides libraries that are known to support Windows, the reviewer **SHOULD** inquire whether the contributor would like to add MinGW builds at the same time. The contributor **MAY** decline this suggestion at their discretion. [/quote] With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Wed, Mar 01, 2023 at 01:45:11PM +0000, Daniel P. Berrangé wrote: When I first read this, it seemed like it was saying that if the upstream project supports Windows we (strongly) should produce a mingw package. I understand this is not what you're saying, but perhaps it could be clarified by adding "... and the Fedora packager wishes to provide a mingw library" I'm actually trying to think of a case. Maybe the tools I wrote like mingw-nsiswrapper and mingw-crossreport? The second one should probably be removed, since it's not very relevant today. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

On Wed, Mar 01, 2023 at 01:45:14PM +0000, Daniel P. Berrangé wrote: I've now opened ticket and pull request with the packaging committee https://pagure.io/packaging-committee/issue/1259 https://pagure.io/packaging-committee/pull-request/1260 so ideally please direct any feedback to the above locations. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Wed, Aug 24, 2022 at 02:49:21PM +0100, Daniel P. Berrangé wrote: I don't know if this is a bug in the spec or in the %find_lang RPM macro, but I've noticed that these packages have files out of the mingw sys-root included in the non-mingw packages: $ find /usr/*mingw32/ -type f | xargs rpm -qf | sort -u gvnc-1.3.0-5.fc37.x86_64 gvncpulse-1.3.0-5.fc37.x86_64 libosinfo-1.10.0-4.fc37.x86_64 libvirt-glib-4.0.0-6.fc37.x86_64 osinfo-db-tools-1.10.0-4.fc37.x86_64 All the files in those packages look like: /usr/{arch}-w64-mingw32/sys-root/mingw/share/locale/{lang}/LC_MESSAGES/{package}.mo There's a thread on the users list about the existence of /usr/i686-w64-mingw32/ and /usr/x86_64-w64-mingw32/ directories on systems without any mingw* packages installed, and it looks like on my system it's all due to the most recent commits to these packages to include mingw subpackages. I suspect the %find_lang macro's shell script (/usr/lib/rpm/find_lang.sh) needs to know not to include the mingw sysroot, or at least filter it out as part of the spec file %install. That is how the files are getting included in the non-mingw subpackages. They have: %files -n ... -f %{name}.lang in the %files section. -- Jonathan Billings <billings(a)negate.org&gt;