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!