[aur-general] Trusted user application: Drew DeVault

Thu Feb 28 01:22:03 UTC 2019

On 2/25/19 5:55 PM, Drew DeVault wrote:
> Thanks for all the feedback! I went through and cleaned up all of my AUR
> packages - something a wiser man would have done before submitting the
> TU application.
> 

You're welcome, but from me this was just the travel version... here
comes the full unleashed feature set of xxarhtna
For now reduced to python only and some random picks, If i find time I
will take a look at the other packages as well.

> 
>> Out of curiosity, what kind of upstream watch are you using to be made
>> aware of new releases? 
> 
> For the AUR I don't keep up with upstream releases, I just wait for
> someone to mark the package as outdated. For Alpine Linux I use a
> combination of subscribing to the upstream -announce mailing list and
> subscribing to GitHub releases as appropriate; would do something
> similar for Arch Linux community.
> 

Well, to be honest its the maintainers responsibility to keep track of
upstream and not outsource out of date flagging to someone else. There
is no difference between [community] and AUR for something that is a
maintainer responsibility.

Back to packages:

Really no offense, but I really had high expectations and got very
surprised: At some point I started wondering if you read error and log
output while trying to package or run tests?
Some of this findings indicates you don't (when you change some stuff)
or at least stop any investigation if f.e. a test suite doesn't run
straight. I would like to see more investigative behavior of a
maintainer in getting things sorted out the correct way instead of just
abandon if it requires a bit of patience and thinking plus time.

Also i encountered some examples of non working pkg build of very recent
changes that make me think changes are pushed straight to the AUR before
any build/test ever happened.

If there is stuff to rule out and you need ideas and another pair of
eyes, just ask for it... that's what a team and a community should be
for, nobody knows everything.
Also some of the packages don't work as they are not python 3.7
compatible at all so i wonder if anyone uses them a all?

Also i noticed you may maybe not know 'namcap' because of so many
missing licenses plus stuff like Non-FHS man page violations.

patchrom:

- Non-FHS man page in /usr/man/man1

mktiupgrade:

- Non-FHS man page in /usr/man/man1

mkrom:

- Non-FHS man page in /usr/man/man1

kpack:

- Non-FHS man page in /usr/man/man1

genkfs:

- Non-FHS man page in /usr/man/man1

sass:

- did you test building this package before pushing
  an added LICENSE dist line 2 days ago? Because this
  indicates something went wrong:
  install: cannot stat 'LICENSE': No such file or directory
  ==> ERROR: A failure occurred in package().

python-sshpubkeys:
- what does the 1.0.5 do in the URL? :P

- do you use proper clean environments for building? asking because:
  ==> ERROR: A failure occurred in build().
  ModuleNotFoundError: No module named 'setuptools'et
  This packages requires setuptools makedepends
  doesn't your CI or AUR testing use clean/isolated and non polluted
  environments for building?

- what does check() do, build the package? that should be 'test' instead
  of 'build' Btw: please use github sources, the pypi re-distribution
  doesn't contain any tests in the first place
  PS: to avoid setuptools download checkdepends it needs:
  cffi, asn1crypto, pycparser (take a look on log output)

- this package doesn't provide LICENSE.txt as github contains, please
  use github sources and include it
  PS: do you use namcap on your packages to find some frequent mistakes?

python-spam-blocklists:

- what does the 0.9.3 do in the URL?

- what does the comment mean about "only py2"?
  if you run the tests reality shows it just doesn't work at all:
  ModuleNotFoundError: No module named 'urlparse'
  sources show from urlparse import urlparse which can't be fulfilled
  anywhere
  nice indicator: Latest commit on Jun 15, 2012, this stuff is just
  dead, nuke

python-pystache:

- doesnt distribute the MIT license which exists in the sources

- there is a test runner using python ./test_pystache.py
  which pretty much shows this is dead non working stuff as well:
  File "/build/python-pystache/src/pystache-0.5.4/pystache/parser.py",
  line 15
  NON_BLANK_RE = re.compile(ur'^(.)', re.M)
  SyntaxError: invalid syntax
  Latest commit 17a5dfd  on Sep 30, 2014

python-patreon:

- license is wrong, if you look at upstream its apache2

- this projects depends on python-six to run

- must depend on setuptools as makedepends instead of distribute
  as thats the correct module it requires

- no tests run, by adding checkdepends for python-mock python-pytest
  python-pytest-cov you can easily run a check() via
  python setup.py test
  which successfully runs 52 passed in 0.82 seconds

python-lark:

- misses python-js2py depends

- "# upstream tests fail due to path resolution errors"
  what exactly do you mean by that? If you investiate the files
  trying to be processed you would notice that they are not distributed
  in the pypi processed files. Taking a look at the sources you would
  notice they use a submodule to get the grammer from, if we get them
  and invoke the tests as upstream does in travis (python -m tests)
  you get: OK Ran 352 tests in 28.259s
  PS: upstream forgot the dot in the latest tag, you may want to
  make them aware but it works flawlessly
 t

python-haxor:

- missing depends on python-aiohttp as requirements.txt also shows

- what exactly do you mean by upstream test suite segfaults?
  Ran 31 tests in 118.626s in a clean isolated environment

python-asyncio_redis:

- distribute license file is missing, just use real sources
  then you get the license file for free as well

- python-hiredis should be a optional dependency as listed
  on the projects page

python-asif:

- upstream does have license files, it would be best to get in
  touch with upstream and make them fix their git tags so you
  can use the source tarball or make them fix the setuptools
  dist files to contain a license as well.
  Either way, making them use proper git tags would be nice

samurai:

- still doesn't care about CPPFLAGS, either sort it out
  upstream or (plus in the meanwhile) handle it in the
  PKGBUILD so all our flags get passed properly

synapse-bt-git:

- maybe the custom user-service file could use some systemd hardening
  options
- it could run some unit tests through cargo test

mako-git:

- a better pkgver() function containing tag/describe would give the
  final packages pkgver attribute a more meaningful value

scas:

- doesn't contain any man packages as SCAS_DOCUMENTATION is
  not respected, the package should make sure the manpages
  are distrubuted

z80e:

- MIT license not distributed

- should have a dependency on readline as namcap complains

koio:

- should have scdoc as makedepends so we get manpages

madonctl:

- doesn't do go extflags magic like gitea so we have
  RELRO builds (like namcap complains)
  lacks FULL RELRO, check LDFLAGS

If i have more time, i will go through the other packages,
cheers,
Levente