Arch Linux User Repository

ok, lets keep i686 here and for llvm: the qt5 chain should be ok

I guess phasing out i686 is generally ok. I really don't need i686 anymore for each and every package. I still like to keep it for core packages and the dependency chain up to Qt 5, though.

So I suggest we:

1. Keep both archs for core packages like GCC, OpenSSL, Boost and a few other small libraries and the dependency chain up to Qt 5. Allow overriding via MINGW_W64_ARCHS so anyone who only needs 64-bit can avoid the 32-bit build.
2. Remove i686 from many other packages by default, especially starting with those that have long build times. Allow overriding via MINGW_W64_ARCHS so anyone who still needs 32-bit can enable it (possibly running into build errors as package maintainers won't have tested whether it actually builds).

That would be the most convenient for me because this way I wouldn't have to override MINGW_W64_ARCHS per package and would still have 32-bit where I need it and avoid having 32-bit where I don't need it. Of course having explicit per-package overrides is something I could implement in my build scripts/service so if you want to remove 32-bit completely I think I'll somehow manage.

hello,

I'm proposing to phase out i686, but we can set MINGW_W64_ARCHS env to override this default, like you did in your packages:

_architectures=${MINGW_W64_ARCHS:-x86_64-w64-mingw32}

what do you think ?

Is i686 no longer supported by upstream (as with Qt 6) or why did you drop that arch? An explaining comment like https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=mingw-w64-qt6-base#n95 would be nice.

If i686 builds are still supported or are not problematic I'd keep them by default. If i686 builds are only useful on systems that are too slow anyway for every practical use case then we can also drop those builds of course.

By the way, I only noticed the removal because my build system added the package automatically to the staging repo:

==> Checking whether staging of mingw-w64-mesa is needed
  -> checking the following databases for affected packages: ownstuff, ownstuff-protected, ownstuff-protected-testing, ownstuff-protected-staging, ownstuff-protected-staging-debug, ownstuff-protected-testing-debug, ownstuff-protected-debug, ownstuff-testing, ownstuff-staging, ownstuff-staging-debug, ownstuff-experimental, ownstuff-experimental-debug, ownstuff-testing-debug, ownstuff-znver3, ownstuff-debug
  -> yes: Other packages need to be re-built:
      - ownstuff/mingw-w64-fltk
      - ownstuff/mingw-w64-glew
      - ownstuff/mingw-w64-qt5-base
      - ownstuff/mingw-w64-freeglut
      - ownstuff/mingw-w64-ftgl
      - ownstuff/mingw-w64-gl2ps
      - ownstuff/mingw-w64-qt5-multimedia
      - ownstuff/mingw-w64-sfml

However, I suppose that's just a false-positive as those packages can still use the system OpenGL library. So I'm moving the package from staging.

I added it

Looks like the make dependency glslang is missing:

meson.build:648:15: ERROR: Program 'glslangValidator' not found or not executable

yes, added python-yaml, sphinx is only used for the doc

Further Python makedepends are missing. It makes probably most sense if you have a look at the regular package when updating, e.g. https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/commit/0e47b98b859e1e5b98ae48af1e0236b226eb7f1f shows the new dependencies as of 24.2.

The build succeeds when adding python-packaging as make dependency. Considering it was used just internally by meson to check for another dependency we might want to add it to mingw-w64-meson. On the other hand, the regular mesa package also lists python-packaging directly.

I had a look at the log file meson wrote:

Running command: /usr/bin/python3 -c '
try:
  from packaging.version import Version
except:
  from distutils.version import StrictVersion as Version
import mako
assert Version(mako.__version__) >= Version("0.8.0")
  '
--- stdout ---

--- stderr ---
Traceback (most recent call last):
  File "<string>", line 3, in <module>
ModuleNotFoundError: No module named 'packaging'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 5, in <module>
ModuleNotFoundError: No module named 'distutils'

After installing python-packaging I can rerun the command just fine. I'll try the build again with python-packaging as make dependency.