Created attachment 680842 [details] emerge --info output Hi there, I was trying to install jellyfin-bin from the src_prepare overly. It contains the following src_unpack: src_unpack() { unpack_deb "${P}-server-${ARCH}.deb" unpack_deb "${P}-web.deb" } which then yields the following error message: >>> Emerging (1 of 1) www-servers/jellyfin-bin-10.7.0_rc2::src_prepare-overlay !!! Fetched file: jellyfin-bin-10.7.0_rc2-server-.deb VERIFY FAILED! !!! Reason: Insufficient data for checksum verification !!! Got: !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 SHA512 WHIRLPOOL * Fetch failed for 'www-servers/jellyfin-bin-10.7.0_rc2', Log file: * '/var/tmp/portage/www-servers/jellyfin-bin-10.7.0_rc2/temp/build.log' Since it's trying to unpack "jellyfin-bin-10.7.0_rc2-server-.deb", it looks like ${ARCH} isn't being properly populated. I found that including any other statement in the src_unpack (such as "true" or "env", etc) causes it to succeed, and that swapping the order of the lines causes it to succeed, but in the current configuration it reliably fails for me every time and I'm at a loss to explain why other than some kind of odd race condition? I'm happy to provide any additional information that may be required to help debug this and I'll attach the output of "emerge --info", just let me know if there's other commands I should be providing. Thanks! 5:)
The problem is that you can't refer to ${ARCH} in SRC_URI, since the value there needs to be constant, so you'll have to substitute amd64 or whatever in SRC_URI.
(In reply to Zac Medico from comment #1) > The problem is that you can't refer to ${ARCH} in SRC_URI, since the value > there needs to be constant, so you'll have to substitute amd64 or whatever > in SRC_URI. Yes, this is metadata invariance: https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-600007.1. The idea being we need to be able to generate e.g. a full Manifest on one machine which will work for all.
(Also: nice to see Jellyfin being worked on - it's a great bit of software and I've been wanting to package it myself!)
Thanks for the replies! Sorry I didn't specify, but SRC_URI did contain the constant values. As you can see from the error, the entry is missing from the manifest (because SRC_URI had the constants in it and so downloaded and created the manifest on the right file). I discovered that even so, during the src_unpack phase the variable couldn't be used immediately (without something else happening first). The issue has been resolved in the ebuild by using constants everywhere, but it seemed as though the variable not resolving at the start of src_unpack (which I understood to just be a bash function) but resolving ok later on was a bit weird? I'm happy to close the bug if it's not considered an issue, just curious as to what might be causing it. I've no idea whether it happens with other variables though...
Maybe add this bug to devmanual or some doc about ${ARCH}.
