[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog

[Samuli Suominen]

On 02/03/13 18:02, Doug Goldstein (cardoe) wrote:
> cardoe 13/03/02 16:02:57
>
> Modified: nvidia-drivers-313.18.ebuild ChangeLog
> Log:
> Revert non-maintainer changes per bug #447566.
>
> (Portage version: 2.1.11.52/cvs/Linux x86_64, signed Manifest commit with key D7DFA8D318FA9AEF!)
>
> Revision Changes Path
> 1.6 x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild
>
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?rev=1.6&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild?r1=1.5&r2=1.6
>
> Index: nvidia-drivers-313.18.ebuild
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -r1.5 -r1.6
> --- nvidia-drivers-313.18.ebuild 2 Mar 2013 11:30:39 -0000 1.5
> +++ nvidia-drivers-313.18.ebuild 2 Mar 2013 16:02:57 -0000 1.6
> @@ -1,6 +1,6 @@
> # Copyright 1999-2013 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> -# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v 1.5 2013/03/02 11:30:39 ssuominen Exp $
> +# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/nvidia-drivers-313.18.ebuild,v 1.6 2013/03/02 16:02:57 cardoe Exp $
>
> EAPI=5
>
> @@ -156,9 +156,6 @@
> epatch "${FILESDIR}"/nvidia-drivers-pax-usercopy.patch
> fi
>
> - epatch "${FILESDIR}"/${PN}-313.18-builddir-config.patch
> - epatch "${FILESDIR}"/${PN}-313.18-linux-3.{7,8}+.patch #447566
> -
> # Allow user patches so they can support RC kernels and whatever else
> epatch_user
> }
>
>
>
> 1.427 x11-drivers/nvidia-drivers/ChangeLog
>
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?rev=1.427&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog?r1=1.426&r2=1.427
>
> Index: ChangeLog
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v
> retrieving revision 1.426
> retrieving revision 1.427
> diff -u -r1.426 -r1.427
> --- ChangeLog 2 Mar 2013 11:30:39 -0000 1.426
> +++ ChangeLog 2 Mar 2013 16:02:57 -0000 1.427
> @@ -1,6 +1,12 @@
> # ChangeLog for x11-drivers/nvidia-drivers
> # Copyright 1999-2013 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v 1.426 2013/03/02 11:30:39 ssuominen Exp $
> +# $Header: /var/cvsroot/gentoo-x86/x11-drivers/nvidia-drivers/ChangeLog,v 1.427 2013/03/02 16:02:57 cardoe Exp $
> +
> + 02 Mar 2013; Doug Goldstein <car...@gentoo.org>
> + -files/nvidia-drivers-313.18-builddir-config.patch,
> + -files/nvidia-drivers-313.18-linux-3.7+.patch,
> + -files/nvidia-drivers-313.18-linux-3.8+.patch, nvidia-drivers-313.18.ebuild:
> + Revert non-maintainer changes per bug #447566.
>
> 02 Mar 2013; Samuli Suominen <ssuo...@gentoo.org>
> nvidia-drivers-313.18.ebuild, +files/nvidia-drivers-313.18-linux-3.8+.patch:

There was no reason for this commit and for reverting you have to
justify your commit in technical terms.

I'll wait for your reply before restoring the patches in the ebuild.

- Samuli

[Alec Warner]

There was a big ole' chat on #gentoo-dev regarding this. My
understanding of the summary is that the nvidia-driver Gentoo team
only supports kernels that nvidia themselves (upstream) support. The
Kernels > 3.4 are not supported by upstream, so they are also not
supported in Gentoo. I believe the ebuild contains instructions on
using user_patches to get these patches. The nvidia maintainers in
Gentoo do not want to be responsible for those patches though; this is
why they are not included (and why your commit was reverted.)

I do not find their stance wholly unreasonable. They offered to point
users at an overlay, if someone was willing to maintain the patches
there (in lieu of user_patches.) The end result is that if users apply
the patches, they will get an unsupported setup. There is a fear as
well, that the patches may damage cards (since the patches are not
supported by the vendor.)

-A

>
> - Samuli
>
>

[Samuli Suominen]

We have discussed this before,

21 Mar 2012; Samuli Suominen <ssuo...@gentoo.org>
nvidia-drivers-295.20-r1.ebuild:
Fix building with Linux 3.3.x wrt #408841

and agreed when the change is only trivial, like adding -I flag for
missing include, a change that doesn't change API/ABI, it's fine to add
to the ebuild

Apparently Cardoe doesn't remember this discussion. I do and well.

And full stop :)

- Samuli

[Tom Wijsman]

On Sat, 2 Mar 2013 23:11:44 -0800
Alec Warner <ant...@gentoo.org> wrote:

> My understanding of the summary is that the nvidia-driver Gentoo team
> only supports kernels that nvidia themselves (upstream) support. The
> Kernels > 3.4 are not supported by upstream, so they are also not
> supported in Gentoo.

There is no official public statements on this as far as I know,
therefore we resort back to the statement as listed in the minimum
requirements of their latest driver release:

All official stable kernel releases from 2.4.22 and up are
supported; "prerelease" versions such as "2.6.23-rc1" are not
supported, nor are development series kernels such as 2.3.x or
2.5.x.

http://us.download.nvidia.com/XFree86/Linux-x86/313.18/README/minimumrequirements.html

Yes, you see that correctly, they have no upper bound on it; they don't
define stable either so it is to interpreted as per http://kernel.org.

Perhaps they should set an upper limit and explicitly check for that in
the setup; they either keep up with it or acknowledge that they
can't, but this intermediate phase that users across all
distributions have to figure out is just silly.

But well, maybe it is 'cause they haven't released a new version lately.

313.09 - December 12, 2012
313.18 - January 16, 2013

http://www.nvidia.com/object/linux_display_archive.html

There used to do a monthly release, but February has been quiet.


With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address : Tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

[hasufell]

On 03/03/2013 08:11 AM, Alec Warner wrote:
>
> There was a big ole' chat on #gentoo-dev regarding this. My
> understanding of the summary is that the nvidia-driver Gentoo team
> only supports kernels that nvidia themselves (upstream) support. The
> Kernels > 3.4 are not supported by upstream, so they are also not
> supported in Gentoo. I believe the ebuild contains instructions on
> using user_patches to get these patches. The nvidia maintainers in
> Gentoo do not want to be responsible for those patches though; this is
> why they are not included (and why your commit was reverted.)
>
> I do not find their stance wholly unreasonable. They offered to point
> users at an overlay, if someone was willing to maintain the patches
> there (in lieu of user_patches.) The end result is that if users apply
> the patches, they will get an unsupported setup. There is a fear as
> well, that the patches may damage cards (since the patches are not
> supported by the vendor.)

What do we have useflags for in gentoo?

add a "unsupported-kernels" useflag, mask it, add a clear statement in
the masking reason and be done

[Carlos Silva]

On Sun, Mar 3, 2013 at 1:42 PM, hasufell <hasu...@gentoo.org> wrote:

What do we have useflags for in gentoo?

add a "unsupported-kernels" useflag, mask it, add a clear statement in
the masking reason and be done

Not a bad solution, still, I, as a user, don't think making the compilation work with a specific kernel should be considered "unsupported". How many times modules stop working because the kernel changed something that breakes compilation? And I'm not only talking  about closed source drivers, even open source ones have this "problem", but in fact, they are fixed faster.

Does the gentoo community really need this kind of strictness? Don't think so.

[Alec Warner]

So I'm going to get a bit meta here, forgive me ;)

Currently the project more or less functions on herd and maintainer
'ownership.' Ownership of problems tends to be good in many cases. It
is clear who is responsible, we know who to contact to fix bugs and
ask questions of. This does lead to disagreements (such as this
thread.) Some developers want these patches and the package
maintainers disagree. In the current scheme, the package maintainer
always wins. This is the downside to ownership, ownership implies
control and responsibility. The package maintainers are against these
patches, they do not want to own them, and they do not want the
associated responsibility of users using them.

I don't even necessarily mind Samuli's commit (ask for forgiveness,
not permission), but I would mind if he put the patches back. The
package maintainer has spoken out about why they dislike the patches
and you should respect their opinion. The maintainers in this case
suggested an overlay, and they even offered point users to it.

This is the system we have; if you think it sucks (and it does,
sometimes) please propose something better.

-A

[Ryan Hill]

On Sun, 03 Mar 2013 15:42:56 +0100
hasufell <hasu...@gentoo.org> wrote:

> What do we have useflags for in gentoo?

Not for conditional patching, that's for sure.

> add a "unsupported-kernels" useflag, mask it, add a clear statement in
> the masking reason and be done

If the description of the flag you're adding could be paraphrased to be
"enable this or nothing works" then you really shouldn't be allowed within 10
feet of any system with a tree checkout on it. 30 feet if you're also
suggesting it should be disabled by default.


--
gcc-porting
toolchain, wxwidgets learn a language baby, it's that kind of place
@ gentoo.org where low card is hunger and high card is taste

[Ryan Hill]

On Sat, 2 Mar 2013 23:11:44 -0800
Alec Warner <ant...@gentoo.org> wrote:

> I do not find their stance wholly unreasonable. They offered to point
> users at an overlay, if someone was willing to maintain the patches
> there (in lieu of user_patches.) The end result is that if users apply
> the patches, they will get an unsupported setup. There is a fear as
> well, that the patches may damage cards (since the patches are not
> supported by the vendor.)

We're talking about updating an include path here. Some files moved. I don't
think that justifies breaking stable.

[Carlos Silva]

On Sun, Mar 3, 2013 at 4:39 PM, Ryan Hill <dirt...@gentoo.org> wrote:

On Sat, 2 Mar 2013 23:11:44 -0800
Alec Warner <ant...@gentoo.org> wrote:

> I do not find their stance wholly unreasonable. They offered to point
> users at an overlay, if someone was willing to maintain the patches
> there (in lieu of user_patches.) The end result is that if users apply
> the patches, they will get an unsupported setup. There is a fear as
> well, that the patches may damage cards (since the patches are not
> supported by the vendor.)

We're talking about updating an include path here.  Some files moved.  I don't
think that justifies breaking stable.

Exactly my point. This a simple "make-it-compile-without-any-new-stuff", not "add-this-cool-new-feature-to-the-package" patch. There are differences in them...

Again, it's just me, and i don't complain if the maintainer doesn't wan't to accept the patch, i'm just expressing my opinion.

[Chí-Thanh Christopher Nguyễn]

Ryan Hill schrieb:

> On Sun, 03 Mar 2013 15:42:56 +0100
> hasufell <hasu...@gentoo.org> wrote:
>
>> What do we have useflags for in gentoo?
>
> Not for conditional patching, that's for sure.

USE="vanilla" already controls conditional patching for around two dozen
packages.

>> add a "unsupported-kernels" useflag, mask it, add a clear statement in
>> the masking reason and be done
>
> If the description of the flag you're adding could be paraphrased to be
> "enable this or nothing works" then you really shouldn't be allowed
within 10
> feet of any system with a tree checkout on it. 30 feet if you're also
> suggesting it should be disabled by default.

Not that I care about nvidia-drivers, but how about "Increase kernel
compatibility at the cost of a supportable system".


Best regards,
Chí-Thanh Christopher Nguyễn

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2013 06:24 PM, Ryan Hill wrote:
> On Sun, 03 Mar 2013 15:42:56 +0100 hasufell <hasu...@gentoo.org>
> wrote:
>
>> What do we have useflags for in gentoo?
>
> Not for conditional patching, that's for sure.
>

That simply diverges from reality.

# qgrep epatch | grep 'use\ ' | wc -l
476

Since conditional seds are practically the same...

# qgrep ' sed ' | grep 'use\ ' | wc -l
447

And those are just lazy greps not catching if else foo syntax.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRM8koAAoJEFpvPKfnPDWzPbQH/1dNTVcmdCoZY4pcmjbwA8BB
qY79pWRTLF0/aMi99VZJOil2XPtWQ3Jgyx+CZLsqxhGmCIwx66hdyY5oV7+117zE
MGqsTMvGCUzxpKUbvEpvJt7/P7g+QwlzAIhEOezGEOfnD8gW4tVdokLqoYxPcaMz
tNBh9ybuVENx9EhSfPwokkLT8Ir1UfPhqPcAWlrpxD1ATgUyJHrZXtPZDh1nEbAo
9hL4vgEDPhlQBL4dZyfzYNgFzQrudnphslYZZNJsPuozlyouAHnIVP7EbPJ2fLAY
eTI7JJii1coGGSoTMGu4fbvnRx4EZNcAImwoEgXIZY28oLLu8wrbtW8Ne8aP72M=
=W6be
-----END PGP SIGNATURE-----

[Ryan Hill]

On Sun, 03 Mar 2013 23:05:28 +0100
hasufell <hasu...@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/03/2013 06:24 PM, Ryan Hill wrote:
> > On Sun, 03 Mar 2013 15:42:56 +0100 hasufell <hasu...@gentoo.org>
> > wrote:
> >
> >> What do we have useflags for in gentoo?
> >
> > Not for conditional patching, that's for sure.
> >
>
> That simply diverges from reality.
>
> # qgrep epatch | grep 'use\ ' | wc -l
> 476
>
> Since conditional seds are practically the same...
>
> # qgrep ' sed ' | grep 'use\ ' | wc -l
> 447
>
> And those are just lazy greps not catching if else foo syntax.

Sometimes it's unavoidable. Sometimes people don't think before they do
something. If the patch makes a fundamental change in the package that can't
be controlled another way (say --configure flags or defines) then, yes, you may
have to use conditional patching. I'm thinking of something like infinality or
x32 support. In both those cases we're adding a feature, not making a bug
fix. That's an important distinction. USE flags exist to give the user a
choice between A and B. If choice A is "package doesn't build" then there's
really no choice at all. You've just added a new way for a package to fail. We
already have plenty of those. Please don't add more.

[Nikos Chantziaras]

On 03/03/13 09:11, Alec Warner wrote:

> [...] My understanding of the summary is that the nvidia-driver

> Gentoo team only supports kernels that nvidia themselves (upstream)
> support. The Kernels > 3.4 are not supported by upstream, so they

> are also not supported in Gentoo. [...] There is a fear as well, that

> the patches may damage cards (since the patches are not supported by
> the vendor.)

Is there any communication with NVidia about this? They have a Linux
developers forum:

https://devtalk.nvidia.com/default/board/98/linux

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/2013 12:24 PM, Ryan Hill wrote:
> On Sun, 03 Mar 2013 15:42:56 +0100 hasufell <hasu...@gentoo.org>
> wrote:
>
>> What do we have useflags for in gentoo?
>
> Not for conditional patching, that's for sure.
>
>> add a "unsupported-kernels" useflag, mask it, add a clear
>> statement in the masking reason and be done
>
> If the description of the flag you're adding could be paraphrased
> to be "enable this or nothing works" then you really shouldn't be
> allowed within 10 feet of any system with a tree checkout on it.
> 30 feet if you're also suggesting it should be disabled by
> default.
>
>

++

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRNBiFAAoJEKXdFCfdEflKBk0P/0KayZkgo6tiQr+jRctZh4Bh
fNOGh1noj+4nrAV7tLmWTOALf1fKoEkcuxXiC65xpk3uMeMOKz7AwrQp7Fp7DskX
dZTC5LH1c1lqtlsFmhWH2pcwqiNiJx0iOtErMuJQFBW5f2ndh4WUiFAVS1ltIFNk
I18eqQ+ZjArag19L9LcpgC4WDzEEY/ZdMZ3PKtSWcer5gN0m1nh2eA8fhG92sQKn
WPZX1UfVEG8aywHY5MJeMDRjHJYPNbo88mU+CVe8c6eL33op1AWxY/8AZP281EsG
rdILERCaX9DnGUeqZbAc7Awhyiz7pHgeYzHVj72tEprfGtMTjgXvOpjQBSf/q0xm
3r6r6gGo4rm8RB7wxsEwsBIPoRC3p/nyZgmqYpqawOjYF8jqMq51T9kVde2IVThy
tKJE4a+Dzyx6Ebhl+IGTW6gUxQZM630+4yq+ClzmP8/g+b4+cvxhPvnZoUu7KCKi
RpQlc4H6LcywL1OdLxYUdyc/Zexq89iXBxs3R3kXID2wFlBWjA9zCM8i7BouG/jA
eUv3mGPcyQtjjliphmlPKsh/+TkxPGSnv1El7oNsdtJIR1kXDbAQ7BieLSvIrW0M
yxbk8P0iv1DM/3X4kIaQT2iltd01NJKKiIFiVAp51bICZuEcanU8EuatZ/WTwFcu
3RY+YNzewyGPBE5reN8c
=A5Db
-----END PGP SIGNATURE-----

[Samuli Suominen]

IUSE="+vanilla" with the + if the maintainer wants should cover all the
issues brought up so far

- Samuli

[Samuli Suominen]

On 03/03/13 19:24, Ryan Hill wrote:
> On Sun, 03 Mar 2013 15:42:56 +0100
> hasufell <hasu...@gentoo.org> wrote:
>
>> What do we have useflags for in gentoo?
>
> Not for conditional patching, that's for sure.

Yet that is exactly what IUSE=vanilla is designed for... ;-)

[Ryan Hill]

Yeah yeah. I'm not always right but I reserve the right to be loudly wrong.

:p