> > - 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. [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/45507
signature.asc
Description: PGP signature