Workflow for i686 fails for no reason ?

[SpidFightFR]

Hey, i got a question.

I made a pull request to update mesa to version 23.1.6 (#45635), when i was in vacation. Everything went well.
Though yesterday i made a PR for mesa 23.1.7 (#45974), and closed the previous PR, to not flood the Pull requests, but i saw that mesa 23.1.7 i686 build in the workflow failed so i guessed it wasn't ready yet.

So i reactivated the PR for 23.1.6 which we knew went correctly before i close it. But the same bug for the Build packages (i686, i686, glibc, linux/386, 1) workflows happens for no reason:

cp: cannot stat '/destdir//mesa-ati-dri-23.1.7/*': No such file or directory
=> ERROR: mesa-ati-dri-23.1.7_1: post-install_80-prepare-32bit: 'cp -a ${PKGDESTDIR}/* ${destdir32}/' exited with 1
=> ERROR:   in hook() at common/hooks/post-install/80-prepare-32bit.sh:64
=> ERROR:   in run_func() at common/xbps-src/shutils/common.sh:21
=> ERROR:   in run_pkg_hooks() at common/xbps-src/shutils/common.sh:262
=> ERROR:   in main() at common/xbps-src/libexec/xbps-src-doinstall.sh:66

(this is the error i got for 23.1.7, but 23.1.6 gets the same error)

I'm unsure why it happens, especially for 23.1.6 because, again, it worked before i closed it.

If someone can help, it would be much appreciated.

[classabbyamp]

it's related to #45927

[SpidFightFR]

Any news on this ?
It prevents us from getting a newer version of mesa... 😓

[onlylunix]

Im not sure, but it has something to do with temporary dummy packages:

$ xbps-query --regex -Rs "^mesa-.*-dri-.*"
[-] mesa-ati-dri-23.1.3_1           Mesa DRI drivers for ATI GPUs (transitional dummy package)
[-] mesa-intel-dri-23.1.3_1         Mesa DRI drivers for Intel GPUs (transitional dummy package)
[-] mesa-nouveau-dri-23.1.3_1       Mesa DRI drivers for NVIDIA GPUs (transitional dummy package)
[-] mesa-vmwgfx-dri-23.1.3_1        Mesa DRI drivers for VMware (transitional dummy package)
[-] mesa-ati-dri-32bit-23.1.3_1     Mesa DRI drivers for ATI GPUs (transitional dummy package) (32bit)
[-] mesa-intel-dri-32bit-23.1.3_1   Mesa DRI drivers for Intel GPUs (transitional dummy package) (32bit)
[-] mesa-nouveau-dri-32bit-23.1.3_1 Mesa DRI drivers for NVIDIA GPUs (transitional dummy package) (32bit)
[-] mesa-vmwgfx-dri-32bit-23.1.3_1  Mesa DRI drivers for VMware (transitional dummy package) (32bit)

If you comment out the template according to the patch, then the package is built normally:

--- a/srcpkgs/mesa/template
+++ b/srcpkgs/mesa/template
@@ -83,7 +83,7 @@
 	_vulkan_drivers+=",amd"
 	subpackages+=" mesa-vulkan-radeon"
 	# transitional dummy packages
-	subpackages+=" mesa-ati-dri"
+	# subpackages+=" mesa-ati-dri"
 	configure_args+=" -Dvideo-codecs=h264dec,h264enc,h265dec,h265enc,vc1dec"
 fi
 
@@ -93,7 +93,7 @@
 	_vulkan_drivers+=",intel,intel_hasvk"
 	subpackages+=" mesa-vulkan-intel"
 	# transitional dummy packages
-	subpackages+=" mesa-intel-dri"
+	# subpackages+=" mesa-intel-dri"
 fi
 
 if [ "$_have_nv" ]; then
@@ -104,7 +104,7 @@
 		subpackages+=" mesa-tegra-dri"
 	fi
 	# transitional dummy packages
-	subpackages+=" mesa-nouveau-dri"
+	# subpackages+=" mesa-nouveau-dri"
 fi
 
 if [ "$_have_arm" ]; then
@@ -132,7 +132,7 @@
 	configure_args+=" -Dgallium-xa=enabled"
 	subpackages+=" libxatracker"
 	# transitional dummy packages
-	subpackages+=" mesa-vmwgfx-dri"
+	# subpackages+=" mesa-vmwgfx-dri"
 else
 	configure_args+=" -Dgallium-xa=disabled"
 fi

Maybe its time to put away these dummy transition bags?

[classabbyamp]

Maybe its time to put away these dummy transition bags?

no those are still necessary. this is caused by a refactoring of the hook that's failing

[Daxot]

well, this issue with mesa is nothing to do with shlibs, because it was fixed in this commit

as @Duncaen pointed out in IRC, mesa 32-bit package failure happens because the hook script /common/hooks/post-install/80-prepare-32bit.sh on the 64th line cp -a ${PKGDESTDIR}/* ${destdir32}/ tries to copy all stuff inside /destdir/$package-$version to /destdir/$package-32bit-$version
it works with normal packages, but it failures with dummy packages because they are empty and there's nothing to copy

i tried to change that line to cp -aT ${PKGDESTDIR} ${destdir32} and it did the job: no packaging failure and all stuff inside /destdir/ looks fine for me, but it might break other things and maybe there is better solution, i dunno

[SpidFightFR]

Please keep me in touch with the solutions you'll find in the future 🙏

[SpidFightFR]

Hello, do we have any solution for this? This issue prevents mesa updates, and some package start to require newer mesa versions... Please help 😅

[classabbyamp]

this should really have been an issue. #46612

[SpidFightFR]

Oh my bad, thank you for opening the issue tho. I hope we'll find a solution in #46612 😓