[aur-general] TU Membership Application

[Santiago Torres-Arias]

> >     - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181107/624f14ad/attachment-0001.asc>