summaryrefslogtreecommitdiff
path: root/eclass
AgeCommit message (Collapse)Author
2025-10-03python-utils-r1.eclass: use 6 'X's for mktempHaelwenn (lanodan) Monnier
As required by POSIX.1-2024 for mkstemp(3) (and future-POSIX for mktemp(1)) Although you'd need de-facto standard mkstemps(3) due to the .xml suffix, but same contrains of 6 'X's applies, at least with musl. Signed-off-by: Haelwenn (lanodan) Monnier <contact@hacktivis.me> Part-of: https://github.com/gentoo/gentoo/pull/43186 Closes: https://github.com/gentoo/gentoo/pull/43186 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-10-03kernel-install.eclass: Fix updating symlinks with -p kernelsMichał Górny
Closes: https://bugs.gentoo.org/963683 Signed-off-by: Michał Górny <mgorny@gentoo.org> Part-of: https://github.com/gentoo/gentoo/pull/44021 Closes: https://github.com/gentoo/gentoo/pull/44021 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-10-03java-utils-2.eclass: re-enable PORTAGE_QUIETVolkmar W. Pogatzki
There are packages like javacup and jflex which cannot be built from source without using a pre-built runtime version of itself. Re-emerging these packages using the installed instead of the bundled pre-built version was causing the java-pkg_getjar() function to trigger java-pkg_ensure-dep() to issue a "QA Notice: java-pkg_ensure-dep:" message. This commit ports the PORTAGE_QUIET variable to java-pkg_getjar() so that it works again as it did in the past for ant-based ebuilds. Bug: https://bugs.gentoo.org/937047 Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net> Part-of: https://github.com/gentoo/gentoo/pull/44017 Signed-off-by: Sam James <sam@gentoo.org>
2025-10-03java-pkg-simple.eclass: fix a problem in multi-relase packagingVolkmar W. Pogatzki
There was too much of '--release ${version}' leading to validation errors and preventing successful creation of the jar when packaging (jar --create -f ) dev-java/fastdoubleparser. Removing it and changing the output directory of multi-release classes solves the problem and allows removal of the multi_release variable. Signed-off-by: Volkmar W. Pogatzki <gentoo@pogatzki.net> Part-of: https://github.com/gentoo/gentoo/pull/42134 Closes: https://github.com/gentoo/gentoo/pull/42134 Signed-off-by: Sam James <sam@gentoo.org>
2025-10-03eclass/nginx.eclass: change /var/tmp -> /var/cache + use new tmpfilesZurab Kvachadze
This commit changes of the default location of NGINX temporary files from /var/tmp/nginx (world-writable) to /var/cache/nginx (root-writable). Additionally, this revbumps all www-servers/nginx consumers of nginx.eclass to use the new nginx-r1.tmpfiles, where the path is updated accordingly. This fixes 962961 by specifying that the cache directory should only be pruned on boot, i.e. tmpfiles (even with --remove option) will not delete the temporary files of *running* NGINX. Closes: https://bugs.gentoo.org/962961 Signed-off-by: Zurab Kvachadze <zurabid2016@gmail.com> Part-of: https://github.com/gentoo/gentoo/pull/43823 Closes: https://github.com/gentoo/gentoo/pull/43823 Signed-off-by: Sam James <sam@gentoo.org>
2025-10-02dev-lang/rust: add 1.91.0Matt Jolly
Signed-off-by: Matt Jolly <kangie@gentoo.org>
2025-10-02dev-lang/rust: add 1.90.0Matt Jolly
Late is better than never, right? Closes: https://bugs.gentoo.org/963518 Signed-off-by: Matt Jolly <kangie@gentoo.org>
2025-10-01toolchain.eclass: fix paths for pax-markAlexander Tsoy
Actually ${ED} != ${D}${PREFIX} Fixes: 4a3bfe56f647fd16ec529d3632030bbbcaacee06 Signed-off-by: Alexander Tsoy <alexander@tsoy.me> Signed-off-by: Sam James <sam@gentoo.org>
2025-10-01llvm.org.eclass: Add 22.0.0_pre20251001 snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-30opam.eclass: dev-lang/ocaml-4 is the min in the treeAlfredo Tupone
Signed-off-by: Alfredo Tupone <tupone@gentoo.org>
2025-09-26kernel-install.eclass: only use cert if non-emptyNowa Ammerlaan
Apparently this file sometimes exists, but is empty, in which case we should not try to use it. Closes: https://bugs.gentoo.org/963425 Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
2025-09-26postgres.eclass: Disable postgres13 supportPatrick Lauer
Signed-off-by: Patrick Lauer <patrick@gentoo.org>
2025-09-26Reapply "profiles/desc: Remove old POSTGRES_TARGETS" & related commitsPatrick Lauer
This reverts commit 787d4fcfcb2743120c5bf5000962676a20f91b5b. Signed-off-by: Patrick Lauer <patrick@gentoo.org>
2025-09-26dune.eclass: dev-lang/ocaml<4 have long goneAlfredo Tupone
Signed-off-by: Alfredo Tupone <tupone@gentoo.org>
2025-09-25Revert "profiles/desc: Remove old POSTGRES_TARGETS" & related commitsJoonas Niilola
This revert series reverts 5 postgresql commits from earlier today. There seems to be a handful of rdeps that need to be addressed before removal of postgresql-13. With this single revert commit, *this* commit can be reverted in future to reapply all 5 commits again when the rdeps are sorted out. This reverts commits: 5adeecf12198ccd5eb12bdeb840a026a59fa3b8b 9718eec39a4ac1e48b216f51341fc2a454e6cca6 353510734c67cdfc622d69823459d7c0e0c8c6ef 7d30725246352824ddff832324ddcd3ceb44ade3 008d3218e93834b16b027ae2953981757e6e41b7 Signed-off-by: Joonas Niilola <juippis@gentoo.org>
2025-09-25kernel-install.eclass: ensure a secureboot cert is always setNowa Ammerlaan
When the kernel is re-installed via pkg_config the certificate may be gone. Detect if this is the case and if so try to extract the certificate from the kernel install directory and use that for verification later on in the (re-)install process. Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
2025-09-25postgres.eclass: Add support for postgres 18Patrick Lauer
Signed-off-by: Patrick Lauer <patrick@gentoo.org>
2025-09-24llvm.org.eclass: Remove old snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-24llvm.org.eclass: Add 22.0.0_pre20250923 snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-18qt6-build.eclass: allow lto again in Qt 6.10+ w/ gcc-15.2+Ionen Wolkens
Unclear what fixed what wrt the last failing qtbase test in bug #955531, but it seems to pass now. Just to be safe, limit this to recent Qt and gcc. Tried all of dev-qt/* (except qtwebengine+webview) with lto + -Werror=odr/mismatch/strict and everything seems to pass. Note that qtwebengine still filters lto in the ebuild, unlikely that this is resolved as it was due to some asm usage I recall (plus we're patching qtwebengine to allow respecting flags at all, Qt doesn't support users passing lto there). If other dev-qt/* have issues in the future we should likewise filter in the ebuild rather have a global one anymore. Formerly this wasn't about one failing test but tons of them everywhere. Closes: https://bugs.gentoo.org/955531 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
2025-09-17wine.eclass: Add arm64ec emulation supportSasha Finkelstein
Enable building arm64ec dlls and hook up fex-emu Signed-off-by: Sasha Finkelstein <fnkl.kernel@gmail.com> Part-of: https://github.com/gentoo/gentoo/pull/43593 Closes: https://github.com/gentoo/gentoo/pull/43593 Signed-off-by: Sam James <sam@gentoo.org>
2025-09-11kernel-build.eclass: replace cert with pubkey in generic-uki .pcrpkeyNowa Ammerlaan
This is the final piece in the Measured Boot puzzle, we have been putting the full certificate in the pcrpkey section. But though the certificate does contain the public key, the tools downstream get confused by the incorrect format. We now resolve the problem by extracting the public key from the certificate and using that instead. See-also: https://github.com/systemd/systemd/issues/38833 Closes: https://bugs.gentoo.org/960276 Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
2025-09-11kernel-install.eclass: verify against SECUREBOOT_SIGN_CERTNowa Ammerlaan
The .pcrpkey section of the UKI should not contain a full certificate. And therefore it is not correct to use it in sbverify. Instead use the set SECUREBOOT_SIGN_CERT which will contain the certificate that was used for signing in kernel-build.eclass. For gentoo-kernel-bin we set this variable to the certificate that was used during build and is included in the gpkg. Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
2025-09-11kernel-build.eclass: Revert "replace cert with pubkey in..."Michał Górny
This change broke at least arm64 dist-kernel builds: ``` Could not find certificate from /var/tmp/portage/sys-kernel/gentoo-kernel-6.16.7/temp/pcrpkey * ERROR: sys-kernel/gentoo-kernel-6.16.7::gentoo failed (postinst phase): * Failed to convert pcrpkey to PEM format ``` Reverts: 45367fd36d1b1be24cefc3d6266012258b3c3068 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-11kernel-build.eclass: replace cert with pubkey in generic-uki .pcrpkeyNowa Ammerlaan
This is the final piece in the Measured Boot puzzle, we have been putting the full certificate in the pcrpkey section. But though the certificate does contain the public key, the tools downstream get confused by the incorrect format. We now resolve the problem by extracting the public key from the certificate and using that instead. See-also: https://github.com/systemd/systemd/issues/38833 Closes: https://bugs.gentoo.org/960276 Signed-off-by: Nowa Ammerlaan <nowa@gentoo.org>
2025-09-11cargo.eclass: fix RUST_MIN_VER typo in errorSam James
Prompted by 986f9e9faf926fd9f882fe4636889434023e6e3c. Bug: https://bugs.gentoo.org/961500 Signed-off-by: Sam James <sam@gentoo.org>
2025-09-10llvm.org.eclass: Add 22.0.0_pre20250910 snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-10llvm.org.eclass: Remove old snapshotsMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-08acct-{group,user}.eclass: destable hppa and sparcArthur Zamarin
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
2025-09-07llvm.org.eclass: Add 22.0.0_pre20250907 snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-06toolchain.eclass: drop support EAPI 7Nicolas PARLANT
should only supports EAPI=8 since rust was introduced in inherit. Signed-off-by: Nicolas PARLANT <nicolas.parlant@parhuet.fr> Part-of: https://github.com/gentoo/gentoo/pull/40954 Closes: https://github.com/gentoo/gentoo/pull/40954 Signed-off-by: Sam James <sam@gentoo.org>
2025-09-06linux-mod-r1.eclass: silence spurious warning with _p* kernelsIonen Wolkens
Like noted in the comment, ideally would want to check for the actual matching version but we'd need to test+sanitize KV_EXTRA and figure out if it's really a version component as it could be anything. _p being used should be a rare event and it shouldn't be a big deal if the check ignores it. Skipping ML review given trivial and is just about a warning. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
2025-09-06usr-ldscript.eclass: spell 'GNU Binutils' consistentlySam James
Signed-off-by: Sam James <sam@gentoo.org>
2025-09-06apache-2.eclass: spell 'GNU Binutils' consistentlySam James
Signed-off-by: Sam James <sam@gentoo.org>
2025-09-06rocm.eclass: update targets for rocm >= 6.4.3 librariesSv. Lockal
According to "System requirements" webpage, gfx1101/gfx1200/gfx1201 are now supported. From the source code few libraries have gfx1103/gfx1150/gfx1151 support, which is not officially announced. Some released components fail to compile on gfx1150/gfx1151 - for these components live ebuilds should be introduced. Bug: https://bugs.gentoo.org/949494 Signed-off-by: Sv. Lockal <lockalsash@gmail.com> Part-of: https://github.com/gentoo/gentoo/pull/43406 Signed-off-by: Sam James <sam@gentoo.org>
2025-09-06python-utils-r1.eclass: replace 2to3 with "unsupported" wrapper for 3.13+Eli Schwartz
It has been removed upstream. Due to the use of a symlink for wrapping it (as opposed to a shell script like python / python-config) this meant searching PATH didn't find the broken symlink, and instead found /usr/bin/2to3-3.12 with a 3.13 impl. Check the version of EPYTHON and add it to nonsupp wrappers instead of making a symlink. Reported-by: Paul Zander <negril.nx+gentoo@gmail.com> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Signed-off-by: Michał Górny <mgorny@gentoo.org> Part-of: https://github.com/gentoo/gentoo/pull/43549 Closes: https://github.com/gentoo/gentoo/pull/43549 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-06pypi.eclass: Introduce provenance verification APIMichał Górny
Introduce a new API to verify provenance of PyPI artifacts. To enable it, set PYPI_VERIFY_REPO to the upstream repository URL. The eclass will automatically add a verify-provenance flag along with dependencies, fetch the provenance file from PyPI and export src_unpack() to verify it. Support for provenance verification can be checked on PyPI's project page. If it is supported, the project metadata (i.e. "Project links") is found in "Verified details", whereas otherwise only "Maintainers" are in that section. It can also be seen under "view details" for individual artifacts. The eclass also provides the low-level functions to account for special needs: pypi_provenance_url and pypi_verify_provenance. The bits are implemented directly in pypi.eclass rather than verify-sig.eclass since they are pretty tightly bound to PyPI infrastructure, with nontrivial URLs and a dedicated provenance file format. On top of that, due to a difference in semantics, the flag is named verify-provenance rather than verify-sig. Signed-off-by: Michał Górny <mgorny@gentoo.org> Part-of: https://github.com/gentoo/gentoo/pull/43549 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-06pypi.eclass: Update the @DESCRIPTIONMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org> Part-of: https://github.com/gentoo/gentoo/pull/43549 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-06pypi.eclass: Fix eclassdoc typo; <package> → <project>Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org> Part-of: https://github.com/gentoo/gentoo/pull/43549 Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-09-03selinux-policy-2.eclass: Document PATCHBUNDLE varJason Zaman
Signed-off-by: Jason Zaman <perfinion@gentoo.org>
2025-09-03selinux-policy-2.eclass: Drop support for <policycoreutils-2.5Jason Zaman
Older policycoreutils has been removed from the tree for many many years now. It required a separate argument for base.pp but is now just making things more complicated than needed. This way the command printed to users is much simpler. Signed-off-by: Jason Zaman <perfinion@gentoo.org>
2025-09-02wine.eclass: fix spacing furtherIonen Wolkens
Missed the line below also had a tab too many. Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
2025-09-02wine.eclass: fix spacingIonen Wolkens
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
2025-09-02toolchain.eclass: ada/d: bdepend on ${PN}:${SLOT} only as a last resortEli Schwartz
In general, there are *preferred* versus *workable* bootstrap compilers, and it is *preferred* to build ${lang} with an already built copy of that compiler, e.g. to get bugfixes and so on. So, for iteration order when setting up the compilation environment, we prefer our own SLOT, if multiple bootstrap compilers are available after `src_*` phases start running. As a separate matter, the dependency merge graph must pull in at least one *workable* compiler, and it would be nice if it is a *preferred* one. Portage solves for dependencies favoring leftmost if it is necessary to merge an additional dependency. So, ordering from most-preferred to least-preferred is plausibly reasonable. Problem: given an installed *workable* but least-preferred compiler, triggering autounmask of USE=ada causes portage to ignore a *workable* compiler if the leftmost dependency is already in the merge graph. It then reports a cycle, where the current package to build depends on itself: ``` * Error: circular dependencies: (sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) depends on (sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) (buildtime) ``` It turns out, the order in the any-of group matters. If: - item 1 is ${PN}:${SLOT} - item 2 is <${PN}-${SLOT} - item 3 is installed (ada-bootstrap) The merge graph wants to build item 1, item 2 would build a ton of versions and eventually need item 3, item 3 simply works without fuss. But item 1 *cannot* be uninstalled, yet still get merged in this transaction to satisfy the deps. And if it is already installed, we don't need leftmost-associativity to force the preferred compiler to be merged for building excellent machine code. Conversely, if item 1 is moved to the end, portage... doesn't try to autounmask item 2 (now item 1), even if item 3 (ada-bootstrap) is *not* installed. Although without autounmasking, if "sys-devel/gcc ada" is in package.use, it does build a large chain of gcc[ada]'s, since it can and is leftmost. But for autounmask, instead, it installs item 3 (ada-bootstrap) if necessary, since it can do so without further autounmask. The incorrect cycle is broken. Make this change, because it only affects cycle-breaking and doesn't affect iteration order in src_configure. Bug: https://bugs.gentoo.org/962273 Acked-by: Sam James <sam@gentoo.org> Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
2025-09-01zig-utils.eclass: add 0.15 to the list of supported versionsEric Joldasov
Signed-off-by: Eric Joldasov <bratishkaerik@landless-city.net> Part-of: https://github.com/gentoo/gentoo/pull/43623 Closes: https://github.com/gentoo/gentoo/pull/43623 Signed-off-by: Sam James <sam@gentoo.org>
2025-08-31llvm.org.eclass: Add 22.0.0_pre20250831 snapshotMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-08-31llvm.org.eclass: Remove old snapshot supportMichał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
2025-08-30wine.eclass: keep -std=* for cross flagsIonen Wolkens
Closes: https://bugs.gentoo.org/962175 Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
2025-08-26chromium-2.eclass: Handle non-standard _ suffixes in locale .pak filesJames Le Cuirot
These were recently added by Chromium for gender-based translations. _ is not a valid language tag character, so we strip this suffix when checking the USE flag, thereby grouping such files with their non-suffixed counterparts. Signed-off-by: James Le Cuirot <chewi@gentoo.org>
2025-08-26llvm.org.eclass: Enable manpages for 21Michał Górny
Signed-off-by: Michał Górny <mgorny@gentoo.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-08 05:35:14 +0000