On Tue, Jan 03, 2023 at 07:10:47PM +0000, Robin Candau wrote:
Le 03/01/2023 à 18:40, Morten Linderud a écrit :
I looked over them and they generally seem fine. The only weird part I have found is this install script that symlinks `/usr/bin/clipboard` to `/usr/bin/cb` in 3 packages. Why did you pick this solution?
https://aur.archlinux.org/cgit/aur.git/tree/clipboard.install?h=clipboard
This is something originally done by upstream in the Cmake build instructions file [1] since this is how upstream decided to handle the possibility to run both the `clipboard` and `cb` command. Obviously, it results as a permission issue when built with `makepkg` (since it tries to modify something outside of the `pkgdir`) preventing me to deal with that directly in the PKGBUILD as well. So to stay as close as possible to the upstream packaging method I deported that symlink instruction to a post install script.
I imagine there's certainly a more elegant way to deal with this symlink, I'll look into it.
https://pkgbuild.vdwaa.nl/?q=ln%20-s&i=nope&literal=nope&files=&excludeFiles=&repos= Generally you can do something like ln -s "/usr/bin/old_name" "${pkgdir}/usr/bin/new_name"
As a TU, I'm looking forward to help with the AUR moderation (reviewing PKGBUILDs, answering AUR related questions and handling AUR requests).
I'd also be interested in moving the following AUR packages to Community:
[snip]
- protonmail-bridge Is this covered under the "protonmail" trademark? Can we redistribute this with the name "protonmail"? Is there any other terms or restrictions on this?
It is indeed copyrighted under the "Proton AG" trademark, but the protonmail-bridge app itself is distributed (and allowed to be redistributed/modified) under the GPL3 license [3] so I'd say we should be allowed to redistribute it with the name "protonmail"? I didn't thought about that (yet) to be honest but I'll search deeper into it if I ever have the chance to move it to community.
GPL3 doesn't give any permissions to trademarks of the project. Generally this isn't a problem since few GPL licensed projects are written by companies and have trademarks registered. This is something that can be explored when it becomes relevant :)
A few of these have two maintainers already, is there any orphaned packages you would like to maintain in the repositories? Keep in mind that any packages in [extra] is not accessible to TUs currently, but the plan is for this to change.
Indeed, my bad. Here's a stripped-down list of packages that only have one maintainer currently:
- glow - xautolock - hq - hexchat - zathura suite (zathura, zathura-cb, zathura-djvu, zathura-pdf-mupdf, zathura-pdf-poppler, zathura-ps) - icewm - firewalld - picom - notification-daemon - blueman - redshift - gsimplecal - tint2 - feh
I haven't found any packages I personally use or would want to maintain in the community/extra's orphaned packages at first glance to be honest, but I could still adopt some if needed. As I said, my primary goal with this application is to contribute/help further :)
There are no rules that says you can't have more than 2 maintainers, but we try to always keep two maintainers on any given package. Generally it's better to adopt a package with one maintainer then adopting a package with two maintainers. It spreads out the work. You'll always find something to adopt if you later anyways :) Note: You sent a clear text email to the list, and an encrypted email to me. It seems like your email client gets confused and produces an invalidly signed email as a result. I'd recommend just disabling encrypted emails when it goes over the mailing list. It's also very annoying to deal with encrypted emails on the reciving end when there is no need for it. -- Morten Linderud PGP: 9C02FF419FECBE16