On 10/25/18 4:26 PM, Brett Cornwall via aur-general wrote:
I am being sponsored by dvzrv.
I've been working in the AUR since 2014 as 'Ainola'.
Hi Brett, some small questions and hints first: It looks like several packages have different issues preventing to build in clean chrooted environments properly. Did you take a look at the devtools package and building packages in clean chroots so far? What software/tool do you using to track all the new ustream releases? You still seem to use `mksrcinfo` for generating SRCINFO files, it was deprecated in favor of native `makepkg --printsrcinfo` you may want to use that in the future. I have noticed that mostly all git packages lack sufficient provides/conflicts on the basic non-git name schema and/or makedepends on git itself, would be nice to keep in mind Also i notices there are multiple packages that store a tarball in the AUR source repo that contain things like icons, please don't miss-use the AUR as a storage for tarball artifacts. some findings after reading your PKGBUILDS, can you please take a look and process the following feedback: ags - upstream Makefile doesn't seem to respect CPPFLAGS try to either get a patch upstream or if that fails extend CFLAGS with CPPFLAGS in the PKGBUILD. creeper-world - upstream source/url provides a https endpoint - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - don't think pkgdesc should ever end with a dot creeper-world2 - upstream source/url provides a https endpoint - don't think pkgdesc should ever end with a dot - unzip to prepare the env is more of a prepare() candidate creeper-world3 - upstream source/url provides a https endpoint - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well csound-blue - please don't use the AUR to store a tar.gz as a source - provides/conflicts on itself doesn't do anything useful - is there a reason for not stripping? - this looks like a -bin package as you are re-distributing pre-compiled files, why not just build from source instead? :) gam - don't think pkgdesc should ever end with a dot - there is some unused client_secrets.patch sitting around in the source repo - python2-oauth2client dependency is missing - this package create cluttering files across the filesystem if you run gam as root, it will have untracked pyc files in /usr/share/gam/ you need to compile them if no distutils is provided gnome-xcf-thumbnailer - prepare() shall never package into $pkgdir gtk-theme-adwaita-tweaks - don't think pkgdesc should ever end with a dot gtk-theme-adwaita-tweaks-git - lack of provides/conflicts - should pull via git+https:// - don't think pkgdesc should ever end with a dot - git makedepends is missing - the dark variant isn't published as "Adwaita Tweaks Dark" i don't think this works compared to the non git variant, it should honor the assets-dark folders and mimic what the release tarballs provide gtk-theme-minwaita - don't think pkgdesc should ever end with a dot hib-dlagent - none-url.patch is not a very unique name for a remote soruce, it could potentially clash, prepend with $pkgname can help imv-git - lack of provides imv i3lock-media-keys - don't think pkgdesc should ever end with a dot interception-ctrl2esc-git - don't think pkgdesc should ever end with a dot - git makedepends is missing - provides/conflicts not proper - is there a reason to have interception- prefix? imo ctrl2esc-git would be the better naming here plus provides/conflicts on ctrl2esc - you should use CMAKE_INSTALL_PREFIX=/usr and DESTDIR for $pkgdir invada-studio-plugins-lv2 - don't think pkgdesc should ever end with a dot lazy-ips-git - don't think pkgdesc should ever end with a dot - git makedepends is missing - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - lack of provides/conflicts linkchecker - don't think pkgdesc should ever end with a dot minecraft-technic-launcher - don't think pkgdesc should ever end with a dot nexuiz - don't think pkgdesc should ever end with a dot - upstream source/url both provides a https endpoint - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well - extracting and patching should be done in prepare() - please don't use the AUR to store a tar.gz as a source, there is also an orphan bin-links.tar.gz file additionally to the used nex-icons.tar.gz checked into the AUR pam_encfs - doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure this is always applied for c/cpp pd-extended - non unique filename that only contains the $pkgname, must always be unique including the pkgver so avoid clashes - doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure this is always applied for c/cpp - orphan file makefile.am.patch in the tree - upstream source/url both provides a https endpoint plasma5-applets-plasma-pass-git - don't think pkgdesc should ever end with a dot - conflicts missing on plasma5-applets-plasma-pass python-google-auth-httplib2-git - this is a split package creating two artifacts, you should not have provides/conflicts on a global level, you need to put them in the separate variants package_*() function once for python- and once for python2- - git makedepends is missing python-humblebundle - is there any reason to not just pull from github which also includes the LICENSE? currently the LICENSE is separately pulled from git master and it doesn't even have any unique file identifiers python-image - don't think pkgdesc should ever end with a dot - don't use the hash based pythonhosted.org endpoint, there is a non changing variant that is more suitable for packaging as it doesn't very other then the $pkgver python-image-git - don't think pkgdesc should ever end with a dot - git makedepends is missing python-oath - don't think pkgdesc should ever end with a dot - each variant must at least depend in its package_* func to at least python/python2 - there are neat tests in the sources, please try to run a check() function python-vipaccess - don't think pkgdesc should ever end with a dot - you should add all the depends from the package_* funcs to the makedepends so the check functions don't start to uselessly download packages via pip - setuptools is a hard depends and must be added in package_* as the entry_point feature is used in the setup.py for /usr/bin/vipaccess - /usr/bin/vipaccess is provided in both variants it should by something like vipaccess-py2 but this looks like a pure CLI tool that is not really usable as a library, is it? If so, it would be appropriate to just purge the python2 variant. python2-image-git - don't think pkgdesc should ever end with a dot - git makedepends is missing - why not use a split package via python-image-git like you do for python-image? - conflicts missing on python2-image - LICENSE and README should be distributed, like in python-image-git residualvm - don't think pkgdesc should ever end with a dot scanbd - please don't use a install file to reference to the wiki, its not meant to be used for such general purpose documentation - upstream source provides a https endpoint ttf-material-wifi-icons-git - should pull via git+https:// - lack of provides/conflicts unruu - should use unique filename prefix with $pkgname-$pkgver - should just pass --prefix=/usr to ./configure and call a proper make DESTDIR="${pkgdir}" install unruu-git - git makedepends is missing - lack of provides/conflicts - should just pass --prefix=/usr to ./configure and call a proper make DESTDIR="${pkgdir}" install cheers, Levente