please unsubscribe me from your mailing list

On 6/10/21 1:15 PM, Caleb Maclennan via aur-general wrote:

Hello all!

My name is Caleb Maclennan (AUR moniker “caleb”, most other places “alerque”). I’m a long time Arch Linux user and AUR contributor looking to get more involved, and specifically to join the TU group so that I can help out with packages in [community]. I’m particularly interested in the Lua ecosystem (which thanks largely to @Daurnimator is much less of a mess than it was a year ago when I first started looking into becoming a TU, but could still use a helping hand) as well as anything related to font development or typesetting. As you’ll see I have some experience in FOSS, software packaging, and Linux in general, but maybe the most important thing is I can still learn and I’m open to learning and adapting so that my contributions are in cooperation with the rest of the community, not in conflict with it.

Two existing TUs, Daurnimator and Archange, have agreed to sponsor my application:

• https://archlinux.org/people/trusted-users/#daurnimator
• https://archlinux.org/people/trusted-users/#Archange

For full disclosure I did put out feelers about a year ago looking for sponsors and didn’t get any takers at the time. Nobody outright refused but several emails went unanswered and TUs in IRC commented on various things but nobody “bit”.

As for the minimum basic requirements:

• I definitely know my way around shell scripts (I prefer ZSH, but have a good grasp of Bash and POSIX usage too) and also most VCS systems.
• I’ve been maintaining hundreds of AUR packages for some years, some of them cleaner than others. I would expect anything destined for [community] to be held to a high standard of cleanliness and testing and won’t be offended if some hacks I’ve let slide in the AUR aren’t appropriate for other repos.
• The weak point in my application may be my low bbs/mailing list involvement, but you can check my Stack Exchange profile or other places to see that I’m not clueless. I’ll be willing to keep in touch with other TUs (and the bug tracker, which I feel like is sometimes neglected for community packages).
• Yes I can Google words.
• Below I’ll outline some packages and my various interests in them.
• I have some past involvement reporting in the Flyspray and GitLab trackers for Arch packages and projects.
• I don’t recall sending patches for any Arch projects yet, only patches for packaging.
• I have lots of other FOSS involvement, everything from well known projects like Harfbuzz or Pandoc to esoteric VIM plugins. I have upstream contributions to dozens of projects in [community] already and a large chunk of the things I current package on the AUR.

Packages I have previously maintained in the AUR which have already been adopted into [community]; where extra hands are welcome I could still help with these:

• age
• birdfont
• gentium-plus-font
• git-annex
• git-crypt
• gitlab
• gitlab-workhorse
• grunt-cli
• lua-filesystem
• lua51-penlight
• mattermost
• otf-libertinus
• pqiv
• python-hsluv
• python-pytoml
• shutter (later demoted back to AUR for good reason)
• ttf-hack
• xkcdpass
• yq

Other packages already in [community] which interest me and I would potentially be interested in co-maintaining, help keeping up to date, fixing packaging bugs, etc:

• hledger: upstream contributor \ Flyspray packaging reports have taken months and some years
• lilypond
• lua-penlight: upstream contributor \ has often been months OOD even when patches in Flyspray
• pandoc: upstream contributor \ is less ofter a problem recently but historically was often OOD in \ community, I know the Haskell deps are deep dark depths, but having \ it OOD has been a constant pain point for me
• sword
• tridactyl: upstream contributor
• vim-nerdcommentor: upstream maintainer
• vim-nerdtree: upstream contributor

Current (semi) orphans in [community] I might pick up:

• python-fonttools \ (current maintainer Andrzej recently said they need help)
• python-unicodedata2 (same)

Things I currently maintain in the AUR that I would like to see eventually migrated to [community], of course dependent on all the packaging details and usage stats being copastetic:

• asterisk
• csvkit
• epubcheck
• font-manager
• gitlab-pages
• lua-busted
• lua-posix
• marktext
• myrepos
• praat
• programmers-dvorak
• sile: upstream maintainer (+12 lua-* deps)
• ttfautohint
• vcsh
• xiphos
• zerobane-studio
• zettlr

Things I don’t maintain in the AUR but would like to see moved someday (off the top of my head, I’m sure there are more):

• bottom
• duf
• git-delta
• gitahead
• gitlab-glab
• wp-cli

AUR packages:

• Maintainer (553): https://aur.archlinux.org/packages/?K=caleb&SeB=m
• Co-maintainer (90): https://aur.archlinux.org/packages/?K=caleb&SeB=c

Even with hundreds of AUR packages I only get a trickle of OOD flags because I follow most of the projects I package upstream. At the very least I subscribe to release notices, but often I’m more involved and use the packages myself, so am motivated to keep them up to date.

I have just a wee bit of *nix experience over the past 27 years, for example you can have a look around my Stack Exchange profile for the Unix & Linux site: https://unix.stackexchange.com/users/1925/caleb?tab=topactivity

Over the years I’ve been involved in quite a few FOSS projects:

• Github profile: https://github.com/alerque
• Gitlab profile: https://gitlab.com/alerque
• OpenHub profile: https://www.openhub.net/accounts/alerque

This won’t even be my first Linux distro rodeo. After cutting my teeth on early RedHat (when it came on 4 floppies!) I eventually became heavily involved in PLD Linux development from 1998 to 2012 (when I started switching to Arch Linux). I was a member of the CDG (Core Developers Group) and contributed thousands of packaging updates. I was always in good standing with the other team members.

My current Arch usage includes use or admin responsibilities OS on 9 desktops, 4 laptops, 13 assorted devices (RPis, print and NAS servers), 6 permanent cloud servers, 3 bare metal servers, and any number of containers (ephemeral cloud server instances, local and remote Docker/lxc services, VirtualBox, etc.). It has been my daily driver for desktop and server use for 9 years now.

Thank you for your consideration, and I look forward to hopefully many more years of being part of a great distro!

Caleb

P.S. Obligatory flame war fodder: (Neo)vim forever, always use Oxford commas, spaces not tabs, döner and tacos.

Hi,

Le 10/06/2021 à 15:15, Caleb Maclennan via aur-general a écrit :

Hello all!

My name is Caleb Maclennan (AUR moniker “caleb”, most other places “alerque”). I’m a long time Arch Linux user and AUR contributor looking to get more involved, and specifically to join the TU group so that I can help out with packages in [community]. I’m particularly interested in the Lua ecosystem (which thanks largely to @Daurnimator is much less of a mess than it was a year ago when I first started looking into becoming a TU, but could still use a helping hand) as well as anything related to font development or typesetting. As you’ll see I have some experience in FOSS, software packaging, and Linux in general, but maybe the most important thing is I can still learn and I’m open to learning and adapting so that my contributions are in cooperation with the rest of the community, not in conflict with it.

Two existing TUs, Daurnimator and Archange, have agreed to sponsor my application:

*https://archlinux.org/people/trusted-users/#daurnimator *https://archlinux.org/people/trusted-users/#Archange

I hereby confirm my sponsorship.

I’ve known Caleb for a while around packaging of certain softwares, especially Mattermost, and I think he showed great knowledge and competences around our work and procedures. I’ve had a look at several of his other PKGBUILD in the AUR, and all of them appeared to be in great shape (they might of course be some minor nits here and there, but nothing outstanding to me).

I think it would be a great addition to the team, so let’s start the discussion period.

Regards, Bruno/Archange

On 2021-06-15 04:19, George Rawlinson via aur-general wrote:

Please remove me from your mailing list too. /s

I would be pleased to remove you from my mailing list, all I ask is two small confirmations:

1. Send any small amount of BTC to 32LTd2RsnrgCbcn6TBunxNSgf1AHFz2ddK to confirm your email address. 2. Place your affirmative vote for me as TU before you leave.

Are there any particular packages that you found difficult to package? We all have some of these. :D

Of course, not all upstream projects are as sanitary as others. The ones I find the most irritating these days are Electron packages. It usually isn't *too* hard to setup a -bin package for them, but actual source builds that use the system Electron package are harder. I don't think I've ever completely failed to get one going but the amount of patching and general hackery needed to make them happen varies — and even once you do get it they often turn out to be brittle and break frequently as either Electron or upstream project updates come down the pipeline. It doesn't help that many (not all) Electron projects are hack jobs to start with written by people that don't know anything beyond web markup. The build systems they include are usually copy/paste efforts cobbled together until it "works" — even if the resulting installs are 2 Gig behemoths for 4k lines of JS code that's the actual app. To add insult to injury some of these include gimmicks like needing to pass some customized css/js linter in order to rebuild the sources. Having patched the sources to build just the project without embedding Electron you have to also figure out how to disable those build steps or setup matching linters in the makedepends=(). Yuck yuck yuck.

Have you noticed I'm not an Electron fan? I *can* beat these packages into shape but I don't have to like the process.

Beyond that, some upstream projects make a lot of assumptions about the host environment, often assuming a containerized environment where everything is tailored to *their* liking. Gitlab is a great example of this. I got it packaged and updated it for ages before it moved to [community], but the constantly changing requirements for exact Ruby versions and assumptions about other services (not to mention the ever changing databases layout migrations) put it in the "difficult" category. Upstream would rather you run their omnibus container than package it on bare metal and the resulting difficulty to packages is apparent. Mattermost wasn't quite as bad and has gotten better, but it wasn't always as easy one to update.

I had some trouble with Go packages early on, but both the projects and the language ecosystem have gotten better and those tend to be relatively easy now. The issues with the module fetcher writing not being separable from build stages without screwing up permissions are obnoxious but passable.

What's your package maintenance/procedure like? I'm always interested in seeing how people approach this so I can steal ^W borrow ideas.

I use `aurpublish` to manage AUR repos, plus a couple hand rolled scripts. One signs and publishes packages I built to my own package repository, the other steps me through the update/build process. The process starts by opening my editor (nvim of course) where I bump the version and clean up anything else that catches my eye. Then it updates checksums and attempts to build the package (both on the host system and in a chroot). If that works it installs it (I only build from systems where I actually *use* packages, so this works. Once installed I do a quick check to make sure nothing broke. For apps this usually means just running them and making sure they don't segfault or complain about deps. For system services I restart the service and make sure it still functions. If that's good then the result gets committed (aurpublish taking care of updating the .SRCINFO) and I push to the AUR repo plus my aurpublish repo and run the other script to publish the package and re-sign my repo.

Does that answer your question? If not I'll refund your BTC from your first request (still send the deposit first so I can verify your identify of course).

Caleb

P.S. Was it you that approved the mass deletion of anything Google Play Music related from the AUR‌ recently without checking which projects actually had been updated to work with YouTube Music even if they still have GPM in their name or description?

On 2021-06-15 14:30, Morten Linderud via aur-general wrote:

How do you stay on top of package updates? Do you have any hand rolled scripts to check for updates or do you use existing tooling?

To elaborate on what my initial posts said about this...

For the most part I am subscribed to upstream release announcements for the projects I package. By far the bulk of the version bumps I make are caught this way. If I can't attend to it when I see the GitHub or other notification come across I flag the AUR packages as OOD‌ myself as a reminder to get back to them.

For those that don't have an effective way to get notified by upstream, I occasionally check through my package sets using Repology and locally scan via aur-out-of-date. The later isn't very useful since it mostly finds ones that have GitHub sources that I'm notified about anyway, but Repology can be useful for catching others.

Ooooohh, backfire 😃!

Just a friendly poke. I was pretty annoyed but I'm sure it was an honest mistake. The tooling around AUR deletions also leaves a bit to be desired. Silently keeping the repo itself but loosing all the comment, vote, and maintainer meta data is not ideal.

On 2021-06-16 00:24, George Rawlinson via aur-general wrote:

There's a lot that should be improved when it comes to the entire Electron ecosystem. It's a concern that the maintenance of these applications falls mostly on distribution packagers, seeing as some upstream Electron apps won't accept bug reports from users with "modified" apps.

Never mind bug reports, half the time they won't accept patches! I've had quite few PRs that tried to fix build issues rejected because "your issue wouldn't even be a problem if you built it our bundled way".

Sure does. Glad to read about your process, and especially that you use your own packages.

Most of them. A handful I don't any more at all besides having them on a machine, a few my usage is intermittent, but yes for the most part the things I package are things I actually care about. As a rule I don't use *any* software if it can't be installed an managed as a system package. I have everything from long running machines (Arch boxes updated for > 10 years) to many ephemeral virtual systems. I can't mess around with installing software manually and then either not being able to match it elsewhere or forgetting what I did or having it leave crud around on my system.

Guilty, m'lud. To the gallows with me!

Your punishment should you choose to accept: use only emacs for the next <M-d> days.

On 18/06/2021 18:59, Caleb Maclennan via aur-general wrote:

On 2021-06-11 03:16, Archange wrote:

...

so let’s start the discussion period.

This message is a short public service announcement reminding all current TUs that today is the halfway point of the discussion period on my application. I know packagers tend to be the easily distracted types that wander off following the latest shinny thing wherever it leads — it takes one to know one. I also know the author of *the* most popular AUR package (not to mention co-author of the second most popular) just threw his hat in the ring too, but I don't want you to loose your chance to hold my toes over the fire.

waves \o/

We can continue the argument of if glibc should be in depends here if you like :P

On 6/18/21 1:59 PM, Caleb Maclennan via aur-general wrote:

If my existing packages or former FOSS involvement doesn't give enough fodder for discussion, lets try some unpopular opinions:

Speaking of unpopular opinions, holy cow.

It appears you've been agitating on the AUR comments for some duplicates of the community/audacity package:

""" @yochananmarqos The Arch [community] package has been flagged out of date for over a year. When exactly is it okay to move on and post an AUR package? I'd say the delete flag should be dropped and re-filed when the repo package is up to date. Yes I know v3 hasn't been out that long, but the minor version bump on the v2 series that was missed a year ago had other fixes that pushed me to switch to audacity-git, now that is broken. This package seems quite reasonable given the circumstances. """

So if I understand correctly, you believe that the official rules of the AUR apply as usual, *EXCEPT* for the exact case they're intended to target?

audacity 3 is released in March, some AUR users are upset it isn't being updated in [community] fast enough.

But... the rules of the AUR state that you must not take this opportunity to upload "audacity-but-actually-kept-up-to-date" style packages.

Your straightforward defense of this is that... a year ago, a minor version bump took too long also, and therefore "given the circumstances" it's reasonable to just up and violate the rules of the AUR because this one package is just, idk, too irresponsibly maintained in [community]?

...

Given the purpose of the Trusted Users to whom you are applying, is not just to publish packages in [community], but also to moderate and keep order in the AUR, I find it extremely relevant that halfway through an otherwise decent application you are advocating for this sort of thing.

On Fri, 18 Jun 2021 20:59:48 +0300 Caleb Maclennan via aur-general aur-general@lists.archlinux.org said:

On 2021-06-11 03:16, Archange wrote:

...

so let’s start the discussion period.

This message is a short public service announcement reminding all current TUs that today is the halfway point of the discussion period on my application. I know packagers tend to be the easily distracted types that wander off following the latest shinny thing wherever it leads — it takes one to know one. I also know the author of *the* most popular AUR package (not to mention co-author of the second most popular) just threw his hat in the ring too, but I don't want you to loose your chance to hold my toes over the fire.

If my existing packages or former FOSS involvement doesn't give enough fodder for discussion, lets try some unpopular opinions:

• I think most non-library Rust projects would benefit from Autoconf

tooling. Rust is a fantastic language but Cargo is terrible in the role of distribution tooling.

• Projects that track auto-generated content (such as Autoconf

generated bits) in their VCS should be taken out behind the woodshed and...

• Non-tiling window managers are mostly just window *observers*, they

clearly aren't *managing* them effectively if they just throw them all in a pile.

Careful there young whipper-snapper... You might want to write a few WM's first.... :) :P :)

• QWERTY is for mechanical typewriters or the birds, no middle ground.

I use (programmer) Dvorak for English, F for Turkish, and MessagEase on mobile. I'm considering learning ARTSEY to facilitate computer use while holding small children.

Caleb

On 2021-06-21 18:58, Eli Schwartz via aur-general wrote:

It appears you've been agitating on the AUR comments for some duplicates of the community/audacity package:

Not "some duplicates", just one duplicate. ;-)

Given the purpose of the Trusted Users to whom you are applying, is not just to publish packages in [community], but also to moderate and keep order in the AUR, I find it extremely relevant that halfway through an otherwise decent application you are advocating for this sort of thing.

But yes this is quite relevant to TU operations so let's dig in.

First I'm quite aware of the no-duplicates rule, and I think it makes perfect sense about 99% of the time. That being said not all upstream software projects are neat and tidy and not all Arch package situations are equal. I do think there is a 1% grey area and that evaluating specifics of a situation will turn up cases where Arch's "pragmatism" should trump 100% ideological by-the-books rule application.

1. There significant precedent in Arch official repos for duplicate packages if they cover incompatible major versions. PHP, Node, Electron, Python, Lua, GTK, and so on. Mostly RTEs and libraries, but apps aren't unheard of either. Sometimes it just makes sense to keep several major versions available so people can use what works for them until the ecosystem moves on far enough that dropping the old ones makes sense.

2. The AUR has an even more significant precedent for this. It's quite common and largely accepted to find what you are labeling as a "duplicate" if they serve some measurable purpose. Duplicates for the same of duplicates of course are not allowed. Duplicates for recently out of date things isn't allowed. Duplicates just to tweak some preferences that either could be set other ways or are not broadly relevant is not allowed. There are quite a few more iterations of this that are just not allowed.

But some cases don't fit any of those situations. There are currently over 3k packages in the AUR that end in a number. A small chunk of these are just projects that end in a number (e.g. x11, v8). Another chunk are useless obsolete cruft that should be deleted. But a significant number of those are legitimate major-version packages older or newer than arch repos that serve substantive purposes.

- Compile time options that make for a significantly different experience are sometimes allowed as AUR packages. Generally Arch repo packages enable all options by default, but there are a handful of cases where that is not the case and something keeps the Arch repo packages in a limited function mode. In some of these cases it is allowed to have AUR packages that enable the feature and let users choose if they want to run that over the official package.

- Major versions with backwards incompatible changes where the version bump is being held back in Arch repos are often allowed in the AUR. The reverse is also common, when the Arch repos get a major version bump that makes backwards comparability a problem, running an old version out of the AUR is the common solution. There are no less that 23 packages for old versions of ICU. I'm guessing half of them are now useless cruft, but I wouldn't say they should all be nuked without reviewing their utility. 14 more for electron (mostly -bin variants), 47 for the Android SDK, and so on.

Yes I realize that many of these are also designed to be used in parallel. Android SDK for example, as well as Electron runtimes. This is not the case for all packages, nor can it be realistically. One example is exim. You can't realistically set up packages to run multiple instances of exim, but there are good reasons to package it in "duplicate" to the community package. The community package is current pretty current, but historically there have been reasons it got held back and patched instead of updated. Allowing AUR packages to take the other road is something I think should be legitimate. If tomorrow an exim 5.0 comes out with some backwards incompatible bits that required libraries or something that broke some systems, I would expect the community repo to hold onto 4.x for a *little* while, and an AUR package for exim5 to crop up in the interim. Later as the migration dust settles and the path to update is more clear for more people, I would expect Arch to stay pretty current and update as soon as feasible, but when it does I would fully expect the exim5 package to go away from the AUR and an exim4 package to take its place for people that can't be bothered to migrate for a while but have production servers they want to otherwise keep patched. Using the same example, Arch has been ignoring the new DMARC features in exim for over a year now. Not enabling them while they were experimental made sense, but they have been stable since Dec 2019 and Arch has been ignoring the relevant bug report / feature request. I think it would be totally fair gaim if somebody wanted to make an AUR package for exim-dmarc that enables the feature. Yes this is a "duplicate", but not all duplicates are just duplicates.

Speaking of duplicates and content moderation, it might be relevant to note that I was a moderator on 2 different stack exchange sites, both pro-tempera and then elected. Anybody that has hung out on SE sites knows the issue of duplicate question closure is a sensitive topic and moderator decisions are often contested. In 8 years of being a moderator there I was challenged many times, but I always took the time to explain myself. My explanations almost never failed to be the highest votes meta answers to controversial decisions.

https://christianity.meta.stackexchange.com/users/30/caleb?tab=summary

I also have a long track record of proposing things for discussion there *before* unilaterally jumping in and doing them. I would expect to follow the same modus operendi as a TU. Many actions as a content moderator are just janitorial and you can follow the rules and plow through them. The expertise comes in spotting the cases where extra care is required and either special handling is needed or discussion needs to be started to handle them in a way that is more broadly satisfactory than a spur of the moment decision. I'll let my track record speak for itself.

Now about Audacity in particular....

As background, many years ago when working as an audio engineer I used to use it in production nearly full time. I'm quite familiar with it's past and the weird development practices upstream (such as forked toolkit versions). I am no longer in that field and only occasionally dabble with it for hobby purposes.

A year ago when the last minor version bump to the 2.x series came out, by chance I happened to be hit with one of the bugs that had been fixed upstream. I don't think I was the flagger for that update, but I came along right about that time hoping for an update. When there was none, I tried to build it myself. I quickly realized what a fiasco that was because the minor version didn't build cleanly at the time without changes to the packaging and other arch libraries. At the time the OOD flag was within a couple weeks old, so I abandoned the project and solved my audio issue another way. Later I switched to the -git package that got updated to resolve the build issues.

Having a minor version bump stay out of date for a while shouldn't be a huge deal, but having one with known bugs that block some production workflows stay out of date for over a year is egregious. That in itself may not be a good reason to allow duplicates on the AUR, but I do think the timeline is relevant. Duplicates in the first couple weeks should be a total no-no. On the AUR 2 weeks is when you can start filing orphan requests. Something like that should probably be implemented for community packages too. Maybe not 2 weeks, but if they are out of date for 2 months and nobody is even responding the flags or bug reports that starts to make the AUR a *better* place that [community]. That's kinda backwards, no? If things stay out of date for two long I think there should be some procedure for either getting other maintainers involved or demoting them to the AUR where interested parties could keep them more up to date.

So far those are just discussion points, not something I would feel free to enforce as a TU, just opinions I have and would root for eventual guideline updates.

Audacity v3 is a bit different. As a major version release being handled by a new upstream developer (the project changed hands) with new release procedures and development cycle, and most notable BACKWARDS INCOMPATIBLE bits that break people's workflow by default, I think it should be fair game to post an audacity3 package to the AUR for adventurous souls that know they want to switch. The maintainer of the [community] package should get the minor version bump at least figured out post-haste. At their discretion they can update to the v3 release whenever they think it reasonable. I would argue for sooner rather than later, but I don't know what complications that might have for wxGTK toolkit packaging, so I am not casting judgement on that. When they to get v3 packaged in the repos, I would expect the audacity3 package to be deleted, and if people feel the need for it an audacity2 package could be posted to the AUR for people that need the old version for their workflow. When that eventually becomes irrelevant it should be cleaned up and removed.

Does that make sense? Even if you don't agree with what I‌ think should have happened with the audacity3 package do you have ongoing concerns about how I would approach controversial decisions? In cases like this I think interacting with other potential decision makes is at least as important as the final decision. We can't just play tug of war posting and deleting packages. I'm willing to take the topics where I don't necessarily agree with other TU's here for discussion before just implementing them. And honestly I've been using Arch on a lot of systems for a lot of years and don't have significant methodology disagreements so I am not anticipating conflict. I use Arch and the AUR because I‌ think it is a good balance of concerns and useful ecosystem pattern.

Regards, Caleb

On 22/06/2021 10:48, Caleb Maclennan via aur-general wrote:

On 2021-06-21 18:58, Eli Schwartz via aur-general wrote:

...

It appears you've been agitating on the AUR comments for some duplicates of the community/audacity package:

Not "some duplicates", just one duplicate. ;-)

...

Given the purpose of the Trusted Users to whom you are applying, is not just to publish packages in [community], but also to moderate and keep order in the AUR, I find it extremely relevant that halfway through an otherwise decent application you are advocating for this sort of thing.

But yes this is quite relevant to TU operations so let's dig in.

First I'm quite aware of the no-duplicates rule, and I think it makes perfect sense about 99% of the time. That being said not all upstream software projects are neat and tidy and not all Arch package situations are equal. I do think there is a 1% grey area and that evaluating specifics of a situation will turn up cases where Arch's "pragmatism" should trump 100% ideological by-the-books rule application.

1. There significant precedent in Arch official repos for duplicate

packages if they cover incompatible major versions. PHP, Node,    Electron, Python, Lua, GTK, and so on. Mostly RTEs and libraries, but    apps aren't unheard of either. Sometimes it just makes sense to keep    several major versions available so people can use what works for them    until the ecosystem moves on far enough that dropping the old ones    makes sense.

That's the opposite case, not precedence. The official repos covers *previous* incompatible versions. If the repos had audacity3 and the AUR uploaded audacity2 we wouldn't talk about this.

I'll move down some paragraphs since my time is limited.

I also have a long track record of proposing things for discussion there *before* unilaterally jumping in and doing them. I would expect to follow the same modus operendi as a TU. Many actions as a content moderator are just janitorial and you can follow the rules and plow through them. The expertise comes in spotting the cases where extra care is required and either special handling is needed or discussion needs to be started to handle them in a way that is more broadly satisfactory than a spur of the moment decision. I'll let my track record speak for itself.

Suggesting to users a deletion request is invalid counts as "unilaterally jumping and doing them". Proposing things for discussion would be opening a topic on aur-general.

Now about Audacity in particular....

As background, many years ago when working as an audio engineer I used to use it in production nearly full time. I'm quite familiar with it's past and the weird development practices upstream (such as forked toolkit versions). I am no longer in that field and only occasionally dabble with it for hobby purposes.

A year ago when the last minor version bump to the 2.x series came out, by chance I happened to be hit with one of the bugs that had been fixed upstream. I don't think I was the flagger for that update, but I came along right about that time hoping for an update. When there was none, I tried to build it myself. I quickly realized what a fiasco that was because the minor version didn't build cleanly at the time without changes to the packaging and other arch libraries. At the time the OOD flag was within a couple weeks old, so I abandoned the project and solved my audio issue another way. Later I switched to the -git package that got updated to resolve the build issues.

Having a minor version bump stay out of date for a while shouldn't be a huge deal, but having one with known bugs that block some production workflows stay out of date for over a year is egregious. That in itself may not be a good reason to allow duplicates on the AUR, but I do think the timeline is relevant. Duplicates in the first couple weeks should be a total no-no. On the AUR 2 weeks is when you can start filing orphan requests. Something like that should probably be implemented for community packages too. Maybe not 2 weeks, but if they are out of date for 2 months and nobody is even responding the flags or bug reports that starts to make the AUR a *better* place that [community]. That's kinda backwards, no? If things stay out of date for two long I think there should be some procedure for either getting other maintainers involved or demoting them to the AUR where interested parties could keep them more up to date.

The way I see it, adding some kind of time-related exception rules is pretty complicated and will soon end up in everyone thinking they qualify for an exception. That doesn't help with an already high amount of stale AUR requests out there.

Now if people want to take up some package in AUR because "nobody is responding on community", it's again fine to start a discussion. The maintainer might even drop it to AUR. In fact, maintainers have dropped "unpackageable" packages (e.g. freeCAD) to AUR before.

So really, it's a shame nobody actually started a discussion, submitted packages going against the submission guidelines instead, and then argued the submission guidelines are actually not right.

Alad

So far those are just discussion points, not something I would feel free to enforce as a TU, just opinions I have and would root for eventual guideline updates.

Audacity v3 is a bit different. As a major version release being handled by a new upstream developer (the project changed hands) with new release procedures and development cycle, and most notable BACKWARDS INCOMPATIBLE bits that break people's workflow by default, I think it should be fair game to post an audacity3 package to the AUR for adventurous souls that know they want to switch. The maintainer of the [community] package should get the minor version bump at least figured out post-haste. At their discretion they can update to the v3 release whenever they think it reasonable. I would argue for sooner rather than later, but I don't know what complications that might have for wxGTK toolkit packaging, so I am not casting judgement on that. When they to get v3 packaged in the repos, I would expect the audacity3 package to be deleted, and if people feel the need for it an audacity2 package could be posted to the AUR for people that need the old version for their workflow. When that eventually becomes irrelevant it should be cleaned up and removed.

Does that make sense? Even if you don't agree with what I‌ think should have happened with the audacity3 package do you have ongoing concerns about how I would approach controversial decisions? In cases like this I think interacting with other potential decision makes is at least as important as the final decision. We can't just play tug of war posting and deleting packages. I'm willing to take the topics where I don't necessarily agree with other TU's here for discussion before just implementing them. And honestly I've been using Arch on a lot of systems for a lot of years and don't have significant methodology disagreements so I am not anticipating conflict. I use Arch and the AUR because I‌ think it is a good balance of concerns and useful ecosystem pattern.

Regards, Caleb

On 22/06/2021 12:05, Sam Mulvey via aur-general wrote:

On 6/22/21 1:48 AM, Caleb Maclennan via aur-general wrote:

...

As background, many years ago when working as an audio engineer I used to use it in production nearly full time. I'm quite familiar with it's past and the weird development practices upstream (such as forked toolkit versions). I am no longer in that field and only occasionally dabble with it for hobby purposes.

I grant that I'm not a part of the TU discussion, have little interest in the TU process, and only manage one significant package, but audacity is relevant to my interests as I am a community broadcast engineer and use arch pretty much everywhere in that context.   I'm in audacity every day.  It is as important to my work flow as my text editor is.

I fully support the efforts to tame audacity3 to the point that I took some shots at it privately.  Keeping it out of the repos is a good idea.  But most of my show producers and all of my clients use other operating systems and are already on audacity3, and I am in no position to dictate what version they can run.  I already get aup3 files from clients now.  After seeing packages repeatedly disappear, I created a package that compiled it as upstream demands, dumped it all in /opt, named it "audacity-bs" for obvious reasons, and called it a day.   It is not a thing I would even think of putting on AUR.

But now my confusion at the disappearing packages is now replaced with confusion that using collaborative tools to solve a non-trivial problem is prohibited in this case where it is not in others, just as Caleb said.  This feels like a political issue eclipsing a real technical issue for real users.  If this is not an exception, there should be no exceptions and it should be made more clear.

I'm not interested in having it out on the forum or the AUR comments, I'm not much for that sort of thing.  So I'm late to this party.   But it is important enough to me to amplify my bafflement.

There's 59 TUs looking after 70676 packages and moderating 85141 users. To make that manageable, you need some a strict set of rules. One of them is not submitting "-latest" packages that are already in the repos.

It works pretty well in the general case. For audacity3, it ostensibly doesn't. But rather than make the rules (and with that, moderation) complicated for all packages - merely for a single package - that single package should be sorted out instead. For example, by dropping it to AUR where points like interoperability with other packages and vendoring of dependencies don't really matter.

Alad

-Sam

On 22/06/2021 12:56, Sam Mulvey via aur-general wrote:

On 6/22/21 3:16 AM, alad via aur-general wrote:

...

There's 59 TUs looking after 70676 packages and moderating 85141 users. To make that manageable, you need some a strict set of rules. One of them is not submitting "-latest" packages that are already in the repos.

But the implementation is not uniform, and non-TUs must heed implementation as well.   Both of these things are obvious, I suspect.

Not creating a thousand AUR packages when a maintainer is twenty minutes late incrementing gnome-pizza-maker is an unqualified good, but not having a community bandage when work on a maintained package is stalled but not abandoned for over a year seems less good.   If the people behind AUR say that this is a situation where community tools are off limits, that's a notable surprise to me and I'll submit my mild objection.

Yes, I agree it's less good. But I did point out one bandage: posting something on the mailing lists if a package can be dropped to AUR. Of course the ideal solution would be to instead figure out how the new version can be packaged without vendoring.

FWIW there seems to be some upstream progress on that [1]. If you use audacity on a regular basis, maybe you can help them figure it out.

P.S. Now that the discussion is there, I'm afraid we'll have to wait a little while longer for definite input. The Arch maintainer of audacity is on holiday until next week.

Alad

[1] https://github.com/audacity/audacity/pull/918

-Sam

On 6/22/21 9:49 AM, alad via aur-general wrote:

On 18/06/2021 19:59, Caleb Maclennan via aur-general wrote:

...

On 2021-06-11 03:16, Archange wrote:

...

so let’s start the discussion period.

This message is a short public service announcement reminding all current TUs that today is the halfway point of the discussion period on my application. I know packagers tend to be the easily distracted types that wander off following the latest shinny thing wherever it leads — it takes one to know one. I also know the author of *the* most popular AUR package (not to mention co-author of the second most popular) just threw his hat in the ring too, but I don't want you to loose your chance to hold my toes over the fire.

Since I don't want to divert all attention to the audacity controversy, let me note my appreciation of your recent activity on various Arch community channels (e.g. IRC and mailing lists here). Whatever the outcome of this application, I hope you keep that activity.

Seconded. :)

Regarding your AUR packages, I guess we can't expect a full review of all 500. So let's talk about a few "random samples" and the packages you want to add to community.

• github-desktop

• That DLAGENTS logic looks strange. I guess makepkg doesn't support

source links with both branch and tag?

This appears to be a homebrew implementation of the following rejected makepkg feature request: https://wiki.archlinux.org/title/User:Apg#makepkg:_shallow_git_clones

• Googling "Xvfb yarn" gave me this rather amusing issue:

https://github.com/cypress-io/xvfb/issues/98

xvfb-run is probably easier here...

• moonscript

• I'd consider adding write_moon{,c} to the git repository, instead of

putting long one-liners in the PKGBUILD.

• You can use parameter substitution instead of sed. For example,

${pkgver/_/-}

I'll add that

_lua_ver="$(lua -e 'print(_VERSION)' | cut -d ' ' -f 2)"

gets evaluated before /usr/bin/lua is installed, and therefore evaluates to the empty string every time the PKGBUILD is sourced, while logging:

PKGBUILD: line 21: lua: command not found

to stderr.

Due to an internal implementation detail of makepkg, the package() function is run after sourcing the PKGBUILD again -- this time after lua is installed. Luckily, the variable is only *used* during package(), so the resulting .pkg.tar.zst isn't created with the wrong content... but then it should be defined during package() too. As it is, it will simply produce stderr every time the PKGBUILD is sourced by default, which can break tooling.

When I tested building it with makechrootpkg to test whether/where any wonkiness resulted, I noticed along the way that it reports:

Missing dependencies for moonscript 0.5.0-1: lpeg >= 0.10, ~= 0.11 (not installed) alt-getopt >= 0.7 (not installed) luafilesystem >= 1.5 (not installed)

then proceeds to download all 3 from https://luarocks.org/, compile them locally, and I think do nothing with them.

Should be updated to depend on all three from the official repos, I guess. I think they're there with the right versions? I know nothing about lua...

On Tue, 2021-06-22 at 10:42 -0400, Eli Schwartz via aur-general wrote:

On 6/22/21 9:49 AM, alad via aur-general wrote:

...

let me note my appreciation of your recent activity on various Arch community channels (e.g. IRC and mailing lists here). Whatever the outcome of this application, I hope you keep that activity.

Seconded. :)

IRC participation is going to keep coming in fits and starts. This is the way it has been for years. I get the bug and hang around for a few months, then get burried in some work and ignore it for a while and it takes 6 monhs before I log in again and see who's still chillin.

For mailing lists, obviously with TU responsibilities I'll have to monitor this list and a few others a bit more closely. I've subscribed and tracked several for many years, but embarasingly my subscription to arch-general had some mailer problem and I didn't even notice for ages until a couple weeks ago when I was writing my application. Oops!

...

• github-desktop

• That DLAGENTS logic looks strange. I guess makepkg doesn't

support source links with both branch and tag?

This appears to be a homebrew implementation of the following rejected makepkg feature request: https://wiki.archlinux.org/title/User:Apg#makepkg:_shallow_git_clones

...

• Googling "Xvfb yarn" gave me this rather amusing issue:

https://github.com/cypress-io/xvfb/issues/98

xvfb-run is probably easier here...

Thanks for this tip. I'll look into it for sure. I'll admit to having adopted and bumped this from the previous maintainer who was tired of dealing with it, but withouth overhauling it. I tried dropping the obviously hacky buts and it failed, but I haven't gotten around to really scrubbing it clean yet with at overhaul.

...

• moonscript

Again thanks to both of you for the tips. You can see I'm not the last packager of this however. I adopted it recently knowing that it was a disaster and started an overhaul, but ran into some unexpected problems updating the build,. I think they are upstream, but still working out the details. I'll be posting an overhaul to this when it works right.

Due to an internal implementation detail of makepkg, the package() function is run after sourcing the PKGBUILD again -- this time after lua is installed.

Yes, quite aware of this. Also aware that I've made that mistake before with Electron packages, and might still have a couple instances to fix! I've only in the last few months started to regularly check my builds in a chroot before posting. As you can imaginge that's been turing up quite a few things I previously overlooked.

Caleb

Unsubscribe

On Tue, Jun 22, 2021, 07:52 Eli Schwartz via aur-general < aur-general@lists.archlinux.org> wrote:

On 6/21/21 12:48 PM, Jayesh Badwaik via aur-general wrote:

...

Dear Eli,

May be a little off-topic from the application discussion but curious. What is a good way to get those packages in AUR then? Would `audacity-jayesh` or `audacity3` would be an appropriate replacement?

The deleted AUR package was "audacity3". Given one of the problems is the package doesn't build properly (when running cmake it git clones https://github.com/audacity/wxWidgets/commits/audacity-fixes-3.1.3 and uses the latest code currently on that branch) I'm skeptical it can be packaged correctly.

If it cannot be packaged correctly, then as one of the rare people who actually believes the AUR is supposed to ideally contain packages which follow the package guidelines (I know this will eternally be a work in progress at best, but I refuse to just give up and not even try), I don't believe it should be submitted to the AUR as an *incorrectly* packaged edition.

... much less uploaded as "audacity-but-actually-up-to-date". The usual standard for this sort of thing is to have an AUR *-bin package containing the upstream prebuilt binaries with presumably vendored everything, including their wxwidgets fork.

If anyone does figure out how to package it correctly for the AUR, then it doesn't belong in the AUR either :p email dvzrv / ainola to have the community package updated.

-- Eli Schwartz Bug Wrangler and Trusted User

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

The two week discussion period has passed and the application is now up for vote.

Thanks to all who participated in the discussion.

https://aur.archlinux.org/tu/?id=129

On Fri, 11 Jun 2021 at 10:16, Archange via aur-general aur-general@lists.archlinux.org wrote:

Hi,

Le 10/06/2021 à 15:15, Caleb Maclennan via aur-general a écrit :

...

Hello all!

My name is Caleb Maclennan (AUR moniker “caleb”, most other places “alerque”). I’m a long time Arch Linux user and AUR contributor looking to get more involved, and specifically to join the TU group so that I can help out with packages in [community]. I’m particularly interested in the Lua ecosystem (which thanks largely to @Daurnimator is much less of a mess than it was a year ago when I first started looking into becoming a TU, but could still use a helping hand) as well as anything related to font development or typesetting. As you’ll see I have some experience in FOSS, software packaging, and Linux in general, but maybe the most important thing is I can still learn and I’m open to learning and adapting so that my contributions are in cooperation with the rest of the community, not in conflict with it.

Two existing TUs, Daurnimator and Archange, have agreed to sponsor my application:

*https://archlinux.org/people/trusted-users/#daurnimator *https://archlinux.org/people/trusted-users/#Archange

I hereby confirm my sponsorship.

I’ve known Caleb for a while around packaging of certain softwares, especially Mattermost, and I think he showed great knowledge and competences around our work and procedures. I’ve had a look at several of his other PKGBUILD in the AUR, and all of them appeared to be in great shape (they might of course be some minor nits here and there, but nothing outstanding to me).

I think it would be a great addition to the team, so let’s start the discussion period.

Regards, Bruno/Archange

Le 05/07/2021 à 13:59, Daurnimator via aur-general a écrit :

On Sun, 27 Jun 2021 at 21:37, Daurnimator quae@daurnimator.com wrote:

...

The two week discussion period has passed and the application is now up for vote.

Thanks to all who participated in the discussion.

https://aur.archlinux.org/tu/?id=129

Voting is over and the results are in:

Yes No Abstain Total Participation 32 12 7 51 86.44%

Welcome our newest Trusted User!

Congrats Caleb! :)

Sorry I could not take part in the interesting discussions that happened during your application. I’ll try to follow-up on them ASAP.

I’ll let you go through the revamped TODO for new TU: https://wiki.archlinux.org/title/AUR_Trusted_User_Guidelines#TODO_list_for_n...

I guess Daurnimator will be much more available than I am since I’ll likely be oob for the rest of the week, but I’ll work on any remaining item after that.

Regards, Bruno/Archange