- I noticed that you didn't add a LICENSE file for this package.
This checks out, Artistic2.0 is a common license.
Yes, my bad. For this and the rest of the licenses below I assumed it was the same case as MIT and such.
- hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg.
I don't see why you'd need the overhead of git for this, and that url is not going to change. They "document" it here: https://blog.github.com/2011-10-21-github-secrets/#diff-patch
They are not even using an API stable url here. I hope it doesn't change, but it wouldn't be the first time I get biten by api's like this[1].
They've provided it for a very long time specifically in order to let people do this, they're not going to change the scheme and render it useless for the very purpose it was created for. :p
It happened to me with gitlab and their releases url, which started defaulting to "I don't recognize this branch parameter, so here's the tarball for master"[1]
- I'm not sure if this would work when built in a chroot due to those touch calls.
... Are you referring to the ones in package()? Not sure why upstream code needs such weird things but AFAICT it should not break just because of a chroot.
Hmm, I see they are named as noupdatecheck and nobrowser. I assume these are to store the program state and thus need be user read-writeable? This is just speculation, hence the "I'm not sure".
- After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building>
Looks like it just copies a couple python modules into a directory and then creates a wrapper script to run them. What would you suggest running in build(), exactly?
I'm not entirely sure, I see that there's a buildscript using pyinstaller, although I'm not sure why exactly...
- I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable...
I'm not sure what the script does either. gam.py does do:
import utils from var import *
Which should really be explicit relative imports, but it's actually legal in python2, and there doesn't seem to be any other reason to want to cd to the directory, but the script does not cd there anyway.