On 11/7/18 10:44 PM, Santiago Torres-Arias via aur-general wrote:
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]
Yes, gitlab is prone to bugs like this. :p gitlab also includes the version of git(1) inside the patch file, and moved the tarball endpoint for legitimately good reasons in https://gitlab.com/gitlab-org/gitlab-ce/issues/38830 Because their tarballs used to be insane. And giving you the tarball for master is a regression they fixed, not an API they dropped. :p
- 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".
It should be owned by root unless some process uses something like install -o username -g groupname.
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...
Most likely in order to create some giant windows executable that ships the entire python application runtime, plus the gam source code, in order to spare Windows users the need to install Python. -- Eli Schwartz Bug Wrangler and Trusted User