[aur-general] Trusted user application: Drew DeVault

Drew DeVault sir at cmpwn.com
Thu Feb 28 03:25:10 UTC 2019 

On 2019-02-28  2:22 AM, Levente Polyak via aur-general wrote:
> > 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.

I respectfully disagree. The barrier to entry for the AUR is almost
nonexistent and there's no expectation of support or quality - from Arch
Linux or from the maintainers. I take some degree of personal pride in
having nice AUR packages, but I also have a limited amount of time. Of
course, I take my responsibility as maintainer much more seriously when
working with packages in official repos.

> 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?

Hmm, sorry to disappoint. I definitely built and did at least a basic
sanity test on every package. I did update a whole bunch of packages at
once, so it's possible I missed a few things... many of which I presume
are the problems you pointed out.

Also, note that I haven't yet taken the time to clean up my
sr.ht-pkgbuilds packages, if you were reviewing those. Many of those are
also adoptions from the AUR where I imported someone else's package so I
could build a binary package - and left their PKGBUILD intact to make
pulling down updates easier. Might rethink that policy.

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

Aye, this is first I've heard of namcap. Is there a reason that this
isn't included with makepkg by default?

I updated several of the packages you mentioned to address your
feedback, and ran namcap on them. Can you take another look when you
have time?

Regarding your Python feedback in particular, I appreciate the tips - I
have a lot of Python packages I need to make but have found resources
for making Arch Linux packages for Python software to be somewhat
lacking. I put a note on my todo list to take the feedback on these AUR
packages and summarize them for the Arch Wiki.

https://wiki.archlinux.org/index.php/Python_package_guidelines

> patchrom mktiupgrade mkrom kpack genkfs
> - Non-FHS man page in /usr/man/man1

I could fix this in the package, but this is an upstream bug, so I filed
a ticket... on my own project.

https://github.com/KnightOS/KnightOS/issues/381

> 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().

Ah, I had thought I did, but it seems I only tested scas. sass is legacy
software, and scas is its replacement. I think I just got mixed up.

> - 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?

My CI uses fresh build environments, but my AUR packages aren't built
with it. Just finished setting up makechrootpkg so I can do this
locally.

> Btw: please use github sources, the pypi re-distribution doesn't
> contain any tests in the first place

Damn, I was really happy to have a consistent sources URL I could reuse
for Python packages.

> python-spam-blocklists:
>   nice indicator: Latest commit on Jun 15, 2012, this stuff is just
>   dead, nuke

Agreed, and I don't even remember what I needed this for. Filed a
deletion request.

> python-pystache:
> - 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

It may be abandoned but I actually do remember why I need this package -
and I still do. The test suite runs on Python 3 but you have to jump
through some hoops - setup.py runs the whole codebase through 2to3
before installing. Jumped through said hoops and updated the package.

> python-lark:
> - "# 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

I'm impressed with your build hardware. I thought I was on a nice
machine here, but I'm 10 minutes in and on 79/416. My PKGBUILD is
attached if you're curious.

I have an early flight to catch and I'd better pack & sleep, so I'll
have to fix up the rest later. These are the ones I have left:

- python-haxor:
- python-asyncio_redis:
- python-asif:
- samurai:
- synapse-bt-git:
- mako-git:
- scas:
- z80e:
- koio:
- madonctl:

Thanks!
-------------- next part --------------
pkgname="python-lark"
_pkgname=lark
pkgver=0.6.6
# typo upstream: https://github.com/lark-parser/lark/issues/329
_pkgver=0.66
pkgrel=1
pkgdesc="A modern parsing library for Python, implementing Earley & LALR(1) and an easy interface"
url="https://github.com/erezsh/lark"
arch=("any")
license=("MIT")
depends=("python" "python-js2py")
makedepends=("git" "python-setuptools")
# Note: the latest tag has a typo in it
source=(
	"$pkgname-$pkgver.tar.gz::https://github.com/lark-parser/$_pkgname/archive/$_pkgver.tar.gz"
	"git+https://github.com/Hardmath123/nearley#commit=a46b37471db486db0f6e1ce6a2934fb238346b44"
)
sha256sums=('a97fa873326ec31743f18d07b81dabefba3a289b38cc9afeda7e9d0dd8b25b55'
            'SKIP')

prepare() {
	cd "$_pkgname-$_pkgver"
	rm -r tests/test_nearley/nearley/
	ln -s ../../../nearley tests/test_nearley/
}

build() {
	cd "$_pkgname-$_pkgver"
	python setup.py build
}

check() {
	cd "$_pkgname-$_pkgver"
	python -m test
}

package() {
	cd "$_pkgname-$_pkgver"
	python setup.py install --root="${pkgdir}/" --optimize=1
	install -Dm644 LICENSE "$pkgdir"/usr/share/licenses/"$pkgname"/LICENSE
}

More information about the aur-general mailing list