On Thu, 2021-06-10 at 16:36 +0200, davidschi via aur-general wrote:

please unsubscribe me from your mailing list

This list, like all the ones on lists.archlinux.org, is a self-managed opt-in list. You can unsubscribe or change your subscription options at any time from the list info page: https://lists.archlinux.org/listinfo/aur-general I believe after entering your email in the unsubscribe form at the bottom of the page it will send you a confirmation message to make sure you're taking action on an address you actually control. By the way if you happen to have previously subscribed to other lists related to Arch Linux links to all the list info pages are here: https://lists.archlinux.org/listinfo

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. * 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

Le ven. 18 juin 2021 20:00, Caleb Maclennan via aur-general < aur-general@lists.archlinux.org> a écrit :

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. * 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

I am not a TU but the keyboard part raised my attention. I totally agree, QWERTY (and AZERTY for French users like me) are for typewriters (I didn't get why birds should support this burden). I used to use programmer Dvorak, but for french people, it is not usable as a daily solution (missing common diacritics). Since then I swapped to BÉPO. It is probably not the best for programming however, to write a thesis it can be blessed ! On mobile I use AnySoftKeyboard (FOSS). MessagEase and artsey seem interesting but are very different approaches. Good choice to avoid any use from any other people ;-p By the way, using a BÉPO layout with an AZERTY keyboard is a very good way to avoid any bad Slack joke in company ! Thanks for these new things queuing on my "things to test" list. Kind, Alexis.

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

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.

Just for those unfamiliar with the situation, audacity is still at 2.8 in [community] because of difficulties to package it without vendored custom forks. Ostensibly AUR users aren't interested in those details and post an "updated" repo duplicate. https://github.com/audacity/audacity/issues/625 https://github.com/audacity/audacity/issues/853 So yes, I definitely agree with the argument. The people supposed to enforce AUR rules should enforce them, not encourage people to go against them. Alad

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

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 18/06/2021 19:59, Caleb Maclennan via aur-general 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

On 2021-06-11 03:16, Archange wrote: 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. 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? - Googling "Xvfb yarn" gave me this rather amusing issue: https://github.com/cypress-io/xvfb/issues/98 * 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/_/-} * mattermost-git - Looks like npm+go is double fun. Good thing for all the comments... * asterisk - Services should be managed by the user, not an .install script. - You'll need to assign a GUID for repo usage, cf. https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database * csvkit - Two missing dependencies. That's a big no-no. * epubcheck * font-manager Looks fine * gitlab-pages - L33-36 looks pretty hard to audit. Does the -help output change often? If not, consider adding a file to the repository. * lua-busted * lua-posix I don't know anything about LUA. With daurnimator as your sponsor, it's probably fine. * marktext Nothing to add here except that it's another electron text editor. * myrepos * praat Looks fine * programmers-dvorak - Might be worth convincing upstream to have a workable install script. * sile: upstream maintainer (+12 lua-* deps) * ttfautohint * vcsh * xiphos Looks fine * zerobane-studio I can't seem to find this one in AUR? * zettlr - Seems very similar to marktext, why add both? - I'd include the auxiliary files (.desktop, mime) in the repository. - Vendored pandoc is sad

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. * 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.

I've considered switching to an AAAAAA layout. Seems perfect for Internet discussions. Alad

Caleb

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, 06:49 alad via aur-general < aur-general@lists.archlinux.org> wrote:

On 18/06/2021 19:59, Caleb Maclennan via aur-general 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

On 2021-06-11 03:16, Archange wrote: 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.

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? - Googling "Xvfb yarn" gave me this rather amusing issue: https://github.com/cypress-io/xvfb/issues/98

* 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/_/-}

* mattermost-git

- Looks like npm+go is double fun. Good thing for all the comments...

* asterisk

- Services should be managed by the user, not an .install script. - You'll need to assign a GUID for repo usage, cf. https://wiki.archlinux.org/title/DeveloperWiki:UID_/_GID_Database

* csvkit

- Two missing dependencies. That's a big no-no.

* epubcheck * font-manager

Looks fine

* gitlab-pages

- L33-36 looks pretty hard to audit. Does the -help output change often? If not, consider adding a file to the repository.

* lua-busted * lua-posix

I don't know anything about LUA. With daurnimator as your sponsor, it's probably fine.

* marktext

Nothing to add here except that it's another electron text editor.

* myrepos * praat

Looks fine

* programmers-dvorak

- Might be worth convincing upstream to have a workable install script.

* sile: upstream maintainer (+12 lua-* deps) * ttfautohint * vcsh * xiphos

Looks fine

* zerobane-studio

I can't seem to find this one in AUR?

* zettlr

- Seems very similar to marktext, why add both? - I'd include the auxiliary files (.desktop, mime) in the repository. - Vendored pandoc is sad

...

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. * 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.

I've considered switching to an AAAAAA layout. Seems perfect for Internet discussions.

Alad

...

Caleb

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!

On Tue, Jun 15, 2021 at 02:23:56PM +0300, Caleb Maclennan via aur-general wrote:

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

...

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.

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?

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?

Ooooohh, backfire 😃! -- Morten Linderud PGP: 9C02FF419FECBE16

On 21-06-15 14:23, Caleb Maclennan via aur-general wrote:

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.

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.

...

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

<snip>

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).

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

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?

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