#37 Add NVidia binary driver as 3rd party repository
Closed 6 years ago Opened 6 years ago by uraeus.

Name of application: NVidia binary driver
Description of Application: This is the binary driver offered by NVidia for Linux users. It is a requirement for various applications and provides the best performance for users with NVidia hardware. Thanks to the work done on glvnd we can now offer it without package conflicts with Mesa.

Type of repository: RPM

URL for repository: https://negativo17.org/nvidia-driver/

License for application submitted: Proprietary - http://www.nvidia.com/object/nv_sw_license.html

Is packager application owner or developer? No, this is a external repo hosted by a Fedora community member. Discussions are happening with NVidia for them to offer hosting, but we don't want to block on that.

If not owner or developer do you have permission to package this either through license terms or directly from owner? Yes, NVidia are explicitly allowing linux redistribution in 2.1.2 of their license.

Is there a group of people maintaining this repository? No, currently negativo is a one man operation run by Simone Carronni.

If you are a single person behind repository what are you contingency plan in case you are unavailable or lose interest or have an accident? We are looking at various medium to long term options here, including some semi official repository from NVidia. In the meantime Simone has dutifully maintained his repositories for years and been very open to feedback and change requests to how his packages are packaged.

How do we contact you in case there are problems? negativo17@gmail.com


We don't want this repo at all. It comes from a person that is know to conflicting content to our 3rd party repository.

RPM Fusion repository for the long time the packaging method used by the upstream NVIDIA repository for Fedora and RHEL:
https://developer.nvidia.com/cuda-downloads

Further we have worked to conformant single feature repo
http://download1.rpmfusion.org/free/fedora/drivers/
http://download1.rpmfusion.org/nonfree/fedora/drivers/

Theses are way better and community handled content.

Who is 'we' here ? 'We' as in the desktop team worked with that person, and we do want that repo...

As stated in several places, there is no way for this repository to scale.

Who is 'we' here ? 'We' as in the desktop team worked with that person, and we do want that repo...

I mean "we" as the whole Fedora/RHEL community. Please Community weight on that fact!
I even mean "we" a lot people working for Red Hat.

mclasen and yet the Desktop Team has not been in the #fedora channel to deal with people with issues coming from using this repo. The rpmfusion maintainers have been around longer and are maintainers for other fedora packages. Rpmfusion Maintainers help in the #fedora channel to help endusers with issues whereas negativo does not. As a member of the IRC Support Sig i consider this something that will not scale and should be avoided.

Did anyone bother asking Simone if it was ok to use his repo or if he intends to continue packaging nvidia driver?

@slaanesh

Maybe this would be better discussed on a mailing list, but I'd just like to add here that I think it is unfortunate that the third-party repository ecosystem on Fedora is slowly splintering again into competing repositories, and I think this should be avoided if possible.

My understanding is that Workstation wanted to use the negativo17 nvidia driver repository because Fedora policy made it impossible to pull in all of RPM Fusion. This made sense, but now that RPM Fusion is working to provide a repository containing the nvidia driver that is compatible with the third-party repository policy, I would encourage a revisit of this plan.

My two cents as a community member (and contributor to both Fedora and RPM Fusion).

So, I've been looking around for an answer to this question and have failed to find it: Will this be enabled/installed by default? I do very much like the idea of the option for the proprietary driver, especially if it is done cleanly, but I do not like the idea of encouraging it as the driver everyone should use, regardless of better performance.

I don't like the idea of using any future NVIDIA-provided repository. I naturally trust them less to make Fedora packaging than the people experienced in Fedora packaging, especially since any decision they make will immediately impact all users with the repository enabled, without going through review by Fedora packagers.

It seems more sensible to use RPMFusion's repository for this, especially now that they've separated the driver form their main/everything repo. They're more closely related to the community and aspires to follow Fedora's own packaging standards, as far as I understand. They seem to do a good job.

So, I've been looking around for an answer to this question and have failed to find it: Will this be enabled/installed by default?
The way it will work is that once you choose enable 3rd party repositories it will show up in GNOME Software. The 3rd party repos will be downloaded onto the system when you say yes to 3rd party systems.

We don't want this repo at all. It comes from a person that is know to conflicting content to our 3rd party repository.
RPM Fusion repository for the long time the packaging method used by the upstream NVIDIA repository for Fedora and RHEL:
https://developer.nvidia.com/cuda-downloads
Further we have worked to conformant single feature repo
http://download1.rpmfusion.org/free/fedora/drivers/
http://download1.rpmfusion.org/nonfree/fedora/drivers/
Theses are way better and community handled content.

Ok, if all issues are resolved now then we should re-open that discussion, but the last update I got from Hans was that there seemed to be mostly negativity and hostility to the requested repository setup from rpmfusion.

https://youtu.be/IF2FEeOdmFE has a screencast how it works in gnome-software

The way it will work is that once you choose enable 3rd party repositories it will show up in GNOME Software. The 3rd party repos will be downloaded onto the system when you say yes to 3rd party systems.

So Workstation will not ship with the proprietary NVIDIA driver installed? Very good; I appreciate this.

The way it will work is that once you choose enable 3rd party repositories it will show up in GNOME Software. The 3rd party repos will be downloaded onto the system when you say yes to 3rd party systems.

So Workstation will not ship with the proprietary NVIDIA driver installed? Very good; I appreciate this.
That is correct

Did anyone bother asking Simone if it was ok to use his repo or if he intends to continue packaging nvidia driver?
@slaanesh

Yes, I spoke to Simone just a week ago about it

Did anyone bother asking Simone if it was ok to use his repo or if he intends to continue packaging nvidia driver?
@slaanesh

Yes, I spoke to Simone just a week ago about it

Three weeks ago he said.

"I'm just writing to inform you that in the last month I informed Christian and Hans that making the negativo17.org repository the default has a lot of implications for people also running RPMFusion and that I'm suggesting to use the RPMFusion driver repository as the default."

Did anyone bother asking Simone if it was ok to use his repo or if he intends to continue packaging nvidia driver?
@slaanesh
Yes, I spoke to Simone just a week ago about it

Three weeks ago he said.
"I'm just writing to inform you that in the last month I informed Christian and Hans that making the negativo17.org repository the default has a lot of implications for people also running RPMFusion and that I'm suggesting to use the RPMFusion driver repository as the default."

Well I just sent Simone an email asking him to respond here and if possible clear this up. Maybe just some miscommunication/misunderstanding somewhere.

Um wow, switching from Negativo to RPMFusion would be a major change in gameplan....

@spot, would use of an RPMFusion repo to provide the NVIDIA driver be approved by legal if the repo contains only the NVIDIA package?

I removed one comment here because it did not seem very friendly.

I presume it should be well-understood that adding third-party repositories requires legal review. I know that's not fun for anybody, but that's the world we live in. To consider using RPMFusion as the source for the NVIDIA driver, the working group first needs to see that it has been approved by Fedora legal. Due to the nature of other software distributed by RPMFusion in other repositories, I was personally working under the assumption that nothing from RPMFusion could ever be considered, and I assume the rest of the working group has been as well. If that's not true, then I'm sure @spot will correct us.

Now, onto the technical issues. The working group had been informed (a while back, a year or two ago) that the Negativo package is of higher technical quality than the RPMFusion package. In particular, it's our understanding that, when a kernel upgrade is incompatible with the NVIDIA driver, the Negativo package ensures graceful fallback to noveau. We have not been previously-informed of any problems with the Negativo packaging, and I was not aware that users in #fedora are having problems with it. @jbwillia, @kwizart, can you help us understand some of the problems you've noticed here? Can you please provide some further detail as to why we should consider the RPMFusion packaging instead? What are the technical differences between the two packages? Does graceful fallback to noveau work properly with the RPMFusion package?

You mention that you've worked to ensure the repository contains a single feature, and I see the repo is named "drivers." But my understanding was that we are only allowed to consider repositories that contain just a single package. Am I wrong about that? If not, it seems a repository named "drivers" would clearly not be appropriate; are there plans to create a separate repository just for the NVIDIA driver?

None of the above is going to matter without legal approval. If the RPMFusion repository is technically superior, but we fail to receive legal approval for it, as seems likely, would you be willing to help the Negativo maintainer improve its packaging instead?

I removed one comment here because it did not seem very friendly.
I presume it should be well-understood that adding third-party repositories requires legal review. I know that's not fun for anybody, but that's the world we live in. To consider using RPMFusion as the source for the NVIDIA driver, the working group first needs to see that it has been approved by Fedora legal. Due to the nature of other software distributed by RPMFusion in other repositories, I was personally working under the assumption that nothing from RPMFusion could ever be considered, and I assume the rest of the working group has been as well. If that's not true, then I'm sure @spot will correct us.

What does it matter what other packages rpmfusion ships in the non-driver repo, perhaps legal should compare negativo and rpmfusion ffmpeg and see which is even distributable.

Now, onto the technical issues. The working group had been informed (a while back, a year or two ago) that the Negativo package is of higher technical quality than the RPMFusion package. In particular, it's our understanding that, when a kernel upgrade is incompatible with the NVIDIA driver, the Negativo package ensures graceful fallback to noveau. We have not been previously-informed of any problems with the Negativo packaging, and I was not aware that users in #fedora are having problems with it. @jbwillia, @kwizart, can you help us understand some of the problems you've noticed here? Can you please provide some further detail as to why we should consider the RPMFusion packaging instead? What are the technical differences between the two packages? Does graceful fallback to noveau work properly with the RPMFusion package?

Rpmfusion driver has the same nouveau fallback.
I believe rpmfusion driver has better optimus support due to modeset being enabled, we have also addressed the incompatibility this cause GDM/mutter

https://pkgs.rpmfusion.org/cgit/nonfree/xorg-x11-drv-nvidia.git/commit/?id=679fb78bdd277f1f51c4f79778d982776aea3b73

None of the above is going to matter without legal approval. If the RPMFusion repository is technically superior, but we fail to receive legal approval for it, as seems likely, would you be willing to help the Negativo maintainer improve its packaging instead?

I can forward kernel patches but don't think I will have much spare time to help due to my existing workload.

Three weeks ago he said.
"I'm just writing to inform you that in the last month I informed Christian and Hans that making the negativo17.org repository the default has a lot of implications for people also running RPMFusion and that I'm suggesting to use the RPMFusion driver repository as the default."

Exactly. The outcome of the previous iteration of communications was that there would have been no separate repository for Nvidia stuff in RPMFusion. Now there is one, so I suggested Christian which did not know about it to take a look.

I have no plan to retire the repositories (I am actually paid a bit to keep them updated) but I'm not advocating one solution or the other, nor I'm pushing this anywhere. I have better things to do in life.

As it has been said already, I am healthy (fingers crossed), but I am a one man show.

I have no plan to retire the repositories (I am actually paid a bit to keep them updated) but I'm not advocating one solution or the other, nor I'm pushing this anywhere. I have better things to do in life.

I agree.
Both solutions are very similar to each other, the only negative I see with your repo is the lack/absence of mirrors .

But my understanding was that we are only allowed to consider repositories that contain just a single package. Am I wrong about that? If not, it seems a repository named "drivers" would clearly not be appropriate; are there plans to create a separate repository just for the NVIDIA driver?

Yes, that is the legal guidance we've been working under here.

If you look at the other issues filed yesterday, there was already a suggestion to add steam to the drivers repo. So... not what we need.

I want to comment on and clear up the 'legal issues' here as I think there are some wrong assumptions being made. First of all there are no legal issues with any of the software discussed here, neither the NVidia binary driver or Steam. If there where we would most likely not be having this discussion. There is no absolute ban on repositories with multiple applications either, they are just strongly discouraged for a variety of reasons, some rooted in mitigating potential future legal concerns.

So the 3rd party policy states various preferences which are based on discussions with legal about how to limit the legal risks posed by 3rd party software to an acceptable level. Some of those preferences are based on trying to mimic the mitigation abilities we have in Fedora itself. For example if legal at any point in time deems a given package in Fedora pose to high legal risk to continue carrying they can call Matthew Miller and he has the ability to get that package pulled from Fedora right away. Having that ability in place is important as part of a risk mitigation plan, even though as far as I know Matthew has not so far had to ever exercise that power during his tenure as Fedora Project lead.

So once we add 3rd party software we of course give up a bit of the control compared to what we currently have in Fedora. And the policies we put forward is thus created to try to find comprises between mitigation potential legal or other risks and technical problems we need to resolve.

So for instance the policy do not absolutely ban multi-application repositories, it discourages their use because they bring with them a lot of extra considerations like for instance if we are ever put in the position where we (as in Fedora/Fedora Workstation) need to stop making something available from a 3rd party repository I think we all agree that it would be good to avoid collateral damage, meaning that just because we had to for example pull the Steam client due to a hypothetical legal concern we also stopped people from getting their NVidia driver security updates. Multi-app repositories would also get a lot more formal requirements put on them by us before we could include them including having written policies in place regulating what could be added to the repository and/or be backed by a legal entity with enough money to be a legal shield for us.

But this is a case of weighing a lot of tradeoffs against each other. For instance Steam is of course by its nature a multi-application repository. But a combination of knowing that Valve has clear rules and governance on what they ship and how things will be removed helps a lot, but even more crucial here is the fact they they are a well funded legal entity owning Steam mitigates the risks for including it for us. The last item is of course something community repositories doesn't have and thus we have to look at other ways to mitigate the risks they pose, just as we have rules on packages in Fedora to mitigate the risk any software we ship pose, which the single package repository is among other things part of.

So yes we could in theory include a multi-application repository run by community members, but the policy preference is towards the single-application repositories as they are easier to evaluate the risk of and monitor.

I would feel a lot more comfortable from a Fedora Legal perspective if we stuck to single package repositories for the purposes of simplifying user enablement of non-free software components in Fedora. It goes a long way to mitigating the potential risk of additional packages showing up in those repositories outside of our direct control.

I agree. I also think it should be noted that some organizations mandate their own reviews of software repositories before adopting the usage of any of the packages within. An arbitrary repository containing various third party packages would be harder to review and accept than a single-scoped repository like the proposed NVIDIA-only repository.

So, again, just giving my 0.02 as a Fedora and RPM Fusion contributor:

I understand why Fedora (and maybe some organizations using Fedora) would prefer to reference single-repository third party packages. But, it seems like we should be able to come up with some way to do so that leverages the RPM Fusion package collection and doesn't create a huge duplication of effort.

Worse, it won't just create a duplication of effort, it will make it harder for people using the Workstation-referenced repositories to get other packages that are maintained in RPM Fusion. I guess the default answer is probably "we don't care about arbitrary third party repositories that aren't being included via the policy"... but I think this would be an unhelpful attitude to take when we are trying to find an easier way to include and reference third-party repositories.

So, again, just giving my 0.02 as a Fedora and RPM Fusion contributor:
I understand why Fedora (and maybe some organizations using Fedora) would prefer to reference > single-repository third party packages. But, it seems like we should be able to come up with some
way to do so that leverages the RPM Fusion package collection and doesn't create a huge
duplication of effort.
I agree and as far as I understood there was an agreement negotiated by Hans de Goede to use rpmfusion some time ago, which also Simone signed off on, but it fell apart as rpmfusion afterwards decided they did not want to provide single application repos afterall. Apologize if my recollection here is wrong, but that is currently my view of what happened.

My take is that I don't want to block on rpmfusion here to add this for F28, we already spent years between engineering work and getting agreement on a policy for handling these things. That said having a team based organization owning it is always better than a single person so if we at some point do get a single app repo here that we can be assured will not have stuff added to it, then I am more than open to switching over to that. It is also worth nothing here that there are ongoing discussions with NVidia and if it can be done having a NVidia hosted repository would beat out any other option, be that negativo or rpmfusion.

Worse, it won't just create a duplication of effort, it will make it harder for people using the
Workstation-referenced repositories to get other packages that are maintained in RPM Fusion. I
guess the default answer is probably "we don't care about arbitrary third party repositories that
aren't being included via the policy"... but I think this would be an unhelpful attitude to take when
we are trying to find an easier way to include and reference third-party repositories.

Well my hope and expectation is that as the list of 'official' third party packages grow then any other 3rd party repositories tries to ensure as far as possible to not conflict with those, just like they do with packages shipped inside the Fedora repositories.

Well, there are lot of comments and not so much time to answer.

Right now the free and nonfree drivers repositories only consumer is expected to be the workstation SIG.
So you can make make use of it as you like. If you wish to have more that one driver, fair enough. If you want to have more than one, but keep at a given version, then good to go. But please engage with us.
Currently the free-fedora-drivers only has libva-intel-driver
the nonfree-fedora-drivers only has the nvidia driver.

Of course it's easier to have to deal with one repository than many, specially as adding too many repositories have a cost on users dnf speed.

I hope to have answered most questions. If you have technical issue. Please report to https:/bugzilla.rpmfusion.org on the repository component.

Thx

Looks like at least one user is having trouble with the driver from RPMFusion: https://www.reddit.com/r/Fedora/comments/863x92/nvidia_update_bricks_system_again/

The comments there have me seriously concerned.

Top comment says:

Your system isn't bricked it's just not loading GDM.

which I think is a known issue with the proprietary NVIDIA driver regardless of source. I've also been testing RPMFusion's akmod-nvidia package in the last couple of days on Xfce and have not had much issue.

Looks like at least one user is having trouble with the driver from RPMFusion: https://www.reddit.com/r/Fedora/comments/863x92/nvidia_update_bricks_system_again/
The comments there have me seriously concerned.

Don't blame us for GDM/mutter broken wayland detection (gnome really needs to fix their crap) , nvidia needs modeset enabled for optimus users.
We have addressed GDM failings by disabling wayland with this commit

https://pkgs.rpmfusion.org/cgit/nonfree/xorg-x11-drv-nvidia.git/commit/?id=679fb78bdd277f1f51c4f79778d982776aea3b73

Looks like at least one user is having trouble with the driver from RPMFusion: https://www.reddit.com/r/Fedora/comments/863x92/nvidia_update_bricks_system_again/
The comments there have me seriously concerned.

The same comments about the kmod generation issue equally apply to negativo17 repo akmod package so I don't get the point your trying to make.

Looks like at least one user is having trouble with the driver from RPMFusion: https://www.reddit.com/r/Fedora/comments/863x92/nvidia_update_bricks_system_again/
The comments there have me seriously concerned.

There is not even any evidence that the user rely on any RPM Fusion package. Maybe it was it's initial intend, but something got replaced on his system or he disabled any important service. None can really know. (We don't even know the fedora version used).
Unfortunately, none in the thread was able to point him to the very basic of bug reporting:
https://rpmfusion.org/Howto/NVIDIA#Bug_Report

As soon as the akmods nvidia drivers from RPM Fusion is concerned. The compatibility with gnome-software was assured and validated with the help of Stephen Gallagher report few months ago.

With that said, compatibility with nvidia and future kernel on fedora is still questionable.
@leigh123linux was very good at patching the nvidia kernel until the proper support for any recent kernel lands. But it usually takes time until a proper patch is found and tested (for the nvidia driver itself). Does it means we can have a delay for any future kernel updates from the fedora kernel team ? Is there help to be expected from the Workstation SIG in this area ?
Same if the module fails because of an issue with the fedora kernel side ?
What will be the situation if we (RPM Fusion) have validated an update fixing or mitigating a situation ? Do you want to give an ack before the updates is made into the drivers ? What if the time is too long until you validate the update (and users start breaking) ?

Metadata Update from @catanzaro:
- Issue tagged with: meeting

6 years ago

Metadata Update from @catanzaro:
- Issue status updated to: Closed (was: Open)

6 years ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting

5 years ago

Login to comment on this ticket.

Metadata