[aur-general] aur client
Since publishing to the AUR is something that all packagers do quite frequently, I have developed a software that reduces the related operations to the bare minimum, making publishing to the AUR instant. Basically it's a SMED https://www.youtube.com/watch?v=Aoqra9bXAAg system. The software is called "aur https://aur.archlinux.org/packages/aur-git" itself, and you can check its manual out by in the terminal entering: curl --silent https://gitlab.com/es20490446e/aur/raw/master/assets/aur.1
aur.1; man ./aur.1; rm aur.1
As long as constructive, suggestions are very welcome. When replying please include my email address in the recipients list. Alberto https://es20490446e.wordpress.com
On Tue, 29 Oct 2019 at 01:49, Alberto Salvia Novella via aur-general
Since publishing to the AUR is something that all packagers do quite frequently, I have developed a software that reduces the related operations to the bare minimum, making publishing to the AUR instant.
Basically it's a SMED https://www.youtube.com/watch?v=Aoqra9bXAAg system. The software is called "aur https://aur.archlinux.org/packages/aur-git" itself, and you can check its manual out by in the terminal entering:
curl --silent https://gitlab.com/es20490446e/aur/raw/master/assets/aur.1
aur.1; man ./aur.1; rm aur.1
As long as constructive, suggestions are very welcome. When replying please include my email address in the recipients list.
The name `aur` is already claimed by aurutils, may wanna pick something else to avoid conflicts.
On 10/28/19 9:49 PM, Alberto Salvia Novella wrote:
What is with your email headers, and the waves of duplicated email I
just got.
To: Arch Linux - Announcements
Since publishing to the AUR is something that all packagers do quite frequently, I have developed a software that reduces the related operations to the bare minimum, making publishing to the AUR instant.
Basically it's a SMED https://www.youtube.com/watch?v=Aoqra9bXAAg system.
"Since packagers quite frequently package things, we need a way to help people package things as utterly fast as possible, without wasting any time at all." This "SMED" thing seems to suggest that the most important thing for the consumer industry is fast labor to produce (cookie-cutter?) products more efficiently. Fine... Why is this relevant to the AUR, which is a creative labor in which uploads require a social contract of responsibility, that responsibility being "I believe I have to the best of my abilities tried to avoid uploading actual literal 💩💩💩💩💩💩💩💩" as well as "the package actually successfully builds on my machine"? (Ideally the package successfully builds and runs in a makechrootpkg clean-build container.) Automation of boring trivia is not necessarily a bad thing, but it comes across as rather funny (funny as in "weird, not funny as in "haha") when your rationale brings positive reinforcement from a promotional video about quantity over quality.
The software is called "aur https://aur.archlinux.org/packages/aur-git" itself, and you can check its manual out by in the terminal entering:
You're really shooting for the most impressive namespace here, I see. :) I have looked at your AUR package, and it seems to also use another AUR package you uploaded -- "silently-git", whose purpose is to run commands and delete their stdout/stderr unless the command returns a fatal exit code, in which case it only deletes stdout. (Note it also uses badly escaped messages and eval, resulting in incorrect commit messages for things that contain, say, quotes.) This is utterly wrong, since makepkg can emit information on stderr at loglevel "warning" (bold yellow "==> WARNING:" followed by some warning) while also exiting with a successful return code, and users should make sure that the warning does not denote something bad (sometimes it does). More generally, I have certainly seen packages whose build systems returned successfully -- and packaged nothing, or just packaged an incomplete portion of the software -- due to incorrectly masking return values of commands in their Makefile. Especially if this is geared to people maintaining/uploading packages, I have a hard time seeing this as anything other than a very bad goal to begin with.
curl --silent https://gitlab.com/es20490446e/aur/raw/master/assets/aur.1
aur.1; man ./aur.1; rm aur.1
As long as constructive, suggestions are very welcome. When replying please include my email address in the recipients list.
No, this is not how mailing lists work. You are posting here to start a discussion, it's expected you subscribe to the discussion rather than ask people to manually add your email address to Cc: (and then re-add it every time it gets dropped by another poster). You are automatically going to miss at least some responses (you have missed 100% of the single response before mine). Please re-enable mail delivery for this mailing list if you expect to have a discussion on it. This is also not how feedback works. You don't get to say no one is allowed to talk to you unless they agree with you, so let's not have another of your mailing list threads where you claim everyone who disagrees with you is being "not constructive" and therefore their comments are "not welcome". No one here is interested in a repetition of https://lists.archlinux.org/pipermail/arch-general/2019-October/046991.html https://lists.archlinux.org/pipermail/arch-general/2019-October/046999.html -- Eli Schwartz Bug Wrangler and Trusted User
Eli Schwartz:
This "SMED" thing seems to suggest that the most important thing for the consumer industry is fast labor to produce (cookie-cutter?) products more efficiently.
Actually SMED was also invented as a quality control mechanism. The idea is that when changing things is fast, it encourages people to correct mistakes as they are discovered. Eli Schwartz:
Uploads require a social contract of responsibility, that responsibility being "I believe I have to the best of my abilities tried to avoid uploading actual literal 💩💩💩💩💩💩💩💩" as well as "the package actually successfully builds on my machine"?
The process that "aur" defines is populated with mistake proofed mechanisms (aka poka joke https://www.google.com/search?q=poka+joke). Since most error detection is standardized in code, not on manual operation, it cannot be overlooked. Plus "aur pack" eases testing the package before uploading. Then any mistake will be exposed. Eli Schwartz:
(Note it also uses badly escaped messages and eval, resulting in incorrect commit messages for things that contain, say, quotes.)
Provide a sample where that happens, and I will consider a solution. Eli Schwartz:
let's not have another of your mailing list threads where you claim everyone who disagrees with you is being "not constructive"
Any feedback which real intention is to help improving is welcome. Alberto https://es20490446e.wordpress.com
Replying on the most relevant mailing list. On Tue 29 Oct 2019 02:49 +0100, Alberto Salvia Novella wrote:
Since publishing to the AUR is something that all packagers do quite frequently, I have developed a software that reduces the related operations to the bare minimum, making publishing to the AUR instant.
Dude you can't just spam all lists with your projects. Please consider mailing list etiquette.
The software is called "aur https://aur.archlinux.org/packages/aur-git"
Please rename your project to avoid confusion. I'm surprised that the name wasn't already blacklisted. I would hope some TU does add 'aur' to the blacklist of package names. Good luck.
Em outubro 29, 2019 12:55 Loui Chang escreveu:
Please rename your project to avoid confusion. I'm surprised that the name wasn't already blacklisted. I would hope some TU does add 'aur' to the blacklist of package names.
There is no "blacklist". Having said that, I don't think that name is good at all. Regards, Giancarlo Razzolini
On 10/29/19 1:06 PM, Giancarlo Razzolini via aur-general wrote:
Em outubro 29, 2019 12:55 Loui Chang escreveu:
Please rename your project to avoid confusion. I'm surprised that the name wasn't already blacklisted. I would hope some TU does add 'aur' to the blacklist of package names.
There is no "blacklist". Having said that, I don't think that name is good at all.
Correction: there is "a blacklist", but it's only used to prevent namespace conflicts for users who attempt to upload packages named the same pkgname as a package in the binary repos. It is correct to say we have never attempted to blacklist names which "shouldn't be allowed to exist as packages because $person dislikes the name". "aur" isn't inherently a bad name, I could conceive of it being the name for a package which installs the aur.archlinux.org software, though "aurweb" would be an even better name. ;) -- Eli Schwartz Bug Wrangler and Trusted User
Em outubro 29, 2019 14:09 Eli Schwartz via aur-general escreveu:
Correction: there is "a blacklist", but it's only used to prevent namespace conflicts for users who attempt to upload packages named the same pkgname as a package in the binary repos.
It is correct to say we have never attempted to blacklist names which "shouldn't be allowed to exist as packages because $person dislikes the name".
"aur" isn't inherently a bad name, I could conceive of it being the name for a package which installs the aur.archlinux.org software, though "aurweb" would be an even better name. ;)
Indeed, a there are two blacklists, one that blacklists repo packages, so they are not uploaded to the AUR. That one is updated automatically. There's a second blacklist, but that one has no way to update, other than through the DB, hence my confusion. I think we should probably start adding a few packages to that list. Regards, Giancarlo Razzolini
On 10/29/19 1:22 PM, Giancarlo Razzolini wrote:
Em outubro 29, 2019 14:09 Eli Schwartz via aur-general escreveu:
Correction: there is "a blacklist", but it's only used to prevent namespace conflicts for users who attempt to upload packages named the same pkgname as a package in the binary repos.
It is correct to say we have never attempted to blacklist names which "shouldn't be allowed to exist as packages because $person dislikes the name".
"aur" isn't inherently a bad name, I could conceive of it being the name for a package which installs the aur.archlinux.org software, though "aurweb" would be an even better name. ;)
Indeed, a there are two blacklists, one that blacklists repo packages, so they are not uploaded to the AUR. That one is updated automatically.
There's a second blacklist, but that one has no way to update, other than through the DB, hence my confusion.
Hence my confusion too... I did not realize we had another table.
I think we should probably start adding a few packages to that list.
Makes sense, we have the functionality so we might as well use it. The question is what criteria to use. :/ -- Eli Schwartz Bug Wrangler and Trusted User
On 10/29/19 5:35 PM, Eli Schwartz via aur-general wrote:
I think we should probably start adding a few packages to that list.
Makes sense, we have the functionality so we might as well use it. The question is what criteria to use. :/
On that note, I'm in the middle of rewriting AIF-NG[0] to be a lot easier to maintain, understand, etc. (Plus it broke, and it needed to be rewritten anyways, so here we are.) (For those unfamiliar, basically a Kickstart equivalent for Arch.) Would that package name ("aif" or "aif-ng") be okay? The *full* name is "Arch (Linux) Installation Framework, Next Generation" but that wouldn't be in the package name, just the description. Is this enough segregation to be okay? (My hope is to get it good enough to be considered as adoption INTO an official package eventually, if that clarifies the case.) [0] https://aif-ng.io; docs haven't been updated for rewrite yet as focusing on code first. -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
Em outubro 29, 2019 18:35 Eli Schwartz escreveu:
Makes sense, we have the functionality so we might as well use it. The question is what criteria to use. :/
I guess that starting with names that might sound "official" like AUR, is a good starting point. Also, having a way to query/edit that list in a better fashion than directly manipulating the DB will certainly make it more appealing. Regards, Giancarlo Razzolini
participants (6)
-
Alberto Salvia Novella
-
brent s.
-
Eli Schwartz
-
Giancarlo Razzolini
-
Loui Chang
-
Morgan Adamiec