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 wrote:
> Hello,
>
> On Sat, 06 Aug 2016, Natanael Olaiz wrote:
> >Tha
s/you are commented/you commented/
:)
On 6 August 2016 at 12:25, Natanael Olaiz 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
ike 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:
Thank you for your explanations! :)
Best regards,
Natanael.
On 6 August 2016 at 04:50, David Haller wrote:
> 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 applie
h 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" > <mailto:nol...@gmail.com>> wrote:
> >&
this?
kernel_is -ge 4 7 && epatch "${P}."
Best regards,
Natanael.
On 5 August 2016 at 20:34, R0b0t1 wrote:
> On Aug 5, 2016 1:23 PM, "Natanael Olaiz" wrote:
> >
> > I applied the attached patch unconditionally locally, and it seems to
> work.
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(
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
Hi,
El 05/10/2012 03:07 PM, Ben escribió:
> On 10 May 2012 05:42, Natanael Olaiz 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 EA
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 Pesa
Thanks!
On 16 April 2012 12:43, Dirkjan Ochtman wrote:
> On Mon, Apr 16, 2012 at 12:37, Natanael Olaiz 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?
>
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 f
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
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 eb
14 matches
Mail list logo
