Am Di, 4. Mai 2021 um 07:01:54 +0000 schrieb George Rawlinson via aur-general aur-general@lists.archlinux.org:

On 21-05-04 08:23, Fabian Bornschein via aur-general wrote:

...

For fcgu-keyring I have had filled a removal request, so this one was deliberate to be erased. For everything else it would be nice to know the reason for this, in case I do something essential wrong.

Thank you.

Hi Fabian,

As per my previous email; while responding to your removal request, I had a look at your other packages and noticed that a lot of them are packages shipping custom configurations.

The AUR is not meant to be a repository for personal items and as such, the packages shipping dotfiles were deleted. Please read the AUR submission guidelines, found here:

https://wiki.archlinux.org/title/AUR_submission_guidelines

-- George Rawlinson

Hi George, it looks like GMail doesn't like EMails. I've got the deletion notification but no other EMail. (Not even in spam). Strange, but back to topic.

Yes, many of them where preconfigurations of some sort, but not in a "specific for me system"-way, but kept generic so everyone can use them. In fact, I barely use any of them myself, but kept them up because someone asked me to keep them around.

Lets go through them one by one * https://aur.archlinux.org/pkgbase/amdgpu-experimental/ Was one of the packages I was asked to keep up, because it's easy access to amdgpu-experimental features, while this can be a struggle to setup manually.

* https://aur.archlinux.org/pkgbase/archlinux-wallpapers-mixbranding/ Is a set of wallpapers. I honestly don't know why this was removed, as it's not even a configuration thing, but (very silly) wallpapers.

* https://aur.archlinux.org/pkgbase/blacklist-hw-watchdog/ * https://aur.archlinux.org/pkgbase/blacklist_pcspkr/

Are both module blacklist. the later one is essentially the same as https://aur.archlinux.org/packages/nobeep/ , but was uploaded in, uhm 2017?. Not specific for my systems as I dont have any beeper. The other one was used by me, still not specific only for only my system.

* https://aur.archlinux.org/pkgbase/fabiscafe-keyring/ Is a pubkey, that is important to have signed packages active for our GNOME-unstable repo: see https://gitlab.com/fabis_cafe/gnome-unstable, and in future maybe also gnome-oldstable, see: https://gitlab.com/fabis_cafe/gnome-oldstable I dont know for sure if this was OK to be in the AUR, but since https://aur.archlinux.org/packages/?O=0&SeB=nd&K=keyring&outdate... archlinuxarm,32, even chaotic-aur and a lot more are there, I never saw a problem with that one.

* https://aur.archlinux.org/pkgbase/preconf-cups-desktop/ Is a preconfiguration that enabled and installed printer support for desktops. Also not specific for me, just easy access.

* https://aur.archlinux.org/pkgbase/preconf-intel-nvidia-prime-render-offloadi... Where a lot of configuration to set up prime-offloading with working powermanagement on newer optimus-ready systems. I actually only bought a GT 710 to write this package in order to help people set this up. Not specific for me. (because AMD ftw :D)

* https://aur.archlinux.org/pkgbase/preconf-sudo-wheel/ This just creates the sudo configuration for wheel users in /etc/sudoers.d. I won't lie, this was made because I'm lazy. I dont know if this is actually used by anyone else.

* https://aur.archlinux.org/pkgbase/systemd-boot-esp-sync/ This one syncs /boot to /efi/$machine-id either via systemd.path or via alpm hook. I've written this in a generic form, so others can use (and I know at least 2 people who use it in addition of myself).

* https://aur.archlinux.org/pkgbase/game-devices-udev/ This one adds udev rules for a lot of gaming controllers who might otherwise not work on your system. It's not really a preconfiguration. So also in here I dont understand why this was removed at all.

* https://aur.archlinux.org/pkgbase/unlock-pacman/ This one just removes to pacman-lock at startup, in case it's there.

None of them are in my opinion really specialized or specific for me alone and almost all of them add something of value to a users system. I can't find something that preconfigurations, wallpapers, udev-rules or "keyrings" are not allowed on the AUR either in https://wiki.archlinux.org/title/AUR_submission_guidelines. So I'm a pretty shocked by that move.

Am Di, 4. Mai 2021 um 13:30:04 +0200 schrieb alad via aur-general aur-general@lists.archlinux.org:

On 04/05/2021 09:52, Fabian Bornschein via aur-general wrote:

...

Am Di, 4. Mai 2021 um 07:01:54 +0000 schrieb George Rawlinson via aur-general <aur-general@lists.archlinux.org mailto:aur-general@lists.archlinux.org>:

...

On 21-05-04 08:23, Fabian Bornschein via aur-general wrote:

...

For fcgu-keyring I have had filled a removal request, so this one was deliberate to be erased. For everything else it would be nice to know the reason for this, in case I do something essential wrong.

Thank you.

Hi Fabian,

As per my previous email; while responding to your removal request, I had a look at your other packages and noticed that a lot of them are packages shipping custom configurations.

The AUR is not meant to be a repository for personal items and as such, the packages shipping dotfiles were deleted. Please read the AUR submission guidelines, found here:

https://wiki.archlinux.org/title/AUR_submission_guidelines

-- George Rawlinson

Hi George, it looks like GMail doesn't like EMails. I've got the deletion notification but no other EMail. (Not even in spam). Strange, but back to topic.

Yes, many of them where preconfigurations of some sort, but not in a "specific for me system"-way, but kept generic so everyone can use them. In fact, I barely use any of them myself, but kept them up because someone asked me to keep them around.

The wiki specifically documents configurations so users can understand what they do and adapt them as they wish. They don't belong as separate packages in the AUR. This especially holds for trivial changes such as blacklisting modules or enabling systemd services.

Hi and thanks for this answer. I think this part would be welcome in the AUR submission guidelines, as there are a lot of packages starting from direct configurations like my packages and ending with applications who create the configuration later on. Because It's in my opinion not apparent that this kind of packages are not welcome in any way.

Some other remarks:

unlock-pacman: if there's a stale pacman lock that means the user should investigate why it happened (e.g. interruption during an update) rather than automatically delete it. Packages offering this kind of functionality should never be uploaded.

Keyrings: Grey area as some are directly related to building packages (eg. debian-keyring, archlinuxarm-keyring) while others are purely to support users of an unofficial repo unrelated to the AUR (eg. chaotic-keyring).

...

None of them are in my opinion really specialized or specific for me alone and almost all of them add something of value to a users system. I can't find something that preconfigurations, wallpapers, udev-rules or "keyrings" are not allowed on the AUR either in https://wiki.archlinux.org/title/AUR_submission_guidelines. So I'm a pretty shocked by that move.

Common sense is advised. When you upload packages with things like

post_upgrade() { printf "\nThanks for still using my pkg 😊\n\n"; } or

post_install() { printf "This is for Testing RN; please report back\n\n"; }

in the install script it should be no surprise these packages are treated with suspicion and eventually deleted.

OK, thats true. Sorry for these mistakes.

However, requests are used to leave a paper trail and (egregious cases aside) leave the maintainer some time to respond. I'd suggest anyone to use that system where they are able.

Alad

On 5/4/21 3:52 AM, Fabian Bornschein via aur-general wrote:

Am Di, 4. Mai 2021 um 07:01:54 +0000 schrieb George Rawlinson via aur-general aur-general@lists.archlinux.org:

...

On 21-05-04 08:23, Fabian Bornschein via aur-general wrote:

...

For fcgu-keyring I have had filled a removal request, so this one was  deliberate to be erased. For everything else it would be nice to know the  reason for this, in case I do something essential wrong.

Thank you.

Hi Fabian,

As per my previous email; while responding to your removal request, I had a look at your other packages and noticed that a lot of them are packages shipping custom configurations.

The AUR is not meant to be a repository for personal items and as such, the packages shipping dotfiles were deleted. Please read the AUR submission guidelines, found here:

https://wiki.archlinux.org/title/AUR_submission_guidelines

-- George Rawlinson

Hi George, it looks like GMail doesn't like EMails. I've got the deletion notification but no other EMail. (Not even in spam). Strange, but back to topic.

Yes, many of them where preconfigurations of some sort, but not in a "specific for me system"-way, but kept generic so everyone can use them. In fact, I barely use any of them myself, but kept them up because someone asked me to keep them around.

The rules of submission which you were pointed at, do not say "can't be specific to your system", so keeping it "generic" is not sufficient.

The rules say "Will anyone else want to use this package? Is it extremely specialized?"

Lets go through them one by one

• https://aur.archlinux.org/pkgbase/amdgpu-experimental/

Was one of the packages I was asked to keep up, because it's easy access to amdgpu-experimental features, while this can be a struggle to setup manually.

• https://aur.archlinux.org/pkgbase/archlinux-wallpapers-mixbranding/

Is a set of wallpapers. I honestly don't know why this was removed, as it's not even a configuration thing, but (very silly) wallpapers.

George was probably concerned that it was too personal and specific to one person.

• https://aur.archlinux.org/pkgbase/blacklist-hw-watchdog/
• https://aur.archlinux.org/pkgbase/blacklist_pcspkr/

Are both module blacklist. the later one is essentially the same as https://aur.archlinux.org/packages/nobeep/ , but was uploaded in, uhm 2017?. Not specific for my systems as I dont have any beeper. The other one was used by me, still not specific only for only my system.

I don't know why the nobeep package exists either, feel free to request its removal. Please don't justify one package that doesn't meet the submission guidelines, simply because someone else did something similar and didn't get noticed.

• https://aur.archlinux.org/pkgbase/fabiscafe-keyring/

Is a pubkey, that is important to have signed packages active for our GNOME-unstable repo: see https://gitlab.com/fabis_cafe/gnome-unstable, and in future maybe also gnome-oldstable, see: https://gitlab.com/fabis_cafe/gnome-oldstable I dont know for sure if this was OK to be in the AUR, but since https://aur.archlinux.org/packages/?O=0&SeB=nd&K=keyring&outdate... archlinuxarm,32, even chaotic-aur and a lot more are there, I never saw a problem with that one.

For keyring packages... please consider the point of a pacman keyring is to manage and distribute a web of trust. Arch Linux, as well as Arch Linux ARM and Arch Linux 32, have multiple packaging keys to manage, so adding them is more complicated than simply pacman-key -r <keyid> && pacman-key -l <keyid>; particularly, they actually need to make use of pacman-key's master key list, or revocation list.

I didn't check any others.

I'm not sure whether such packages are needed for one key, but I'm a bit skeptical.

• https://aur.archlinux.org/pkgbase/preconf-cups-desktop/

Is a preconfiguration that enabled and installed printer support for desktops. Also not specific for me, just easy access.

We can tell what it is, yes. That's the problem. This PKGBUILD does nothing other than enable the systemd units from the cups package. It's explicitly a problem -- do not reupload it under any circumstances.

https://aur.archlinux.org/pkgbase/preconf-intel-nvidia-prime-render-offloadi...

Where a lot of configuration to set up prime-offloading with working powermanagement on newer optimus-ready systems. I actually only bought a GT 710 to write this package in order to help people set this up. Not specific for me. (because AMD ftw :D)

• https://aur.archlinux.org/pkgbase/preconf-sudo-wheel/

This just creates the sudo configuration for wheel users in /etc/sudoers.d. I won't lie, this was made because I'm lazy. I dont know if this is actually used by anyone else.

It's a package that adds one line to your system, for people who don't want to uncomment the same line in the default /etc/sudoers

:/

• https://aur.archlinux.org/pkgbase/systemd-boot-esp-sync/

This one syncs /boot to /efi/$machine-id either via systemd.path or via alpm hook. I've written this in a generic form, so others can use (and I know at least 2 people who use it in addition of myself).

Regardless of any other problems...

install=$(/usr/bin/tail -n 1 /usr/lib/os-release | /usr/bin/cut -d= -f2).install

This is not ok.

• https://aur.archlinux.org/pkgbase/game-devices-udev/

This one adds udev rules for a lot of gaming controllers who might otherwise not work on your system. It's not really a preconfiguration. So also in here I dont understand why this was removed at all.

This one seems like it should be ok, I guess...

• https://aur.archlinux.org/pkgbase/unlock-pacman/

This one just removes to pacman-lock at startup, in case it's there.

"this one just X"

You think "it just" is an explanation several times here, but no, you can't "just" because there are rules and you need to follow them.

A package to remove the pacman database lock on every boot is definitely not useful to more than one person, in large part because IT IS BASICALLY MALWARE.

Do not recommend people break their systems. Do not recommend people with critically damaged systems, remove the lockfile that is supposed to both point this out, and prevent them from breaking it even further. That lockfile means something -- it means you need to fix your system and if you don't know why then you need to ask for help.

You cannot normally get this lockfile unless pacman segfaulted halfway through an update -- or the entire operating system segfaulted, or abnormally powered off.

None of them are in my opinion really specialized or specific for me alone and almost all of them add something of value to a users system. I can't find something that preconfigurations, wallpapers, udev-rules or "keyrings" are not allowed on the AUR either in https://wiki.archlinux.org/title/AUR_submission_guidelines. So I'm a pretty shocked by that move.

On 5/4/21 9:07 AM, Fabian Bornschein via aur-general wrote:

Hello. Yes, you're of course right. It just seems to be not to clear on what point "extremely specialized" starts. I'm pretty much confused. Can I give an example? (If not, please just ignore) I got it now that pre-configurations are not OK and should stay on the wiki. What if I build a shellscript, pkgbuild this up and send it to the AUR, where a user installes and runs it later on? It will add the same configuration as my pkgbuild right now. In my mind that would also be not OK, because it's pretty much the same. Now I also add more configurations to this script, for printer setup, hardwareacceleration in browsers and whatever. Would it be OK in that case to put it to the AUR? I don't want to be rude in any way, I really really do not understand this one.

Sounds like it would still ultimately be user configurations through and through... it's fine to have a PKGBUILD for user configs, the question is whether they're useful in the AUR.

I'd recommend doing something like this:

https://github.com/Earnestly/pkgbuilds/blob/master/system-config/PKGBUILD

And then documenting it, using factored-out *.d/ directory dropins where possibble, and so on, in order to let people take inspiration from you, but keep it out of the AUR.

Maybe start a wiki page similar to the dotfiles one: https://wiki.archlinux.org/title/Dotfiles

Then people can both share tips on designing their system config packaging, and share their actual configuration as examples.

...

For keyring packages... please consider the point of a pacman keyring is to manage and distribute a web of trust. Arch Linux, as well as Arch Linux ARM and Arch Linux 32, have multiple packaging keys to manage, so adding them is more complicated than simply pacman-key -r <keyid> && pacman-key -l <keyid>; particularly, they actually need to make use of pacman-key's master key list, or revocation list.

I didn't check any others.

I'm not sure whether such packages are needed for one key, but I'm a bit skeptical.

I know this is OT, but is there an alternative to a pkgbuild to add the key? What would be the optimal way tell pacman that packages of repo XY can be trusted?

Sure. a pacman keyring compiles a known collection of keys as a shortcut to, again, using

sudo pacman-key --recv-keys <keyid> sudo pacman-key --lsign-key <keyid>

But mostly it is there to help manage pinning a collection of them as "master keys" which are lsigned, and other keys which are not but use Web of Trust.

For a single user key, I'd recommend using the recv-keys && lsign-key route. Simply document on the page describing the repository, that the key needs to be added. For example, on the wiki page: https://wiki.archlinux.org/title/Unofficial_user_repositories

There is a template for listing the Key-ID needed, and the page has a preamble describing how to enable those keys. It works for 64 different publicly listed user repositories as of right now.

Use a keyring package if you have more complicated requirements including key rotation and delegated trust. Unless you're managing an organization such as a CPU port of all of Arch Linux (like the i686 port, or the ARM port), you probably do not need this.

...

We can tell what it is, yes. That's the problem. This PKGBUILD does nothing other than enable the systemd units from the cups package. It's explicitly a problem -- do not reupload it under any circumstances.

I will not upload anything again until I am sure what's OK and what's not.

Thank you. Remember that the aur-general mailing list, the freenode IRC channel #archlinux-aur, and the official forum's dedicated AUR subforum, are all available to anyone who wants help creating packages *or* a friendly set of eyes to review a package before upload. If in doubt, feel free to ask, we won't bite people asking honest questions and being careful. :)

(It is possible we might bite if a package was mistakenly uploaded which should not be -- but that would be tied to individual reactions on failure to ask first and the resulting work it causes. :p)

...

Regardless of any other problems...

install=$(/usr/bin/tail -n 1 /usr/lib/os-release | /usr/bin/cut -d= -f2).install

This is not ok.

I'm with you on this. At some point all my packages have had that one. Most of them where changed back.

Ok, good -- please do fix up any remaining ones. :D