It is in testing repositories??

(In reply to Jose Manuel López from comment #2)
> It is in testing repositories??

Yes, nonfree/updates_testing

This is a new package, right?

AFAIK, it needs to go into backport_testing, then.

CC: (none) => marja11

(In reply to Marja Van Waes from comment #4)
> This is a new package, right?
> 
> AFAIK, it needs to go into backport_testing, then.

Hi. And then, it will live in Backport?
As it is a leaf package and not part of our ISO, should it be there?
Because, if so, it will be hard for people to find it.

From https://wiki.mageia.org/en/Updates_policy#Version_Policy

"We will make exceptions for packages that did not make it into Mga-current and are additions to the distribution, provided they do not impact any other packages and can pass full QA."

CC: (none) => davidwhodgins

My highest AMD GPU is a HD 8570 (Oland) chip. It uses the amdgpu driver on Mageia. I have no idea if it can use this driver, how to test it if it can, or what to do with it.

All of my other AMD GPUs use the radeon driver, and I'm assuming that they would not be able to use this.

CC: (none) => andrewsfarm

(In reply to Dave Hodgins from comment #6)
> From https://wiki.mageia.org/en/Updates_policy#Version_Policy
> 
> "We will make exceptions for packages that did not make it into Mga-current
> and are additions to the distribution, provided they do not impact any other
> packages and can pass full QA."

Thanks for your comment, Dave,

That line was already there in 2011 and has never been removed. 
https://wiki.mageia.org/mw-en/index.php?title=Updates_policy&oldid=381

At that time I was told, that this rule was _only_ about packages that were present in Mandriva, but not (yet) in Mageia. 
At that time, if the Mandriva version was still installed, the Mageia version would be proposed as an update.

Now, it is extremely unlikely that there is anyone left with a Mdk version of a package we never imported.

Apart from that, if this package lands in core/updates, it'll never be proposed as an update, because there is no previous version in core/release.

Forget the last line ;-)

(In reply to christian barranco from comment #0)

> It uses the former flash-player plugin philosophy, informing the users about
> their acceptance of AMD EULA before downloading the driver from the AMD
> website.

the flash-player plugin in mga had a "flaw" that when upstream was changing the version in their site, the mga/mdk package wasn't working anymore (you can verify this nowadays just taking the package from older ISO and try to make it working on a VM). Not much we can do here, apart maybe referring, as a fallback, in case the upstream package doesn't exist anymore, to some archived version somewhere on the net.

Anyway since the version was hardcoded in the package, please add also the following security mechanism:

- add the amd rpm package public signing key into the mageia package (thus the key it's "hardcoded" into the mga package).

- in the %pre script, just before the rpm2cpio command, just verify the downloaded rpm package against the amd signing key.

- if the signature checks matches then proceed as before, otherwise stop installation and show some mismatch error.

CC: (none) => ghibomgx

(In reply to Giuseppe Ghibò from comment #10)
> (In reply to christian barranco from comment #0)
> 
> > It uses the former flash-player plugin philosophy, informing the users about
> > their acceptance of AMD EULA before downloading the driver from the AMD
> > website.
> 
> the flash-player plugin in mga had a "flaw" that when upstream was changing
> the version in their site, the mga/mdk package wasn't working anymore (you
> can verify this nowadays just taking the package from older ISO and try to
> make it working on a VM). Not much we can do here, apart maybe referring, as
> a fallback, in case the upstream package doesn't exist anymore, to some
> archived version somewhere on the net.
> 
> Anyway since the version was hardcoded in the package, please add also the
> following security mechanism:
> 
> - add the amd rpm package public signing key into the mageia package (thus
> the key it's "hardcoded" into the mga package).
> 
> - in the %pre script, just before the rpm2cpio command, just verify the
> downloaded rpm package against the amd signing key.
> 
> - if the signature checks matches then proceed as before, otherwise stop
> installation and show some mismatch error.

The thing is such siging keys don't exist on AMD website. The only option I see is to create them myself based on the downloads I have done already.
Should I? Other option?

(In reply to christian barranco from comment #11)
> (In reply to Giuseppe Ghibò from comment #10)
> > (In reply to christian barranco from comment #0)
> > 
> > > It uses the former flash-player plugin philosophy, informing the users about
> > > their acceptance of AMD EULA before downloading the driver from the AMD
> > > website.
> > 
> > the flash-player plugin in mga had a "flaw" that when upstream was changing
> > the version in their site, the mga/mdk package wasn't working anymore (you
> > can verify this nowadays just taking the package from older ISO and try to
> > make it working on a VM). Not much we can do here, apart maybe referring, as
> > a fallback, in case the upstream package doesn't exist anymore, to some
> > archived version somewhere on the net.
> > 
> > Anyway since the version was hardcoded in the package, please add also the
> > following security mechanism:
> > 
> > - add the amd rpm package public signing key into the mageia package (thus
> > the key it's "hardcoded" into the mga package).
> > 
> > - in the %pre script, just before the rpm2cpio command, just verify the
> > downloaded rpm package against the amd signing key.
> > 
> > - if the signature checks matches then proceed as before, otherwise stop
> > installation and show some mismatch error.
> 
> The thing is such siging keys don't exist on AMD website. The only option I
> see is to create them myself based on the downloads I have done already.
> Should I? Other option?

Is this one good?

https://repo.radeon.com/rocm/rocm.gpg.key

(In reply to Giuseppe Ghibò from comment #12)
> (In reply to christian barranco from comment #11)
> > (In reply to Giuseppe Ghibò from comment #10)
> > > (In reply to christian barranco from comment #0)
> > > 
> > > > It uses the former flash-player plugin philosophy, informing the users about
> > > > their acceptance of AMD EULA before downloading the driver from the AMD
> > > > website.
> > > 
> > > the flash-player plugin in mga had a "flaw" that when upstream was changing
> > > the version in their site, the mga/mdk package wasn't working anymore (you
> > > can verify this nowadays just taking the package from older ISO and try to
> > > make it working on a VM). Not much we can do here, apart maybe referring, as
> > > a fallback, in case the upstream package doesn't exist anymore, to some
> > > archived version somewhere on the net.
> > > 
> > > Anyway since the version was hardcoded in the package, please add also the
> > > following security mechanism:
> > > 
> > > - add the amd rpm package public signing key into the mageia package (thus
> > > the key it's "hardcoded" into the mga package).
> > > 
> > > - in the %pre script, just before the rpm2cpio command, just verify the
> > > downloaded rpm package against the amd signing key.
> > > 
> > > - if the signature checks matches then proceed as before, otherwise stop
> > > installation and show some mismatch error.
> > 
> > The thing is such siging keys don't exist on AMD website. The only option I
> > see is to create them myself based on the downloads I have done already.
> > Should I? Other option?
> 
> Is this one good?
> 
> https://repo.radeon.com/rocm/rocm.gpg.key

Nope. It is not the rocm package.

(In reply to christian barranco from comment #13)
> (In reply to Giuseppe Ghibò from comment #12)
> > (In reply to christian barranco from comment #11)
> > > (In reply to Giuseppe Ghibò from comment #10)
> > > > (In reply to christian barranco from comment #0)
> > > > 
> > > > > It uses the former flash-player plugin philosophy, informing the users about
> > > > > their acceptance of AMD EULA before downloading the driver from the AMD
> > > > > website.
> > > > 
> > > > the flash-player plugin in mga had a "flaw" that when upstream was changing
> > > > the version in their site, the mga/mdk package wasn't working anymore (you
> > > > can verify this nowadays just taking the package from older ISO and try to
> > > > make it working on a VM). Not much we can do here, apart maybe referring, as
> > > > a fallback, in case the upstream package doesn't exist anymore, to some
> > > > archived version somewhere on the net.
> > > > 
> > > > Anyway since the version was hardcoded in the package, please add also the
> > > > following security mechanism:
> > > > 
> > > > - add the amd rpm package public signing key into the mageia package (thus
> > > > the key it's "hardcoded" into the mga package).
> > > > 
> > > > - in the %pre script, just before the rpm2cpio command, just verify the
> > > > downloaded rpm package against the amd signing key.
> > > > 
> > > > - if the signature checks matches then proceed as before, otherwise stop
> > > > installation and show some mismatch error.
> > > 
> > > The thing is such siging keys don't exist on AMD website. The only option I
> > > see is to create them myself based on the downloads I have done already.
> > > Should I? Other option?
> > 
> > Is this one good?
> > 
> > https://repo.radeon.com/rocm/rocm.gpg.key
> 
> Nope. It is not the rocm package.

AFAIK that's the seeked AMD public key. See this:

1) wget https://repo.radeon.com/amdgpu/latest/rhel/9.2/proprietary/x86_64/opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm

2) wget https://repo.radeon.com/rocm/rocm.gpg.key

3) rpmkeys --checksig ./opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm

   ./opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm: digests SIGNATURES NOT OK

5a) rpmkeys --dbpath=$(pwd) --import ./rocm.gpg.key
5b) rpmkeys --dbpath=$(pwd) --checksig ./opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm

./opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm: digests signatures OK

In other words the package would have just to include rocm.gpg.key as Source2, install on some path, and then your script you have to use before rpm2cpio, the commands like 5a)+5b) with the proper path for keys and package and a writable temp area for --dbpath. Then check the return value ($?) if it's 0, then package is verified, if it's 1, then failed signature so exit and show some error (you might add the argument --quiet to rpmkeys to avoid verbosity).

https://bugs.mageia.org/show_bug.cgi?id=32396#c14
Ok. I was looking at the same location where the proprietary lib rpm were.
I will update accordingly.
Thanks Sir!

(In reply to christian barranco from comment #15)
> https://bugs.mageia.org/show_bug.cgi?id=32396#c14
> Ok. I was looking at the same location where the proprietary lib rpm were.
> I will update accordingly.
> Thanks Sir!

The question remains though: should I really submit them into backports_testing?

If Council could take a position very quickly, I would appreciate it.

(In reply to christian barranco from comment #16)

> (In reply to christian barranco from comment #15)
> > https://bugs.mageia.org/show_bug.cgi?id=32396#c14
> > Ok. I was looking at the same location where the proprietary lib rpm were.
> > I will update accordingly.
> > Thanks Sir!
> 
> The question remains though: should I really submit them into
> backports_testing?
> 
> If Council could take a position very quickly, I would appreciate it.

If I can express an opinion, if we plan to add for mga9, the final destination (once stabilized, i.e. after it works) should be nonfree/updates (and updates_testing for newer releases before being promoted).
Also as a fallback we might use some network global archive service (e.g. arhive.org), so in the script we might use:

if wget  https://repo.radeon.com/amdgpu/latest/rhel/9.2/proprietary/x86_64/opencl-legacy-amdgpu-pro-icd-23.20-1654522.el9.x86_64.rpm -> fails, then try
wget https://...<somearchiveservice>.org/repo.readeon.com/..../opencl-legacy-23.20-1654522.el9.x86_64.rpm as fallback. In this way the script wouldn't fail if on the main site that particular rpm version that matches what is hardcoded in the package, would be removed, and we may don't update to the latest version anymore.

For what I know ROCm/HIP has several area of compatibility (there was a matrix of supported GPUs somewhere, ordered by what AMD calls "platforms" but was moved again...), and the legacy library it's only for older Polaris GPUs, but even with that it's not said to get the whole compatibilities level for any HIP task. So that's only a tiny part of the whole ROCm stack (which should go in main since is free).

I have installed this package in a computer:

Intel I5 
Graphic card AMD RX550

Installation ok, the last driver is downloaded and installed

Opencl ok.

Darktalble with opencl.
Libreoffice with opencl.

It looks very much like Council will agree to make an exception for this package and the other AMD OpenCL one, so I'd like to upload the advisories.
However, going by the discussion in the last comments, it looks like a new release of these packages will be pushed to testing. Is that so?

(In reply to Marja Van Waes from comment #19)
> It looks very much like Council will agree to make an exception for this
> package and the other AMD OpenCL one, so I'd like to upload the advisories.
> However, going by the discussion in the last comments, it looks like a new
> release of these packages will be pushed to testing. Is that so?

Yes. I am on it. I will then push it in nonfree testing as well.

@Christian:

This is beginning to sound like a lot to keep track of and maintain. Three packages now, and maybe more as AMD issues new GPUs in the future.

I well remember the problems we had with the flashplayer package, and the need to stay on it to keep it working when Adobe put out a new update. We weren't always timely with that.

I realize that Flash was a security nightmare with more holes than a screen door, and that meant frequent updates, and I'm not saying that is the case with these packages, but still...

I have no idea how complicated these packages are, and probably wouldn't understand if you tried to explain it. I'm not suggesting that you can't handle it - I don't know you well enough to make that judgement. However, I would suggest that you enlist the aid of another developer who could step in to maintain the packages in case you are unavailable for some reason.

(In reply to Thomas Andrews from comment #21)
> I realize that Flash was a security nightmare with more holes than a screen
> door, and that meant frequent updates, and I'm not saying that is the case
> with these packages, but still...
> 
By "these packages" I meant the ones from AMD, not yours. I didn't mean to imply that yours are possibly full of security holes.

Sigh. I really wish we could edit our own already-posted comments on Bugzilla, not for the first time.

There is a little confusion here. I might be wrong too, however from
from what we stated when in june we were doing some testing about ROCm/HIP, ROCm is free software that can go directly in core/release of cauldron (and core/updates of mga9). I don't understand why we were discussing about adding the whole stack to nonfree, if we plan to build the rest ourself from sources and not from AMD binaries? And that would work on newer AMD GPUs. According to what was stated and tested at that time, the extra proprietary library we were actually discussing here is just an "optional" and it's only required for older Polaris GPUs, which is the one you are actually using for your local testing, IIRC a Radeon RX570). But newer GPUs won't require it and might get ROCm/HIP working without it. According to this, that extra library it's just the icing on a cake, and the analogy with flashplayer nightmares ends just on the same approach used to distribute that nonfree software.

The analogy at most could be like with java, we might repackage the oracle binaries (or someone else bin) or provide the version compiled from sources of our own.

Mageia9, x86_64
$ inxi -G
Graphics:
  Device-1: AMD Lucienne driver: amdgpu v: kernel
  Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X:
    loaded: amdgpu,v4l dri: radeonsi gpu: amdgpu resolution: 2560x1440~60Hz
  API: OpenGL v: 4.6 Mesa 23.1.7 renderer: AMD Radeon Graphics (renoir LLVM
    15.0.6 DRM 3.54 6.5.3-server-1.mga9)

This package is probably not relevant to this hardware.  Installed it and looked for it in XFdrake.  Could not identify it in the ATI list.  Current choice is Volcanic Islands and later (amdgpu).  Same after reboot.

Looked up OpenCL and came across this quote:
"OpenCL is the primary language used to run graphics processing on AMD GPUs."

amdgpu driver is listed under Xorg.

CC: (none) => tarazed25

Len, if I am reading https://www.techpowerup.com/gpu-specs/amd-lucienne.g995 correctly, your chip falls under the "Vega" series, Bug 32397.

My "best" chip is from the Southern Islands series, too old and feeble for any of this stuff. It uses the amdgpu driver, but barely.

@Giuseppe: Confusion is the word, all right. And in my case, MORE than a little.

TJ, thanks for the link.  Would never have guessed there was any other information to be had.  Shall work on the other bug later.

All I did was highlight "AMD Lucienne" in your comment and told Firefox to search with DuckDuckGo. (I quit using Google for search a few years ago.)

That link was the first thing on the list.

MGA9-64 Xfce on Acer Aspire 5253.
No installation issues.
This laptop has Radeon HD 6250 graphics. I don't know whether this would be affected by this update, but it keeps performing OK after installation and reboot.
glmark2 is inline with previous tests in M8.

CC: (none) => herman.viaene

Ready again for QA, with signature check of the downloaded package, as recommended in https://bugs.mageia.org/show_bug.cgi?id=32396#c14 

Please, do remember, it is not a the graphic driver as such.
What is installed here is the OpenCL library.

To check whether it works. Install clinfo. 
Do clinfo -l before and after installation of this package.
You should see a difference.


ADVISORY NOTICE PROPOSAL
========================

AMD OpenCL proprietary driver "orca".


Description
AMD OpenCL proprietary driver for graphic cards prior Vega generation, i.e. Grenada XT, Carrizo and Polaris.

This package does not contain the AMD OpenCL library itself.
The software is automatically downloaded from AMD official website during package installation.

Installing this package indicates acceptance of the AMD License Agreement, available at https://www.amd.com/en/support/linux-eula


References
https://bugs.mageia.org/show_bug.cgi?id=32396
https://www.amd.com/en/support/linux-drivers

SRPMS
9/nonfree
amdgpupro-opencl-orca-23.20-0.1654522.2.mga9.nonfree.src.rpm



PROVIDED PACKAGES:
=================
x86_64
amdgpupro-opencl-orca-23.20-0.1654522.2.mga9.nonfree.x86_64.rpm

(In reply to Thomas Andrews from comment #21)
> @Christian:
> 
> This is beginning to sound like a lot to keep track of and maintain. Three
> packages now, and maybe more as AMD issues new GPUs in the future.
> 
> I well remember the problems we had with the flashplayer package, and the
> need to stay on it to keep it working when Adobe put out a new update. We
> weren't always timely with that.
> 
> I realize that Flash was a security nightmare with more holes than a screen
> door, and that meant frequent updates, and I'm not saying that is the case
> with these packages, but still...
> 
> I have no idea how complicated these packages are, and probably wouldn't
> understand if you tried to explain it. I'm not suggesting that you can't
> handle it - I don't know you well enough to make that judgement. However, I
> would suggest that you enlist the aid of another developer who could step in
> to maintain the packages in case you are unavailable for some reason.

Hi Thomas

Actually, I don't think any update of amdgpupro-opencl-orca and amdgpupro-opencl-pal will be required.

Even if the full AMDGPUPRO stack evolves, I don't think these legacy opencl libraries do.

Eventually, ROCm could even replace amdgpupro-opencl-pal; yet to be confirmed though.
In that case, only ROCm will really require some maintenance.

Thanks for caring !

Advisory from comment 29 added to SVN. Please remove the "advisory" keyword if it needs to be changed. It also helps when obsolete advisories are tagged as "obsolete"

Keywords: (none) => advisory

Could someone (Joselp :) ) do one more test of this update?
After that, I recommend to push it.

OT: I think we should add to the distro some tiny benchmark for it (opencl),  to see how it's working. Looking around I found this:

https://github.com/ekondis/mixbench

it has entries for standard cpu, opencl, cuda, hip, sycl. We might package it and provide binaries according to where the corresponding dev tools are located (e.g. for cuda in nonfree), etc.

(In reply to Giuseppe Ghibò from comment #33)
> OT: I think we should add to the distro some tiny benchmark for it (opencl),
> to see how it's working. Looking around I found this:
> 
> https://github.com/ekondis/mixbench
> 
> it has entries for standard cpu, opencl, cuda, hip, sycl. We might package
> it and provide binaries according to where the corresponding dev tools are
> located (e.g. for cuda in nonfree), etc.

That sounds like something to take through the usual procedure of proposing/adding to Cauldron, possibly backporting to MGA9.

Validating.

Note this is a new package, but Mageia council have voted for it to be placed in updates instead of backport.

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

Sorry for my delay, very busy here....

I have installed the latest revision. Hassle-free installation.

Works ok for me on Slimbook ProX15 AMD

Libreoffice recognizes opencl again.
Darktable recognizes opencl again.
Sorry for my delay, very busy here....

I have installed the latest revision. Hassle-free installation.

Works ok for me on Slimbook ProX15 AMD

Libreoffice recognizes opencl again.
Darktable recognizes opencl again.

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

https://advisories.mageia.org/MGAA-2023-0101.html

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

Added https://wiki.mageia.org/en/Mageia_9_Errata#AMD_OpenCL

Keywords: (none) => IN_ERRATA9