Hey o/ On 08.06.20 15:08, hashworks via aur-general wrote:

My name is Justin Kromlinger aka hashworks and I'm applying as a Trusted User with the sponsorship of Thore Bödecker aka foxxx0 and Christian Rebischke aka shibumi who recently reviewed my AUR packages [1] – thanks for that!

I am confirming my sponsorship. Cheers -- Thore "foxxx0" Bödecker GPG ID: 0xEB763B4E9DB887A6 GPG FP: 051E AD6A 6155 389D 69DA 02E5 EB76 3B4E 9DB8 87A6

Hi hashworks, On 2020-06-08 15:08, hashworks via aur-general wrote:

My name is Justin Kromlinger aka hashworks and I'm applying as a Trusted User with the sponsorship of Thore Bödecker aka foxxx0 and Christian Rebischke aka shibumi who recently reviewed my AUR packages [1] – thanks for that! Some may know me from freenode#archlinux.de, where I'm lingering since a few years. I am and will be reachable there anytime.

I have had a quick look over your AUR packages and found some issues: brickstrap-git: should provide and conflict on "brickstrap" (even though there is currently no such AUR package, it would be easy to create one at any time given upstream has stable releases). certbot-dns-hetzner-git: remove the leading "v" in pkgver, see [1]. dns-zone-blacklist-git: missing provides and conflicts on "dns-zone-blacklist". goaccess-git: remove the leading "v" in pkgver, use 'make DESTDIR="$pkgdir" install' instead of 'prefix="$pkgdir/usr" sysconfdir="$pkgdir/etc"'. i3blocks-contrib: remove the useless provides and conflicts entries for itself. mustache: since this package only installs an architecture-independent header file, it should be arch=('any'). pam-ihosts: remove the makedepends on "gcc" and "binutils" since they are in base-devel [2]. pam-ihosts-git: remove the makedepends on base-devel packages, arch should be "x86_64" instead of "any" (like pam-ihosts). prismatik-bin: the package currently conflicts on "prismatik-psieg", which prismatik-sieg-git doesn't even provide. Just let prismatik-bin conflict on prismatik instead (like you already do for prismatik-psieg-git). zimwriterfs: arch should be "x86_64" instead of "any", also the upstream repository has recently been archived in favour of "zim-tools".

For most of my packages I use a personal GitLab instance to verify the builds with a pipeline [3] and since a while the process of new releases is automated.

I like the sound of that! Out of curiosity, do you trigger builds for every upstream commit of VCS packages, or is it linked to committing new revisions of a PKGBUILD file? Best of luck with your application! Jonas [1] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Git [2] https://wiki.archlinux.org/index.php/PKGBUILD#makedepends

On 08/06/2020 15:08, hashworks via aur-general wrote:

Hello everyone,

My name is Justin Kromlinger aka hashworks and I'm applying as a Trusted User with the sponsorship of Thore Bödecker aka foxxx0 and Christian Rebischke aka shibumi who recently reviewed my AUR packages [1] – thanks for that! Some may know me from freenode#archlinux.de, where I'm lingering since a few years. I am and will be reachable there anytime.

I was born in Germany in 1994. My oldest Arch installation dates back to the month of July in 2015, at least according to my pacman logs. Just a year later I successfully qualified as an IT specialist in application development, together with a (soon to be expired) LPIC-1 certificate. Last year I got my bachelor's degree in informatics in Leipzig (come visit me at the C3!), where I currently study for a master's degree. So you could say Arch Linux accompanied my whole education!

I started my first job at a small web agency as a Developer, but I slowly but surely turned into their System Administrator. At my current job for a larger IT company my external e-mail signature states I'm a "DevOps Engineer" – and while that term is by all means not fully defined, it kinda describes what I do. I create and maintain pipelines (mainly GitLabCI), design deployment processes and try to make our Docker Images a bit saner every day. And since I was able to enforce using Arch Linux on my work ThinkPad the distribution keeps on supporting my life, so I might try to give a little back! While I try to do some FOSS development in Go or – more recently – Rust now and then [2], my free time mostly flows into the maintenance of software and infrastructure for friends and family – and I have to admit that BASH remains my most fluent language.

Regarding my own packages I would like to move filebin and pam-ihosts since I use those on my servers. srrdb-terminal-client is also something I regularly use that I would like to move. Additionally I would like to ask to take over kiwix-desktop of which I maintain the dependency chain (kiwix-lib, libzim and mustache) – and while I'm at it the whole stack (mainly kiwix-tools). Other small packages that would suite Community are mdcat and insect if the current maintainers agree. i3blocks-contrib is another possible candidate, but I would need to request new and frequent releases for that. Out of the orphaned packages the only one I could reasonably maintain is hddtemp (since I still use it).

I quickly looked at your packages and found a few issues: * filebin - the package is not -git but does pull from git master, ideally it would use #commit= and maybe verify the commit if it's signed. source=("git+https://github.com/Bluewind/filebin.git" * srrdb-terminal-client is not reproducible at least not as you embed the build date. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=srrdb-terminal-client... This can be fixed with using SOURCE_DATE_EPOCH as for example is applied here: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... You can check if your package is reproducible by using `makerepropkg`. Greetings, Jelle van der Waa

Hi hashworks, some findings while I looked over your packages: Tiny side notes: nothing that really changes but I noticed you added some prefixed sources like ${pkgname}-${pkgver}.tar.gz:: to github urls, just wanted to make you aware github understands the following pattern: source=("${url}/archive/v${pkgver}/${pkgname}-${pkgver}.tar.gz") I've seen lots of .gitignore that contain "*.tar.*" and thought maybe worth mentioning the existence of SRCDEST and PKGDEST which IMO is super handy compared to spitting out stuff into CWD. I've nearly never seen the distribution of README.md when it contains some useful bits that may help people in /usr/share/doc/${pkgname} not like that's a requirement or such, but can sometimes be super useful. brickstrap-git: - should distribute the man page it stores in docs by processing it via pandoc --standalone --to man docs/brickstrap.md > docs/brickstrap.1 certbot-dns-hetzner: - uses setuptools entry_point so python-setuptools is a first level hard dependency - missing hard requires on python-requests and python-zope-interface as used in the modules certbot-dns-hetzner-git: - same as certbot-dns-hetzner dns-zone-blacklist-git: - doesn't properly distribute a license declaration but just a comment about the json that declares the license type. Please distribute something in the licenses folder and ask upstream to provide a license file in tree filebin: - downloads all submodules all the time, must be declared in the source=() array and the url of the submodules updated to reflect the dependencies like f.e. mono does. kiwix-desktop-git: - the qmake file doesn't understand CPPFLAGS, you need to add that as a workaround to the regular flags to enable fortified sources - didn't have time, but does PREFIX really need to contain ${pkgdir}? libzim: - should add explicit nepends on zstd as in fact it gets enabled automatically and hence is a hard dependency mustache: - project contains the tests via cmake that can be called in check() to ensure stuff most likely will work pam-ihosts: - does not respect CPPFLAGS nor LDFLAGS leading to unfortified binary without full RELRO as namcap also complains - declares -fno-stack-protector... excuse me? ehm just no :D - distributes an empty /usr/bin which isn't desired pam-ihosts-git: - same as pam-ihosts prismatik-bin: - hmm sources exist and a -git package seems to be possible, why not build from source instead? we love sources :) prismatik-psieg-bin: - same as prismatik-bin, more source more love terraformer: - RADME.md looks super useful, maybe worth distributing zimwriterfs: - does this really require gumbo-git, it has like 5 more commits since 2015 compared to repo gumbo-parser. Maybe would make more sense to poke some upstream folks to tag a new version instead? - seems to soon be superseded by zim-tools anyway cheers, Levente