Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hello,
On Fri, 05 Aug 2016, Mike Gilbert wrote:
>On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz wrote:
>> I know that. But the patch should be applied *only* for versions of kernels
>> 4.7+. So, I'm asking how is the policy for that.
>
>If you're asking for policy: The Gentoo packaging policy is not to do
>conditional patching. Instead, modify the patch so that the resulting
>code works for both cases. This can generally be accomplished via
>pre-processor macros.
My patch does it like that. See
https://archives.gentoo.org/gentoo-user/message/baa36d14d8cdbf58404267ee2ffd34ea
Just dumping the attached patch into
/etc/portage/patches/x11-drivers/nvidia-drivers-367.35/
(and making it readable for the portage user) is sufficient.
HTH,
-dnh
--
Every feature is a bug, unless it can be turned off. -- Karl Heuerdiff -purN a/kernel/nvidia-drm/nvidia-drm-fb.c b/kernel/nvidia-drm/nvidia-drm-fb.c
--- a/kernel/nvidia-drm/nvidia-drm-fb.c 2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-fb.c 2016-07-28 09:43:11.494515158 +0200
@@ -32,6 +32,8 @@
#include
+#include
+
static void nvidia_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct nvidia_drm_device *nv_dev = fb->dev->dev_private;
@@ -114,7 +116,11 @@ static struct drm_framebuffer *internal_
* We don't support any planar format, pick up first buffer only.
*/
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, cmd->handles[0]);
+#else
gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
+#endif
if (gem == NULL)
{
diff -purN a/kernel/nvidia-drm/nvidia-drm-gem.c b/kernel/nvidia-drm/nvidia-drm-gem.c
--- a/kernel/nvidia-drm/nvidia-drm-gem.c 2016-07-12 06:53:45.0 +0200
+++ b/kernel/nvidia-drm/nvidia-drm-gem.c 2016-07-28 09:27:24.610637573 +0200
@@ -28,6 +28,8 @@
#include "nvidia-drm-ioctl.h"
#include "nvidia-drm-gem.h"
+#include
+
static struct nvidia_drm_gem_object *nvidia_drm_gem_new
(
struct drm_file *file_priv,
@@ -408,7 +410,11 @@ int nvidia_drm_dumb_map_offset
mutex_lock(&dev->struct_mutex);
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,7,0)
+gem = drm_gem_object_lookup(file, handle);
+#else
gem = drm_gem_object_lookup(dev, file, handle);
+#endif
if (gem == NULL)
{
diff -purN a/kernel/nvidia-uvm/uvm_linux.h b/kernel/nvidia-uvm/uvm_linux.h
--- a/kernel/nvidia-uvm/uvm_linux.h 2016-07-12 06:52:17.0 +0200
+++ b/kernel/nvidia-uvm/uvm_linux.h 2016-07-28 09:29:21.096322608 +0200
@@ -554,11 +554,13 @@ static void uvm_init_radix_tree_preloada
INIT_RADIX_TREE(tree, GFP_NOWAIT);
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
static bool radix_tree_empty(struct radix_tree_root *tree)
{
void *dummy;
return radix_tree_gang_lookup(tree, &dummy, 0, 1) == 0;
}
+#endif
#if !defined(NV_USLEEP_RANGE_PRESENT)
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hello,
On Sat, 06 Aug 2016, Natanael Olaiz wrote:
>Thank you for your patch. It was a good example to answer my question.
>
>But about the patch itself, I see that you are commented the code for
>radix_tree_empty(...). In my patch I renamed it and it only usage instead,
>so I'm sure it's calling the same code. I don't know the expected
>compatibility with the kernel function implementation... But without
>knowing the specific code for neither the nvidia driver nor the kernel, I
>think the rename is safer...
If you're in doubt or hit any trouble, yes, definitely change/adapt
the patch to only rename that function and use the renamed function in
the nvidia-driver as in your original patch. Keep/adapt the stuff
about kernel-versions though. That's the "safe" approach.
That "just put it in /etc/portage/patches/..." should work tough :)
I've looked quite sharp at the code, i.e. in the nvidia code
static bool radix_tree_empty(struct radix_tree_root *tree)
{
void *dummy;
return radix_tree_gang_lookup(tree, &dummy, 0, 1) == 0;
}
vs. the kernel function
static inline bool radix_tree_empty(struct radix_tree_root *root)
{
return root->rnode == NULL;
}
*oik* I miss a check for root != NULL there ;)
Anyway, it was quite clear, that the driver calls kernel-stuff at this
point anyway, radix_tree_gang_lookup() is a kernel function. (I love
to use mc for digging for stuff like this!)
So, digging into the kernel-source I came to the conclusion that
calling the _kernel code_(!)
radix_tree_gang_lookup(tree, &dummy, 0, 1);
actually _is_ (or SHOULD BE) equivalent to the kernel code for
the new
radix_tree_empty(tree);
and the latter should be faster (unless the compiler optimizes the
'radix_tree_gang_lookup(root, &dummy, 0, 1)' call away).
All this applies if and only if the last two arguments of
radix_tree_gang_lookup() are 0 and 1! And yes, I did go through the
code of radix_tree_gang_lookup() step by step (repeatedly) until I was
sure enough that the code is equivalent). But I'm not a C guru. I
might have missed something even important. So, if more guys firm in C
can check this ...
As I'm a guy generally trusting the kernel guys _a lot_ and that
nvidia assumedly got it right implementing 'radix_tree_empty(tree)'
via 'radix_tree_gang_lookup(tree, &dummy, 0, 1);' and I think those
two equivalent (with 0, 1 being the 3rd and 4th parameters!), I tried
it, and it worked.
And Meino has not yet complained. AFAIR he's around long enough to
have complained by now (and circumvented problems with the patch).
I'll ping him on the -user ML though in a parallel mail.
Recap: calling the kernel function in this way (via the nvidia function)
radix_tree_gang_lookup(tree, &dummy, 0, 1);
is IMHO equivalent to calling the kernel function
radix_tree_empty(tree);
and on this I based my patch on. I'm rather sure from looking at the
code. It worked in a short test. Meino has not complained yet. If you
want a "sure"/"safe" approach, go with renaming the function in the
nvidia-code, or wait a bit if Meino pipes up, he should've been
running the driver with my patch for a week by now. Or until an
official patch crops up.
Or, take precautions, some other way to boot+chroot, and keep the
"old" driver handy or to disable it, build a binary package of the
previous driver, have an older kernel ready etc. pp., you know the
drill, don't you?
-dnh
--
MCSE: "Microsoft Certified Stupidity enclosed"-- A. Spengler
Re: [gentoo-dev] bash-4.4 - call for testers
Hello, On Tue, 20 Sep 2016, Lars Wendler wrote: >This is a call for testers. If you feel brave enough, please give >bash-4.4 a shot and report all problems you might have with it. > >Add the following to you package.unmask file/directory: > > =app-shells/bash-4.4* > =sys-libs/readline-7.0* with basically no testing so far: builds ok. >in order to get all readline reverse deps being built against new >readline. Reporting those packages in our bug tracker [1] would be >helpful. Creating a new bug or what? [2] seems inappropriate. >[2] https://bugs.gentoo.org/594496 I've found this that I guess has to do with the new readline: >From the build.log of emerge -1 dev-lisp/clisp [..] * Package:dev-lisp/clisp-2.49-r8 * Repository: gentoo * Maintainer: common-l...@gentoo.org * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk kernel_linux pcre postgres readline threads unicode userland_GNU zlib * FEATURES: ccache compressdebug nostrip preserve-libs sandbox splitdebug userpriv usersandbox [..] ;; Loading file /var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas ... *** - FFI::FIND-FOREIGN-VARIABLE: foreign variable # does not have the required size or alignment ./clisp-link: failed in /var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir Makefile:2621: recipe for target 'base' failed make: *** [base] Error 1 [..] # equery uses -i =dev-lisp/clisp-2.49-r8 | xargs echo +X +berkdb -dbus -fastcgi +gdbm +gtk -hyperspec -pari +pcre +postgres +readline +threads +unicode +zlib So, something with 'rl_readline_state' and how clisp uses that has changed that I won't dig into right now. Clisp maintainers? That seems to be the only problem with readline-7.0/bash-4.4 on this install (so far). -dnh -- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Edsger Wybe Dijkstra
Re: [gentoo-dev] bash-4.4 - call for testers
Hello, On Thu, 22 Sep 2016, David Haller wrote: [..] >I've found this that I guess has to do with the new readline: > >>From the build.log of >emerge -1 dev-lisp/clisp > > >[..] > * Package:dev-lisp/clisp-2.49-r8 > * Repository: gentoo > * Maintainer: common-l...@gentoo.org > * USE:X abi_x86_64 amd64 berkdb elibc_glibc gdbm gtk > kernel_linux pcre postgres readline threads unicode userland_GNU > zlib > * FEATURES: ccache compressdebug nostrip preserve-libs sandbox > splitdebug userpriv usersandbox >[..] >;; Loading file >/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir/readline/readline.fas > ... >*** - FFI::FIND-FOREIGN-VARIABLE: foreign variable #"rl_readline_state" #x0088B460> does not have the > required size or alignment > >./clisp-link: failed in >/var/tmp/portage/dev-lisp/clisp-2.49-r8/work/clisp-2.49/builddir >Makefile:2621: recipe for target 'base' failed >make: *** [base] Error 1 >[..] > [..] Got a patch for that: https://bugs.gentoo.org/show_bug.cgi?id=594552 https://bugs.gentoo.org/attachment.cgi?id=447492 -dnh -- Since attendees must wear their name tags, they must also wear shirts or blouses. Pants or skirts are also highly recommended. -- RFC 1391
USE=doc gnustep-make broken (was: Re: [gentoo-dev] package.use.mask / package.use.stable.mask priority)
Hello,
On Wed, 11 Jan 2017, Bernard Cafarelli wrote:
>Le 11/01/2017 8:30, Ulrich Mueller a écrit :
[..]
>> Putting flag in arch/{amd64,x86}/package.use.stable.mask should solve
>> it.
>Indeed, I tested (and committed) this yesterday and repoman was happy again
gnustep-base/gnustep-make-2.6.8.ebuild is broken when built with USE=doc,
as it tries to install into the system, not the image. Easy fix:
diff -U7 -r a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild
b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild
--- a/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild 2017-01-14
19:55:10.658259392 +0100
+++ b/gnustep-base/gnustep-make/gnustep-make-2.6.8.ebuild 2017-01-14
19:55:17.158259179 +0100
@@ -97,15 +97,15 @@
src_compile() {
emake
# Prepare doc here (needed when no gnustep-make is already installed)
if use doc ; then
# If a gnustep-1 environment is set
unset GNUSTEP_MAKEFILES
pushd Documentation &> /dev/null
- emake -j1 all install
+ emake -j1 all install DESTDIR="${D}"
popd &> /dev/null
fi
}
src_install() {
# Get GNUSTEP_* variables
. ./GNUstep.conf
HTH,
-dnh
--
What once was muesli is now of a colour and (from the looks) consistency
unheard of in dairy produce. At a second guess, it might be running for
political office by the time flattie's back.
-- The Bastard Flatmate From Hell
Re: [gentoo-dev] [RFC] New global USE flag: gtk-doc
Hello, On Fri, 24 Aug 2018, Mart Raudsepp wrote: [..] >Suggested description for global gtk-doc USE: >Build and install gtk-doc based developer documentation Mentioning gtk-doc, what about: https://bugs.gentoo.org/646850 Ready-made patch since 2018-02-07, and then what? -dnh -- If you don't see why, please stay the fuck away from my code. -- Paul "Rusty" Russel, in /usr/src/linux/Documentation/DocBook/kernel-locking.tmpl
Re: [gentoo-dev] Last rites: dev-lang/solidity
Hello,
On Thu, 13 Sep 2018, Michal Górny wrote:
># Michal Górny (13 Sep 2018)
># Depends on old version of dev-libs/jsoncpp, blocking its pruning.
># Downstream maintainer is inactive to bump it. Removal in 30 days.
>dev-lang/solidity
As per the "no -Werror" policy, the following patch to the ebuild, or
something to the same effect should be done anyway, and it compiles
without '-Werror'.
--- a/solidity-0.4.18.ebuild 2017-12-20 21:09:16.0 +0100
+++ b/solidity-0.4.18.ebuild 2018-09-13 15:59:06.584892127 +0200
@@ -28,6 +28,11 @@
"${FILESDIR}"/${P}-fix-cmake-external-jsoncpp.diff
)
+src_prepare() {
+ sed -i '/add_compile_options(-Werror)/d' cmake/EthCompilerSettings.cmake
+ cmake-utils_src_prepare
+}
+
src_configure() {
local mycmakeargs=(
"-DBoost_USE_STATIC_LIBS=off"
HTH,
-dnh
--
| Ceci n'est pas une pipe
Re: [gentoo-dev] Last rites: dev-python/epydoc
Michal, ...
On Wed, 29 Jan 2020, Michal Górny wrote:
># Michal Górny (2020-01-29)
># Abandoned in 2009. Python 2 only. No blockers left.
># Removal in 30 days. Bug #706218.
>dev-python/epydoc
... I think you're getting a liiittle bit trigger happy there ...
# equery d dev-python/epydoc
* These packages depend on dev-python/epydoc:
sys-apps/portage-2.3.86 (python_targets_python2_7 ?
>=dev-python/epydoc-2.0[python_targets_python2_7(-)?,-python_single_target_python2_7(-)])
$ cd /usr/portage/sys-apps/portage
$ grep epydoc portage-2.3.86.ebuild
IUSE="build doc epydoc gentoo-dev +ipc +native-extensions +rsync-verify selinux
xattr"
epydoc? (
>=dev-python/epydoc-2.0[${PYTHON_USEDEP}]
REQUIRED_USE="epydoc? ( $(python_gen_useflags 'python2*') )"
use epydoc && DISTUTILS_ALL_SUBPHASE_IMPLS=( python2.7 )
use epydoc && targets+=( epydoc )
use epydoc && targets+=(
install_epydoc
... and thats the fricking bleeding edge unstable portage, mind!
Stable 2.3.84-r1 looks almost identical when grepped ...
BTW: has it been taken note of that (at least ESR) Mozillen like
firefox still use python2.7 for quite a bit in the build process?
-dnh
--
3rd Law of Computing:
Anything that can go wr
fortune: Segmentation violation -- Core dumped
-- from a post by Simon Cozens
Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?
Hello, On Mon, 28 Dec 2020, Michal Górny wrote: >The only problem that I can think of are packages that depend >on libressl specifically and do not support openssl. I don't think we >have anything like that but I'll double check. A naive check finds these: Depends unconditionally on dev-libs/libressl: app-crypt/acme-client Depends conditionally on only dev-libs/libressl (no openssl alternative): net-misc/s6-networking net-misc/openntpd HTH, -dnh -- New, from IKEA: DARCKENSE, the chair. Available in white only. All-natural materials! -- Niklas Karlsson
