FS#53161 - [vim-spell] Missplaced hyphen in PKGBUILD

Attached to Project: Arch Linux
Opened by NicoHood (NicoHood) - Saturday, 04 March 2017, 14:19 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 20 April 2017, 16:52 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/vim-spell#n72

Please remove the hyphen. Otherwise namcap fails to parse the package.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Thursday, 20 April 2017, 16:52 GMT
Reason for closing:  Not a bug
Comment by Daniel M. Capella (polyzen) - Saturday, 04 March 2017, 18:51 GMT
The one in line 65? There is no hyphen on line 72.
Comment by NicoHood (NicoHood) - Sunday, 05 March 2017, 00:12 GMT
A damn. My english... I meant this character: "
It seems to start with the eval command which causes trouble for me. Maybe this can be simplified.
I will try to write a proper fix.
Comment by Doug Newgard (Scimmia) - Sunday, 05 March 2017, 00:37 GMT
Sounds more like a namcap problem
Comment by NicoHood (NicoHood) - Sunday, 05 March 2017, 14:10 GMT
The problem was the echo. Can we remove this?
---------------
for _i in ${pkgname[@]}; do _j=${_i/vim-spell-/}; eval "package_$_i() {
cd \"\$srcdir\"
install -d \"\$pkgdir\"/usr/share/vim/vimfiles/spell
install -m644 $_j* \"\$pkgdir\"/usr/share/vim/vimfiles/spell
[[ -f README_$_j.txt ]] \
&& install -Dm644 README_$_j.txt \"\$pkgdir\"/usr/share/licenses/$_i/README #\
# || echo 'No README for $_j...'
}"; done
-------------------

Which will give an invalid parsepkgbuild output:
----------------
sha256sums
source
url

No README for af...
%NAME%
vim-spell-af

%VERSION%
20150901-1
------------------

Otherwise I get with the namcap python API:
PacmanPackage({None: ['No README for af...'], 'name': 'vim-spell-af', [...] })

Maybe this also needs to be better fixed in parsepkgbuild or the namcap python part.
Comment by NicoHood (NicoHood) - Sunday, 05 March 2017, 14:36 GMT
To fix this in namcap one could disable echo when the PKGBUILD is sourced in parsepkgbuild.sh:

# Disable echo for the sourceing of the PKGBUILD to avoid errors
echo() { :; }
printf() { :; }
source $1

And then use builtin echo for every command below that line. This works for me.
Comment by Doug Newgard (Scimmia) - Monday, 06 March 2017, 00:28 GMT
Added keenerd to the notification list for probable namcap issue.
Comment by Kyle Keen (keenerd) - Monday, 06 March 2017, 07:35 GMT
I want to say that in the past there have been packages that used echo to create the basic metadata, but I don't see any like that at the moment.

Anyway, weird pkgbuilds are likely to be parsed weird. Using eval to generate a pkgbuild function that echos to stdout is weird. It is a bug, but given the exceptional nature of what it took to produce the error I kind of feel it isn't worth fixing.

Half of the problem can be fixed by replacing "echo" with "msg", a makepkg function that won't exist during this non-interactive use. This removes the "None: ['No README for af...'" junk. (I'm leaning towards this, because we have "msg" for a reason. And because of all the solutions it is the only one that makes the total size smaller :-)

Or namcap can be tweaked. In PacmanPackage(), changing "elif line.strip() != '':" to "elif line.strip() != '' and attrname:" ignores the malformed data and never creates a "None" field.
Comment by NicoHood (NicoHood) - Monday, 06 March 2017, 17:23 GMT
Can't we just fix both? The namcap fix you suggested (it wont hurt and fix possible other bugs) and the msg change or even fix the eval completely to parse this package properly?
Comment by Daniel M. Capella (polyzen) - Monday, 06 March 2017, 18:24 GMT
I was under the impression that the use of makepkg functions in pkgbuilds is frowned upon and sought to be ended, no?
Comment by Doug Newgard (Scimmia) - Tuesday, 07 March 2017, 01:40 GMT
You're correct, polyzen.  FS#43502 

Loading...