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).
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. If possible I would like to support Arch in that direction, things that come to my mind are reproducible builds and CI/CD for repo packages, migration from SVN to Git might be a larger topic I could help with. Since I have an interest in keeping our GitLab packages stable and up-to-date I would like to co-maintain that if anatolik agrees.
Since the question comes up frequently in TU applications: I mainly use a Telegram RSS bot [4] to monitor releases and urlwatch for stuff without RSS feeds.
Best Regards hashworks
[1] https://aur.archlinux.org/packages/?K=hashworks&SeB=m [2] https://github.com/hashworks [3] https://git.hashworks.net/aur-packages [4] https://github.com/iovxw/rssbot/blob/2.x/README.en.md
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
On 08.06.20 15:11, Thore Bödecker via aur-general wrote:
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.
The discussion period is over, may the voting start:
https://aur.archlinux.org/tu/?id=122
Cheers
On 25.06.20 11:36, Thore Bödecker via aur-general wrote:
The discussion period is over, may the voting start:
The voting period is over and we have a result:
Yes: 28 No: 4 Abstain: 16 Participation: 85.71%
So congratulations are in order, welcome to the team!
Cheers
On Mon, Jun 08, 2020 at 03:08:04PM +0200, Discussion about the Arch User Repository (AUR) 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 confirm my sponsorship, may the discussion period begin.
shibumi
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
Hi Jonas,
I have had a quick look over your AUR packages and found some issues
Thanks, fixed!
zimwriterfs: [...] the upstream repository has recently been archived in favour of "zim-tools".
Good catch! I've created a new AUR package for "zim-tools". However, the current release does not yet include zimwriterfs, so I'll wait with the `replaces` tag until the next version.
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?
GitLab allows to create webhooks that trigger builds for a specific ref. Additionally one can provide variables in the request that appear in the pipeline. Currently I'm using IFTTT to trigger a webhook whenever a new GitHub release of a package is available (ATOM feed) – I'm planing to replace that in the near future so I don't depend on a third party service. Additionally some pipelines trigger other pipelines when a rebuild (pkgrel increase) is required.
Naturally new commits to the repositories (as in, changes to the PKGBUILD files) trigger the pipelines as well.
Best Regards hashworks
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 Jelle,
- 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.
I've switched to `#tag=${pkgver}?signed` and `validpgpkeys`. Much better than a checkout in `prepare()`, thanks!
- srrdb-terminal-client is not reproducible at least not as you embed
the build date.
Ah, correct. I've altered the date command to use `$SOURCE_DATE_EPOCH`, good to know that exists.
You can check if your package is reproducible by using `makerepropkg`.
I'll have to implement that in my pipeline, but that is something for the weekend.
Best Regards hashworks
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
Hi Levente,
Thanks for your review, packages have been updated accordingly.
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
It should be noted that this lead to a wiki change, which previously stated "Dependencies that are provided by other dependencies do not need to be listed" [1].
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
Fixed upstream [3], I've added the file in the package.
kiwix-desktop-git: [...]
- didn't have time, but does PREFIX really need to contain ${pkgdir}?
You're right, it doesn't.
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
Building stale QT software from 2015 is a little bit less love ;) Packages added [3] [4], but namcap complains: * ELF file ('usr/bin/prismatik') lacks FULL RELRO, check LDFLAGS * Unused shared library '/usr/lib/libGL.so.1'
I'll have to look into it.
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
As you said, I'm only waiting for a new version of zim-tools that includes zimwriterfs, so I'm not touching it for now. I'll keep gumbo-parser in mind.
Best Regards hashworks
[1] https://wiki.archlinux.org/?title=PKGBUILD&diff=prev&oldid=620592 [2] https://github.com/oznu/dns-zone-blacklist/pull/17 [3] https://aur.archlinux.org/packages/prismatik [4] https://aur.archlinux.org/packages/prismatik-psieg
aur-general@lists.archlinux.org