Davinci-resolve makepkg error

hello !

the package davinci-resolve is currently out of date on the aur (and therefore uninstallable) so i downloaded the PKGBUILD file and changed the minor_version from 4 to 5. when i try build the package it spits out this error, and i cant figure out why.

❯ makepkg
==> Making package: davinci-resolve 18.6.5-1 (Sat 17 Feb 2024 02:55:15 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found DaVinci_Resolve_18.6.5_Linux.zip
==> Validating source files with sha256sums...
    DaVinci_Resolve_18.6.5_Linux.zip ... Passed
==> Extracting sources...
  -> Extracting DaVinci_Resolve_18.6.5_Linux.zip with bsdtar
==> Starting prepare()...
~/davinci-resolve/src ~/davinci-resolve/src
squashfs-root/.DirIcon
squashfs-root/AppRun
squashfs-root/AppRun.desktop

... (outputs the contents of squashfs-root)

squashfs-root/Developer/DaVinciCTL/Spline.dctl
squashfs-root/Developer/Fusion Fuse
squashfs-root/Developer/Fusion Fuse/Fusion Fuse Manual.pdf
fopen error: Permission denied
==> ERROR: A failure occurred in prepare().
    Aborting...

im not sure exactly what information i need to provide ! but ill provide whatever information is requested

thank you to whoever tries to help :]

These are the first few lines of the prepare() function inside the PKGBUILD:

pushd "${srcdir}"
chmod u+x "${srcdir}/${_installer_binary}"
"${srcdir}/${_installer_binary}" --appimage-extract
popd

# Fix permission to all files and dirs
chmod -R u+rwX,go+rX,go-w "${srcdir}/squashfs-root"

Can you add these two echoes into the prepare() function inside the PKGBUILD?

pushd "${srcdir}"
chmod u+x "${srcdir}/${_installer_binary}"
echo "Problem Start"
"${srcdir}/${_installer_binary}" --appimage-extract
echo "Problem End"
popd

# Fix permission to all files and dirs
chmod -R u+rwX,go+rX,go-w "${srcdir}/squashfs-root"

Run it again. Do you see the second echo? I suspect you won’t because the installer failed. If the installer had worked, you would’ve seen the output of the popd command that comes right after it, which I don’t see in the output you posted.

i did as you asked! the second echo isnt shown.

> makepkg
==> Making package: davinci-resolve 18.6.5-1 (Sat 17 Feb 2024 06:30:42 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found DaVinci_Resolve_18.6.5_Linux.zip
==> Validating source files with sha256sums...
    DaVinci_Resolve_18.6.5_Linux.zip ... Passed
==> Extracting sources...
  -> Extracting DaVinci_Resolve_18.6.5_Linux.zip with bsdtar
==> Starting prepare()...
~/davinci-resolve/src ~/davinci-resolve/src
Problem Start
squashfs-root/.DirIcon
squashfs-root/AppRun
squashfs-root/AppRun.desktop

... (same as before)

squashfs-root/Developer/DaVinciCTL/Spline.dctl
squashfs-root/Developer/Fusion Fuse
squashfs-root/Developer/Fusion Fuse/Fusion Fuse Manual.pdf
fopen error: Permission denied
==> ERROR: A failure occurred in prepare().
    Aborting...

the only reason im asking this is because i tried reinstalling resolve (unrelated audio issue) and but AUR package has been out of date for a week and a half… should i just wait and hope that the maintainer updates the AUR package or is it worth trying to fix? i would like to have resolve back as soon as possible so i can continue to work on my projects :]

thanks!

Just as I suspected.

Which means the failure occurred at:

"${srcdir}/${_installer_binary}" --appimage-extract

If you want to further diagnose the issue, you need to look at the source code of the installer. I’m not sure if we have access to that.

i see. is there anything else that could be done?

You can report the problem upstream. In their forum.

Can you check whether DaVinci_Resolve_${pkgver}_Linux.run is a binary file or a shell script? If it’s just a shell script, it is possible to inspect its contents with a text editor. You can use the file command to check.

The reason I ask is because after browsing through BlackMagic’s forums, I came across a thread mentioning that the .run installer files used to be .sh files. So I suspect the installer file could be a shell script despite the misleading shell variable name used to reference it (_installer_binary).