Re: [aur-general] [PRQ#29045] Deletion Request for hugo-bin
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. 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. On Fri, Nov 5, 2021 at 2:00 PM notify at aur.archlinux.org <ra+xgepysjjbcltexbfrteyggrkpgpclsgvngecpizxwjpvijvgp@simplelogin.co> wrote:
grawlinson [1] filed a deletion request for hugo-bin [2]:
Hugo is available in the community repository.
[1] https://aur.archlinux.org/account/grawlinson/ [2] https://aur.archlinux.org/pkgbase/hugo-bin/
Am 06.11.21 um 17:05 schrieb B via aur-general:
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.
Well, as it's already in the repos, why should it exist in AUR? Is there any benefit of the -bin-PKGBUILD? Best Regards Björn
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...
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 <nzdhmllkzsryyxkzwmuhvygoecmyjclu@simplelogin.co> 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 2021-11-06 18:47, 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.
I fear that you would be in the minority :). But please do feel free to maintain your own personal PKGBUILD for when you need an update faster than a maintainer can provide it!
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.
Thanks for bringing this to my attention! I submitted a request.
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
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...
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 <nzdhmllkzsryyxkzwmuhvygoecmyjclu@simplelogin.co> 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...
When it was first moved to a trusted package there were some longer delays. I guess on average it gets updated almost immediately or within a week. Thank you for maintaining the package and this was not meant as a complaint, nor directed at you. I will definitely consider contributing to a mirror and did not realize that was an option. On Sat, Nov 6, 2021 at 11:54 AM Christian Rebischke via aur-general - aur-general at lists.archlinux.org <nzdhmllkzsryyxkzwmuhvygoecmyjclu@simplelogin.co> 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
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 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.
On Sun, 7 Nov 2021 17:47:16 -0800 Brett Cornwall via aur-general <aur-general@lists.archlinux.org> 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 <alad@archlinux.org>
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? Regards, Kevin On Mon, Nov 08, 2021 at 04:34:20PM +0100, alad via aur-general wrote:
On Sun, 7 Nov 2021 17:47:16 -0800 Brett Cornwall via aur-general <aur-general@lists.archlinux.org> 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 <alad@archlinux.org>
-- Kevin Morris Software Developer Identities: - kevr @ Libera
On Tue, 9 Nov 2021 at 11:11, Kevin Morris via aur-general <aur-general@lists.archlinux.org> 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 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
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
That is kind of what I was thinking; we are improving the accountability regardless, so there really would be no possible way for ninja deletions to occur. I'll keep looking on this thread for more feedback, though, in case anyone brings up a nice point/idea. Thanks guys. On Tue, Nov 09, 2021 at 01:33:56AM +0000, Jonathon Fernyhough via aur-general wrote:
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
-- Kevin Morris Software Developer Identities: - kevr @ Libera
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
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
Wednesday, November 10, 2021 12:00 AM +11:00 from Giancarlo Razzolini via aur-general <aur-general@lists.archlinux.org>: 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 Wed, Nov 10, 2021 at 09:00:23PM +0300, Radislav Golubtsov via aur-general wrote:
(*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.)))))
because more often than not, these people have some other role in Arch Linux. developer, wiki admin, etc.
-- Kind regards, Radislav (Radicchio) Golubtsov Arch Linux and OpenBSD addict. http://rgolubtsov.github.io/
-- Sincerely, Alexander | Trusted User
On Tue, Nov 9, 2021 at 1:24 AM George Rawlinson via aur-general <aur-general@lists.archlinux.org> 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
Hi B, Nov 6, 2021 11:05:53 AM B via aur-general <aur-general@lists.archlinux.org>:
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.
If a package is out of date, the correct solution is to contact the maintainer, not to create a duplicate package on the AUR that violates the rules. Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email
participants (16)
-
alad
-
Alexander Epaneshnikov
-
B
-
Bjoern Franke
-
Brett Cornwall
-
Christian Rebischke
-
Daurnimator
-
George Rawlinson
-
Giancarlo Razzolini
-
Henry-Joseph Audéoud
-
Jonathon Fernyhough
-
Kevin Morris
-
Knut Ahlers
-
Maxwell G (＠gotmax23)
-
Radislav Golubtsov
-
Sven-Hendrik Haase