Project

General

Profile

Bug #1949

[makepkg]: syntax error

bill-auger - about 5 years ago - . Updated 7 days ago.

Status:
in progress
Priority:
bug
Assignee:
% Done:

50%


Description

while updating blacklist.git there is a syntax error that was hit several times

remote: /usr/share/makepkg/util/pkgbuild.sh: eval: line 90: unexpected EOF while looking for matching `)'
remote: /usr/share/makepkg/util/pkgbuild.sh: eval: line 91: syntax error: unexpected end of file

UPDATE 2019-11-15:
the original error is fixed - now there is a new error

remote:  |  /usr/share/makepkg/util/pkgbuild.sh: line 92: blacklist-7091865c91f06d7b38fd6dfbeb2c1
remote: 51c.txt: No such file or directory


Related issues

Related to Servers - Bug #2003: [autobuilder] new 'your-freedom' package creation failsnot-a-bug

Actions

History

#1

Updated by bill-auger about 5 years ago

  • Parent task set to #1948
#2

Updated by bill-auger about 5 years ago

  • File deleted (your-freedom-build-log)
#3

Updated by bill-auger about 5 years ago

  • Parent task deleted (#1948)
  • Description updated (diff)
  • Subject changed from 'your-freedom' build hook failed to build to [makepkg]: syntax error

correction to the original report - it was a fluke that the 'your-freedom' build hook failed to build the package - it turns out that freemor had pushed to abslibre during the build - a second try built the package successfully

the syntax error remains though

#4

Updated by bill-auger over 4 years ago

  • Related to Bug #2003: [autobuilder] new 'your-freedom' package creation fails added
#5

Updated by eschwartz over 4 years ago

makepkg does not have a syntax error. If it did have a syntax error, that would be an upstream bugreport. But the issue here is actually that makepkg is incompatible with the multiline, complex command used in https://git.parabola.nu/abslibre.git/tree/libre/your-freedom/PKGBUILD?id=40c9803c67beb8be6aca389ca7f6f715271150b3#n22

#6

Updated by oaken-source over 4 years ago

  • % Done changed from 0 to 90
  • Assignee set to oaken-source
  • Status changed from open to in progress

the syntax errors were caused by load_PKGBUILD not recognizing multi-line commands in the conflicts() array of the your-freedom PKGBUILD.
It should by fixed now. I'm leaving this at 90% until the next rebuild.

#7

Updated by oaken-source over 4 years ago

  • % Done changed from 90 to 100
  • Status changed from in progress to fixed
#8

Updated by bill-auger almost 4 years ago

  • Status changed from fixed to confirmed

i am re-opening this because i saw the same error today while 'your-privacy' was rebuilding

#9

Updated by oaken-source almost 4 years ago

  • Status changed from confirmed to fixed

I have applied the same fix to nonprism/your-privacy, libre/your-freedom_emu, nonsystemd/your-initfreedom, that I had applied to libre/your-freedom.

This should get rid of the error messages.

#10

Updated by bill-auger almost 4 years ago

  • Status changed from fixed to confirmed

the original error message is gone; but a new one appeared:

remote:  |  /usr/share/makepkg/util/pkgbuild.sh: line 92: blacklist-7091865c91f06d7b38fd6dfbeb2c1
remote: 51c.txt: No such file or directory

again it does not appear to cause any trouble - the new 'your-freedom' was built and published successfully

#11

Updated by bill-auger about 3 years ago

  • Description updated (diff)
#12

Updated by bill-auger about 3 years ago

  • % Done changed from 100 to 50
#13

Updated by bill-auger 7 days ago

  • Assignee changed from oaken-source to bill-auger

i finally nailed down that last niggling annoyance - it is caused by the initial load/validation of the PKGBUILD, which evals all standard PKGBUILD variables - the 'conflicts' array of the your-* PKGBUILDs needs to load the blacklist file to file the array - that validation happens immediately upon the download stage, but before the blacklist (any) 'source' file actually gets downloaded, hence the "No such file or directory"

so the problem is not exactly a bug in makepkg, but that we are doing something unconventional in the package() function, and assuming (incorrectly) that it (the hack of populating the 'conflicts' array programmatically) will never be executed until after the download stage is competed

i silenced the error by redirecting STDERR of the eval to /dev/null

diff --git a/scripts/libmakepkg/util/pkgbuild.sh.in b/scripts/libmakepkg/util/pkgbuild.sh.in
index 93bae4e8..381d7d8b 100644
--- a/scripts/libmakepkg/util/pkgbuild.sh.in
+++ b/scripts/libmakepkg/util/pkgbuild.sh.in
@@ -89,7 +89,7 @@ extract_function_variable() {
        while read -r; do
                # strip leading whitespace and any usage of declare
                decl=${REPLY##*([[:space:]])}
-               eval "${decl/#$attr/$outputvar}" 
+               eval "${decl/#$attr/$outputvar}" 2> /dev/null

                # entering this loop at all means we found a match, so notify the caller.
                r=0
#14

Updated by bill-auger 7 days ago

  • Status changed from confirmed to in progress

Also available in: Atom PDF