| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
|
|
| |
Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
|
|
|
|
|
|
|
|
| |
Usual mirror was not updated, so using alternate sources (which
is updated first is often random, so hard to say which to prefer
and can't use both given different compression for github).
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Warnings were mostly added to help the transition to newer
kernels for unsuspecting users. May have helped in some cases,
not in others.
But with 6.1.x being stable for a while, there's little reason
to keep this wall of warnings *here* and try to keep it accurate
and updated -- especially when we can't tell what's really in-use
or what the user needs (this was just vague suggestions).
For initial setting up issues, it sounds better to refer to the
Wiki. So if anyone has anything to share with their experience
with FB (or other issues) feel free to edit it and improve it so
it can help others.
Also drop the "builtin" nouveau check that was part of this block.
Module is already blacklisted and, if users went out of their way
to make it builtin, then let's assume they know what they're doing.
Closing #910058 but rather than a fix it's more of a dissociation.
Closes: https://bugs.gentoo.org/910058
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
This reverts commit f820cfb16e9fe4e496e7d51746ae086d9a4e4b59.
It got dropped again, but see 138405e809ff0e3fb82967bf3053ea23a14ccfa4.
Bug: https://bugs.gentoo.org/906995
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
|
|
|
| |
All done wrt bug #909226
Bug: https://bugs.gentoo.org/909226
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/909226
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Bug: https://bugs.gentoo.org/909226
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
| |
This also brings kernel 6.4 support to the 0/470 branch.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not really tested, but it should be harmless vs not having the file.
Skipping revbump, letting it propagate on kernel upgrades / bumps
(470 and 525 are bumped in next commits). Please rebuild if want this
now for other versions.
For 390.x the icd is a template, while the newer drivers had hardcoded
libGLX, but docs mentions libEGL is usable for all versions (unlikely
to be useful for 390.x given its partial wayland support is broken).
Closes: https://bugs.gentoo.org/909181
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
There is new CVEs for nvidia-drivers but this branch was not
updated for it. Assumed to be EOL, so it's time to drop it.
If for some reason newer drivers don't work right for you, please
fallback to the 470.x branch which is on long term support.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
| |
There was one "new" issue that affects 0/470 with 6.4 on top of 6.3's,
but newer versions already have a condition to not use the removed
dumb_destroy callback.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
| |
Technically 0/390+470+515 also need this, but they have bigger issues
with clang-16 and I can only recommend to not use clang with old
branches. NVIDIA may update 470 for clang in the future though, the
others are unlikely.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
| |
Signed-off-by: Michael Mair-Keimberger <mmk@levelnine.at>
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
| |
New production branch (now non-beta), and a potential future
stable candidate.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
| |
Apologies for another rebuild in the short timeframe.
See previous linux-mod-r1.eclass commit if want an explanation.
Rebuild is not needed for the vast majority of people, but is
a precaution given how easy it is to get API mismatch issues.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Matt Turner <mattst88@gentoo.org>
|
|
|
|
| |
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Noticed portage does not easily figure out rebuilds if do a plain
`emerge openssl:0/1.1`, but does if drop the || ( ) block. Not fully
correct to given wouldn't work with theoretical new subslots, but
dropping it for user experience sake (ultimately this is temporary).
Skip rebuild given this version won't be keyworded (this is for the
next one) and is still rebuilt on kernel bumps either way.
2. Had modified the .manifest block to handle this, but there is
no need to. Revert and use skip_files.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just noticed /etc/sandbox.d/20nvidia was installed executable,
thankfully very few likely have it yet plus it gets cleared
on kernel bumps.
Could re-order so nothing is done after .manifest, or use a
subshell but feel it'd be more confusing / nastier. May revisit
the general handling of .manifest eventually.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bit of a risky move (stable), but given just did a revbump for
sandbox.d and that IUSE=+modules/+strip will cause a rebuild
as well, it makes some sense to do this at same time.
Migration did mostly prove itself with ~arch's 0/530 so far
and other notable modules are using the eclass already, and
no known issues. So let's hope.
*Should* have no real impact on users unless they were disabling
USE=driver given renamed to modules to match global IUSE, but
will fix asap if something else comes up.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/dev/nvidiactl been a long standing issue, sometime appearing in sneaky
ways when a revdeps is built with opencl/cuda support even though the
package itself does not use it.
And /dev/char is newly needed with >=nvidia-drivers-525.105.17 or
>=535.43.02, but not 530.41.03. The production branch's 525.105.17
is newer than ~arch's long-living 530 and led to this being overlooked
until it hit stable (older stable 525.89.02 was not affected) and
was unaware of this until rebuilt libomp[offload] with 535 today
(note that 535.43.02 is unkeyworded, it's a beta).
Need /dev/char rather than /dev/char/195:255 given it tries to remove
+ create a symlink and does not simply try to write there.
This is not meant to be a full coverage of nvidia devices and only
for those being a widespread problem. Special needs or addwrite
(typically to run tests) should be handled manually or using
cuda.eclass' cuda_add_sandbox.
Adding /dev/char to all versions even if not needed *yet* just so it's
not overlooked when nvidia spreads it to other branches (except 390
given it's EOL, not to mention has no cuda packages anymore).
Bug: https://bugs.gentoo.org/904292
Bug: https://bugs.gentoo.org/905436
Closes: https://bugs.gentoo.org/904944
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Sam James <sam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|
|
|
|
| |
Signed-off-by: Arthur Zamarin <arthurzam@gentoo.org>
|