Recently, rustup moved std-*.dll from the $sysroot\bin directory to
the libdir. This causes issues with CI; fix them by adding the
libdir to the path and, while at it, getting the sysroot and libdir
directly from rustc.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Portage uses a different directory now for cached remote binpkgs to
distinguish those from locally-produced ones.
Signed-off-by: Sam James <sam@gentoo.org>
Wine wants to initialize the prefix on first use. In our CI, we were
initializing the prefix lazily when the tests actually ran. Since we run
tests in parallel, this became contentious and resulted in the following
failure:
wine client error:0: recvmsg: Connection reset by peer
Sometimes the CI job would pass and other times it would fail.
Signed-off-by: Tristan Partin <tristan@partin.io>
```
emerge: there are no ebuilds built with USE flags to satisfy ">=media-libs/freetype-2.5.0.1:2[harfbuzz,png,abi_x86_64(-)]".
!!! One of the following packages is required to complete your request:
- media-libs/freetype-2.14.1-r1::gentoo (Change USE: +harfbuzz)
(dependency required by "x11-libs/pango-1.57.0::gentoo" [binary])
(dependency required by "gnome-base/librsvg-2.60.0::gentoo" [binary])
(dependency required by "x11-themes/adwaita-icon-theme-legacy-46.2::gentoo" [binary])
(dependency required by "x11-themes/adwaita-icon-theme-48.1::gentoo" [binary])
(dependency required by "x11-libs/gtk+-3.24.51::gentoo" [binary])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
```
This comes from the change we made now that the FT<->HB cycle is gone
where pango now unconditionally depends on freetype[harfbuzz] because it's
janky at runtime otherwise.
Bug: https://bugs.gentoo.org/712374
Bug: https://bugs.gentoo.org/962715
Signed-off-by: Sam James <sam@gentoo.org>
Currently what this does is permit freethreaded builds, which are
stablemasked but not masked, which means we get a binpackage cache miss
for something we frankly very much do not care about at all.
We can and do unmask implementations themselves later on in this file,
which should handle all this for us anyway.
We've been using the desktop profile until now, mostly because it
automatically provides various frameworks we test e.g. wayland, gtk, qt
etc that all install out of the box. It also guarantees that binpackages
match.
The image is also really fat though. :( Switch to the base profile,
install a few packages that otherwise wouldn't be installed, and tweak
individual USE flags for binary coverage.
Gentoo does a weirdo thing where you cannot detect vala without setting
an environment variable. It's usually only set in ebuild recipes, and
vala simply does not work on Gentoo at all, period, end of story,
outside of that.
Capitulate, and parse the output of portage to find the most recent vala
installed and export that directly into meson's binary table lookup. We
aren't interested in whether *Gentoo* works with Vala, we are interested
in finding out whether newly packaged vala versions in Gentoo are
compatible with meson.
Bug: https://bugs.gentoo.org/513658
This dates back to before we changed to Python 3.12 default in Gentoo. I
don't remember why we specifically wanted/needed 3.12 in the CI builder
though (maybe something to do with distutils removal to test that). The
Python changes here shouldn't make much difference to binpkg eligibility
right now because the binhost has a double builder for old targets, though
it won't cover everything.
Signed-off-by: Sam James <sam@gentoo.org>
Build hotdoc from the git repository to work around the build failures
resulting from C99 incompatibilities. The issues are already fixed,
but the fix has not made it into a release yet.
Signed-off-by: Michał Górny <mgorny@quansight.com>
Fix `scalapack.MKLPkgConfigDependency` not to crash when `MKLROOT`
is unset:
```
File "/meson/mesonbuild/dependencies/scalapack.py", line 65, in __init__
super().__init__(name, env, kwargs, language=language)
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/meson/mesonbuild/dependencies/pkgconfig.py", line 322, in __init__
self._set_cargs()
~~~~~~~~~~~~~~~^^
File "/meson/mesonbuild/dependencies/scalapack.py", line 141, in _set_cargs
cflags = self.pkgconfig.cflags(self.name, allow_system, define_variable=(('prefix', self.__mklroot.as_posix()),))
^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'as_posix'
```
The code is crashing because the `_set_cargs()` method assumes that
`self.__mklroot` will always be set, presumably because it assumes
it will only be called only when `MKLPkgConfigDependency.__init__()`
finishes with `is_found = True`. However, both `_set_cargs()`
and `_set_libs()` are called during `PkgConfigDependency.__init__()`,
and therefore they will be called if pkg-config lookup succeeds even
without `MKL_ROOT` set.
To avoid the issue, check for `self.__mklroot is None` in both
functions, and raise a `DependencyException` — effectively causing
the pkg-config lookup to fail in a natural way.
Fixes#11172
Signed-off-by: Michał Górny <mgorny@quansight.com>
See https://github.com/mesonbuild/meson/issues/14756#issuecomment-3020599903.
When I changed Gentoo's binhost.git in a117703e74dfabc6972911504453c2492c11dead,
I'd forgot that we match those settings in Meson's CI builder, so we've
not been able to take advantage of the binpkg since then.
The current approach of determining dub dependencies is by specifying
a name and, optionally, a version. Dub will then be called to generate
a json summary of the package and code in meson will parse that and
extract relevant information. This can be insufficient because dub
packages can provide multiple configurations for multiple use-cases,
examples include providing a configuration for an executable and a
configuration for a library. As a practical example, the dub package
itself provides an application configuration and multiple library
configurations, the json description of dub will, by default, be for
the application configuration which will make dub as a library
unusable in meson.
This can be solved without modifying the meson build interface by
having dub describe the entire local project and collecting
dependencies information from that. This way dub will generate
information based on the project's 'dub.json' file, which is free to
require dependencies in any way accepted by dub, by specifying
configurations, by modifying compilation flags etc. This is all
transparent to meson as dub's main purpose is to provide a path to the
library file generated by the dependency in addition to other
command-line arguments for the compiler.
This change will, however, require that projects that want to build
with meson also provided a 'dub.json' file in which dependency
information is recorded. Failure to do so will not break existing
projects that didn't use a 'dub.json', but they will be limited to
what the previous implementation offered. Projects that already have a
'dub.json' should be fine, so long as the file is valid and the
information in it matches the one in 'meson.build'. For example for a
'dependency()' call in 'meson.build' that dependency must exist in
'dub.json', otherwise the call will now fail when it worked
previously.
Using a 'dub.json' also has as a consequence that the version of the
dependencies that are found are the ones specified in
'dub.selections.json', which can be helpful for projects that already
provide a 'dub.json' in addition to 'meson.build' to de-duplicate code.
In terms of other code changes:
- multiple version requirements for a dub dependency now work, though
they can only be used when a 'dub.json' is present in which case the
version of dependencies is already pinned by 'dub.selections.json'
- the 'd/11 dub' test case has been changed to auto-generate the
'dub.json' config outside of the source directory, as the
auto-generated file triggers warning when parsed by dub, which upsets
the new code as the warnings interfere with the legitimate output.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
I assume I only added this when copying Arch as a template initially,
it certainly isn't needed now, as pointed out by Eli being suspicious
of its presence...
Signed-off-by: Sam James <sam@gentoo.org>
The D stdlib function std.process.spawnProcessPosix suffers from a bug
that causes any program that calls it to OOM if the nofile ulimit is
large.
This doesn't affect CI currently but trying to run or build the
containers locally will most likely crash when calling dub as docker
defaults to something like 1073741816 for both the hard limit and soft
limit. Lowering the soft limit is enough to make dub behave.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
Bump the version of the cidata archive and remove the code that tries
to setup dmd and the dub packages from run.ps1 as it doesn't work as
expected (builds for x86 instead of x86_64) and cidata should already
take care of them.
Signed-off-by: Andrei Horodniceanu <a.horodniceanu@proton.me>
Qt 6 now has stable keywords (and has for a while). Recent stabilisation
of Plasma 6 now pulls in Qt 6 in the image builder so frameworks: 4 qt
fails as qttools is missing.
Signed-off-by: Sam James <sam@gentoo.org>
Paolo Bonzini