The pycipher ebuild calls `newexe' to install a python data file with invalid arguments for portage's `newexe', so the package isn't even installed. It also doesn't need to be executable. The licence in the script is a BSD 2-clause, not BSD(the 3-clause version). The wrapper script that is built is wrapping a module with no command line functionality, it only defines classes, so the wrapper does nothing. The byte-compiled files aren't built either. The attached patch fixes these problems, and cleans some minor whitespace things at the same time. Thanks, James Reproducible: Always
Created attachment 181747 [details, diff] pycipher_fixes.patch
Just out of interest which package manager was this tested with? It is likely a bug in whichever package manager's `newexe' if it re-splits arguments on whitespace boundaries, as it would break if somebody did use paths with spaces. May want to test this and possibly report it
Can't reproduce the doexe issue, but that is broken on so many levels ... where's my napalm? ;) the /usr/bin/pycipher script needs to be changed, that's not even wrong anymore.
(In reply to comment #3) > Can't reproduce the doexe issue, but that is broken on so many levels ... > where's my napalm? ;) If `newexe' is installing anything I'd be interested to know what package manager you're using, it reeks of a bug because it would be fiddling with the whitespace in its arguments. The quoting breaks portage's `newexe' script, because of the quoting, you should see an error from the following test when using the ebuild: if [[ -z ${T} ]] || [[ -z ${2} ]] ; then echo "$0: Need two arguments, old file and new file" 1>&2 exit 1 fi
Looks like this has been mostly fixed since this bug was opened, just without a comment or closure on this bug. The ebuild in the tree still has the incorrect license value though. Thanks
Thanks for reporting back on that. I've fixed the license.
