FS#64648 - file:// sources not extracted automatically anymore
Attached to Project:
Pacman
Opened by Sami B. (spider-mario) - Monday, 25 November 2019, 22:15 GMT
Last edited by Andrew Gregory (andrewgregory) - Thursday, 02 July 2020, 20:08 GMT
Opened by Sami B. (spider-mario) - Monday, 25 November 2019, 22:15 GMT
Last edited by Andrew Gregory (andrewgregory) - Thursday, 02 July 2020, 20:08 GMT
|
Details
makepkg used to automatically extract 7z archives in the
source array, but it does not anymore. Looking at the git
repository, it is unclear to me which change could have
caused this, but it seems rather recent, since I was able to
build
https://aur.archlinux.org/packages/pianoteq-stage/
(where this was reported to me) on the 16th of October with
pacman 5.1.3-1 and libarchive 3.4.0-2.
|
This task depends upon
Closed by Andrew Gregory (andrewgregory)
Thursday, 02 July 2020, 20:08 GMT
Reason for closing: Fixed
Additional comments about closing: Commit 349c22d043290ccd0cce9f30981f5415e295442a
Thursday, 02 July 2020, 20:08 GMT
Reason for closing: Fixed
Additional comments about closing: Commit 349c22d043290ccd0cce9f30981f5415e295442a
==> Extracting sources...
-> Extracting test.7z with bsdtar
I'm unsure how this could *not* work, since in any case where no previous extraction tool was discovered, we fall back to seeing if bsdtar recognizes it as a file bsdtar knows how to handle.
On the package in question, I get:
==> Retrieving sources...
-> Found pianoteq_stage_linux_v660.7z
-> Found pianoteq_icon_128.png
==> Validating source files with sha512sums...
pianoteq_stage_linux_v660.7z ... Passed
pianoteq_icon_128.png ... Passed
==> Extracting sources...
==> Starting prepare()...
So the archive is not even listed under “Extracting sources”.
local -; set -x
This would tell you what is being run here, and you could verify what branches are being run. I'm not able to debug this case myself, because the relevant file download requires registration and possibly payment.
9c817b654996249b8022e189ee7e2692f4668431 is the first bad commit
commit 9c817b654996249b8022e189ee7e2692f4668431
Author: Eli Schwartz <eschwartz@archlinux.org>
Date: Mon May 28 23:30:29 2018 -0400
libmakepkg: implement extendable source protocols
Lookup the existence of matching functions for each protocol, and
fallback on the generic file handler. New source protocols can then be
added via thirdparty libmakepkg drop-ins without requiring modifications
to source.sh
Fixes
FS#49076Signed-off-by: Allan McRae <allan@archlinux.org>
scripts/libmakepkg/source.sh.in | 47 ++++++++-----------------------------
scripts/libmakepkg/source/bzr.sh.in | 5 ++++
scripts/libmakepkg/source/git.sh.in | 5 ++++
scripts/libmakepkg/source/hg.sh.in | 5 ++++
scripts/libmakepkg/source/svn.sh.in | 5 ++++
5 files changed, 30 insertions(+), 37 deletions(-)
Is it because it’s a file:// URI?
+ local file=file://pianoteq_stage_linux_v660.7z
++ get_filepath file://pianoteq_stage_linux_v660.7z
+++ get_filename file://pianoteq_stage_linux_v660.7z
+++ local netfile=file://pianoteq_stage_linux_v660.7z
+++ [[ file://pianoteq_stage_linux_v660.7z = *::* ]]
++++ get_protocol file://pianoteq_stage_linux_v660.7z
++++ [[ file://pianoteq_stage_linux_v660.7z = *://* ]]
++++ local proto=file://pianoteq_stage_linux_v660.7z
++++ proto=file
++++ printf '%s\n' file
+++ local proto=file
+++ case $proto in
+++ filename=pianoteq_stage_linux_v660.7z
+++ printf '%s\n' pianoteq_stage_linux_v660.7z
++ local file=pianoteq_stage_linux_v660.7z
+++ get_protocol file://pianoteq_stage_linux_v660.7z
+++ [[ file://pianoteq_stage_linux_v660.7z = *://* ]]
+++ local proto=file://pianoteq_stage_linux_v660.7z
+++ proto=file
+++ printf '%s\n' file
++ local proto=file
++ case $proto in
++ [[ -f /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_stage_linux_v660.7z ]]
++ file=/home/sami/Programmes/aur4/pianoteq-stage/pianoteq_stage_linux_v660.7z
++ printf '%s\n' /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_stage_linux_v660.7z
+ local filepath=/home/sami/Programmes/aur4/pianoteq-stage/pianoteq_stage_linux_v660.7z
+ rm -f /tmp/makepkg/pianoteq-stage/src/file://pianoteq_stage_linux_v660.7z
+ ln -s /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_stage_linux_v660.7z /tmp/makepkg/pianoteq-stage/src/
+ in_array file://pianoteq_stage_linux_v660.7z
+ local needle=file://pianoteq_stage_linux_v660.7z
+ shift
+ local item
+ return 1
++ file -bizL -- file://pianoteq_stage_linux_v660.7z
+ local 'file_type=cannot open `file://pianoteq_stage_linux_v660.7z'\'' (No such file or directory)'
+ local ext=7z
+ local cmd=
+ case "$file_type" in
+ bsdtar -tf file://pianoteq_stage_linux_v660.7z -q '*'
+ return 0
+ local file=pianoteq_icon_128.png
++ get_filepath pianoteq_icon_128.png
+++ get_filename pianoteq_icon_128.png
+++ local netfile=pianoteq_icon_128.png
+++ [[ pianoteq_icon_128.png = *::* ]]
++++ get_protocol pianoteq_icon_128.png
++++ [[ pianoteq_icon_128.png = *://* ]]
++++ [[ pianoteq_icon_128.png = *lp:* ]]
++++ printf '%s\n' local
+++ local proto=local
+++ case $proto in
+++ filename=pianoteq_icon_128.png
+++ printf '%s\n' pianoteq_icon_128.png
++ local file=pianoteq_icon_128.png
+++ get_protocol pianoteq_icon_128.png
+++ [[ pianoteq_icon_128.png = *://* ]]
+++ [[ pianoteq_icon_128.png = *lp:* ]]
+++ printf '%s\n' local
++ local proto=local
++ case $proto in
++ [[ -f /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_icon_128.png ]]
++ file=/home/sami/Programmes/aur4/pianoteq-stage/pianoteq_icon_128.png
++ printf '%s\n' /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_icon_128.png
+ local filepath=/home/sami/Programmes/aur4/pianoteq-stage/pianoteq_icon_128.png
+ rm -f /tmp/makepkg/pianoteq-stage/src/pianoteq_icon_128.png
+ ln -s /home/sami/Programmes/aur4/pianoteq-stage/pianoteq_icon_128.png /tmp/makepkg/pianoteq-stage/src/
+ in_array pianoteq_icon_128.png
+ local needle=pianoteq_icon_128.png
+ shift
+ local item
+ return 1
++ file -bizL -- pianoteq_icon_128.png
+ local 'file_type=image/png; charset=binary'
+ local ext=png
+ local cmd=
+ case "$file_type" in
+ bsdtar -tf pianoteq_icon_128.png -q '*'
+ return 0
Looks like it is indeed because of the file:// URI.
+ local 'file_type=cannot open `file://test.7z'\'' (No such file or directory)'
My opinion is we should make extract_file behave like the other extract_* functions, and expect a netfile then resolve that inside the function itself.