| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This reverts commit 41faa907e3a36f4ed00aced3499d469abb865281.
Bug: https://bugs.gentoo.org/207098
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Closes: https://github.com/gentoo/gentoo/pull/37156
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
|
|
| |
Removes the first of two different versions of java-pkg_get-current-vm()
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Closes: https://github.com/gentoo/gentoo/pull/35287
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/207098
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/591142
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/813342
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/637768
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
| |
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
|
|
|
|
|
|
|
| |
With .ONESHELL active, only the return status of the final recipe line
will be checked.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
| |
Fixes: 16b2c5ebb2869f4132536e5eb0a465b534556fb6
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
The path returned by $(get_erl_libs) starts with a slash, so
${EPREFIX}/$(get_erl_libs) resulted in a double slash.
Fixes: 7ee6937e6219f250559ee26eb64e5991b27cd289
Closes: https://bugs.gentoo.org/770283
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Overriding a shell builtin command is generally a very bad idea,
especially when that command is used in code that is sourced (in this
case, /lib/gentoo/functions.sh). Therefore, rename test() to test_sc().
Also make sure that the directories that are used as targets for rm -rf
in cleanup() are actually different from the root directory.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
| |
Signed-off-by: Nick Sarnie <sarnex@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
multilib USE flags have unintentionally appeared against all Cargo
packages since this eclass was used by cargo.eclass. The rust_all_abis()
function is not used anywhere though, and removing it makes the
multilib-build inherit that is causing the issue redundant.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Prefix targets have been dropped from toolchain-funcs.eclass in
commit cab79611b07c9eb. Update tests accordingly.
Fixes: cab79611b07c9ebb795c6f65562ef72ba77550b1
Closes: https://bugs.gentoo.org/934150
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Patrick Lauer <patrick@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Remove base git-r3 tests, they are broken for a long time and I can't
figure out how to fix them properly. There is probably no point
in testing these functions standalone anyway since they're extensively
used by ebuilds.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
| |
dc from sys-devel/bc doesn't support the -S option. Set the precision
with the k command instead.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/933195
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
|
|
|
|
|
|
|
|
| |
But only in KF6-based packages as those are still masked, for getting
away with changing installed files.
Closes: https://bugs.gentoo.org/928345
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
|
|
|
|
|
|
|
| |
Previously blocked by postgres.eclass, which was fixed in
304ab5e1acc056aca413ed69bc6791270502cbce
Signed-off-by: Patrick Lauer <patrick@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CARGO_BUILD_TARGET and CARGO_TARGET_<triple>_LINKER are enough for pure
Rust. The linker otherwise defaults to `cc`. This doesn't respect any
linker specified in LDFLAGS, but this is also true for native builds. We
would need to do something with RUSTFLAGS.
The HOST_* variables are for the cc-rs crate, which is often used to
build non-Rust code. It uses the usual variables (CC, CFLAGS, etc) for
the target.
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
|
|
|
| |
It is going to inherit rust-toolchain, which is EAPI 8 only.
Closes: https://bugs.gentoo.org/715890
Signed-off-by: James Le Cuirot <chewi@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
|
|
|
|
| |
linux-info.eclass checks for the kernel_linux flag since 2018,
introduced with commit 9e7c4b6d2daa9a8b1c33154f8dd296a2d1a26e92.
Closes: https://bugs.gentoo.org/934130
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
| |
Minor stylistic changes.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
many vdr plugins need small adjustments because API or makefile changes
in upstream media-video/vdr which can be easily fixed with small changes
These fixes should no longer be reported as "equawarn", instead now only
an "einfo" will be printed out.
Closes: https://bugs.gentoo.org/925762
Closes: https://bugs.gentoo.org/925763
Closes: https://bugs.gentoo.org/925764
Closes: https://bugs.gentoo.org/925765
Closes: https://bugs.gentoo.org/925766
Closes: https://bugs.gentoo.org/925767
Closes: https://bugs.gentoo.org/925768
Closes: https://bugs.gentoo.org/925769
Closes: https://bugs.gentoo.org/925770
Closes: https://bugs.gentoo.org/925771
Closes: https://bugs.gentoo.org/925773
Closes: https://bugs.gentoo.org/925774
Closes: https://bugs.gentoo.org/925775
Closes: https://bugs.gentoo.org/925776
Closes: https://bugs.gentoo.org/925777
Closes: https://bugs.gentoo.org/925778
Closes: https://bugs.gentoo.org/925779
Closes: https://bugs.gentoo.org/925780
Closes: https://bugs.gentoo.org/925781
Closes: https://bugs.gentoo.org/925782
Closes: https://bugs.gentoo.org/925783
Closes: https://bugs.gentoo.org/925784
Closes: https://bugs.gentoo.org/925785
Closes: https://bugs.gentoo.org/925786
Closes: https://bugs.gentoo.org/925787
Closes: https://bugs.gentoo.org/925788
Closes: https://bugs.gentoo.org/925791
Closes: https://bugs.gentoo.org/925792
Closes: https://bugs.gentoo.org/925793
Closes: https://bugs.gentoo.org/925794
Closes: https://bugs.gentoo.org/925795
Closes: https://bugs.gentoo.org/925796
Closes: https://bugs.gentoo.org/925797
Closes: https://bugs.gentoo.org/925798
Closes: https://bugs.gentoo.org/925799
Closes: https://bugs.gentoo.org/925800
Closes: https://bugs.gentoo.org/925801
Closes: https://bugs.gentoo.org/925802
Closes: https://bugs.gentoo.org/925803
Closes: https://bugs.gentoo.org/925804
Closes: https://bugs.gentoo.org/925805
Closes: https://bugs.gentoo.org/925806
Closes: https://bugs.gentoo.org/925807
Closes: https://bugs.gentoo.org/925808
Closes: https://bugs.gentoo.org/925809
Closes: https://bugs.gentoo.org/925810
Closes: https://bugs.gentoo.org/925811
Closes: https://bugs.gentoo.org/925812
Closes: https://bugs.gentoo.org/925817
Closes: https://bugs.gentoo.org/925818
Closes: https://bugs.gentoo.org/925819
Closes: https://bugs.gentoo.org/925820
Closes: https://bugs.gentoo.org/925821
Closes: https://bugs.gentoo.org/925822
Closes: https://bugs.gentoo.org/925823
Closes: https://bugs.gentoo.org/925824
Closes: https://bugs.gentoo.org/925825
Closes: https://bugs.gentoo.org/925826
Closes: https://bugs.gentoo.org/925827
Closes: https://bugs.gentoo.org/925828
Closes: https://bugs.gentoo.org/925829
Closes: https://bugs.gentoo.org/925830
Closes: https://bugs.gentoo.org/925831
Closes: https://bugs.gentoo.org/925832
Closes: https://bugs.gentoo.org/925833
Closes: https://bugs.gentoo.org/925834
Closes: https://bugs.gentoo.org/925835
Closes: https://bugs.gentoo.org/925837
Closes: https://bugs.gentoo.org/925838
Closes: https://bugs.gentoo.org/925839
Closes: https://bugs.gentoo.org/925840
Closes: https://bugs.gentoo.org/925841
Closes: https://bugs.gentoo.org/925842
Closes: https://bugs.gentoo.org/925922
Closes: https://bugs.gentoo.org/925923
Closes: https://bugs.gentoo.org/925924
Signed-off-by: Martin Dummer <martin.dummer@gmx.net>
Closes: https://github.com/gentoo/gentoo/pull/36504
Signed-off-by: Joonas Niilola <juippis@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With my upstream meson hat on, I have griped about this for years any
time someone mentions "meson compile" to me. I think it was badly
motivated and shouldn't exist.
The purpose of this command is "for symmetry" with meson setup and meson
test and meson install, even though all of those are python programs
first and foremost, which have ninja targets that simply call back into
the meson tool but with less control.
Symmetry doesn't make a whole lot of sense. The compile phase actually
is implemented as a... ninja file, not a python program. Using ninja
directly is:
- faster, since you don't load hundreds of python modules into memory,
just to fork out to ninja
- easier to control, since you can directly control the ninja arguments
The "meson compile" program actually, in fact, only really exists for
two reasons:
- meson supports multiple backends -- only when manually requested -- on
operating systems other than linux. Namely, VS on Windows, and xcode
on macOS. The wrapper first checks which backend has been generated,
and then runs the appropriate command there. It also provides the
ninja argument syntax for options that multiple backends understand,
so, you can pass -v -j8 and it actually works regardless of backend
(even if in fact it has to pass `-verbosity:minimal -maxCpuCount:8` to
do it).
- via retconning, on Windows when using the MSVC `cl.exe` meson compile
started actually adding this to PATH and setting it up (because it
requires sourcing a batch script in order to both add to PATH and set
inscrutable mandatory environment variables) to prevent ninja utterly
failing if you missed this yourself.
For portage purposes, neither of these matter whatsoever. Even if
portage were to ever use cl.exe on Windows (???) it could set up the
environment just fine on its own, and actually using alternative
backends would require extending the eclass to configure xcode/vs for
tremendous slowdown in compile time, which would be silly.
In exchange for all these features portage doesn't need, what do we get?
meson compile unabashedly doesn't support all possible ninja arguments,
and says you should instead pass the combination of --ninja-args "..."
--vs-args "..." --xcode-args "..." and it will figure out which ones are
relevant for *your* backend and forward it to the backend. We don't
actually do that -- it would be super ugly for the common case of -v
-j8.
As a result, we ignore $NINJAOPTS, which ninja-utils.eclass claims we
are allowed to use. Instead we manually parse out some subset of
"supported" values. We *cannot* respect NINJAOPTS anyways, because...
... meson compile sucks and cannot handle it. To be more accurate: it
expects --ninja-args to be formatted using `meson-format-array`, the
same format that machine files use. No thank you!
And we still have to move to get_NINJAOPTS, then pass it as:
```
meson compile -C "${BUILD_DIR}" --ninja-args="['-j', '8', '-k', '0', '-v', '-l', '0']"
```
instead of:
```
meson compile -C "${BUILD_DIR}" -j 8 -v -l 0 --ninja-args="['-k0']"
```
The overengineered complexity of this is immense. ninja-utils.eclass
exists for an extremely good reason, provides best practices, and means
we don't have to maintain an interface to a custom tool with unintuitive
behavior since we get precisely the common functionality we already
want, for free.
Just use eninja.
Fixes:
- the absolute inability to use standard $NINJAOPTS to fine-tune
meson-using packages, for example to keep going and collect all the
build errors before aborting with a failure.
- support for ${NINJA_VERBOSE} (expected to be the fallback if
MESON_VERBOSE isn't set)
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also replaces the nasty workaround from qtbase's ebuild
on top of the function here.
Should "hopefully" be far less error prone, while still allowing
-march=native for people who aren't affected. Does mean slightly
worse optimizations for those affected, but this still tries
to use the highest x86-64-v* and should be insignificant.
Tentative, can't fully test without having an affected cpu so
may still need work.
Closes: https://bugs.gentoo.org/933374
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/738418
Signed-off-by: Alfredo Tupone <tupone@gentoo.org>
|
|
|
|
|
| |
Closes: https://bugs.gentoo.org/928104
Signed-off-by: Alfredo Tupone <tupone@gentoo.org>
|
|
|
|
| |
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
| |
The last version below 3.4.0 that used this SRC_URI has been removed in
2021 in bd4380d7b621baa6b63b24bedce94dfebe171cf3
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
| |
This default was never used since it was always overwritten by the
if/else following it.
Signed-off-by: Hans de Graaff <graaff@gentoo.org>
|
|
|
|
|
|
|
|
| |
Include the ':=' slot operator in examples. While generally LLVM
does not change its ABI within a single slot, it technically reserves
that possibility and it has historically been used in LLVM 11.1.0.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
|
| |
Patch dropped (upstreamed) since _QT5_GENTOOPATCHSET_REV=5:
Match deadcode elimination with cpu feature check
Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
|
|
|
|
|
|
| |
Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net>
Closes: https://github.com/gentoo/gentoo/pull/36819
Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
| |
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
|
|
|
|
|
|
| |
With EAPI 6 banned, eapi7-ver.eclass will be removed in the foreseeable
future. Copy its code because it is still needed for tests.
Signed-off-by: Ulrich Müller <ulm@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TL;DR: If we set 'ccflags', we're clobbering the Perl default. We're already
setting 'optimize' which is what we're supposed to use here.
We set ccflags *and* optimize for Module::Build (which dev-perl/Net-DNS uses),
while we only set OPTIMIZE (case is fine) for MM (which dev-perl/Net-LibIDN2 uses).
ccflags clobbers the Perl default, while optimize appends. We should just set optimize -
to not clobber what Perl sets, but also for consistency between the two build systems).
(Unfortunately, this does mean we also inherit things we don't really
want to, which don't affect ABI, like -fno-strict-aliasing, but let's
live with it for now...)
Bug: https://bugs.gentoo.org/261375
Bug: https://bugs.gentoo.org/877659
Closes: https://bugs.gentoo.org/932176
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Florian Schmaus <flow@gentoo.org>
|