| Summary: | List of 19.20-812932 release mistakes | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Andrew Shark <ashark> |
| Component: | DRM/AMDgpu-pro | Assignee: | Default DRI bug account <dri-devel> |
| Status: | RESOLVED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | 110957, 110958, 110959, 110960, 110961, 110962, 110963, 110964, 110965, 110966, 110967, 110968 | ||
| Bug Blocks: | |||
Please split this ticket into separate issues - one issue per ticket. Currently it is impossible to track progress via the ticket status, and discussing any item from the list is cumbersome with lots of noise inbetween when discussing other items from the list. Bug 110957 - wsa-amdgpu package has empty copyright file Bug 110958 - Mentioning 32 bit OS support in Release page Bug 110959 - Broken link to Homepage of some packages Bug 110960 - Non-existent alternative dependencies in some deb packages Bug 110961 - Are provoded libdrm packages completely open source? Bug 110962 - Wrong dependencies cause force dependency on amdgpu-dkms Bug 110963 - Wrong condition and wrong variable substitution in libgl1-amdgpu-mesa-dri in postinst script Bug 110964 - Documentation update about provided Open Vulkan implementation Bug 110965 - Documentation update about not provided PX package Bug 110966 - Documentation update about required lunar sdk Bug 110967 - Naming packages with pro suffix depending if open or close source Bug 110968 - Allow ubuntu users to install on other ubuntu versions I added the bugs you created in the dependency list for this one so that it tracks the overall progress. That said, from a quick overview those are all Ubuntu packaging issues, which means you need to talk to Ubuntu about these, we can't do anything about it. I'll close the ones that are clearly something the Ubuntu packager needs to do as INVALID; I hope you don't take it badly, this was just the wrong bug tracker ;) BTW, when possible you should try to make a proper Arch package instead of taking what someone built for Ubuntu and extracting it on Arch. There are things like file paths that change depending on the distro and might get built into the file, so your method might lead to spurious failures. OK, there are 4 issues left: 110965 & 110964 are about the docs on https://amdgpu-install.readthedocs.io/; a quick look at the repo shows only one member, Tim Writer (https://gitlab.com/amdgpu/docs/amdgpu-install/-/project_members). You should try to contact him about these, or maybe simply send him an MR with your updates. I'll close these two now. 110958 is about the docs on the AMD.com website, which we have no control over, but there are some AMD devs that read the bug tracker; maybe they'll see this bug and know how to update the docs. Lastly, 110966 is about the Vulkan SDK from LunarG; I don't know much about it other than the fact it is used on Windows to distribute the vulkan loader (the thing that manages the various vendors' vulkan drivers). As for the api version numbers, 1.1.x should be all compatible with one another, aside from missing features from newer releases, obviously. (In reply to Eric Engestrom from comment #3) > I'll close the ones that are clearly something the Ubuntu packager needs to > do as INVALID; I hope you don't take it badly, this was just the wrong bug > tracker ;) I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's meant for the AMD developers who very much have control (or at least influence) over these things. (In reply to Ilia Mirkin from comment #5) > I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's > meant for the AMD developers who very much have control (or at least > influence) over these things. Something just dawned on me: as amdgpu-pro is closed source, is it only ever distributed as ubuntu packages, and therefore AMD are the ones making these packages? If so, I think I need to apologize, and all your bugs can be re-opened, sorry :/ (In reply to Eric Engestrom from comment #6) > (In reply to Ilia Mirkin from comment #5) > > I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's > > meant for the AMD developers who very much have control (or at least > > influence) over these things. > > Something just dawned on me: as amdgpu-pro is closed source, is it only ever > distributed as ubuntu packages, and therefore AMD are the ones making these > packages? They are just packaged drivers. Most of it is open source. There are a few closed source components you can optionally install for workstation parts but everything else is open source. A few notes: - Installing on 32bit is unsupported, but you could in theory still do it as I don't thing we block this. This configuration is not advised. - I am looking into a better way of providing source packages for open components. I might just make a PPA but design is pending. - We do not support --no-dkms with --pro, granted this should be documented but is likely not. - PX should be marked as deprecated in the installer, this is likely not yet documented correctly. - I'm aware of the mesa dri post install script issues. I pushed some fixes, but I'm not sure which build it landed in. Will try to address the individual bugs if I haven't done so already. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/27. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
I was repacking amdgpu-pro (ubuntu archive) for Arch linux, and while doing this, I have noticed many probable mistakes. Here is my list. - wsa-amdgpu package has empty copyright file - Release page says that it supports ubuntu x86_64, but actually it can be installed on ubuntu x86. Is this an error? - In clinfo package description Homepage link is broken (404 page) - In alternative dependencies there are such occurances: libva1-amdgpu, libva2-amdgpu, libvdpau-1-amdgpu. But these are not provided neither by ubuntu repos, nor in bundled archive. So is it an error? - Provided libdrm packages have MIT licence. But are they built completely from open source? In the changelog I can see that it is some amd-mainline-hybrid-master20190125. And actually if I omit these packages, then proprietay libgl driver and clinfo utility crashes. I want to avoid needing of installation of these libdrm packages (libdrm-amdgpu-amdgpu1, libdrm-amdgpu-common, libdrm2-amdgpu). Is that possible? - amdgpu-pro(-hwe) and amdgpu-pro-lib32 depend on amdgpu(-hwe), but actually they should depend on amdgpu-lib(-hwe) (just like open variant packages). Because of that even when running installer with --no-dkms, it still is in packages list (because amdgpu(-hwe) depends on it). Is it intensional ar just a mistake? - In libgl1-amdgpu-mesa-dri in postinst script in Support I+A hybrid graphics there is such condition: if [ -f ... ] && [ "str1" != "str2" ]; then You just compare two different strings? I guess you wanted to compare folder contents. But now that condition will always be false. in if [ "${f%%/*}"... there is extra percent symbol, you should remove it. Btw, in rpm variants scriptlets, it is already fixed. - In the documentation at readthedocs there is missing information about Open Vulkan component - There is actually no PX package in bundled archive, so maybe remove it completely from installer script and from the documentation? - Release page says that you need to install lunar_sdk for vulkan to work. Is it really true? And even then, it says that you need version 1.1.106.0, but in vulkan-amdgpu-pro inside json file we have 1.1.108. The documentation is outdated? - roct-amdgpu-pro and roct-amdgpu-pro-dev have MIT licence. Are they actually open souce components? If yes, then why do they called with -pro suffix? - Can you remove hardcoded declining of installation on unsupported ubuntu release? Just leave a warning (as you let it for non-ubuntu systems), but let the users to decide. Otherwise, they need to edit release version or modify debian packages internals (I even did a special script for this and published in this bugtracking system).