Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hi,
Thanks for the detailed explanation of your testing procedure! It is good
to know what is behind a local patched driver, just in case.. :)
Best regards,
Natanael.
On 6 August 2016 at 16:20, David Haller <gen...@dhaller.de> wrote:
> 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, , 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, , 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, , 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, , 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, , 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] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
s/you are commented/you commented/ :) On 6 August 2016 at 12:25, Natanael Olaiz <nol...@gmail.com> wrote: > David, > > 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... > > > Best regards, > Natanael > > > On 6 August 2016 at 04:50, David Haller <gen...@dhaller.de> wrote: > >> Hello, >> >> On Fri, 05 Aug 2016, Mike Gilbert wrote: >> >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz <nol...@gmail.com> 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/baa36d14d8c >> dbf58404267ee2ffd34ea >> 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 Heuer > > >
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
David, 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... Best regards, Natanael On 6 August 2016 at 04:50, David Haller <gen...@dhaller.de> wrote: > Hello, > > On Fri, 05 Aug 2016, Mike Gilbert wrote: > >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz <nol...@gmail.com> 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 Heuer
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Thank you for your explanations! :) Best regards, Natanael. On 6 August 2016 at 04:50, David Haller <gen...@dhaller.de> wrote: > Hello, > > On Fri, 05 Aug 2016, Mike Gilbert wrote: > >On Fri, Aug 5, 2016 at 3:10 PM, Natanael Olaiz <nol...@gmail.com> 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 Heuer
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Yes, thank you. I did the local repository path at the moment. I was
thinking on pushing the patch upstream, but now I read on the ebuild I'm
editing (using the check kernel_is :) ) :
if use kernel_linux && kernel_is ge 4 7; then
ewarn "Gentoo supports kernels which are supported by NVIDIA"
ewarn "which are limited to the following kernels:"
ewarn " wrote:
> On 08/05/2016 02:34 PM, R0b0t1 wrote:
> > On Aug 5, 2016 1:23 PM, "Natanael Olaiz" <nol...@gmail.com
> > <mailto:nol...@gmail.com>> wrote:
> >>
> >> I applied the attached patch unconditionally locally, and it seems to
> > work.
> >> Which is correct way to apply the patch or not depending on the kernel
> > version?
> >>
> >
> > See ebuild, there is a patch phase. Shove it in proper directory. Will
> > need local overlay.
> >
>
> if you are editing the ebuild in a local repo, put your patch in the
> files/ directory. If you want to conditionally patch for kernel 4.7,
> you can test this with "kernel_is" from the linux-info eclass. In that
> conditional block, epatch "${FILESDIR}/nameofyourfile.patch".
>
> Alternatively, use https://wiki.gentoo.org/wiki//etc/portage/patches to
> guide you on adding the patch to the proper place to have the ebuild
> automatically patch (without need for an local repo) for you
> (unconditionally wrt kernel version)
>
> --
> NP-Hardass
>
>
Re: [gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
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.
I see in the linux-info eclass documentation (
https://devmanual.gentoo.org/eclass-reference/linux-info.eclass/index.html)
that I can maybe apply it with a line like this?
kernel_is -ge 4 7 && epatch "${P}."
Best regards,
Natanael.
On 5 August 2016 at 20:34, R0b0t1 <r03...@gmail.com> wrote:
> On Aug 5, 2016 1:23 PM, "Natanael Olaiz" <nol...@gmail.com> wrote:
> >
> > I applied the attached patch unconditionally locally, and it seems to
> work.
> > Which is correct way to apply the patch or not depending on the kernel
> version?
> >
>
> See ebuild, there is a patch phase. Shove it in proper directory. Will
> need local overlay.
>
[gentoo-dev] Patch for nvidia-drivers 367.35-r1 for kernels > 4.7.0
Hi all,
After an update to the kernel 4.7.0, I ran into these problems with
the NVIDIA drivers: http://rglinuxtech.com/?p=1746 :
../home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-uvm/uvm_linux.h:557:13:
error: redefinition of ‘radix_tree_empty’ static bool
radix_tree_empty(struct radix_tree_root
*tree)../home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm/nvidia-drm-gem.c:
In function
‘nvidia_drm_dumb_map_offset’:/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-367.18/kernel/nvidia-drm/nvidia-drm-gem.c:411:33:
error: passing argument 1 of ‘drm_gem_object_lookup’ from incompatible
pointer type [-Werror=incompatible-pointer-types] gem =
drm_gem_object_lookup(dev, file, handle);
I applied the attached patch unconditionally locally, and it seems to work.
Which is correct way to apply the patch or not depending on the kernel version?
Best regards,
Natanael.
diff -ur NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-drm/nvidia-drm-fb.c NVIDIA-Linux-x86_64-367.35/kernel/nvidia-drm/nvidia-drm-fb.c
--- NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-drm/nvidia-drm-fb.c 2016-07-12 06:53:45.0 +0200
+++ NVIDIA-Linux-x86_64-367.35/kernel/nvidia-drm/nvidia-drm-fb.c 2016-08-05 20:10:51.114008113 +0200
@@ -114,7 +114,7 @@
* We don't support any planar format, pick up first buffer only.
*/
-gem = drm_gem_object_lookup(dev, file, cmd->handles[0]);
+gem = drm_gem_object_lookup(file, cmd->handles[0]);
if (gem == NULL)
{
diff -ur NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-drm/nvidia-drm-gem.c NVIDIA-Linux-x86_64-367.35/kernel/nvidia-drm/nvidia-drm-gem.c
--- NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-drm/nvidia-drm-gem.c 2016-07-12 06:53:45.0 +0200
+++ NVIDIA-Linux-x86_64-367.35/kernel/nvidia-drm/nvidia-drm-gem.c 2016-08-05 20:01:41.942998089 +0200
@@ -408,7 +408,7 @@
mutex_lock(>struct_mutex);
-gem = drm_gem_object_lookup(dev, file, handle);
+gem = drm_gem_object_lookup(file, handle);
if (gem == NULL)
{
diff -ur NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-uvm/uvm8_gpu.c NVIDIA-Linux-x86_64-367.35/kernel/nvidia-uvm/uvm8_gpu.c
--- NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-uvm/uvm8_gpu.c 2016-07-12 06:52:17.0 +0200
+++ NVIDIA-Linux-x86_64-367.35/kernel/nvidia-uvm/uvm8_gpu.c 2016-08-05 19:34:51.454968692 +0200
@@ -647,7 +647,7 @@
gpu->id, uvm_gpu_retained_count(gpu));
// All channels should have been removed before the retained count went to 0
-UVM_ASSERT(radix_tree_empty(>instance_ptr_table));
+UVM_ASSERT(NV_radix_tree_empty(>instance_ptr_table));
// Remove the GPU from the table.
uvm_spin_lock_irqsave(_uvm_global.gpu_table_lock);
diff -ur NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-uvm/uvm_linux.h NVIDIA-Linux-x86_64-367.35/kernel/nvidia-uvm/uvm_linux.h
--- NVIDIA-Linux-x86_64-367.35-original/kernel/nvidia-uvm/uvm_linux.h 2016-07-12 06:52:17.0 +0200
+++ NVIDIA-Linux-x86_64-367.35/kernel/nvidia-uvm/uvm_linux.h 2016-08-05 19:34:45.541968585 +0200
@@ -554,7 +554,7 @@
INIT_RADIX_TREE(tree, GFP_NOWAIT);
}
-static bool radix_tree_empty(struct radix_tree_root *tree)
+static bool NV_radix_tree_empty(struct radix_tree_root *tree)
{
void *dummy;
return radix_tree_gang_lookup(tree, , 0, 1) == 0;
[gentoo-dev] Liblo 0.26 wrong ebuild license
It is LGPL, not GPL.
diff -aru liblo_original/liblo-0.26.ebuild liblo/liblo-0.26.ebuild
--- liblo_original/liblo-0.26.ebuild2011-09-12 20:38:28.0
+0200
+++ liblo/liblo-0.26.ebuild 2012-07-02 10:43:29.0
+0200
@@ -8,7 +8,7
@@
HOMEPAGE=http://plugin.org.uk/liblo;
SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz
-LICENSE=GPL-2
+LICENSE=LGPL-2.1
SLOT=0
KEYWORDS=amd64 ppc ppc64 x86 ~ppc-macos
IUSE=doc ipv6 static-libs
Best regards,
Natanael.
Re: [gentoo-dev] Last rites: media-sound/qsampler
Hi, El 05/10/2012 03:07 PM, Ben escribió: On 10 May 2012 05:42, Natanael Olaiz nol...@gmail.com wrote: Hi, Here I attach a version that removes the eclass use. [...] Please check the comments on bug #380589. A new ebuild needs to: - use qt4-r2.eclass and EAPI=4 - be compatible with Qt 4.8.1 - use the QA fixes from bug #379663 Thanks, Ben and Davide for the tips! If someone is willing to do that, then they can contact me (I'm involved with both qt and sound herds) and I will commit the new ebuild and remove the mask. I uploaded to the tracker an ebuild using a specific revision of subversion, that seems to solve the bugs of the tracker. I'm not sure about the name : the commit date is 20120413 , but the about says 0.2.2.33. Does that works? Best regards, Natanael. Cheers, Ben | yngwin Gentoo developer, Qt project lead
Re: [gentoo-dev] Last rites: media-sound/qsampler
Hi,
Here I attach a version that removes the eclass use.
I then replaced a eqmake4 for qmake. I don't know if there is a
better solution, but at least removes the deprecated eclass and
hopefully the mask (the live ebuild is newer).
Best regards,
Natanael.
El 05/02/2012 11:24 PM, Davide Pesavento escribió:
# It has been broken for more than 2 years (bug 380589),
# last upstream release in 2009, uses deprecated qt4 eclass,
# long list of QA issues (bug 379663).
# Masked for removal in 30 days.
media-sound/qsampler
# Copyright 1999-2009 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/media-sound/qsampler/qsampler-0.2.2.ebuild,v
1.1 2009/12/04 19:01:06 aballier Exp $
EAPI=1
DESCRIPTION=A graphical frontend to the LinuxSampler engine
HOMEPAGE=http://www.linuxsampler.org;
SRC_URI=http://download.linuxsampler.org/packages/${P}.tar.gz;
LICENSE=GPL-2
SLOT=0
KEYWORDS=~amd64 ~x86
IUSE=debug +libgig
RDEPEND=x11-libs/qt-gui:4
=media-libs/liblscp-0.5.5
libgig? ( =media-libs/libgig-3.2.1 )
=media-sound/linuxsampler-0.5
media-libs/alsa-lib
DEPEND=${RDEPEND}
src_compile() {
econf $(use_enable debug) \
$(use_enable libgig)
qmake qsampler.pro -o qsampler.mak
emake || die emake failed.
}
src_install() {
emake DESTDIR=${D} install || die emake install failed.
dodoc AUTHORS ChangeLog README TODO
doman debian/${PN}.1
}
[gentoo-dev] eclass history
Hi, Since the last updates, every update I have more and more problems with ebuilds that I use from an authenticated https server. For instance: the first time subversion asks to accept the certificate... but since a time ago the subversion fetch eclass function is non interactive at all, so it fails -have to do the checkout by hand- ; the UUID have some kind of problem that after the first checkout make every update to make a new checkout, etc. I want to debug this, because for me (that have to work with this) is a real PITA My question is : where I can see the history of the eclasses? Some time ago all worked perfect! But with the rsync I have no idea what is going on, I don't know the history (and all local changes are lost each --rsync...) Thanks in advance, Natanael
Re: [gentoo-dev] eclass history
Thanks! On 16 April 2012 12:43, Dirkjan Ochtman d...@gentoo.org wrote: On Mon, Apr 16, 2012 at 12:37, Natanael Olaiz nol...@gmail.com wrote: I want to debug this, because for me (that have to work with this) is a real PITA My question is : where I can see the history of the eclasses? Some time ago all worked perfect! But with the rsync I have no idea what is going on, I don't know the history (and all local changes are lost each --rsync...) Start here: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/subversion.eclass?view=log (Of course, you can also get a checkout via anonymous CVS, but cvs is slow PITA.) Cheers, Dirkjan
Re: [gentoo-dev] Private SVN repository for live-ebuild
Hi, El 01/27/11 18:24, Zac Medico escribió: On 01/27/2011 09:05 AM, Matthew Summers wrote: Now, as to whether to include the value ESVN_PASSWORD in the ebuild, I would not do that. Personally, I would setup svn+ssh and use an ssh key to access the repo. I do this with git using the git eclass. I am prompted for a password/key by portage in this case. To automate this using an ssh key, you can just use a passwordless key or setup ssh-agent. Also note, the key will be sought out first in /root/.ssh (I think it looks there first anyway). In this case, you could potentially have a problem if you have FEATURES=userpriv enabled, since that would cause src_unpack to execute as the portage user. Regarding your final question, I think that portage will ask you to enter the password if it tries to access something over HTTPS requiring authentication, but I am not 100% certain at the moment. In this case, depending on the FETCHCOMMAND behavior, you could have a problem with FEATURES=parallel-fetch since it launches fetches in the background. So, if background fetch doesn't fail gracefully, you might want to set FEATURES=-parallel-fetch in /etc/make.conf. Also, you could set PROPERTIES=interactive in the ebuild, in order ensure that the fetcher is executed in the foreground. Matthew and Zac, thanks a lot for your very informative answers! Best regards, Natanael.
[gentoo-dev] Private SVN repository for live-ebuild
Hi all, I want to make a live-ebuild for a private subversion repository. I see in the developers manual [1] that CVS have the vars ECVS_USER and ECVS_PASS, but cannot found equivalent ones for SVN [2]. Anyone knows what would be the prefered way to do that? Is safe to include the login in the ebuild? Can it have only read permissions to root? And a similar case: a .tar.gz source package which is on a private web URL. What is the best way to download it from the ebuild? Thanks in advance, Natanael. [1] http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/cvs-sources/index.html [2] http://devmanual.gentoo.org/ebuild-writing/functions/src_unpack/svn-sources/index.html
