On 02/17/2017 03:25 PM, Christian Rebischke wrote:
Hello everyone, I am Christian Rebischke (in the internet mostly known as 'shibumi') and I would like to increase my work in the Arch Linux Community and become Arch Linux TU. Thanks to Florian Pritz (bluewind) for being my sponsor.
First at all: I know shibumi for quite a while now (also personally in meat space) and what i could say in a short summary: great news!! *cheer* :D So far its bit lonely in this thread *tumbleweed*... lets get this rolling a bit. I'm also sure one or the other may miss my reply :P zsh> xxarhtna --pedantic --input aur/shibumi [+] Starting up xxarhtna [+] Analyzing 46 packages [+] Dumping 18 results... apk-signer: - upstream seems gone, googlecode redirects to a 404 github and search doesn't reveal any trace of upstream existence. Bit meh it vanished and there is only a binary blob left on a random dropbox >.> awesome-terminal-fonts: - you could distribute the non-common license as its available in the tarball - fc-cache in .install is not needed anymore as thats handled by a pacman hook - the .install creates a symlink and if the package gets uninstalled a dangling symlink will remain pointing into nothing. awesome-terminal-fonts-git: - same as awesome-terminal-fonts binnavi: - makes sense to use ${pkgver} in source, otherwise it tends to be forgotten on bump :P - the combination of mkdir + mv can be simplified with a single install -Dm 644 - the custom start script calls /usr/bin/java (which can by java6) but it seem to require >= 8 (< please note the comment about binnavi-git related to fixing this) binnavi-git: - the combination of mkdir + mv can be simplified with a single install -Dm 644 - the custom start script calls a java-8 specific path, but the dependency is specified as >= 8. If a java >= 9 will arrive, it may not work if java8 is not installed, while the dependency is still fulfilled. Either pin the version to java8 and use a java8 path or do some dynamic sorcery to find the proper jre java executable. cloud-buster: - makes sense to use ${pkgver} in source, otherwise it tends to be forgotten on bump :P - requires python-dnspython as optdepends in its mxrecords.py inetsim: - perlipq dependency does not seem to exist - upstream provides gpg signatures that can be used - grep inetsim in the install file isn't safe enough as it can match anything (theoretically) use getent instead. - gid 16 is already reserved for stunnel libemu: - whitespace after '--prefix=/usr' :P :D nyan: - makes sense to use ${pkgver} in source, otherwise it tends to be forgotten on bump :P puppetserver: - upstream gpg signature are available python-requests-cache: - needs (make)depends of python-requests - with adding checkdepends of python{2}-pytest and python{2}-mock you can add a check() call doing py.test and py.test2 python-pypdns: - requires dependency of python{2}-requests (see source) - optdepends of python{2}-requests-cache. - license could be shipped as its available in the tarball python-pymisp: - 2.4.65 is out :P - requires python{2}-requests python{2}-dateutil python{2}-jsonschema as dependens - optionally requires a new package python{2}-pyme otherwise the sign and verify functionality of this will error out - with python{2}-pytest and python{2}-requests-mock a check() can be used running py.test and py.test2 python-piexif: - when adding python{2}-pytest and python{2}-pillow to checkdepends, a check() can be used having set PYTHONPATH=. running py.test and py.test2 python-pefile: - update available :P - "setup.py check" doesn't do what you think it does, it only checks some metadata and stuff, the target for setup.py you are looking for is "test"... but there are no tests provided by the exported tarball version you choose (there are also non-exported source tarballs containing them) python-virustotal-api: - "setup.py check" doesn't do what you think it does, it only checks some metadata and stuff, the target for setup.py you are looking for is "test"... if you want to run tests it provides nosetests via ./tests - requires dependency python{2}-requests python-terminaltables: - distributing LICENSE would be neat as they are inside the tarball python2-pydeep: - not an 'any' package as it compiles native code. - license can be distributed as its inside the tarball cheers, Levente