Re: Removal of linux-bin AUR package (suspended account)
I'm asking for my account to be restored on the basis presented above. -- Odoslané pomocou Tutanoty. Užívaj si bezpečné e-maily bez reklám.
On Wed, 20 Dec 2023 18:57:46 +0100 (CET) myself600@tutanota.de wrote:
I'm asking for my account to be restored on the basis presented above.
On the basis of ignoring the moderators repeatedly?
How did I ignore the moderators repeatedly? -- Odoslané pomocou Tutanoty. Užívaj si bezpečné e-maily bez reklám. 20. 12. 2023, 19:54 od dnewgard@outlook.com:
On Wed, 20 Dec 2023 18:57:46 +0100 (CET) myself600@tutanota.de wrote:
I'm asking for my account to be restored on the basis presented above.
On the basis of ignoring the moderators repeatedly?
You do not simply "address" a deletion by reuploading the package without any changes. You should've consulted someone like you recently did here. The first communication from you that I know was what you sent here to this mailing list. Also, welcome to the mailing list! Please have a look at the [guidelines](https://wiki.archlinux.org/title/General_guidelines#Mailing_lists). In particular, it is a sin to commit what we call "top posting", which is quoting the entire email chain at the end of your email. -- Cheers, Aᴀʀᴏɴ
Here's the summary: I uploaded a package that soon got flagged for deletion. There were multiple reasons stated in the email which got soon accepted afterwards. I was able to find an email address of the TU and sent him a response to the claims and even tho they were not valid, namely that ARM only packages break the rules of the submission guidelines, and that the package is of low quality due to using curl to fetch pkgver and checksums, I tried to comply in ways that would eventually make the package better. I explained that the way AUR handles package updates is not optimal and that I prefer automated updates over pushing repetitive git commits. After some time have passed I reuploaded a modified PKGBUILD that added x86 support, after which it was removed again with the reason "Dupe of [base] linux package". Even tho the pkgurl field has shown it's the Debian kernel, I've seen this wasn't communicated properly on my behalf so informed the TU that I'll make a note about the difference in the package comments section. I pushed a package update after some days and added the said note and this led to my account being suspended. From my point of view, I'm being attacked for my effort to resolve issues, but the expectation is to follow orders rather than obey rules, which is abusive and also shameful. I have not broken any of the rules despite being accused of doing so. Meanwhile, only a single person has shown willingness to help. After reading posts of people facing the same or a similar situation, I was thinking why the Arch community treats its userbase in such a condescending way and came up with the idea that perhaps it's because "Arch Linux" is more of a hobby project than it is a commercial distribution, so there is a sense of ownership and consequently shared decisions of what "I" want or not to be in it, and therefore no incentive to keep the users happy. Despite of that, there are better ways to achieve your goals without the need to be offensive to other people I think.
Ah, that makes a lot more sense, thanks. Perhaps your email to that TU was blocked by a spam filter? You may want to contact the Arch forums with your summary. Looking at the archived PKGBUILD, yes, that (using curl to fetch fields) is low quality. The checksum field is supposed to be embedded in the PKGBUILD, not autogenerated. AFAIK Packages are meant to be self-contained and require no further internet access to install other than downloaded sources, not to mention part of a checksum's purpose is to make sure your connection isn't intercepted, and downloading the checksum over the network defeats that purpose. Also, I don't have any affiliation with Arch. Wish you luck. -- Cheers, Aᴀʀᴏɴ
On Wed, Dec 20, 2023, at 5:19 PM, myself600@tutanota.de wrote:
Here's the summary:
I uploaded a package that soon got flagged for deletion. There were multiple reasons stated in the email which got soon accepted afterwards. I was able to find an email address of the TU and sent him a response to the claims and even tho they were not valid, namely that ARM only packages break the rules of the submission guidelines, and that the package is of low quality due to using curl to fetch pkgver and checksums, I tried to comply in ways that would eventually make the package better. I explained that the way AUR handles package updates is not optimal and that I prefer automated updates over pushing repetitive git commits.
After some time have passed I reuploaded a modified PKGBUILD that added x86 support, after which it was removed again with the reason "Dupe of [base] linux package". Even tho the pkgurl field has shown it's the Debian kernel, I've seen this wasn't communicated properly on my behalf so informed the TU that I'll make a note about the difference in the package comments section. I pushed a package update after some days and added the said note and this led to my account being suspended. From my point of view, I'm being attacked for my effort to resolve issues, but the expectation is to follow orders rather than obey rules, which is abusive and also shameful. I have not broken any of the rules despite being accused of doing so. Meanwhile, only a single person has shown willingness to help.
After reading posts of people facing the same or a similar situation, I was thinking why the Arch community treats its userbase in such a condescending way and came up with the idea that perhaps it's because "Arch Linux" is more of a hobby project than it is a commercial distribution, so there is a sense of ownership and consequently shared decisions of what "I" want or not to be in it, and therefore no incentive to keep the users happy. Despite of that, there are better ways to achieve your goals without the need to be offensive to other people I think.
As a bystander in this debate, but as a long-time Arch user, I wanted to address a few things here.
ARM only packages break the rules of the submission guidelines
I believe you're sort of right here but also sort of wrong. While there's no rule against having architectures other than x86_64, there have been other discussions on this very same list about AUR packages for other Arch-based distros, such as Garuda and Manjaro, and the rule of thumb is that "all uploaded packages must be capable of being built on at least on supported Arch Linux system, and do something useful when installed there" (source https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org/...). When you uploaded a package with only aarch64 as a supported architecture, and the only supported Arch distro is itself which is x86_64, then it's not hard to derive that the package is *not* for Arch Linux proper.
the package is of low quality due to using curl to fetch pkgver and checksums,
You shouldn't be using curl for any *any* field in the pkgbuild; it should essentially be a static file with some functions for running prepare, build, and package commands. Anything you may be curling should be pulled ahead of time and placed into the PKGBUILD file. More on that after the next comment...
I explained that the way AUR handles package updates is not optimal and that I prefer automated updates over pushing repetitive git commits.
The AUR handles package updates just fine, it's that your expectation of how it works is wrong. PKGBUILDs aren't supposed to update themselves, that's the job of the maintainer. You, by uploading the package, took on that responsibility of being the maintainer. If you do not want that responsibility, don't upload the package. Also, it's not the job of a singular PKGBUILD to "handle updates"; it shouldn't blindly be fetching some data from a remote source to find things like the version number and checksums. You could very well have scripts that automatically pull the newest version and update the PKGBUILD, which a handful of packages I use actually appear to do to help with updates, but the PKGBUILD itself should be static, a snapshot in time if you will. Additionally, even if you automate the update of PKGBUILD files, you as the maintainer should at the very least be verifying checksums and whatnot to make sure they're correct before uploading.
I pushed a package update after some days and added the said note and this led to my account being suspended.
It's likely because you re-added your package again as "linux-bin" rather than say, "linux-dfsg-bin" as someone suggested earlier in this thread. While the TU may have not mentioned that, they still told you that "linux-bin" was not okay. Now, you might come back and say "well linux-bin doesn't exist in the repos", so you'd be right, however "linux-bin" implies a relationship with the "linux" package, which *does not** *use debian sources, and therefore is named incorrectly anyway. I'm also not sure what you're referring to about "added the said note" as there's no "note" added to your update commit on 12/12. Regardless, the package name was still wrong and should have been corrected.
From my point of view, I'm being attacked for my effort to resolve issues, but the expectation is to follow orders rather than obey rules, which is abusive and also shameful.
You should read the wiki page entitled "Package Maintainer guidelines https://wiki.archlinux.org/title/Package_Maintainer_guidelines"; they are "charged with keeping the AUR in working order", and "should also make an effort to check package submissions in the AUR for malicious code and good PKGBUILDing standards." They're not picking on you, they're simply trying to ensure that the AUR has good hygiene. Everything about your package, including the name, was simply bad, regardless of whether or not it technically worked. So, no it wasn't abusive or shameful.
I have not broken any of the rules despite being accused of doing so.
You broke many rules; please read the Arch package guidelines https://wiki.archlinux.org/title/Arch_package_guidelines.
Meanwhile, only a single person has shown willingness to help.
One thing I learned a long time ago is that you can't and shouldn't infer a person's tone via written speech, as words can be read in a variety of tones; you'll likely pick the one that you think the writer is using and assume that's how you should interpret it. Therefore, you should assume the position that the person communicating with you in this situation is trying to help rather than going straight to a combative stance. The TU and others aren't trying to attack you; that's you interpreting something that's not there. The TUs are just doing the job they've been tasked with doing.
After reading posts of people facing the same or a similar situation, I was thinking why the Arch community treats its userbase in such a condescending way and came up with the idea that perhaps it's because "Arch Linux" is more of a hobby project than it is a commercial distribution, so there is a sense of ownership and consequently shared decisions of what "I" want or not to be in it, and therefore no incentive to keep the users happy.
There's a few things to unwrap here. First, I don't think it's condescending that people assume that you've read the documentation before doing things like submitting packages. Lots of work has been put into writing those wiki pages and for someone to come along and break all the rules because they haven't read them comes across a being very disrespectful. Second, if you think commercial distributions are going to just let anyone come along and submit packages, think again. Try submitting the Arch kernel to Debian or Ubuntu; you'll probably just get laughed at and told to go away. Creating packages on Launchpad or OBS isn't the same either; while you can search for packages on the website, and then add those repos to your system, it's not as easy as "yay -S my-package"; it's a completely different type of system. My suggestion for you is: First, contact the TU you've been bad mouthing and apologize, say you didn't understand that they were really trying to help you and that you didn't understand their responsibilities. If English isn't your first language, maybe throw that in there too to help show that it was a genuine misunderstanding. Second, once you've been unsuspended, *before* submitting any more packages to the AUR, maybe post it to this mailing list to get some suggestions, and start the discussion of what the package name should be and whether it even belongs in the AUR in the first place rather than having to get a TU involved after submission. Lastly, ditch the idea that you're going to have the PKGBUILD update itself. As I mentioned, it should effectively be a snapshot in time, with static data. That's not to say you can't automate updating of said PKGBUILD, see this script from the microsoft-edge-stable-bin https://aur.archlinux.org/cgit/aur.git/tree/update_version.sh?h=microsoft-ed... package as an example. But yes, every time there's an update, you'll have to run your update script and push the new PKGBUILD to the AUR. If that's not acceptable to you, then well just don't upload a package. Just keep the PKGBUILD on your own machine and run a script to automatically check for updates and use said PKGBUILD to build the package. Anyway, thanks for listening.
Hello, (Disclaimer: I'm just an AUR user and maintain a couple of packages, not a PM/TU and not associated with the Arch team)
I was able to find an email address of the TU and sent him a response
This is not how one should oppose a deletion request and not how AUR works. A merge/deletion/orphan request could be opened by any registered user against any AUR package. A email is then automatically generated with associated info and sent to the aur-requests public list. Anyone subscribed to the list would get that mail delivered, and those not subscribed could check the list archive by themselves. The "anyone" here includes any user, and any PM (previously named TU). The initial mail in the thread does not carry any metadata of any PM, but rather just the no-reply sender, and the maintainers and the requester as the recipients. At this point (mail describing the request sent to aur-requests list), no PM is associated with that request except the maintainer(s) themselves and the requester. Any one of the more than 60 PMs could come to their duty and accept the request to keep the AUR packages tidy and clean. So unless you've really made a good point to the exact PM you were sending mail to and they decided to refuse request, the only possible result is another PM that didn't read your private mail (which is not available in the public thread) decided to accept/refuse it based on what's available publicly. See, you've made the situation worse by not opposing in the thread but only privately with one particular PM. Please, the way one should continue a discussion/thread and potentially express their thoughts against the request, is to reply to the thread. The other posters could be included in the CC list, but should not be the only one the mail is delivered to.
I prefer automated updates over pushing repetitive git commits
But that's not how AUR and further how PKGBUILD should work. Yes, PKGBUILD is a Bash script under the hood but it's not just a Bash script. Its syntax is well-documented in PKGBUILD(5) and a well-formatted PKGBUILD is nearly always expected by the makepkg routine. Furthermore, a PKGBUILD itself should've defined a stable state of source(s) that should (at least try its best to) deliver a reproducible package on any builder/user. Your PKGBUILD however did some things on the other hand that one would never expect in a PKGBUILD: * It relies on network access to yield proper data structures. Without network it does not even work. If I run `unshare -fmp --net --map-current-user` then `makepkg` then the PKGBUILD is completely broken since it could not get those data you expected to be always available. It I do `printsrcinfo` then it gives an interesting broken `url = https://packages.debian.org/source//linux-signed-amd64`. * It could yield different data each time itself is parsed. Keep in mind that during the makepkg routine the PKGBUILD needs to be parsed more than once. What if the upstream updated their releases? Not only could this result in different packages built in different runs, this could also result in corrupted packages built (or not even build-able) in the same run. * It does things unexpected in a PKGBUILD and makes itself a dangerous Bash script just like any other script you get from Internet and breaks the safety assumption about PKGBUILDs by the build systems. Yes one should always check PKGBUILDs but yours effectively makes it more hard that one needs to check not only the essential functions but also a lot of things you do outside those mandatory functions. Any one of those places you do `curl` and pipe around could become a vulnerability to shell injection. * It writes to the current work directory which is a big no-go for PKGBUILDs. The work directory is expected to never be touched by the in-PKGBUILD routine but only makepkg itself. On the other hand your `linux-bin` PKGBUILD tries to create a `linux2.install`. It does not only dynamically generates code under the current work directory but also one that should be released statically alongside the PKGBUILD itself. * It does some dirty parsing to get something already pre-defined by the makepkg routine, namely trying to manually get the arch when it should always be defined as CARCH in makepkg.conf and read by makepkg, etc. * It slows down the whole building process a lot by assembling itself dynamically. On a normal PKGBUILD the `makepkg --printsrcinfo` usually only take ~2.1s but yours take ~11.26s. I have an optimized PKGBUILD parsing library (7Ji/pkgbuild-rs) which parses any PKGBUILD in merely a couple milliseconds but yours take a whopping 7.12 seconds, which is almost the time needed to parse 12406 official Arch PKGBUILDs when multi-threaded by the library. If you do need dynamically generated PKGBUILD, at least make the dynamical part not a part of PKGBUILD itself. A lot of packagers do this to their AUR packages. E.g. a lot of third-party repo maintainers also post their PKGBUILDs on AUR with automatically generated commit message, of which the generator itself is not committed as part of the AUR history.
make a note about the difference in the package comments section
Comments section is for note and for those who do check the AUR pages. Keep in mind a lot of users just use an AUR helper and never check the page. Your decision to keep the name misleading and not adding a descriptive pkgdesc is a no-go. When someone using AUR helpers dedicatedly without using Pacman itself searchs a kernel, this would appear to be a pre-built alternative to linux but is really not, and that is already troublesome as it could lead to some user installing it and bricking their system.
I'm being attacked for my effort to resolve issues
As mentioned above, your "effort to resolve issues" were never posted to public list and those are not considered to even exist by any other trying to get what has happened. From my point of view and potentially others, what you did was repeatedly uploading the `linux-bin` package without properly fixing it and communicating with the community. And you only jumped out to the aur-general list after doing this three times and finally got your account suspended.
not broken any of the rules despite being accused of doing so
Well if you do think you didn't break any rules, at least try to fix your package when informed to do so, instead of posting the broken PKGBUILD again and again. Posting a deleted package to AUR automatically revives it and considered an objection to the previous accepted deletion request. That itself is breaking the rules. Please, calm down when you posting and tone like that is really not helpful. Yours, Guoxin Pu (7Ji)
21 Dec 2023, 03:49 by myself600@tutanota.de:
Here's the summary:
I uploaded a package that soon got flagged for deletion. There were multiple reasons stated in the email which got soon accepted afterwards. I was able to find an email address of the TU and sent him a response to the claims and even tho they were not valid, namely that ARM only packages break the rules of the submission guidelines, and that the package is of low quality due to using curl to fetch pkgver and checksums, I tried to comply in ways that would eventually make the package better. I explained that the way AUR handles package updates is not optimal and that I prefer automated updates over pushing repetitive git commits.
After some time have passed I reuploaded a modified PKGBUILD that added x86 support, after which it was removed again with the reason "Dupe of [base] linux package". Even tho the pkgurl field has shown it's the Debian kernel, I've seen this wasn't communicated properly on my behalf so informed the TU that I'll make a note about the difference in the package comments section. I pushed a package update after some days and added the said note and this led to my account being suspended. From my point of view, I'm being attacked for my effort to resolve issues, but the expectation is to follow orders rather than obey rules, which is abusive and also shameful. I have not broken any of the rules despite being accused of doing so. Meanwhile, only a single person has shown willingness to help.
After reading posts of people facing the same or a similar situation, I was thinking why the Arch community treats its userbase in such a condescending way and came up with the idea that perhaps it's because "Arch Linux" is more of a hobby project than it is a commercial distribution, so there is a sense of ownership and consequently shared decisions of what "I" want or not to be in it, and therefore no incentive to keep the users happy. Despite of that, there are better ways to achieve your goals without the need to be offensive to other people I think.
I guess that you didn't read Packaging Guidelines and Submission Guidelines in ArchWiki __Properly__, before submitting your package to AUR. Arch is a community based GNU/Linux distro, in the frame of its rules and guidelines. Every system has a Frame, defined by its conducts, rules and guidelines. Any system has to have a it, it's unavoidable. And in Arch Linux, they have just some easygoing rules which I found not any hard to follow. These rules and guidelines are up for benefit of all of us. So, this community has a pretty lose frame that can include most types of orientations. And Compared to other Distros, it takes much less effort contributing back into it. But if you don't want or can't follow its simple rules, You always can keep everything local and stay a user, not a contributor. I am personally maintaining some PKGBUILDs in my local repo. For the case of your PKGBUILD, why you didn't try to send it to mailing list and/or Arch forum before uploading into AUR, as is advised by ArchWiki? -- Best Regards, Abraham Sent with Tutanota; https://tuta.com
participants (6)
-
Aaron Liu
-
Abraham S.A.H.
-
Doug Newgard
-
Guoxin Pu
-
myself600＠tutanota.de
-
Ryan Petris