Re: Unable to push to or clone from existing aur package repo
On 24/07/12 07:00AM, Chris Speck wrote: > Hello, Hey Chris, do you still suffer from the issue you have described in your initial mail? > I know that my ssh keys and setup are working because it used to > function with the AUR and I continue to use it every hour of the day > at work. > > Any idea what is going wrong? Can you please help me fix this? No clue whats going wrong, especially since you still seem to be able to access the general ssh interface ... If the issue persists I think we'll need some more debug information, i.e. running with "export GIT_TRACE=1" set. There are also more[0] parameters like this, but I doubt the'll help with the issue we're (possibly) facing here. Also since "ssh a...@aur.archlinux.org" seems to work you could try to just leave the ssh:// specifier, since that seems to be the only notable difference between the commands. > Also, I am away for a few days at the start of next week - could you > please prevent any "orphaned package" requests while my access issues > are fixed? This should not be an issue as orphan requests have a 14 day cooldown period anyways. > Regards, > Chris Regards, Chris signature.asc Description: PGP signature
Re: hostility in the comments
On 24/07/08 11:25PM, james smith wrote: > A request for the pkgbuild to be updated[1] [2] quickly degenerated in > insults > [1]https://aur.archlinux.org/packages/sunshine?O=10#comment-981082 > [2]https://aur.archlinux.org/packages/sunshine?O=10#comment-981374 Hey james, thanks for bringing this to our attention, I have also received a report via private mail and have a look with the other moderators soon! Cheers, Chris signature.asc Description: PGP signature
Re: Package Maintainer application - Giovanni Harting
On 24/05/20 11:46AM, Giovanni Harting wrote: > Hey everyone. Hey Giovanni > 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 > ## 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. > - 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 樂 > 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=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! Cheers, chris [0]: https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_packages_entering_the_extra_repository signature.asc Description: PGP signature
Re: Package Maintainer application - Bert Peters
On 24/05/20 12:22PM, gromit wrote: > On 5/5/24 5:04 PM, gromit wrote: > > On 5/5/24 2:18 PM, Bert Peters wrote: > > > > > My name is Bert Peters, or bertptrs on IRC and various other places, > > > and I'm applying to become a package maintainer for Arch Linux. My > > > application is sponsored by Christian Heusel (gromit) and Jakub > > > Klinkovský (lahwaacz). > > > > > > This therefore marks the beginning of the discussion period which will > > last for 2 weeks until 2024-05-19 after which we will have the voting > > period, which will be announced separately. > > > The voting for this application is now live for one week (until ** > 2024-05-27 12:20 (CEST)): > > https://aur.archlinux.org/package-maintainer/153 The voting period has ended and we got ourselves a new packager: Yes: 41 No: 4 Abstain: 4 Participation: 76.56% (66% required) Congratulations to bertptrs! Cheers, gromit signature.asc Description: PGP signature
Re: User TalionRanger comments
On 5/25/24 2:19 PM, Fabio Loli wrote: A request for help quickly degenerated in several insults https://aur.archlinux.org/packages/octopi#comment-974574 https://aur.archlinux.org/packages/octopi#comment-974594 Please take appropriate action Hey Fabio, thanks for the heads-up, I have dealt with the problematic user! Cheers, gromit OpenPGP_signature.asc Description: OpenPGP digital signature
Re: tor-browser depublication and replacment
On 24/02/05 03:47AM, Zehka wrote: > Hello everyone, Hello! > Today i noticed by chance that the aur/tor-browser package is gone and > replaced by extra/torbrowser-launcher The aur/tor-browser package on the aur was merged[0] into aur/tor-browser-bin and was not replaced by extra/torbrowser-launcher as far as I understand it. > That worries me a bit because as a user of an aur helper i did either not > receive or see a notice about that so i stayed on version 12.5.3-1 that was > the last one on aur without noticing it was getting outdated. > I just wonder if that's common practice? This case is particularly unlucky > in my eyes because tor browser has a special role in the security concepts > of many people and because the new package is spelled torbrowser-launcher a > search in both databases with "yay tor-browser" in september only showed me > the aur result. > So i just wanted to ask if there is any possibility to make that transition > better because i assume i'm not the only user out there who didn't notice. Usually when a package is moved to the main repos the pkgrel is bumped so that people who already have it on their system get the update. Of course when it is also renamed at the same time things get a little more complicated and depending on how popular the package is a replaces directive is used or not. > And more thought that i had even though i didn't want to check in order to > cause unnecessary chaos: Is the name tor-browser now blocked in aur or could > anyone just upload a malicious package to that name and until somebody > notices that everyone who has the old tor browser and uses an aur helper for > updates gets a malicious version? You are advised to inspect every PKGBUILD on install and any update anyways and I'd say especially if you have a special threat model and/or care about security: "DISCLAIMER: AUR packages are user produced content. Any use of the provided files is at your own risk." and "Verify that the PKGBUILD and accompanying files are not malicious or untrustworthy."[1] > Regards > Zehka Cheers, gromit [0]: https://lists.archlinux.org/hyperkitty/list/aur-reque...@lists.archlinux.org/message/4RCWE2NX6E4NORQHVXR2TCGRUR756HSN/ [1]: https://wiki.archlinux.org/title/Arch_User_Repository#Installing_and_upgrading_packages signature.asc Description: PGP signature
Re: [PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
On 23/09/02 01:24AM, Christian Heusel wrote: > On 8/28/23 21:01, Christian Heusel wrote: > > On 8/24/23 13:08, Christian Heusel wrote: > > > On 23/08/24 01:33AM, Christian Heusel wrote: > > > > Most of our worflows have moved from mailing lists and patches to merge > > > > requests on gitlab. Until now amending the TU Bylaws formally requires > > > > sending patches via mail which this amendment intends to replace with > > > > merge requests on the gitlab repository. > > > As per the rules for amending the bylaws discussion period for the > > > proposal will last until Monday 28th August (5 days) with the voting > > > started afterwards and running until 4th September (7 days). > > > > The vote is now live: https://aur.archlinux.org/tu/148 > > There are three days left and we still need at least 18 people to vote to > achieve the quorum of 75%. > > Please go vote everybody :) > The proposal was voted as follows and is therefore accepted: - Yes: 49 - No: 2 - Abstain: 1 - Participation: 82.54% Thanks for participating everybody! ^_^ Chris / gromit signature.asc Description: PGP signature
Re: [PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
On 8/28/23 21:01, Christian Heusel wrote: On 8/24/23 13:08, Christian Heusel wrote: On 23/08/24 01:33AM, Christian Heusel wrote: Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days). The vote is now live: https://aur.archlinux.org/tu/148 There are three days left and we still need at least 18 people to vote to achieve the quorum of 75%. Please go vote everybody :) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
On 8/24/23 13:08, Christian Heusel wrote: On 23/08/24 01:33AM, Christian Heusel wrote: Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days). The vote is now live: https://aur.archlinux.org/tu/148 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
On 23/08/24 01:33AM, Christian Heusel wrote: > Most of our worflows have moved from mailing lists and patches to merge > requests on gitlab. Until now amending the TU Bylaws formally requires > sending patches via mail which this amendment intends to replace with > merge requests on the gitlab repository. As per the rules for amending the bylaws discussion period for the proposal will last until Monday 28th August (5 days) with the voting started afterwards and running until 4th September (7 days). I view as a rather formal change but if anyone objects I am happy to discuss. cheers, gromit signature.asc Description: PGP signature
[PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. Signed-off-by: Christian Heusel --- tu-bylaws.adoc | 19 --- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/tu-bylaws.adoc b/tu-bylaws.adoc index 376d909..70a8a27 100644 --- a/tu-bylaws.adoc +++ b/tu-bylaws.adoc @@ -170,21 +170,10 @@ These bylaws may be amended at any time. A TU must motion for an amendment by sending an announcement to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. -The message must either contain, or have attached, a Git-formatted patch -against this document which accomplishes the suggested change. The patch should -be based on the master branch of the official -https://gitlab.archlinux.org/archlinux/tu-bylaws.git/[tu-bylaws repository] and should -be sent "inline" (i.e. using `git send-email`) so that other TUs can easily -comment on specific parts. The strings `[PATCH]` and `[tu-bylaws]` should be -included in the subject. `git send-email --annotate` can be used to edit a -patch before sending it to the mailing list. - -Sending multiple patches is generally discouraged and should only be done if no -more than one of the patches are subject for debate (the remaining patches -might be formatting changes or minor wording changes). If multiple patches are -sent as part of one proposal, a cover letter describing the changes must be -included. The `--cover-letter` option of `git send-email` can be used to -achieve this. +The message must contain a link to a merge reqest in the official +https://gitlab.archlinux.org/archlinux/tu-bylaws[tu-bylaws repository] and the +merge request description should contain a meaningful description and +motivation for the change. SVP is commenced at the time of the motion, with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. -- 2.42.0
Re: application as package maintainer - fabiscafe
Excerpts from Fabian Bornscheins mail at 23/08/11 10:04AM: > Hey everyone! Hey Fabian! > Now that I'm back on Arch, I do help people on various platforms, such > as Fedi/Mastodon, Matrix, and Telegram. You can find me using my > 'fabiscafe' alias. I think I have also seen some helpful comments from you on Reddit :) > In the last 2-3 years, I've been working on another project: FCGU. > It's an Arch Linux repo for GNOME pre-releases. I started it because > testing GNOME pre-releases on Arch was tough, and the AUR wasn't > suitable for something as big as GNOME. What began as a personal > venture grew when others wanted to test it too. I reached out to find > some people who wanted to provide mirrors, and now it's a thing! :) > The PKGBUILDs are nowadays on Arch gitlab. While skimming through the packages a bit I found two things: - *rpan-studio*: (I saw afterwards that you wanted to drop the package[0] anyways ^^) - I think you could use `-DCMAKE_BUILD_TYPE=None` as per the cmake packaging guidelines[1] in build() - Currently fails to build > So, around 2015/16-ish, I found my way back to Arch, just to jump ship > yet again over to (oh no!) Manjaro. > Now I hope the Manjaro stuff doesn't exclude me directly and thanks > for reading all of this. :) Please dont overdo the "Manjaro bad" meme ... While arch sometimes has (had) a rocky relationship with its downstream distributions or their userbase (especially because of the fact that support is limited to arch only) there is nothing wrong with using them as long as its fullfills a usecase for you. > So, in a nutshell, I want to: > - Offer GNOME unstable releases (beta, rc) in gnome-unstable > - Assist in transitioning them to Arch once they become stable > versions I think you could be a great addition to the team, so good luck regarding the further application process! cheers, gromit [0] https://aur.archlinux.org/packages/rpan-studio#comment-826926 [1] https://wiki.archlinux.org/title/CMake_package_guidelines#CMake_can_automatically_override_the_default_compiler_optimization_flag signature.asc Description: PGP signature
Re: Fwd: vte-git, vte-common and toxic trolls
Hello tallero,
I think Antiz explained in his answer pretty nicely what was done why, please
re-read the mail if you want to understand why the Merge Request to vte-git was
rejected (for technical reasons) and why the behaviour of you and xiota is not
acceptable.
Considering the current state of things I also see no way that the merge
request (vte{3,4}-git -> vte-git) will ever be accepted, even with resolved
technical issues.
Your previous reply in this thread also makes a factual discussion really hard
as it resorts to personal accusations and twists facts to back your position.
Since your various mails also mention me multiple times I will say that neither
do I find any of my moderation actions around the mentioned requests erroneous
nor do I want to take any side in this argument.
So going forward let me remind you of the Archlinux Code of Conduct[1], which
encourages us as a community to work well with each other, leaving personal
issue aside and working together for the greater good of keeping the
distribution thriving.
That said this mail also serves as a warning for you to also adhere to the CoC.
Actually enforcing the CoC is a last resort though, so I am still hoping that
this will not be needed.
cheers,
gromit
[1] https://terms.archlinux.org/docs/code-of-conduct/
signature.asc
Description: PGP signature
Re: PKGBUILD for pissircd-git
Hey Ross! > Hey and hello, new here, and am wondering how to submit a patch to a > file... specifically the PKGBUILD for the package pissircd-git -- I've been > copying my own PKGBUILD file over during the generation of a package build > to avoid having it try to create a socket file in my home directory. Been > doing this for a long time, and am wondering how to make it more permanent. The most common way to get a patch to a maintainer is via email or as a comment on the AUR webinterface Most maintainers are happy to accept patches that fix things or nontrivial changes for an upgrade. cheers, gromit signature.asc Description: PGP signature
Re: Help with old large commit to AUR
Hey Iyán, > I think the issue is that in the past I commited a large patch file (by > mistake) instead of including the url in the sources array (that's commit > ef079835), and somehow the remote didn't complain back then but it does now. > > I have removed that patch and replace it with the upstream url, but I can't > push a new version. This is what I'm trying to commit: > > https://github.com/iyanmv/PKGBUILDs/commit/5e642048f438b3857007621d8b778689776244f3 Yes that indeed seems to be the issue here. If you compare the history of the PKGBUILD on GitHub[0] and on the aur[1] seems that the problematic commit is currently not in the aur and would only be added once your push goes through. You could try to remove the patch file from the problematic commits[2][3] and re-publish using aurpublish. Another solution which is maybe more easily doable is to directly clone the aur repo of python-tweedledum, re-apply and push the fixed changes (so without the big patch) and re-import the package into your GitHub repository. There is currently no need to rewrite the git history on the AUR, so you should be able to do this without TU support :) cheers, chris [0] https://github.com/iyanmv/PKGBUILDs/commits/main/python-tweedledum/PKGBUILD [1] https://aur.archlinux.org/cgit/aur.git/log/?h=python-tweedledum [2] https://github.com/iyanmv/PKGBUILDs/commit/03f29bc9219ecc3c35e969011dc810484b25584e [3] https://github.com/iyanmv/PKGBUILDs/commit/5e642048f438b3857007621d8b778689776244f3 signature.asc Description: PGP signature
Re: Non-git AUR with submodules
Hey Christian ;)
> I took over the package blink1. It is not a -git package so it should
> have a stable checksum, in my opinion. But since the project it builds
> uses a submodule, the package uses source=("git+https:/…) and SKIP for
> the checksum. This way prepare() can do a submodule init and submodule
> update.
This is described in the package guidelines[0], you resolve the tag to
the git commit it points at and pin that.
So the package still does have SKIP in the checksum array but you get
similar stability guarantees since you pinned the exact commit you
packaged.
If you need an example you can look at the PKGBUILD for pawxel[1].
> Is there a better way to deal with submodules?
See Dougs answer for the other tip regarding submodules and the source
array!
> Or would it be better to download the released binary for the correct
> architecture and install that?
> As I currently understand it this would only be acceptable for a -bin
> package, wouldn't it? (I found no clear guidance when to use that
> prefix, e.g. zoom)
This is then a different package, so its blink1-bin instead of blink1
since generaylly if you download a binary (for software where the source
is availiable) the -bin suffix should be used as per the AUR submission
guidelines![2]
> This is my first AUR and I'd like to do it properly.
Two other small points regarding the PKGBUILD on a quick glance would be:
- there is a duplicate source array
- you miss the Maintainer: comment (also see [2] for that)
Cheers,
Christian / gromit
[0] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_sources
[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=pawxel
[2]
https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submission
signature.asc
Description: PGP signature
Re: Error pushing package: "remote: fatal: bad object .alternate"
On 23/05/04 08:07PM, é wrote: > Hi all, > > I'm attempting to update https://aur.archlinux.org/packages/cpuset, and > cloning it works fine, however trying to commit and push changes results in > the following error (snipped): > > ``` > Total 5 (delta 0), reused 0 (delta 0), pack-reused 0 > remote: fatal: bad object .alternate > fatal: bad object refs/heads/python-degiro-connector > To ssh://aur.archlinux.org/cpuset.git > ! [remote rejected] master -> master (missing necessary objects) > error: failed to push some refs to 'ssh://aur.archlinux.org/cpuset.git' > ``` > > Also, interestingly enough it seems that python-degiro-connector itself has > some issues; cloning it via https simply fails: > > ``` > Cloning into 'python-degiro-connector'... > fatal: remote error: upload-pack: not our ref > ae7907349a087b4ec7e550cccbb059dc212d2bc9 > ``` > > Referring somehow to this commit > https://github.com/archlinux/aur/commit/ae7907349a087b4ec7e550cccbb059dc212d2bc9 > (which seems fine to me?) > > I don't know how to resolve this issue as I'm not familiar with git > alternates, and searching snippets of errors on the mailing list / google > was not fruitful. > Any suggestions? > > Best, > éclairevoyant Hey, just a quick heads up that this is a general problem with the aur right now and not connected to your updates or your actions. The person who pushed the update also said that it all worked on their side of things, so its most likely just a backend failure. Check out the comments of the mentioned package[0], there are more people waiting .. Thanks for putting together a nice report tho! cheers, chris / gromit [0] https://aur.archlinux.org/packages/python-degiro-connector signature.asc Description: PGP signature
Re: Application as Trusted User - gromit
On 23/04/21 01:30PM, Levente Polyak wrote:
> Hi there,
Hey anthraxx!
>
> I've been talking to Christian off-list and nobody yet seemed to have posted
> packaging feedback so I somehow squeezed in a bit of time and gave him a
> couple of packaging feedback lately. Just for transparency find that list
> here as well:
>
Thank you again for taking the time, its really appreciated!
If I only knew what I unleashed on myself with that tiny little question
;)
Most of your feedback I have already implemented in the PKGBUILDs, just
some was not released to the AUR yet as I will wait for the next
upstream release to include the changes.
> pawxel
> - you need to declare all submodule sources in the sources array, or they
> always get cloned freshly. take a look how "mono" does it, also note the
> submodule update command etc
Thank you for that remark, somehow I missed this information when
reading the article about VCS packages ...
I guess I have to read until the end the next time :D
https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules
> prometheus-mosquitto-exporter
> - you may also want to specify something like -X main.Version=${pkgver} so
> the binary reports the correct thing
> - prometheus-mosquitto-exporter.service a good start for hardening, but
> maybe you can borrow some more options depending on what it needs to access.
> things that come to my mind to look up what kind of hardening is available
> in the service is umurmur, caddy, tor, postgresql
>
Yes, I already thought about ways I could harden the systemd service but
tbh that's an area which is very new to me ... To start out reasonable I
just took the services of prometheus-node-exporter and modified them :p
But I will definitely check that out since I find learning some systemd
hardening interesting beyond the scope of packaging
prometheus-mosquitto-exporter!
> google-chrome-beta:
> google-chrome-dev
> - printing messages in the install file on every upgrade does not sound
> right
The google-chrome* packages could generally see some improvements, but
I am rather conservative with regard to changes in them as their
userbase is really large :D But the changes you suggested have already
been implemented.
General question: Is the Rule regarding custom variables and functions
beginning with an underscore also applicable for .install files?
> kopia:
> - we have tests, lets use them
Yes some of these currently seem to fail, that's why I put this change
on hold while I investigate whats going wrong there. Maybe this is a bug
I have to fix in packaging kopia or these are issues upstream has to
figure out.
https://github.com/christian-heusel/aur/pull/2
> Good luck,
> Cheers,
> Levente
Thanks!
Cheers,
Chris
signature.asc
Description: PGP signature
Re: Application as Trusted User - gromit
On 4/9/23 23:39, Brett Cornwall wrote: Hi, Chris! Hey Brett! I like the dedication to keeping packages managed rather than just bringing in a whole bunch of new packages. :) As time goes on I'll probably find some more software that could be brought to the official repos, but the status quo is pretty nice wrt the range of available packages. So far I could benefit from all the work that goes into maintaining the various repositories so I now want to take part in making all that work ... I also realized that updating software and being a packager is great fun to me during the testing for the git poc and by being an AUR maintainer! :p The quality of the packages is good! I like your commitment to following the wiki guidelines. I also appreciate your useful commit messages. I like that there's a TODO on one of your packages to upstream a patch: It's important to make sure all distros benefit, not just Arch! I love that you have comments telling *why* you do something out of the ordinary instead of randomly doing something with no explanation. Thank you for the overall positive feedback here! It's worth noting that only two packages have been maintained for more than a month; The rest of your packages were adopted/created only recently! I guess if you've had good commits, good adherence, and good community engagement, there's not much else to "prove". Yes, nice catch :D I recently upped my packaging game a bit, since this part of the application would be hard to judge for y'all otherwise ... So I packaged and adopted a few packages recently, where I also tried to improve the packages and make their PKGBUILDs more clean ... If you have more feedback just lemme know! :) I hope you have a great day, Chris OpenPGP_signature Description: OpenPGP digital signature
Application as Trusted User - gromit
Hello everyone! My name is Chris and I am a 24 year old computer science student from Heidelberg in southern Germany. With this mail I would like to apply to become part of the Trusted User group! I am happily using arch-based systems since 2016 and Archlinux since around 2018. Generally I use Linux systems since 2012, and have even worked as linux system administrator (paid and as volunteer) which was very fun! Aside from that I am trying my best to contribute to open source projects and the overall FOSS community, so far mostly by open sourcing personal projects, modifying & extending existing projets to my liking and reporting the bugs I find. Most of this activity is taking place on GitHub[0]. In my spare time I rock climb and hike, play the drums and I am an active youth lead in my local YMCA. In the last few years I also was very active in student politics but I am now winding down this involvement since I am about to finish my studies. Sometimes I can also be found in my local chaos computer club[1] chatting with other people about computers and stuff. In general you may know me better by the nick of "gromit" in IRC tho, under which I also participate in the various other arch resources: - Since 2018 I am part of the Arch Testing team to check packages in the various testing repos - I help out on the bugtracker[2] where I can, but I also just read a lot of it to keep up to date for support requests on IRC - I have some minor contributions on Gitlab[3], mostly around devtools and mkinitcpio - I participated in the proof of concept testing for the git package migration - I maintain packages on the Arch User Repository[4] and try to help out in the AUR comments aswell - I have some minor contributions on the wiki[5] - I also comment on /r/archlinux regularily (please note that reddit usernames[6] cannot be changed once created :p) To further extend this involvement and to help the arch community I am now applying as trusted user. Here is a collection of packages from [community] that I frequently use and could therefore possibly (Co-)Maintain: - bat 1 - blueberry 1 - borgmatic 1 - bpython 0 - gopass 2 - gopass-jsonapi 1 - gum 1 - lolcat 1 - mosquitto 1 - nemo 1 - nethogs 1 - pasystray 1 - polybar 1 - rofi-emoji 1 - scrcpy 1 - sxiv 1 - tailscale 1 - terminator 1 - unp 1 - variety 1 - yamllint 1 I especially selected these packages because they currently lack maintainers (except for gopass), but I am also open to help out with other packages! Additionally I could imagine bringing the following packages to the [community] repos, should I be accepted: - https://aur.archlinux.org/packages/ly - https://aur.archlinux.org/packages/nsxiv - https://aur.archlinux.org/packages/systemd-boot-pacman-hook My sponsors are Morten Linderud (Foxboron) and Robin Candau (Antiz) which I am both very thankful for because they also guided me through the application process! Cheers, and thanks for reading until here! Christian "gromit" Heusel [0] https://github.com/christian-heusel [1] https://www.noname-ev.de/howtotreff.html [2] https://bugs.archlinux.org/user/30483 [3] https://gitlab.archlinux.org/gromit [4] https://aur.archlinux.org/account/gromit [5] https://wiki.archlinux.org/title/Special:Contributions/Gromit [6] https://www.reddit.com/user/TheEbolaDoc OpenPGP_0xC047D4F328B52585.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
