[aur-general] TU Membership Application
santiago at archlinux.org
Thu Nov 8 03:44:16 UTC 2018
> > - 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:
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
> 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"
> > - 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the aur-general