| Age | Commit message (Collapse) | Author |
|---|
|
https://github.com/actions/runner-images/issues/12045
|
|
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.
|
|
|
|
|
|
They've changed it from "linux-x86_64" to "x86-64-linux".
|
|
The latter is needed for vulkan.pc now, but let's add vulkan-headers
explicitly while at it.
|
|
Workaround for cmake-4.0 vs wxwidgets-gtk2 by setting CMAKE_POLICY_VERSION_MINIMUM=3.5.
|
|
See https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/BJO756KHSCBPDMXVGFMGPHPUMW4PZK6T/#SLVEVFEFOCT3R5RCSVZPQN3GZSZYAEXL.
Use sdl2-compat-devel instead. I did try 'pkgconfig(sdl2)' but it failed
with some resolver error I didn't probe further.
|
|
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 can't find the equivalent of opensuse's "last rites" for package
removal but gtk-sharp3-complete appears gone from Factory and I can't find
any reference except for one mentioning it failing to build [0].
Drop it from the list of packages to install to fix the image build.
[0] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/TXFU2U5N3IMN3QA7VRDFLDC5M7NPKFVP/
Signed-off-by: Sam James <sam@gentoo.org>
|
|
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>
|
|
These packages are required to test `qml_module` from qt
|
|
This reverts commit 1da230c9e0f66cf7ecf5a9f5fed70e74e15418ac.
Should be fixed now in upstream rustc.
|
|
Signed-off-by: Sam James <sam@gentoo.org>
|
|
It is needed by objfw.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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>
|
|
Hack for https://github.com/linux-test-project/lcov/issues/245. I tried
to backport https://github.com/linux-test-project/lcov/commit/bf135caf5f626e02191c42bd2773e08a0bb9b7e5
but had no luck (worked in one container but didn'y apply in another, whatever).
This fixes the coverage unittests.
>=lcov-2.1-beta works fine. The beta has landed in a beta version of
Ubuntu too.
Bug: https://github.com/linux-test-project/lcov/issues/245
|
|
`test_meson_installed` fails without setuptools:
```
$ /usr/bin/python3 run_meson_command_tests.py -v
Meson build system 1.5.99 Command Tests
test_meson_exe_windows (__main__.CommandTests.test_meson_exe_windows) ... skipped 'NOT IMPLEMENTED'
test_meson_installed (__main__.CommandTests.test_meson_installed) ... Traceback (most recent call last):
File "/meson/setup.py", line 12, in <module>
from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'
ERROR
```
|
|
Like in a5211a15207a2e6e30e213c5530a5d1bf5c2531c.
|
|
This fixes a pesky failure in vs2019 vc2019x64ninja for d/11 dub:
```
Searching in DUB cache for compatible urld.lib
WARNING: No such cache folder: C:\Users\VssAdministrator\AppData\Local\dub\packages\urld-2.1.1\urld\.dub\build
ERROR: urld@2.1.1 not found
You may try the following command to install the necessary DUB libraries:
dub run --yes dub-build-deep -- urld --arch=x86_64 --compiler=dmd --build=debug
Run-time dependency urld found: NO
test cases\d\11 dub\meson.build:13:11: ERROR: Dependency "urld" not found
```
Follow dub's advice by installing urld in ci/run.ps1 before the testsuite;
we were already doing this for ubuntu, opensuse, and even recommending
it in our docs before now:
* ci/ciimage/ubuntu-rolling/install.sh
* ci/ciimage/opensuse/install.sh
* docs/markdown/Dependencies.md
We also bump to 'ci4' which has newer D added (from the cidata repo).
|
|
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
[Eli: do not add to CI tests as this is only a preparatory PR]
|
|
makepkg can do this, if when building packages from source you enable
debug. This is apparently being shipped in the /etc/makepkg.conf in
docker containers, which means building AUR packages now requires
installing debugedit, and then bloating your container with
/usr/src/debug. We really do not want that.
Reconfigure so that we do not, in fact, need that.
|
|
|
|
Due to reasons, Arch has chosen to split out the glib2 package into a
glib2-devel package containing a small handful of python programs. The
references to these programs are contained in the main glib2 package, so
meson fails a lot in CI with e.g.
```
test cases/frameworks/7 gnome/gdbus/meson.build:1:18: ERROR: Dependency 'gio-2.0' tool variable 'gdbus_codegen' contains erroneous value: '/usr/bin/gdbus-codegen'
This is a distributor issue -- please report it to your gio-2.0 provider.
```
|
|
It started failing CI as soon as the default shifted to 1.78. Something
is broken and it prevents running stable CI. Tracking issue opened.
We pin the version because that is the same way we handle CI for linux
-- with the exception that Linux CI can upgrade itself as soon as we
fix issues causing the CI Image Builder to jam itself, whereas
unfortunately Windows will need to be manually unpinned, but such is
life as a Windows supporter.
Bug: #13236
|
|
Arch profile.d scripts were converted to use an appending function that
disappears when /etc/profile exits, and overall are simply not suitable
-- any more -- for sourcing individually.
(I will freely admit I'm not really sure what the overall goal of
refraining from sourcing /etc/profile itself is. Arguably it's kind of
misuse of the profile...)
This silently broke the cuda tests, which never ran because the cuda
compiler was not detected as available.
While we are at it, I guess we can convert gentoo to use the same trick
of appending it in install.sh
|
|
|
|
It is now getting uninstalled instead of updated, due to blockers on old
glib. In fact, we explicitly need it...
|
|
|
|
```
# Ubuntu sources have moved to the /etc/apt/sources.list.d/ubuntu.sources
# file, which uses the deb822 format. Use deb822-formatted .sources files
# to manage package sources in the /etc/apt/sources.list.d/ directory.
# See the sources.list(5) manual page for details.
```
Adapt to the new format.
|
|
We need this for scalapack -> virtual/mpi -> openmpi
See https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1b86025be85171281811eaced7b342fbdfdb591
We now get an immediate, very nicely readable error that the USE flag is
necessary. For our use cases, there's no reason not to globally enable
it.
|
|
We need to load various environment variables from /etc/profile. We
cannot unconditionally load it, because opensuse sources env_vars and
their /etc/profile has a fatal bug in it that causes it to return
nonzero and abort under `set -e` (which is *amazing* as a thing to have
in /etc/profile specifically -- just saying).
Alas, even /etc/profile.env is not enough since Java support depends on
profile.d logic. Re-conditionalize this check to only be added to
env_vars.sh for the image named "gentoo".
|
|
FAILED unittests/linuxliketests.py::LinuxlikeTests::test_install_strip - FileNotFoundError: [Errno 2] No such file or directory: 'file'
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
We may want to consider our own binpkg cache for future to speed things up,
in addition to the ones provided by Gentoo's own binhost.
Signed-off-by: Sam James <sam@gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
|
|
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
|
|
The former has rust dependencies, which lead to max capping on Cygwin
since there is no rust compiler there. But it turns out there are other
disadvantages of jsonschema:
- it involves installing 5 wheels, instead of just 1
- it is much slower
To give some perspective to the latter issue, this is what it looks like
when I test with jsonschema:
```
===== 1 passed, 509 deselected in 3.07s =====
Total time: 3.341 seconds
```
And here's what it looks like when I test with fastjsonschema:
```
===== 1 passed, 509 deselected, 1 warning in 0.28s =====
Total time: 0.550 seconds
```
I cannot think of a good reason to use the former. Although in order to
work on old CI images, we'll support it as a fallback mechanism
|
|
|
|
|
|
In commit 5c479d7a13a518c18ccb4dc3b6bdd7bfc2a9bdb5, we deleted bad stuff
that makes python not work. But we missed the case where it is installed
to lib64.
|
|
Regression in commit 0af126fec798d6dbb0d1ad52168cc1f3f1758acd. We added
support for some "test cases/" stuff that actually relies on test files
being a symlink, but when testing the image builder, we copied the meson
repository contents into the docker container without telling python
that it is in fact super important to copy symlinks as symlinks.
As a result, the tests themselves ran fine when merging, but caused the
image builder to thereafter fail.
|
|
They do not appear to have 20 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 21.
Last time we chose one randomly and hoped it doesn't keep changing
value. This dismally failed: 20 was upgraded to 21. It looks like 17 may
have some staying power.
|
|
|
|
|
|
They do not appear to have 15 in their repos anymore, and no traces can
be found of it in the history, as usual. They do have 11, 17, and 20, so
choose one randomly and hope it doesn't keep changing value.
|
|
Azure pipelines is removing python2 from the hostedtoolcache, see
https://github.com/actions/runner-images/issues/7401
We want to test that meson can still build modules for it, anyway.
|
|
In this case, PEP 668 was created to allow a thing that Debian wanted,
which is for `pip install foobar` to not break the system python. This
despite the fact that the system python is fine, unless you use sudo pip
which is discouraged for separate reasons, and it is in fact quite
natural to install additional packages to the user site-packages.
It isn't even the job of the operating system to decide whether the user
site-packages is broken, whether the operating system gets the answer
correct or not -- it is the job of the operating system to decide
whether the operating system is broken, and that can be solved by e.g.
enforcing a shebang policy for distribution-packaged software, which
distros like Fedora do, and mandating not only that python shebangs do
not contain `/usr/bin/env`, but that they *do* contain -s.
Anyway, this entire kerfuffle is mostly just a bit of pointless
interactive churn, but it bites pretty hard for our use case, which is a
container image which is fortunately tested before deployment, so
instead of failing to deploy because of theoretical conflicts with the
base system (we specifically need base system integration...) we fail to
deploy because 5 minutes into pulling apt updates at the very beginning,
pip refuses point-blank to work. I especially do not know why it is the
job of the operating system to throw errors intended for interactive
users at people baking "appliance" containers who cannot "break" the
system python anyway.
Fix this by doing what Debian and Ubuntu should both have done from the
beginning, and opting containers out of this questionable feature
entirely.
Note that CI images may still not actually complete their build/test
cycle and be updated, because e.g. LLVM 16 issues tracked by #11642 or
glib ASAN issues tracked by #11754.
|
