extras/package/snap: Add `layout:` to symlink `/usr/share/libdrm`

Thanks

Thanks for your contribution!

When all of the following conditions are fulfilled, your MergeRequest will be reviewed by the Team:

the check pipeline passes
the MR is considered as 'mergeable' by gitlab

You can find more details about the acceptance process here.

This message was automatically generated by homer-bot.

This shares all of /usr/share/libdrm/ -- is there anything else in there, like any shared libraries that may not have been well-tested with the VLC snap?

There is nothing else in /usr/share/libdrm/, so this change could be restricted to only /usr/share/libdrm/amdgpu.ids.

In general though, this is just symlinking files which are already bundled in the snap. The contents of $SNAP/usr/share/libdrm are the direct result of the the directives in snapcraft.yaml, and are system-independent.

FWIW, the few other snap packages I've seen so far are using bind and not simlink

I've seen similar, though bind comes at a performance penalty and is only needed if the application treats symlinks different for whatever reason, which is not the case here.

https://forum.snapcraft.io/t/snap-layouts/7207

This does not look like a VLC problem. libdrm is used by almost any graphical application, and it's provided by Canonical not VideoLAN

I think libdrm isnt exactly available in snap cores, so if we need to use it, we must explicitely allow it.

Does this symlink/mount actually fix any actual issue with the snap , or it's just fixing the No Such File message?

This doesn't look like libdrm proper, which is just a (pretty useless) glorified ioctl wrapper, and wouldn't access the filesystem this way. It rather looks like one of the vendor-specific sublibrary (out of many, all doing different things).

This must be provided by the system, whether Canonical likes it or not, as it is an essential part of the graphical drivers.

Indeed, we do not carry libdrm in contribs (and shouldn't have it there), even less libdrm vendor libraries.

This is not a problem with VLC itself, but just a small misconfiguration in the snapcraft.yaml file for the VLC snap, which happens to live in the same repo as the rest of the VLC code.

libdrm is provided as a dependency to one or more package in stage-packages. In particular, it looks like mesa-vulkan-drivers requires libdrm-amdgpu1 requires libdrm2 requires libdrm-common, which provides /usr/share/libdrm/amdgpu.ids. (This is checked on an Ubuntu 23.04 system, but the dependency tree should be fairly similar on Ubuntu 20.04, which is the base system for this snap in the VLC master branch, Ubuntu 18.04 in 3.0.x.) When snaps are built, a VM with the base system is spun up, packages installed or built there, and stage-packages end up as part of the filesystem which is then squashfsed into the .snap file itself. Snaps work by mounting that squashfs file on the host system and then allowing the snap very selective access to that system.

All that is to say, amdgpu.ids ends up in /snap/vlc/<revision-number>/usr/share/libdrm/ (visible in the same place to both the host system and the snap), since it is provided by a package built into the snap itself. VLC expects it to be in /usr/share/libdrm/, so creating a symlink within the snap filesystem lets the VLC application within the VLC snap find what it is looking for, and the change is completely internal to the snap itself and independent from anything on the host system.

amdgpu.ids looks like a list of PCI IDs for AMD/ATI Radeon GPUs.

It is and its access is hardcoded https://gitlab.freedesktop.org/mesa/drm/-/blob/main/amdgpu/amdgpu_asic_id.c#L116 (configured as define https://gitlab.freedesktop.org/mesa/drm/-/blob/main/amdgpu/meson.build#L35)

It's used for the amdgpu_get_marketing_name() API.

Bleh, it seems a bit pedantic to log that at error level.

added MRStatus::InReview label and removed MRStatus::Reviewable label

added Component:: CI label

changed milestone to %4.0

This doesn't look like libdrm proper, which is just a (pretty useless) glorified ioctl wrapper

AFAIK libdrm is the location where kernel developers can implement userland workaround and quirks for some drivers to ensure they behave correctly, so it's a bit than just a wrapper.

That might be true of the vendor-specific libraries under the libdrm umbrella, but libdrm.so proper is just a glorified ioctl wrapper plus some historical helpers for X servers and libraries.

added MRStatus::Stale label and removed MRStatus::InReview label

extras/package/snap: Add `layout:` to symlink `/usr/share/libdrm`

Merge request reports

Activity

Thanks