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