Created attachment 14805 [details]
files list

Please note, starting from this release it's provided also the package:

dkms-nvidia-newfeature-open-565.77-1.mga9.nonfree

This is an "alternative" package to 'dkms-nvidia-newfeature' which uses open source kernel modules instead of the closed source ones. Note that only NVidia cards of arch Turing and beyond are supported by this dkms-nvidia-newfeature-open Older NVidia cards, e.g. in the Maxwell or Pascal arch supports only the standard dkms-nvidia-newfeature. So for instance Quadro K620 is in the Maxwell arch and are not supported by the -open variant. GTX 1080 is in the Pascal arch and it's not supported. RTX 2070, GTX 1660 are in the Turing arch and are supported. Quadro RTX A6000 is in the Ampere arch and is supported, etc.

Note also that such dkms-nvidia-newfeature-open package it's not installed automatically by the drakx11 utils, but could be installed manually (in that case the cards must be already configured by the utils). So only for the brave and with a minimal competence with manual package installing.

Very cool!!

CC: (none) => eatdirt

I have the Quadro K620 card, so the newfeature-open package does not apply.

The install that I have set up to test the newfeature package already has the older newfeature driver installed, so my first attempt was to do a simple update, with the packages in the file list downloaded with Qarepo. That didn't go well:

[root@localhost ~]# urpmi --auto-update
medium "QA Testing (64-bit)" is up-to-date
medium "Core Release" is up-to-date
    http://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/updates/media_info/20241207-184827-synthesis.hdlist.cz
updated medium "Core Updates"                                                                                
medium "Nonfree Release" is up-to-date
    http://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/nonfree/updates/media_info/20241207-183635-synthesis.hdlist.cz
updated medium "Nonfree Updates"                                                                             
medium "Tainted Release" is up-to-date
    http://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/tainted/updates/media_info/20241207-183714-synthesis.hdlist.cz
updated medium "Tainted Updates"                                                                             
A requested package cannot be installed:
x11-driver-video-nvidia-newfeature-565.77-1.mga9.nonfree.x86_64 (due to unsatisfied libxcb-dri3.so.0)
Continue installation anyway? (Y/n) 

I did not continue the installation.

CC: (none) => andrewsfarm

Seem it requires the package libxcb-dri3_0 from 32bit repo. If you install libxcb-dri3_0-1.15-2.mga9 can you proceed?

That's not the only one. Installing that library brought it three others:

[root@localhost ~]# urpmi libxcb-dri3_0
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch
(medium "Core 32bit Release")
  libxau6                        1.0.11       1.mga9        i586
  libxcb-dri3_0                  1.15         2.mga9        i586
  libxcb1                        1.15         2.mga9        i586
  libxdmcp6                      1.1.4        1.mga9        i586

I left the 32-bit repos enabled as I went back to the update. Good thing I did:

To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch
(medium "QA Testing (64-bit)")
  dkms-nvidia-newfeature         565.77       1.mga9.nonfr> x86_64
  nvidia-newfeature-doc-html     565.77       1.mga9.nonfr> x86_64
  nvidia-newfeature-utils        565.77       1.mga9.nonfr> x86_64
  x11-driver-video-nvidia-newfe> 565.77       1.mga9.nonfr> x86_64
(medium "Tainted Updates")
  lib64dri-drivers               24.2.8       1.mga9.taint> x86_64
  lib64gbm1                      24.2.8       1.mga9.taint> x86_64
  lib64glapi0                    24.2.8       1.mga9.taint> x86_64
  lib64mesaegl1                  24.2.8       1.mga9.taint> x86_64
  lib64mesagl1                   24.2.8       1.mga9.taint> x86_64
  lib64mesavulkan-drivers        24.2.8       1.mga9.taint> x86_64
  lib64xatracker2                24.2.8       1.mga9.taint> x86_64
  mesa                           24.2.8       1.mga9.taint> x86_64
(medium "Core 32bit Release")
  libxcb-present0                1.15         2.mga9        i586
(medium "Core 32bit Updates")
  libx11-xcb1                    1.8.6        1.1.mga9      i586
35MB of additional disk space will be used.
334MB of packages will be retrieved.
Proceed with the installation of the 14 packages? (Y/n)

Two more 32-bit libraries. (Not sure, but I think the tainted mesa packages were simply left over from testing the last mesa update.)

Anyway, the update proceeded, this time completing. On the reboot, auto-login is still disabled, but everything else seems OK.

There are 64-bit versions of those 32-bit libraries. It surprises me that this driver can't use them. If this driver eventually becomes nvidia-current I think that's going to cause problems on a number of user 64-bit systems.

Just my $0.02.

There 64-bit versions of those libraries are already used. but the x11-driver-video-nvidia contains already some 32-bit library (also in nvidia-current). It has been so since at least our initial package long ago. Only that sometimes newer drivers add further more libraries...

There will be nvidia-newfeature-565.77-2.mga9 soon. Note that for full 64(+32) bit experience install the package nvidia-newfeature-lib32 (and nvidia-newfeature-all) for everything, including -lib32.

As reminder, since dkms-nvidia-newfeature and dkms-nvidia-newfeature-open are mutually exclusive we need to add dkms-nvidia-newfeature to meta-task, so that it's the automatically preferred one.

(In reply to Giuseppe Ghibò from comment #9)

> As reminder, since dkms-nvidia-newfeature and dkms-nvidia-newfeature-open
> are mutually exclusive we need to add dkms-nvidia-newfeature to meta-task,
> so that it's the automatically preferred one.

and also to the dnf's meta-task companion.

Interesting!
Todo: Note the news from comment 2 etc in rel notes 10 and wiki:
 https://wiki.mageia.org/en/Setup_the_graphical_server#Nvidia_proprietary_drivers

CC: (none) => fri
Keywords: (none) => FOR_RELEASENOTES10
Status comment: (none) => TODO wiki, see c11

565.77-2.mga9 should be propagated in mirrors.

Created attachment 14811 [details]
file list

updated files list

Attachment 14805 is obsolete: 0 => 1

Updated with no issues, then I installed the newfeature-all package, as suggested in comment 8. This drew in newfeature-32 package, which in turn drew in a rather long list of 32-bit packages.

After the reboot, everything seemed to be working - except for auto-login. (In the future, I shall not bring up auto-login unless it suddenly starts working, or I am asked about it.)

Since it looks like the 6.6.65-2 kernel will probably be approved, I then updated to that, and rebooted again, with the same results as with the older kernel. So far, it looks OK.

My one remaining question is, what happens to the user who wants to try the newfeature driver, installs it, and of course wants the "full 64(+32) bit experience," thus installing the newfeature-all package, then decides it's not for him for whatever reason, and tries to use XFdrake to return to nvidia-current? 

Will the extra packages he installed produce conflicts?

(In reply to Thomas Andrews from comment #14)
> Updated with no issues, then I installed the newfeature-all package, as
> suggested in comment 8. This drew in newfeature-32 package, which in turn
> drew in a rather long list of 32-bit packages.
> 
> After the reboot, everything seemed to be working - except for auto-login.
> (In the future, I shall not bring up auto-login unless it suddenly starts
> working, or I am asked about it.)
> 
> Since it looks like the 6.6.65-2 kernel will probably be approved, I then
> updated to that, and rebooted again, with the same results as with the older
> kernel. So far, it looks OK.
> 
> My one remaining question is, what happens to the user who wants to try the
> newfeature driver, installs it, and of course wants the "full 64(+32) bit
> experience," thus installing the newfeature-all package, then decides it's
> not for him for whatever reason, and tries to use XFdrake to return to
> nvidia-current? 
> 
> Will the extra packages he installed produce conflicts?

NV 32+64 bit packages with "-all" isn't a new feature of -newfeature series, but was also there for nvidia-current and 470. What happens when switching to another nvidia series (admitting everything goes smooth) when extra 32-bit packages are also installed is...nothing. I.e. the extra 32bit packages, which mostly are 32bit X11 libs and mesa libs, remains there, and then the drivers just changes, but the 32bit libs remains the same. Conflicts might arise later if you disable the 32-bit repos and then later you do some update to the system.

As an example, for instance suppose now you disable the 32-bit repos. 32-bit already installed packages, like some mesa 32bit packages remains there. They are used only for 32bit applications (at least those already installed, e.g. suppose you play steam) if any, otherwise remains just the libs installed in /usr/lib, unused.

Now suppose you upgrade mesa from 24.2.8 o next 24.3.2: when it tries to update mesa 24.2.8 (the 64bit version), it detects some lib is wrong when updated (because it can't update the 32bit version from 24.2.8 to 24.3.2) and then would fail the upgrading ("fail" in the meaning that it would tell something is missed before upgrading). In that case one should remove the 32-bit packages BEFORE the upgrading. E.g. 1st detect the 32-bit packages installed with:

rpm -qa --qf '%{ARCH} %{NAME}-%{VERSION}-%{RELEASE}\n'| grep i[5,6]86 |sort

and then remove those involved before the upgrade. Of course this situation is not related to just these drivers but to any 32 bit library installed and then with the corresponding 32-bit repos disabled.

I shall have to remember that when testing mesa on this system, at least, I need to instruct qarepo to get the 32-bit packages, as well. 

May be prudent on almost all update tests...

What about the cuda-opencl packages that were installed by newfeature-all? 
Will they work with nvidia-current? 
Can the newfeature and current cuda packages co-exist? 
Will they be changed automatically, or will that have to be done manually by the user?

Please forgive me for belaboring this. I'm trying to put myself in the shoes of an inexperienced user, one that knows even less than I do. I don't want us to lay a trap for him to fall into. I have always believed that's part of the reason QA exists.

(In reply to Thomas Andrews from comment #17)

> What about the cuda-opencl packages that were installed by newfeature-all? 
> Will they work with nvidia-current? 
> Can the newfeature and current cuda packages co-exist? 
> Will they be changed automatically, or will that have to be done manually by
> the user?

newfeature-all, nvidia-current-all, nvidia470-all installs everything is available on the driver, not much different than what would be installed if the driver were installed from the original self-extracting .run upstream package.

The -cuda-opencl subpackage are not interchangeable, each series has it's own -cuda-opencl package. They were splitten from the main Requires because otherwise the nvidia package were not fitting in the LIVE ISOs. AFAIK (unless it's a bug) they should be automatically removed when another series it's installed. If not, then probably a mutual Conflicts in each of the -cuda-opencl in the SPEC file is still missed.

> 
> Please forgive me for belaboring this. I'm trying to put myself in the shoes
> of an inexperienced user, one that knows even less than I do. I don't want
> us to lay a trap for him to fall into. I have always believed that's part of
> the reason QA exists.

No pb.

So, of course, I gave it a try - an attempt to use XFdrake as root to switch to nvidia-current from nvidia-newfeature, when "all" newfeature packages are installed, except for the new "open" package that my GPU can't use.

I didn't get far. This popped up when I agreed to install the proprietary driver:

Some requested packages cannot be installed:
dkms-nvidia-newfeature-open-565.77-2.mga9.nonfree.x86_64 (due to conflicts with dkms-nvidia-current-550.135-1.mga9.nonfree.x86_64, trying to promote kmod(nvidia-newfeature.ko))
Continue installation anyway?

I aborted it, and was told the proprietary driver wasn't installed properly, and it would switch to using the non-proprietary driver (nouveau, I assume)

I have not yet rebooted. Should be interesting to see what happens...

Well, it rebooted OK. Auto-login working again, and it is using nouveau:

$ inxi -G
Graphics:
  Device-1: NVIDIA GM107GL [Quadro K620] driver: nouveau v: kernel
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: nouveau,v4l dri: nouveau gpu: nouveau resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: nouveau,swrast
    platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.3 vendor: mesa v: 24.2.8 renderer: NV117
  API: Vulkan v: 1.3.231 drivers: llvmpipe surfaces: xcb,xlib

On the plus side, nouveau is working well with this GPU...

Let me know where you want to go next. Oh, I almost forgot: When I used qarepo to get the packages for the new kernel, I left the newfeature packages on the list, so they were there to be used by XFdrake - just as they would be if they had been pushed.

(In reply to Thomas Andrews from comment #19)
> So, of course, I gave it a try - an attempt to use XFdrake as root to switch
> to nvidia-current from nvidia-newfeature, when "all" newfeature packages are
> installed, except for the new "open" package that my GPU can't use.
> 
> I didn't get far. This popped up when I agreed to install the proprietary
> driver:
> 
> Some requested packages cannot be installed:
> dkms-nvidia-newfeature-open-565.77-2.mga9.nonfree.x86_64 (due to conflicts
> with dkms-nvidia-current-550.135-1.mga9.nonfree.x86_64, trying to promote
> kmod(nvidia-newfeature.ko))
> Continue installation anyway?
> 
> I aborted it, and was told the proprietary driver wasn't installed properly,
> and it would switch to using the non-proprietary driver (nouveau, I assume)
> 
> I have not yet rebooted. Should be interesting to see what happens...

using nouveau is a side effect fallback and shouldn't happen. What is strange is that it tries to retrieve the -open package, which shouldn't be retrieved automatically. Probably this is because we still need the meta-task hasn't yet added. As for -cuda-opencl I've rechecked, and it has the Conflicts against nvidia-current-cuda-opencl and nvidia470-cuda-opencl.

I tried something different this time... (All of this was with the test newfeature packages in an enabled qarepo repo)

While under nouveau I used MCC to remove all nvidia packages, then rebooted and used XFdrake to install nvidia-current. That went normally. Then I rebooted and installed nvidia-current-all and dependencies. That went normally, too.

Another reboot, and I told XFdrake to switch to the newfeature driver. That went normally as well. Another reboot, and I checked into the "other" packages. I found that nvidia-current-all had been removed, but newfeature-all needed to be installed manually. 

Doing this produced a conflict: the current-all and current-cuda packages had been removed, but not the current-lib32 package. MCC told me it had to be removed; I said OK; and the install went normally.

So, it's a conflict that was caught and resolved by our tools, but I'm reporting it here in case you want to resolve it another way.

(In reply to Thomas Andrews from comment #19)

> So, of course, I gave it a try - an attempt to use XFdrake as root to switch
> to nvidia-current from nvidia-newfeature, when "all" newfeature packages are
> installed, except for the new "open" package that my GPU can't use.
> 
> I didn't get far. This popped up when I agreed to install the proprietary
> driver:
> 
> Some requested packages cannot be installed:
> dkms-nvidia-newfeature-open-565.77-2.mga9.nonfree.x86_64 (due to conflicts
> with dkms-nvidia-current-550.135-1.mga9.nonfree.x86_64, trying to promote
> kmod(nvidia-newfeature.ko))
> Continue installation anyway?

I added a newer 565.77-3.mga9.nonfree plus meta-task and mageia-repos (mageia-repos is the dual of meta-task for dnf), where there is the preferences between dkms-nvidia-newfeature and dkms-nvidia-newfeature-open, so this shouldn't happen.

Source RPM: nvidia-newfeature-565.77-2.mga9.nonfree => nvidia-newfeature-565.77-2.mga9.nonfree, meta-task, mageia-repos
Summary: Update request: nvidia-newfeature-565.77-2.mga9.nonfree => Update request: nvidia-newfeature-565.77-3.mga9.nonfree

(In reply to Thomas Andrews from comment #22)
> I tried something different this time... (All of this was with the test
> newfeature packages in an enabled qarepo repo)
> 
> While under nouveau I used MCC to remove all nvidia packages, then rebooted
> and used XFdrake to install nvidia-current. That went normally. Then I
> rebooted and installed nvidia-current-all and dependencies. That went
> normally, too.
> 
> Another reboot, and I told XFdrake to switch to the newfeature driver. That
> went normally as well. Another reboot, and I checked into the "other"
> packages. I found that nvidia-current-all had been removed, but
> newfeature-all needed to be installed manually. 
> 
> Doing this produced a conflict: the current-all and current-cuda packages
> had been removed, but not the current-lib32 package. MCC told me it had to
> be removed; I said OK; and the install went normally.
> 
> So, it's a conflict that was caught and resolved by our tools, but I'm
> reporting it here in case you want to resolve it another way.

Thanks for reporting.

Over the years the nvidia packages series got better, though apparently this seems not yet completely "failure-proof" on driver switching, as we might wish.

I've some idea on getting them more robust (e.g. by adding nouveau.modeset=0 under certain curcumstances) but requires intervention to drakx11 code.
But also consider that there is also XWayland... so the tree of possibilities doubles.

At the moment the nvidia{470|-current|-newfeature}-all isn't automatically managed by drakx11|mcc which instead installs the minimal driver packages (so to be "live" compliant for "fitting", and thus the packages keepen at minimal). The *-all package can be considered as an "external" aid/completion to drakx11 config and allows to extend to the "full-optional" set of driver, so to avoid stuff missed, once they are configured. What could be done here could be to 'preserve' the '-all' state on driver switching, so sort something like this, i.e. if a nvidia-*-all is installed and this is detected by drakx11, then re-install it if the driver is switched to another series. Of course this is not limited to nvidia-newfeature, but should extended to any other driver set. But to do this a further change to drakx11 code is required, that IMHO requires a new bug number, so to get a minimal planning eventually.

Please check if i got this right:

https://wiki.mageia.org/en/Setup_the_graphical_server#The_alternative_opensourced_nvidia_kernel_modules

Please edit directly, alternatively tell me what to do.

Status comment: TODO wiki, see c11 => (none)

(In reply to Morgan Leijström from comment #25)
> Please check if i got this right:
> 
> https://wiki.mageia.org/en/
> Setup_the_graphical_server#The_alternative_opensourced_nvidia_kernel_modules
> 
> Please edit directly, alternatively tell me what to do.

Sound ok, I'd omit the reference of bug # source. I'd fix the grammar of the phrase 'So for instance Quadro K620 is in the Maxwell arch and are not supported by the -open variant', into 'So for instance Quadro K620 car is in the Maxwell arch and IS not supported by the -open variant'.

For the installation procedure, I'd correct the steps into:

- The cards must be already configured by the XFdrake/drakx11 util as an nvidia card with proprietary driver. After completed that step, install the dkms-nvidia-current-open (or dkms-nvidia-newfeature-open), that would uninstall the current dkms-nvidia-current (or dkms-nvidia-newfeature) kernel modules and would install and rebuild the -open variant.

More technical details for the -open variant here: https://us.download.nvidia.com/XFree86/Linux-x86_64/565.77/README/kernel_open.html (that for 565.77, but would change over the updates to newer versions).

For the dependency text about the kernel-devel, I'm not sure is completely like that, or not completely as described there, because as soon as the 'dkms' package is installed a -devel kernel should be retrieved as a dep, so probably is triggered in some else condition.

OK thanks, fixed plus some personal taste formulation :)

Regarding kernel-devel: dkms only pulls in one kernel-devel (for the running kernel in my case - or i was just lucky by having booted latest) even if user have several versions and flavours of kernels installed, so I noted so.

But!

Logically, should really the opensourced drivers be in nonfree repo?

Users wanting them but not wanting to enable nonfree repo?

OK for now a reason is that the utilities need to install the nonfree drivers first and then user switch.  But that is a problem that should be fixed in future by improving drakx11 and installer...

Etc... 

Should we try to rearrange something of this for Mageia 10 ?

I added a point under
https://wiki.mageia.org/en/Mageia_10_Release_Notes#Proprietary_NVIDIA_driver

I think the text there should be elaborated, later.

Keywords: FOR_RELEASENOTES10 => IN_RELEASENOTES10

In reply to Morgan Leijström from comment #28)

> But!
> 
> Logically, should really the opensourced drivers be in nonfree repo?
> 
> Users wanting them but not wanting to enable nonfree repo?

IMHO it's too much complicate to rearrange in other ways, at least at the moment. Current way it's actually pretty "linear". But it's not a complete free driver, it's only the kernel modules free (where much stuff has been moved from the driver to firmware). Also closed firmware (those .bin files in the package) are still required even in the -open package, and without that, for what I know, the modules won't work. Last but not least, it's not a fully replacement of closed source drivers, like could be for instance nouveau+plain Xorg, because still it requires the x11-driver-video-nvidia* package, with the full set of proprietary libraries (e.g. libGLX_nvidia.so, etc.) which are selected trough GLVND (libglvnd, https://github.com/NVIDIA/libglvnd). In other words with the dkms-nvidia-newfeature-open alone, you can't use anything without the other stuff in nonfree repo, so won't go far anyway.

Furthermore beyond the various ways of using the proprietary and free drivers, there was added another new one, that we have too in our mesa, and it's through the Vulkan driver using NVK, see:

https://docs.mesa3d.org/drivers/nvk.html

but this requires using the nouveau.ko kernel module. So now we have 8 (nvidia470, nvidia-current, nvidia-newfeature, modesetting, nouveau DDX), plus nvidia-current(+open), nvidia-newfeature(+open), nvk, plus doubling all them for XWayland...

> 
> OK for now a reason is that the utilities need to install the nonfree
> drivers first and then user switch.  But that is a problem that should be
> fixed in future by improving drakx11 and installer...

the fact is that drakx11 won't get such level of improving to the code because it would require adding too much complexity, unless someone would to get into.

It was added also the -open, because upstream also suggests to use it, and might be worthwhile to have it available.

> 
> Etc... 
> 
> Should we try to rearrange something of this for Mageia 10 ?

IMHO I'd keep as is at the moment.

Thank you for the exhaustive explanation and extra info, as always :-)

Yes we should keep it as is.

---

Regarding many nvidia drivers, did you forget Xorg nv?

( For reason i have not yet understood, i had recently to change to nv on my Thinkpad T510 (neither xorg nouveau nor modesetting did not work any longer).  That machine was unused and had no updates since summer and when updating it fully last week it booted to black screen, nouveau errors in log.  I will check it later, in another bug if necessary, lets let it rest for now.)

(In reply to Morgan Leijström from comment #31)

> Thank you for the exhaustive explanation and extra info, as always :-)
> 
> Yes we should keep it as is.

The right way in this case would be to do that "automatically", i.e. if the card is beyond or equal to turing then install the dkms-*-open variant, otherwise install the plain variant. But that would require a deep rework of the drakx11 code, because it actually just maps PCI ID signatures of cards to driver series (470, -current), and has no concept of kernel module open "variant".

> 
> ---
> 
> Regarding many nvidia drivers, did you forget Xorg nv?
> 
> ( For reason i have not yet understood, i had recently to change to nv on my
> Thinkpad T510 (neither xorg nouveau nor modesetting did not work any
> longer).  That machine was unused and had no updates since summer and when
> updating it fully last week it booted to black screen, nouveau errors in
> log.  I will check it later, in another bug if necessary, lets let it rest
> for now.)

Probably nouveau support of the card has been dropped upstream in newer mesa, you might try to disable the 3D acceleration.

Which was the PCI-id and model of the card (lspcidrake -v)?

Thank you for pushing me to dig.

Bug 33882 - mesa-24.2.8-1 dropped support for GT218M [NVS 3100M] -> reboot to black login

Created attachment 14828 [details]
files list

Attachment 14811 is obsolete: 0 => 1

Files list was updated to 565.77-5.mga9.

For the -open modules variant (only for card Turing and beyond), the usage is this:

1) Configure with XFdrake/drakx11 as usual for nvidia-newfeature driver (that would install dkms-nvidia-newfeature). Then reboot.

2) install dkms-nvidia-newfeature-open, that would uninstall dkms-nvidia-newfeature. Let it rebuild the kernel modules. Then reboot.

MGA9-64 Plasma, i5-7500, nvidia Quadro K620.

I started by booting using nouveau, and removed all newfeature packages. Then I used qarepo to get the newfeature packages to test, as well as the list from Bug 33872. I updated, to install new meta-task, ldetect-lst, and mageia-repo packages.

Now I was ready to test the newfeature candidate. I installed it using XFdrake, and rebooted. No apparent issues except no autologin. Then I installed nvidia-newfeature-cuda-opencl, and ran cuda-z, receiving information comparable to what I saw with the other drivers in bug 33872.

Next I used XFdrake to switch to nvidia-current, with no conflicts, so the issue from comment 19 appears to be resolved.

I switched back to the newfeature driver, and left it there, playing a bit with no apparent issues. It looks OK with this GPU, but of course, I can't test the new "open" driver.

(In reply to Thomas Andrews from comment #37)

> MGA9-64 Plasma, i5-7500, nvidia Quadro K620.
> 
> I started by booting using nouveau, and removed all newfeature packages.
> Then I used qarepo to get the newfeature packages to test, as well as the
> list from Bug 33872. I updated, to install new meta-task, ldetect-lst, and
> mageia-repo packages.
> 
> Now I was ready to test the newfeature candidate. I installed it using
> XFdrake, and rebooted. No apparent issues except no autologin. Then I
> installed nvidia-newfeature-cuda-opencl, and ran cuda-z, receiving
> information comparable to what I saw with the other drivers in bug 33872.
> 
> Next I used XFdrake to switch to nvidia-current, with no conflicts, so the
> issue from comment 19 appears to be resolved.
> 
> I switched back to the newfeature driver, and left it there, playing a bit
> with no apparent issues. It looks OK with this GPU, but of course, I can't
> test the new "open" driver.

Apparently all the triplet (-current, -470 and -newfeature) seems OK (apart the known autologin). I updated also cuda-z, fixing two bugs (i.e. the string after Multiprocessors now is shown correctly, and the performance are now in par with real card GFLOPS), that I think it's worthwhile to push also cuda-z together with these packages.

I've checked the cuda-z update, and it looks OK to me. So, is it time to validate? I would prefer to have the new "open" packages tested by someone with the needed hardware, but it's looking like it's not going to happen. 

Katnatek, I'm removing the advisory keyword because I don't see where you have updated the one you originally uploaded.

Keywords: advisory => (none)

(In reply to Thomas Andrews from comment #39)
> I've checked the cuda-z update, and it looks OK to me. So, is it time to
> validate? I would prefer to have the new "open" packages tested by someone
> with the needed hardware, but it's looking like it's not going to happen. 
> 
> Katnatek, I'm removing the advisory keyword because I don't see where you
> have updated the one you originally uploaded.

Just please say me if the cuda-z packages should be here or in bug#33872 , then I'll update both advisories as needed

(In reply to katnatek from comment #40)
> (In reply to Thomas Andrews from comment #39)
> > I've checked the cuda-z update, and it looks OK to me. So, is it time to
> > validate? I would prefer to have the new "open" packages tested by someone
> > with the needed hardware, but it's looking like it's not going to happen. 
> > 
> > Katnatek, I'm removing the advisory keyword because I don't see where you
> > have updated the one you originally uploaded.
> 
> Just please say me if the cuda-z packages should be here or in bug#33872 ,
> then I'll update both advisories as needed

Let's keep just here and not in #33872. Final version for cuda-z is cuda-z-0.11.291-9.mga9 (latest version fixed the output of driver version when the open dkms modules are used).

Validating.

Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2025-0002.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED