I've made a bug report for moving nvidia-smi here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5308
>If you install steam from flatpak, we cannot know which tools are
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
I don't remember what the error was, I just remember that attempting to launch Proton games(GTA 5) would fail under system Steam but worked under Flatpak Steam. I'll have to reinstall it to see...
>Theses libs are know as soon as the support
Can you rephrase this?
from the "software" application. On regular fedora the
rpmfusion-nonfree-nvidia-driver is selectable from the interface
(don't know about silverblue, but it was intended).
You just have to install the driver by selecting it, so you don't even
have to worry about the gory details of the packaging name.
Just installed Fedora 30 and I'm not seeing anything in Gnome Software despite the repo existing and enabled from within Gnome Software itself(The Nvidia and Steam one that is) besides Gnome 3 extensions for Nvidia. Something is broke if Gnome Software is supposed to allow Nvidia GPU driver installs. Nothing under "add-ons" either which i've seen "hardware-drivers" listed in Arch.
Regardless, that still doesn't install the *whole* Nvidia driver that you would get in Windows or Ubuntu and what a user is probably wanting.
>Nope, It's the default interface to install the driver not the "Core" one.
(and etc)
That doesn't make any sense. If they were installed rpm-ostree would spit out an error saying they where already requested or installed if you where to install those packages step by step...
Could rpm-ostree not be registering that recommended or optional packages are installed and are reinstalling them despite being installed? Pretty sure even if you were to not reboot and keep installing ontop of the same rpm-ostree image it will still resolve for the next image and error out...
>False, it's a dependency of the xorg-x11-drv-nvidia, this is the usual
multilibs split, so it's very much a trivial packaging meme.
multilibs split, so it's very much a trivial packaging meme.
Oh... That's kinda confusing. How is someone to know it includes multiarch without looking into what it provides?
>Wrong, xorg-x11-drv-nvidia-cuda will requires
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
That seems really odd to me. If nvidia-cuda-libs is installed anyway and nvidia-cuda requires it shouldn't it just be merged into the driver package(or its libs?). I take it this is what would happen if nvidia-smi(nvidia-cuda) was merged into the driver package itself or libs right?
On Tue, Jul 9, 2019 at 4:22 AM Nicolas Chauvet <kwizart@xxxxxxxxx> wrote:
Le mar. 9 juil. 2019 à 09:42, Ty Young <youngty1997@xxxxxxxxx> a écrit :
For more clarity, please answer in bugzilla (either as new RFE or the
current report).
> > With that said, the appropriate doc is here:
> > https://rpmfusion.org/Howto/NVIDIA
> > It is only mentioned to install akmod-nvidia and xorg-x11-drv-nvidia
> > that's the interface we rely on. (Everything else should be
> > auto-detected on purpose).
> > Also to wait a few for the module to build and install and reboot
> > (it's explicitly required).
>
>
> That gets you a working driver but not OpenGL or any of the core Nvidia
> driver utils/libs such as nvidia-smi, nvidia-settings, nvidia-xconfig,
> etc. If you try to install Steam for example it will blow up real bad.
If you install steam from flatpak, we cannot know which tools are
needed on the "host" side, so this become a documentation issue.
The "no OpenGL driver" is a situation that cannot arise with the
nvidia packaged driver because we rely default to install it. So it's
more probably a delay between the availability of the nvidia-gl
overlay ?
I'm not sure to understand what you mean here. Unless you mean the
OpenGL.so over the "legacy" libGL.so ?
> >> -nvidia-settings is the Linux alternative to Window's control panel and if not included by default, *should* be included via a "meta" package for desktop users.
> > It's a separate package, but it is required by the drivers as it's
> > mandatory indeed. So I don't understand the metapackage thing, it's a
> > solution for others distros, the Fedora ways is different. (virtual
> > provides , booleans dependencies, etc).
>
>
> If memory serves me correctly nvidia-settings *is* silently installed
> but not explicitly. In other words, you can see and launch the
> application in Gnome 3 without explicitly installing it but doing:
>
>
> rpm-ostree install nvidia-settings
>
>
> Will still work and "install" the package despite it already been
> installed. I'll have to do another reinstall and install just the driver
> to make sure. Could be smoking shrooms here but I remember it being there...
>
>
> I'd like to pose the question though, is this really a good thing?
> People don't like it when you silently install things behind their back.
> A meta package(at least in the form I'm thinking of) is different as it
> points to other packages and says to install those packages. If you want
> more information on what those packages contain you should be able to
> lookup what each package provides.
A meta package is yet-another-package that do not provide any content.
It's totally spurious in Fedora packaging land. (over boolean deps,
virtual provides, etc).
The other point is that usually, you should enable the nvidia driver
from the "software" application. On regular fedora the
rpmfusion-nonfree-nvidia-driver is selectable from the interface
(don't know about silverblue, but it was intended).
You just have to install the driver by selecting it, so you don't even
have to worry about the gory details of the packaging name.
> >> -it isn't clear if the command I posted(above) installs the 32-bit libraries or not. Really, meta packages would go a long way in simplifying GPU driver installs!
> > In regular Fedora, it will install the 32bit libraries on purpose with
> > the nvidia driver if you have at least a package that requires 32bit
> > libGL. (same for cuda-libs).
>
>
> That doesn't work for 32-bit games though since they don't use the
> package manager and Steam does need 32-bit libs if not installed via
> Flatpak. Yes, Steam provides many 32-bit libs but as they have said
> during the whole Ubuntu 32-bit support mess, they still use system libs.
> Which libs? I don't know, they'd probably have a good idea.
Theses libs are know as soon as the support
> It isn't possible to play Proton games using Fedora Steam but is
> possible with Flatpak Steam for example which I can only assume is
> because of missing 32-bit libs. Installing Wine would probably pull in
> the requires 32-bit libs since Proton is Wine...
No, this is wrong, I have proton support in regular Fedora. with the
steam package from RPM Fusion.
> >> Neither Windows nor even other Linux distros fragment the driver this much. You'd have to add 32-bit libraries alongside the 64 bit driver and 64 bit libraries to equal Fedora's fragmented driver packaging in some distros. Why?
> > Well, It could be worst. You could have sub-packages depending on the
> > need to run headless or without Xorg or without wayland dependencies
> > etc.
> > That's constraints you might not have, but a good packaging should
> > works everywhere.
>
>
> I've never heard of a situation where you would *just* want the driver
> and *not* (at the very least) OpenGL support. Are there any examples?
> Can CUDA be used without OpenGL?
Yes, only few cuda functions requires OpenGL interrop,
> >
> > With that said the rpm-ostree line you have used is silly with respect
> > to the need to llst all sub-packages. Can you point me to the
> > documentation you have used ?
>
>
> https://fedora.pkgs.org/30/rpmfusion-nonfree-x86_64/
Please reference https://rpmfusion.org/Howto/NVIDIA or
https://download1.rpmfusion.org/nonfree/fedora/releases/30/Everything/x86_64/os/repoview/index.html
But the above site is not affiliated to either fedora or rpmfusion and
might provide a totally in-accuratte information.
> rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia = core working driver
Nope, It's the default interface to install the driver not the "Core" one.
> rpm-ostree install xorg-x11-drv-nvidia-libs = OpenGL/Vulkan
False, it's a dependency of the xorg-x11-drv-nvidia, this is the usual
multilibs split, so it's very much a trivial packaging meme.
> rpm-ostree install nvidia-settings = explicitly installed nvidia-settings
Wrong, it's mandatory for any desktop usage so far it cannot be bypassed.
> rpm-ostree install nvidia-xconfig = x config utility for Nvidia
Wrong, it's a deprecated tool only needed for sample, it shouldn't be
used on fedora (or even documented, sorry but too much bad history on
this tool).
> rpm-ostree install xorg-x11-drv-nvidia-cuda xorg-x11-drv-nvidia-cuda-libs = nvidia-smi
Wrong, xorg-x11-drv-nvidia-cuda will requires
xorg-x11-drv-nvidia-cuda-libs, (same packaging meme as above).
As I said I can evaluate a RFE to move the nvidia-smi to the default
set of packages, maybe enforce the -cuda to be installed by default
(with recommends).
But let's move to bugzilla.
Thx for the report.
--
-
Nicolas (kwizart)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
