Thank you for bringing this to my attention. I did not realize that it was an issue to have a duplicate package in the AUR, and clearly see now that I should not. I guess the action of deleting the package makes more sense so I apologize for any confusion and unnecessary complaint. I do think if a package in an official repo is not getting updated that it makes sense to allow one in the AUR, but that would be a separate proposal. Please note, I also maintain a separate Skaffold package (skaffold-bin) since at times new updates were not getting pushed for a month or more. Feel free to delete that as well. On Sat, Nov 6, 2021 at 11:32 AM Brett Cornwall via aur-general - aur-general at lists.archlinux.org wrote:

On 2021-11-06 16:05, B via aur-general wrote:

...

grawlinson made a deletion request on this package after I updated it to v0.89.1, and they immediately approved their own request. The community package is flagged out-of-date and is at v0.88.1.

First, this violates the AUR community guidelines that requests a user be contacted before a package is removed. Additionally, I find that they are making a request and then immediately approving their own request without any discussion to be concerning.

Indeed, that's not something that should happen! Thanks for bringing this to our attention.

...

I do not think you should be deleting AUR packages, unless they are malicious. If they are not being maintained, then you should be contacting the users before deleting them. Otherwise, there is no harm in having an AUR and trusted package, as many times they be actually be different or the trusted package is the one not actively getting updated.

The AUR is not a democracy! There are standards and guidelines that clearly state that hugo-bin was not an acceptable package in the AUR [1]. So while the acceptance of their own request should not have happened, this package should not have existed in the first place.

Hope this helps.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

On Sat, Nov 06, 2021 at 06:47:04PM -0000, B via aur-general wrote:

Thank you for bringing this to my attention. I did not realize that it was an issue to have a duplicate package in the AUR, and clearly see now that I should not. I guess the action of deleting the package makes more sense so I apologize for any confusion and unnecessary complaint. I do think if a package in an official repo is not getting updated that it makes sense to allow one in the AUR, but that would be a separate proposal.

Please note, I also maintain a separate Skaffold package (skaffold-bin) since at times new updates were not getting pushed for a month or more. Feel free to delete that as well.

Hi, I am the skaffold maintainer. Are you sure about this? I am very confident that I have updated skaffold over the last months within 24 hours. Are you maybe on an old mirror or do you speak about longer ago? Some general advice: Patches are always welcome. Many package maintainers (including me) have their own PKGBUILD mirror on Github. For example: https://github.com/shibumi/pkgbuilds Feel free to open a PR against this repository. chris

There were longer delays when it was first added. I was just explaining why I had maintained a separate package. Now that I know the guidelines advises against this, I have no qualms with them being removed as I can just maintain my own PKGBUILDS. On Sat, Nov 6, 2021 at 11:56 AM Sven-Hendrik Haase via aur-general - aur-general at lists.archlinux.org wrote:

On Sat, 6 Nov 2021 at 19:54, Christian Rebischke via aur-general < aur-general@lists.archlinux.org> wrote:

...

On Sat, Nov 06, 2021 at 06:47:04PM -0000, B via aur-general wrote:

...

Thank you for bringing this to my attention. I did not realize that it was an issue to have a duplicate package in the AUR, and clearly see now that I should not. I guess the action of deleting the package makes more sense so I apologize for any confusion and unnecessary complaint. I do think if a package in an official repo is not getting updated that it makes sense to allow one in the AUR, but that would be a separate proposal.

Please note, I also maintain a separate Skaffold package (skaffold-bin) since at times new updates were not getting pushed for a month or more. Feel free to delete that as well.

Hi,

I am the skaffold maintainer. Are you sure about this? I am very confident that I have updated skaffold over the last months within 24 hours. Are you maybe on an old mirror or do you speak about longer ago?

Some general advice: Patches are always welcome. Many package maintainers (including me) have their own PKGBUILD mirror on Github. For example: https://github.com/shibumi/pkgbuilds

Feel free to open a PR against this repository.

chris

We can see here [0] that updates for the official skaffold package happen fairly often so I don't really see where the frustration about the packaging delay is coming from.

[0] https://github.com/archlinux/svntogit-community/commits/packages/skaffold/tr...

On 21-11-06 11:32, Brett Cornwall via aur-general wrote:

On 2021-11-06 16:05, B via aur-general wrote:

...

grawlinson made a deletion request on this package after I updated it to v0.89.1, and they immediately approved their own request. The community package is flagged out-of-date and is at v0.88.1.

First, this violates the AUR community guidelines that requests a user be contacted before a package is removed. Additionally, I find that they are making a request and then immediately approving their own request without any discussion to be concerning.

Indeed, that's not something that should happen! Thanks for bringing this to our attention.

It's been brought up before, and doing it via request & request action is preferable due to it providing an audit log. There are options to directly handle packages, but do not provide any audit log at all.

...

I do not think you should be deleting AUR packages, unless they are malicious. If they are not being maintained, then you should be contacting the users before deleting them. Otherwise, there is no harm in having an AUR and trusted package, as many times they be actually be different or the trusted package is the one not actively getting updated.

The AUR is not a democracy! There are standards and guidelines that clearly state that hugo-bin was not an acceptable package in the AUR [1]. So while the acceptance of their own request should not have happened, this package should not have existed in the first place.

Hope this helps.

[1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submissi...

What is the issue with handling one's own requests, specifcally? -- George Rawlinson

On Sun, 7 Nov 2021 17:47:16 -0800 Brett Cornwall via aur-general wrote:

On 2021-11-07 18:26, George Rawlinson via aur-general wrote:

...

What is the issue with handling one's own requests, specifcally?

I guess I don't see anything on the Wiki. I was under the impression that we didn't service our own requests so that there were sanity checks to keep us all in check.

When I was still handling requests, I'd only accept my own in "exceedingly obvious cases"... like a repo or "-latest" duplicate. -- alad

On Tue, 9 Nov 2021 at 11:11, Kevin Morris via aur-general wrote:

I'd be up for programmatically making it impossible for any user (user or TU) to accept their own requests.

However, that does bring some complications into play in regards to deleting packages.

Currently, on the /packages search page (for a TU), it is possible to delete packages without a request. In the new FastAPI implementation of aurweb, we have countered this accountability issue by auto-generating requests for the action performed. That being said, removing the ability for TUs to accept their own requests would also mean that TUs would not really be allowed to blanket delete packages on their own without a request; furthermore, they couldn't create a request themselves and go through the path.

So... the behavior would have to be changes to only allow blanket deletions on packages which already have a request from _another_ user.

This decision is really up to the Trusted User community of the AUR; not its developers. Some return feedback on this topic would be greatly appreciated. It would, without a doubt, remove some of Trusted User's freedoms. But it would also force sort of community-shared accountability, which may be a good thing.

What do you all think?

Deleting obvious spam packages shouldn't require two people. Furthermore, I don't think requiring a unverified member of the public + a TU is much of a higher bar, aside from making spam removal more difficult.

On 09/11/2021 00:23, George Rawlinson via aur-general wrote:

I am interested in seeing what others think (not just staff members) of the situation.

TUs are supposed to be trusted, and "deleted" AUR packages can be trivially reinstated when required. There's an audit log available, and if someone wants to query a deletion then there's this list and the IRC channel. Therefore, I don't see an issue with a TU handling their own request. J

On 09/11/2021 02:33, Jonathon Fernyhough via aur-general wrote:

TUs are supposed to be trusted, and "deleted" AUR packages can be trivially reinstated when required. There's an audit log available, and if someone wants to query a deletion then there's this list and the IRC channel.

Same opinion from here. As AUR users are human also, TUs still *have to* clearly indicate *why* the package had been deleted (e.g., as grawlinson did in its deletion: “Hugo is available in the community repository.”). But they already do that, isn't it? ;-) -- Henry-Joseph Audéoud audeoudh

Wednesday, November 10, 2021 12:00 AM +11:00 from Giancarlo Razzolini via aur-general :   Em novembro 8, 2021 21:23 George Rawlinson via aur-general escreveu:

...

On 21-11-09 11:19, Daurnimator via aur-general wrote:

...

Deleting obvious spam packages shouldn't require two people.

Furthermore, I don't think requiring a unverified member of the public + a TU is much of a higher bar, aside from making spam removal more difficult.

Agreed. There's already an audit log (via aur-requests) of all actions taken.

I am interested in seeing what others think (not just staff members) of the situation.

-- George Rawlinson

If it helps, when I was a TU, every request I created myself, I would usually not be the one handling it. I always waited on another TU to handle it, because there's a clear interest conflict there.

There are no rules preventing a TU from making a request and also being the one handling said request, but that's how I did things. However, I would handle requests for clearly problematic packages, like when I did a huge cleanup of manjaro packages.

Perhaps make a rule preventing TU's from handling their own requests?

Regards, Giancarlo Razzolini   Hi guys,    I am interested in seeing what others think (not just staff members) of the situation. TUs are *Trusted Users* by definition, so they are trusted by... whom? and for... what?)) - I'd bet when they are wipe out spam comments and simply spam or nasty things like so, they don't have to get so called "four-eyes" approvals for that. But what's regarding their own requests, they should be well on their own, because thay are TUs. - We (ordinary Arch Linux users) trust them to do what they consider like a common sense.   Arch developers are few, but TUs are many. Besides that (almost) every TU has gone through a two-step procedure admitting as a TU, which is clearly visible in this ML, regularly. - Once again: we trust them and their vision regarding common sense.   (*Sidespin* : I notice this for a long period of time that stepped-down TUs still use their own emails with archlinux.org domain, at least in the current ML. And I wonder, why those email addresses not withdrawal upon their membership as TUs has finished? - Giancarlo, Alad, maybe someone else? - This is a funny curiosity, no more.)))))   --  Kind regards, Radislav (Radicchio) Golubtsov Arch Linux and OpenBSD addict. http://rgolubtsov.github.io/

On Tue, Nov 9, 2021 at 1:24 AM George Rawlinson via aur-general wrote:

I am interested in seeing what others think (not just staff members) of the situation.

Not a TU here so just my two cents: In general I like to have a four-eyes review for things being done (code / infrastructure changes, "moderation actions", …) though I do understand the requirement of being able to handle problematic cases without waiting for another party to review the change (spam packages, emergency fixes, misbehaving users, …). For the action which caused this discussion for me the self-approval was less an issue (the action is clearly documented and therefore the path and reason of action is clear) than the short time of notice:

From my own perspective having management of my packages mostly automated this might cause trouble in the AUR as my automation might interfere with the mod-action of removing the package.

So I would go with a guideline: actions **should** be reviewed and not self-approved but in cases quick response is required, the acting TU is **not required** to wait for a review. If there is no other TU available, the requesting TU **should** at least give some time for the maintainer to notice the request before approving themselves. -- Knut Ahlers Software & Infrastructure Developer Web & Blog: https://ahlers.me/ GPG-Key: 0xD215AD7D