Le 03/01/2023 à 20:37, Morten Linderud a écrit : > 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" Well... I guess it's always the easiest solutions that are the hardest to find in the first place, right? :p I don't know how I missed that to be honest... Anyway, thanks a lot. I made the associated corrections on the clipboard* PKGBUILDs! >>>> 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 :) Fair enough. > > 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. Whoops... Didn't mean to. I disabled encrypted emails.
Regards, Antiz (Robin C.)