[aur-general] TU application for sudoforge
Hello good people and fellow miscreants, My name is Benjamin Denhartog, better known as sudoforge [0], and I'd like to formally submit an application to become a TU. I've maintained a few AUR packages for a while now [1], and you've probably seen me around and about in IRC (_mostly_ `#archlinux-offtopic` these days). Both Felix Yan (felixonmars) and Morten Linderud (Foxboron) have agreed to sponsor my application. I've been in, on, and around computers for my entire life (thanks fam), and have been involved in the open source community from the moment I started learning to program in the early 2000s. I currently work in the "DevOps" space, focusing on developer tooling, workflow automation, and all of the ancillary things that come with that, like infrastructure-as-code, CI/CD, observability and remediation. I enjoy mentoring less experienced engineers (and people brand new to technology alike), having been a part of mentorship and educational programs both at work and in the public (via Meetup). Outside of things related to computers, I enjoy snowboarding, cooking, and trying to take halfway-decent pictures. I currently live in the Rocky Mountains, somewhere around 3050m (9150ft) elevation, where the oxygen is a bit thinner, just like the crowds (except for the tourist-heavy days). Below are some of the things I pledge to do as a TU. # AUR packages that I'll move to community - bazelisk - buildozer - copybara (`copybara-git`) - firebase-tools - google-appengine-go - google-cloud-sdk - google-cloud-sdk-app-datastore-emulator - google-cloud-sdk-app-engine-java - google-cloud-sdk-app-engine-python - google-cloud-sdk-app-engine-python-extras - kind (`kind-bin`) - ledger-live - ledger-udev - lf Additionally, I'll be packaging the rest of the `google-cloud-sdk` plugins which are not yet packaged, and I'd love to help co-maintain or adopt Rust or Golang packages, and anything else that strikes my fancy along the way. # A non-exhaustive list of packages I use and would love to co-maintain - alacritty - bat - bazel - bottom - buildah - container-diff - crictl - critest - go - gopass - kubectl - kubectx - ledger - neomutt - packer - podman - restic - ripgrep - rtorrent - rust - rust-analyzer - rustup - signal-desktop - unbound - vault - zsa-wally-cli # Miscellaneous things I want to do - Take a look at the TU and maintainer workflows, and automate what can be automated (e.g. onboarding), with the goal of simplifying management of the Arch Linux ecosystem - Help out with infrastructure maintenance and other operational tasks - Make a billion dollars and never have to work again, so I can spend my time traveling and working on open source projects Thanks for taking the time to read this (or at least, quickly scan over the above wall of text). Take a break and get a coffee/tea/beer -- have a good weekend. [0]: https://aur.archlinux.org/account/sudoforge [1]: https://github.com/sudoforge/pkgbuilds All the best, sudoforge
On Sat, Jan 29, 2022 at 03:27:44PM -0700, Ben Denhartog via aur-general wrote:
Hello good people and fellow miscreants,
My name is Benjamin Denhartog, better known as sudoforge [0], and I'd like to formally submit an application to become a TU. I've maintained a few AUR packages for a while now [1], and you've probably seen me around and about in IRC (_mostly_ `#archlinux-offtopic` these days). Both Felix Yan (felixonmars) and Morten Linderud (Foxboron) have agreed to sponsor my application.
Yo, I confirm my sponsorship of sudoforge :) -- Morten Linderud PGP: 9C02FF419FECBE16
On 1/30/22 00:27, Ben Denhartog via aur-general wrote:
Hello good people and fellow miscreants,
My name is Benjamin Denhartog, better known as sudoforge [0], and I'd like to formally submit an application to become a TU. I've maintained a few AUR packages for a while now [1], and you've probably seen me around and about in IRC (_mostly_ `#archlinux-offtopic` these days). Both Felix Yan (felixonmars) and Morten Linderud (Foxboron) have agreed to sponsor my application.
I confirm my sponsorship. Let the discussion period begin :) -- Regards, Felix Yan
On 30/1/22 09:27, Ben Denhartog via aur-general wrote:
# AUR packages that I'll move to community
- kind (`kind-bin`)
- ledger-live I once tried to package this correctly, but it was non-trivial: at the time at least, it didn't neatly fit into the pattern of our existing electron application flows, and I recall it had a confusing build
Out of curiousity: why kind? At one point I used it, but found that for all use-cases k3s (or k3d) was a better choice. process (doesn't even node.js project? :/) How far have you gone down this rabbit hole?
On Fri, Feb 4, 2022, at 07:12, Daurnimator via aur-general wrote:
On 30/1/22 09:27, Ben Denhartog via aur-general wrote:
# AUR packages that I'll move to community
- kind (`kind-bin`)
Out of curiousity: why kind?
At one point I used it, but found that for all use-cases k3s (or k3d) was a better choice.
I wholeheartedly agree that k3s is preferred (and superior for many reasons) tool for running Kubernetes in the environments it targets (edge, arm, etc). It's actually the distribution I use for my Pi cluster (which runs a few lightweight things I want to keep local, such as dns, ad blocking, lightweight tasks, etc). I use GKE with k8s proper for everything else. I have two use cases for Kind: - Spinning up and running N versions of Kubernetes locally on my machine when desired, such as for testing services locally when I'm offline and unable to get networked (e.g., when traveling in remote areas, or on a plane without internet access, or really, really poor internet access). This is infrequent, but useful. - Running tests against Kubernetes within my CI pipeline. This is a dark and cavernous rabbit hole that most people might want to run away from, but is a standard part of my infrastructure test suite. An alternative to using Kind within my cluster (which I'm in the middle of exploring) is to spin up ephemeral, separate clusters within my cloud environment.
- ledger-live I once tried to package this correctly, but it was non-trivial: at the time at least, it didn't neatly fit into the pattern of our existing electron application flows, and I recall it had a confusing build process (doesn't even node.js project? :/)
How far have you gone down this rabbit hole?
Not that far at the moment, to be honest. The AUR package [0] is currently built using `yarn`, and is fairly straightforward, but I'm not sure what the existing electron flows are, or how this may need to be refactored to fall in line. Optimizing and standardizing this is something I'd explore in greater detail before moving it to community. [0]: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=ledger-live
On 5/2/22 03:01, Ben Denhartog via aur-general wrote:
I'm not sure what the existing electron flows are
See https://wiki.archlinux.org/title/Electron_package_guidelines
Thanks for the link; I somehow missed that when searching the wiki prior to sending my previous reply. I'd have to play around with patching `ledger-live` to see if I ran into a set of similarly challenging issues that you did -- something I don't see as a necessary task until I begin exploring porting it to community. -- Ben Denhartog ben@sudoforge.com
Hi, On 29/01/2022 23:27, Ben Denhartog via aur-general wrote:
Hello good people and fellow miscreants,
My name is Benjamin Denhartog, better known as sudoforge [0], and I'd like to formally submit an application to become a TU. I've maintained a few AUR packages for a while now [1], and you've probably seen me around and about in IRC (_mostly_ `#archlinux-offtopic` these days). Both Felix Yan (felixonmars) and Morten Linderud (Foxboron) have agreed to sponsor my application. <snip> Below are some of the things I pledge to do as a TU.
# AUR packages that I'll move to community
Some notes on the proposed packages:
- bazelisk
No offense, but the Github description made me think, "now I have bazel and Golang, now I have three problems".
- buildozer
This seems to not use the AUR bazelisk package for building, but a release from github? Why doesn't it use the AUR package? I myself try to avoid using "advanced" (or hard to read) bash in PKGBUILDs such as here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44
- copybara (`copybara-git`) - firebase-tools - google-appengine-go
This depends on python2, something we want to get rid of :)
- google-cloud-sdk - google-cloud-sdk-app-datastore-emulator - google-cloud-sdk-app-engine-java - google-cloud-sdk-app-engine-python - google-cloud-sdk-app-engine-python-extras
These don't seem to be super popular packages, what would be the benefit of having them in the repo? It seems that the Python runtime is python2 something we actively want to get rid off. Secondly why can't it install itself in the proper location /usr/lib/python2.7/site-packages/$thing?
- kind (`kind-bin`) - ledger-live - ledger-udev - lf
Additionally, I'll be packaging the rest of the `google-cloud-sdk` plugins which are not yet packaged, and I'd love to help co-maintain or adopt Rust or Golang packages, and anything else that strikes my fancy along the way.
# A non-exhaustive list of packages I use and would love to co-maintain
- alacritty - bat - bazel - bottom - buildah - container-diff - crictl - critest - go - gopass - kubectl - kubectx - ledger - neomutt - packer - podman - restic - ripgrep - rtorrent - rust - rust-analyzer - rustup - signal-desktop - unbound - vault - zsa-wally-cli
Sounds good!
# Miscellaneous things I want to do
- Take a look at the TU and maintainer workflows, and automate what can be automated (e.g. onboarding), with the goal of simplifying management of the Arch Linux ecosystem
Cool, the current pain points are that archlinux.org is not on SSO, mailman subscriptions aren't automated for Staff. Help is certainly welcome there, so feel free to drop in #archlinux-devops with questions :) Thanks for applying, Jelle van der Waa
# AUR packages that I'll move to community
Some notes on the proposed packages:
- bazelisk
No offense, but the Github description made me think, "now I have bazel and Golang, now I have three problems".
I'm not sure I follow you. Bazelisk is written in Golang, sure, but it's a thin executable that downloads an appropriate version of Bazel for any given workspace. I'm not sure what your familiarity with Bazel is as a contributor or user, but Bazelisk is pretty much the defacto "bazel" binary for most heavy users (companies, contributors, people who work in Bazel workspaces...).
- buildozer
This seems to not use the AUR bazelisk package for building, but a release from github? Why doesn't it use the AUR package?
I like to keep things simple for users. For AUR packages, that means trying to avoid depending on other AUR packages, as in my experience, most utilities that people use cannot resolve them, especially if they are building in a chroot.
I myself try to avoid using "advanced" (or hard to read) bash in PKGBUILDs such as here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44
Perhaps it is because I use parameter substitution in shell scripts regularly, I don't find that to be particularly hard to read. I understand that it could cause users who are not familiar with parameter substitution to scratch their heads, though, and think that's a fair comment and something that could be changed.
- copybara (`copybara-git`) - firebase-tools - google-appengine-go
This depends on python2, something we want to get rid of :)
I assume you only meant to include google-appengine-go here. Understandable, but python2 is an optdep, and I don't control upstream -- however, patching the source to remove the dependency on py2 altogether is something that's very feasible, and I'd glady do.
- google-cloud-sdk - google-cloud-sdk-app-datastore-emulator - google-cloud-sdk-app-engine-java - google-cloud-sdk-app-engine-python - google-cloud-sdk-app-engine-python-extras
These don't seem to be super popular packages, what would be the benefit of having them in the repo? It seems that the Python runtime is python2 something we actively want to get rid off.
Except for google-cloud-sdk (which I'd argue is fairly popular), the component packages are additional utilities supporting the gcloud ecosystem. If the former is moved into community (which I believe makes sense, as it's a common tool used both in corporate and individual environments), then I personally think it makes sense to move the component packages into community as well. That said, it is possible to install the components from the gcloud command line tool, which could be enabled -- it's disabled to support using ALPM for the components.
Secondly why can't it install itself in the proper location /usr/lib/python2.7/site-packages/$thing?
I adopted the package and simply haven't made that adjustment, although it's one that I should.
# Miscellaneous things I want to do
- Take a look at the TU and maintainer workflows, and automate what can be automated (e.g. onboarding), with the goal of simplifying management of the Arch Linux ecosystem
Cool, the current pain points are that archlinux.org is not on SSO, mailman subscriptions aren't automated for Staff. Help is certainly welcome there, so feel free to drop in #archlinux-devops with questions :)
Will do! -- Ben Denhartog ben@sudoforge.com
On 2022-02-07 13:33, Ben Denhartog via aur-general wrote:
- buildozer
This seems to not use the AUR bazelisk package for building, but a release from github? Why doesn't it use the AUR package?
I like to keep things simple for users. For AUR packages, that means trying to avoid depending on other AUR packages, as in my experience, most utilities that people use cannot resolve them, especially if they are building in a chroot.
It's more important to be correct than convenient. Downloading the builder is not appropriate here.
I myself try to avoid using "advanced" (or hard to read) bash in PKGBUILDs such as here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44
Perhaps it is because I use parameter substitution in shell scripts regularly, I don't find that to be particularly hard to read. I understand that it could cause users who are not familiar with parameter substitution to scratch their heads, though, and think that's a fair comment and something that could be changed.
This is not a matter of understanding but of readability. I'm with Ben here: It's better to be clear than clever.
On 2022-02-07 16:07, Brett Cornwall via aur-general wrote:
On 2022-02-07 13:33, Ben Denhartog via aur-general wrote:
- buildozer
This seems to not use the AUR bazelisk package for building, but a release from github? Why doesn't it use the AUR package?
I like to keep things simple for users. For AUR packages, that means trying to avoid depending on other AUR packages, as in my experience, most utilities that people use cannot resolve them, especially if they are building in a chroot.
It's more important to be correct than convenient. Downloading the builder is not appropriate here.
I myself try to avoid using "advanced" (or hard to read) bash in PKGBUILDs such as here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44
Perhaps it is because I use parameter substitution in shell scripts regularly, I don't find that to be particularly hard to read. I understand that it could cause users who are not familiar with parameter substitution to scratch their heads, though, and think that's a fair comment and something that could be changed.
This is not a matter of understanding but of readability. I'm with Ben here: It's better to be clear than clever.
Do you have any response to these statements? I'm curious to hear your thoughts.
On Mon, Feb 7, 2022, at 17:07, Brett Cornwall via aur-general wrote:
On 2022-02-07 13:33, Ben Denhartog via aur-general wrote:
- buildozer
This seems to not use the AUR bazelisk package for building, but a release from github? Why doesn't it use the AUR package?
I like to keep things simple for users. For AUR packages, that means trying to avoid depending on other AUR packages, as in my experience, most utilities that people use cannot resolve them, especially if they are building in a chroot.
It's more important to be correct than convenient. Downloading the builder is not appropriate here.
I have no issue with making this adjustment prior to moving the package into community. I'm recalling now that the change was initially made due to a `bazel` version mismatch between what was available in community and what was specified in the `bazelisk` repository; this is mentioned in the commit message that introduced this change [0]. As an alternative to doing this, patching the `.bazelversion` file is what I'd likely end up doing in community if/when the same issue occurs in the future (or simply hold updates while working on getting bazel updated [my understanding is that tensorflow is the main antagonist during major upgrades]). [0]: https://github.com/sudoforge/pkgbuilds/commit/15bc9c863219e7a3d2a94430ccd062...
I myself try to avoid using "advanced" (or hard to read) bash in PKGBUILDs such as here https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=buildozer#n44
Perhaps it is because I use parameter substitution in shell scripts regularly, I don't find that to be particularly hard to read. I understand that it could cause users who are not familiar with parameter substitution to scratch their heads, though, and think that's a fair comment and something that could be changed.
This is not a matter of understanding but of readability. I'm with Ben here: It's better to be clear than clever.
I think you meant to say that you're with Jelle, correct? While I don't personally find any sort of difficulty in reading through parameter substitution, it seems like this is a sticking point, and that's perfectly fine. Refactoring that is straightforward and not something I'm going to contend with. -- Ben Denhartog ben@sudoforge.com
Il 29/01/22 23:27, Ben Denhartog via aur-general ha scritto:
# AUR packages that I'll move to community [...] - kind (`kind-bin`)
Hello, kind is open source and hosted on github, is there any problem compiling it from source?
No, it's pretty straightforward, but note that being "closed source" and/or "difficult to compile from source" are not qualifying factors for determining whether or not a package should be moved to community. I'm not arguing that `kind-bin` _should absolutely_ be moved to community, simply that the parameters you're asking about are not pertinent to whether or not it is. -- Ben Denhartog ben@sudoforge.com On Thu, Feb 17, 2022, at 10:41, Fabio Loli via aur-general wrote:
Il 29/01/22 23:27, Ben Denhartog via aur-general ha scritto:
# AUR packages that I'll move to community [...] - kind (`kind-bin`)
Hello, kind is open source and hosted on github, is there any problem compiling it from source?
On 2022-02-17 11:59, Ben Denhartog via aur-general wrote:
No, it's pretty straightforward, but note that being "closed source" and/or "difficult to compile from source" are not qualifying factors for determining whether or not a package should be moved to community.
I'm not arguing that `kind-bin` _should absolutely_ be moved to community, simply that the parameters you're asking about are not pertinent to whether or not it is.
To be honest, I'm not sure what you're arguing here. Are you saying that software being closed source or with significant compiling difficulty would have no bearing on their inclusion into [community]. Are you saying that you would rather bring in binary releases into the repositories? (BTW, please do bottom post on Arch mailing lists :))
On Thu, Feb 17, 2022, at 14:22, Brett Cornwall via aur-general wrote:
On 2022-02-17 11:59, Ben Denhartog via aur-general wrote:
No, it's pretty straightforward, but note that being "closed source" and/or "difficult to compile from source" are not qualifying factors for determining whether or not a package should be moved to community.
I'm not arguing that `kind-bin` _should absolutely_ be moved to community, simply that the parameters you're asking about are not pertinent to whether or not it is.
To be honest, I'm not sure what you're arguing here. Are you saying that software being closed source or with significant compiling difficulty would have no bearing on their inclusion into [community]. Are you saying that you would rather bring in binary releases into the repositories?
Ah, I get the issue. Yes, the AUR package is a binary package; no, if it were moved to community I would not be downloading the release binary but instead building from source in accordance with the Go Package Guidelines [0]. I replied off-the-cuff while in a meeting and completely glossed over that aspect of the discussion. [0]: https://wiki.archlinux.org/title/Go_package_guidelines
(BTW, please do bottom post on Arch mailing lists :))
Good catch :) -- Ben Denhartog ben@sudoforge.com
On 2022-01-29 15:27:44 (-0700), Ben Denhartog via aur-general wrote:
Hello good people and fellow miscreants,
Hi Ben, sorry I'm a bit late to the party.
# AUR packages that I'll move to community
- kind (`kind-bin`)
I guess that would be interesting (from source)
# A non-exhaustive list of packages I use and would love to co-maintain
- crictl - critest
Here we can use some effort to upstream fixes so that it is easier to build.
- kubectl
This comes at the cost of maintaining the kubernetes pkgbase. I would be interested to hear your thoughts on improvements and or post-build test scenarios for this (that we can hand to the testers).
- podman
This is an interesting one, especially in regards to e.g. containers-common, which is still a bit weird and only recently we have found out how it is "supposed to be packaged". Do you have any improvement suggestions for it and/or test scenarios that you could think of?
- zsa-wally-cli
If you have improvement suggestions for this in regards to providing fixes for upstream, that would be very much appreciated. Upstream unfortunately does not use their issue tracker anymore and expects people to send mails. They are unfortunately also easily offended :S
# Miscellaneous things I want to do
- Take a look at the TU and maintainer workflows, and automate what can be automated (e.g. onboarding), with the goal of simplifying management of the Arch Linux ecosystem - Help out with infrastructure maintenance and other operational tasks
That would be much appreciated. We can always use help in automating our things away. What comes to mind here (apart from the packager workflows) is e.g. our installation artifact release process and also our CI integration with archlinux-keyring to detect soon expired keys as soon as possible, to list a few that are rather pressing and/or fall on our feet from time to time. A good place to idle for that would be #archlinux-releng and #archlinux-projects! :) Best, David -- https://sleepmap.de
On Fri, Feb 18, 2022, at 02:51, David Runge wrote:
On 2022-01-29 15:27:44 (-0700), Ben Denhartog via aur-general wrote:
- crictl - critest
Here we can use some effort to upstream fixes so that it is easier to build.
I'm happy to help with that.
- kubectl
This comes at the cost of maintaining the kubernetes pkgbase. I would be interested to hear your thoughts on improvements and or post-build test scenarios for this (that we can hand to the testers).
Kubernetes has a pretty robust test suite. To better understand how to improve our post-build test scenarios, I'd want to take a look at what we're currently doing. Personally, new versions of Kubernetes are tested in my pipeline as such before upgrading: - A cluster-in-clu - The new version is deployed - Upstream's E2E test suite is ran (kubetest2). This tests API conformance. - My own tests specific to my environment, which is used to test basic workflows like deploying a dummy application and routing to it, etc. This is robust, but comes at a cost (both financial cost of the infra and the opportunity cost of the time spent building this out). Whether or not doing this within the Arch Linux ecosystem makes sense is something we'd need to discuss.
- podman
This is an interesting one, especially in regards to e.g. containers-common, which is still a bit weird and only recently we have found out how it is "supposed to be packaged". Do you have any improvement suggestions for it and/or test scenarios that you could think of?
Well, we could start by running upstream's tests :) I agree that the separation they have for documentation and libraries that are shared into the "common" repository is... different. Heavy reusability is why I prefer monorepos, so perhaps I'm biased against this separation.
- zsa-wally-cli
If you have improvement suggestions for this in regards to providing fixes for upstream, that would be very much appreciated. Upstream unfortunately does not use their issue tracker anymore and expects people to send mails. They are unfortunately also easily offended :S
What sort of issues are you encountering? I haven't packaged this myself, but from the PKGBUILD, it doesn't seem like there's complexity to it (or the graphical app) that require upstream patches.
What comes to mind here (apart from the packager workflows) is e.g. our installation artifact release process and also our CI integration with archlinux-keyring to detect soon expired keys as soon as possible, to list a few that are rather pressing and/or fall on our feet from time to time. A good place to idle for that would be #archlinux-releng and #archlinux-projects! :)
Both of those sound like the sort of projects I'd like to look at and work to improve. I'll follow up with you in IRC. -- Ben Denhartog ben@sudoforge.com
- A cluster-in-clu
Whoops, I didn't quite finish this thought. s/.*/A cluster-in-cluster deployment is created (I currently use Kind)/ -- Ben Denhartog ben@sudoforge.com
The discussion period is over, but please do continue discussing if there are any unresolved questions :) Voting has started: https://aur.archlinux.org/tu/135 -- Morten Linderud PGP: 9C02FF419FECBE16
Yo! During the voting of this application we experienced something we haven't seen before. Mainly that we did not reach the participation number we need to get a consensus on the application. This has never happened before and we suspected it might had been because of the recent aurweb release. After a bit of mocking around we discovered our mailserver had a queue with 2.7k emails and a *lot* of people expecting vote reminder emails simply did not get them. This resulted in the application being rejected because of a technical issue. This shouldn't happen, and the TU Bylaws doesn't account for errors like this. That means Ben would have to reapply in 3 months time which is silly. After a small discussion on the internal TU list we decided we'll allow a revote on this application and pay a bit more attentio to the email queue so all the emails people expect do get sent out. However, due to an aurweb bug I had issues submitting the new application. This has been fixed :) Please go vote! https://aur.archlinux.org/tu/136 Thanks for your patience. I have included the results of the previous application for the sake of transparency. Yes No Abstain Total Voted Participation 27 4 8 39 Yes 63.93% -- Morten Linderud PGP: 9C02FF419FECBE16
After almost 2 months we have the results :) Yes No Abstain Total Voted Participation 39 6 7 52 Yes 85.25% Congratulations on becoming a Trusted User! Start reading the wiki and we'll get you sorted out over the next couple of days :) https://wiki.archlinux.org/title/AUR_Trusted_User_Guidelines#TODO_list_for_n... -- Morten Linderud PGP: 9C02FF419FECBE16
participants (8)
-
Ben Denhartog
-
Brett Cornwall
-
Daurnimator
-
David Runge
-
Fabio Loli
-
Felix Yan
-
Jelle van der Waa
-
Morten Linderud