On 02/06/2024 01:11, Christian Heusel wrote:
On 24/05/20 11:46AM, Giovanni Harting wrote:
Hey everyone.

Hey Giovanni 👋


Hey Christian.

I'm hereby applying as a package maintainer,
which is kindly sponsored by David (dvzrv) and Jelle (jelly) and formally by
Levente (anthraxx), for whom Jelle has taken over the sponsorship.

Thanks for applying and good luck in the process! 😋
Sorry for replying last minute, but I didn't find the time / got
sidetracked with other things in the last week!

## Who

I'm Giovanni, also known as anonfunc or idlegandalf. I've been using Arch
Linux as my day-to-day driver since 2013 and Linux in general since probably
2008 (mostly server-side until 2011-12, last Windows I actually used was 7).
As for notable contributions, you might have heard of ALHP, which I started
in 2020.

ALHP developed from the idea of utilising modern CPU extensions all the way
back in Q4 2019 (after I had a quick Gentoo detour on one of my laptops). At
the time, no x86_64 levels were defined, so the first rough outlines still
considered building for specific gcc CPU-baselines, like Haswell for example
(which seems crazy in hindsight). When the x86_64 levels were announced in
2020, I started developing a buildbot capable of doing the heavy lifting, at
the time in Python. After ditching Python in 2021 (after I got annoyed of
multi-process) and rewriting the buildbot in Go, the project launched in
July 2021. At the time, ALHP only provided x86_64-v3, shortly after launch
x86_64-v2 followed. In December 2023 the x86_64-v4 repo launched, after I
got my hands on a machine capable of building v4.
Not sure how many users it actually has, since I do not do any tracking, but
as far as requests on the tier 0 mirror go (ALHP has 7 mirrors in total, one
operated by myself), it seems to see some usage.
The buildbot is completely FOSS, you can have a look down in the links
section.

That sounds cool and like a very useful addition to the team!

In which way did these endeavours make you contribute back to the Arch
Linux ecosystem so far? Because your name only rings a bell for me
regarding the ALHP project but not i.e. via bug reports, merge requests
or similar 🤔 Then again I'm not part of the team for too long 😄


There are a few here and there, but that's mostly packaging stuff (most recent one was a (more or less) missing mesa dep. I found because the ALHP build failed). There are also some related to outdated packages (like firefox currently not building because llvm introduced a bug in 18.1 preventing the build with lto: https://somegit.dev/ALHP/ALHP.GO/issues/222), for which I do not want to file bugs. I think most would creep up if Arch would introduce x86_64-v3, since there are quite a few special snowflake packages that I collected over the years :)

pkgctl has a few odd behaviours (like if/when one moves a package between any and x86_64) I want to have a look at that if I find time. Until now I mostly "fixed" things like this on ALHPs end, but I think now is certainly the time to change that. The git migration also helped immensely in that area :)

## Goals & Packages

I want to help with package maintenance and advance infrastructure topics
with the overall goal of bringing x86_64-v3 and build automation to life, as
well as helping with potential problems that may come with v3, since ALHP
had plenty of those already.

Sounds good, especially since this is already ratified from the RFC side
(RFC002) and can (in theory) just be started with!

As for packages, I have a few that I think would benefit the general Arch
Linux audience by being promoted to official packages, mostly QoL stuff:

- batsignal

Is this an AUR package already? If yes I think I couldn't find it.


https://aur.archlinux.org/packages/batsignal

- wljoywake
- jellyfin-mpv-shim (+ deps)
- prismlauncher
- victoriametrics
- asus-numpad
- mmdbinspect

With regard to votes & popularity some of these seem a bit low (with
prismlauncher being the obvious outlier), so even though the related
rules[0] are not enforced strictly some of these might need some extra
consideration 🤔


Sure, if you have anything in mind regards to what should be considered, please let me know.

I'm also open to co-maintainer roles if there are any packages in need.
Candidates could include DevOps related packages like Grafana or packages
from the Go ecosystem in general, since I use that language extensively.

Besides the mentioned categories, I'm also interested to co-maintain:

- home-assistant
- jellyfin

## Links

AUR packages: https://aur.archlinux.org/packages?SeB=m&K=anonfunc
AUR source repo: https://somegit.dev/anonfunc/aur-packages

I had a quick look at your AUR packages and didn't find many extra
comments to those of Antiz. Some things are weirdly indented, but well
thats just nitpicking 😆

ALHP: https://somegit.dev/ALHP/ALHP.GO
ALHP Status: https://status.alhp.dev/

Feel free to criticise PKGBUILDs to your heart's content :) Improvement is a
continuous thing, so keep them coming.

Giovanni

Again, thanks for applying and I already got some ideas/questions
looking at the repositories so I'm looking forward to having you on the
team and discussing/implementing these things! 🚀


Happy to be here and looking forward to getting things rolling :)

Cheers,
chris

[0]: 
https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_packages_entering_the_extra_repository

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to