On 03/01/2023 19:08, Leonidas Spyropoulos wrote:

This marks the beggining of the discussion period which will conclude in two weeks on 2023-01-18. The voting will start on the same day and conclude on 2023-01-25.

Kind reminder the discussion period has 1 more week left. -- Leonidas Spyropoulos PGP: 59E43E106B247368

Hello On 18/01/2023 09:43, Leonidas Spyropoulos wrote:

Discussion period is over and the vote is live. Please cast your votes

https://aur.archlinux.org/tu/142 The voting period has ended.

          Yes 40            No  5       Abstain 9         Total 54 Participation 88.52% Result: Accepted Congratulations Antiz, you are now officially accepted as TU. Please proceed with https://wiki.archlinux.org/title/AUR_Trusted_User_guidelines#TODO_list_for_n... Regards, -- Leonidas Spyropoulos PGP: 59E43E106B247368

Le 03/01/2023 à 18:40, Morten Linderud a écrit :

On Tue, Jan 03, 2023 at 11:03:07AM +0000, Robin Candau wrote:

...

Hello, Yo, Hi My name's Robin Candau and I'd like to apply to become a Trusted User. My sponsors are Leonidas Spyropoulos <artafinde> and T.J. Townsend <blakkheim>. Thanks for you application and good luck! Thanks! - I maintain some packages on the AUR. 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.

...

    - More recently, I've been working with Rudra Saraswat (the Ubuntu Unity project lead) to help him properly packaging the Unity desktop environment for Arch (this is still a WIP) [5]. Nice, I looked over the original packaging and was disappointed in the package quality. Hopefully it will shape up nicely in the future. Yeah, I left a comment on the AUR web page of the initial Unity package (which has been deleted since then) to point out what could/should be improved regarding the packaging guidelines/best-practices and eventually offer my help to Rudra to properly package Unity for Arch; and this is how we started to work together on this.

...

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

For the moment, all of the Unity packages has been moved to a dedicated pacman repo [2]. As I said, this is still a WIP I'm looking forward to continue on with Rudra. Hopefully it will shape up nicely in the future, indeed :) 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.

...

- unrar-free (which I currently maintain) I had similar concerns with `unrar`, but it seems like Fedora and Ubuntu is packaging this. I'd assume this should be safe then.

https://repology.org/project/unrar-free/versions Indeed, this one is already packaged by several other distributions, so it should be fine.

...

Finally, those are the packages I use and/or I'd be interested in (co-)maintaining in Community: - glow - flameshot - xautolock - numlockx - playerctl - autorandr - hq - hexchat - pacman-contrib - zathura* (zathura, zathura-cb, zathura-djvu, zathura-pdf-mupdf, zathura-pdf-poppler, zathura-ps) - tmux - icewm - firewalld - picom - notification-daemon - blueman - redshift - xautolock - gsimplecal - tint2 - feh 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 :) [1] https://github.com/Slackadays/Clipboard/blob/ab064974c931f49d84caa7d512178f4... [2] https://unity.ruds.io/arch-unity/ [3] https://github.com/ProtonMail/proton-bridge/blob/master/COPYING_NOTES.md Regards, Antiz (Robin C.)

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.)

Le 03/01/2023 à 21:21, Levente Polyak a écrit :

On 1/3/23 21:16, Robin Candau wrote:

...

Le 03/01/2023 à 20:37, Morten Linderud a écrit :

...

...

Le 03/01/2023 à 18:40, Morten Linderud a écrit : Note: You sent a clear text email to the list, and an encrypted email to me. It seems

On Tue, Jan 03, 2023 at 07:10:47PM +0000, Robin Candau wrote: 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.

First: Good luck :) Hi, thanks :)

Hm it looks like you now also disabled signed messages all together, which isn't really desired :D

Also I'm not sure if its just my end, but I'm unable to verify any of your signed emails unfortunately.

Cheers, Levente Yeah, I definitely have an issue with my PGP settings in Thunderbird. I assume this mail will have problems as well. I'm really sorry about that... I'm looking that up for the next messages!

Regards, Antiz (Robin C.)

On 1/3/23 22:58, Robin Candau wrote:

...

Yeah, I definitely have an issue with my PGP settings in Thunderbird. I assume this mail will have problems as well. I'm really sorry about that... I'm looking that up for the next messages! It seems like my protonmail address doesn't want to send properly signed mails for some reasons ¯\_(oO)_/¯ I'm switching to my gmail address which, hopefully, will produces a

Le 03/01/2023 à 21:29, Robin Candau a écrit : properly signed mail.

Regards, Antiz (Robin C.)

Can confirm it produced a valid and working signatures :) Thanks for trying to debug this :) Cheers, Levente

Le 16/01/2023 à 12:12, Jan Alexander Steffens (heftig) a écrit :

On Tue, Jan 3, 2023 at 12:03 PM Robin Candau wrote:

- I maintain a few packages in the AUR with what I think are high-quality/clean PKGBUILDs [1].

[1] https://aur.archlinux.org/packages?O=0&SeB=M&K=Antiz&outdated=&SB=p&SO=d&PP=50&submit=Go https://aur.archlinux.org/packages?O=0&SeB=M&K=Antiz&outdated=&SB=p&SO=d&PP=50&submit=Go

Hi Robin, Hi Jan!

I looked at your PKGBUILDs. In general, they look very good! I have a few questions:

Regarding clipboard and clipboard-git: Doesn't setting CMAKE_C_FLAGS or CMAKE_CXX_FLAGS make it ignore the CFLAGS and CXXFLAGS in the environment?

Regarding unrar-free: Doesn't passing CFLAGS to configure make it ignore the CFLAGS in the environment?

Indeed, I think you're right! I corrected the clipboard, clipboard-git and unrar-free PKGBUILDs according to that, by adding the necessary flags to the existing environment variable in the build function like so: `export CFLAGS=${CLAFGS} -NEEDED_FLAG"` Thanks for raising this!

Regarding ame and ame-git: You export 'RUSTUP_TOOLCHAIN=nightly'. Does Amethyst require nightly Rust to build?

If it doesn't, it would break building on systems using rustup but only the stable toolchain installed.

If it does, I think you should makedepend on rustup and ensure the nightly toolchain is installed in prepare(). This would also allow it to build in clean chroots.

Regarding malachite: You export 'RUSTUP_TOOLCHAIN=stable'. I think you should just let it use the default toolchain because the stable toolchain might not be installed and using a newer toolchain shouldn't break the build. (In general, I would expect the stable toolchain to be the default, to match the rust package.)

I discussed that subject with upstream and it appears that pointing to a specific toolchain for the build was initially implemented because it was historically needed for older versions of those packages. As seen with them, this is not required anymore so I could delete the "export RUSTUP_TOOLCHAIN" in both the "ame(-git)" and the "malachite" PKGBUILDs in order to use the default toolchain. Once again, thanks for the suggestion!

Greetings, Jan

-- Regards, Robin

Le 17/01/2023 à 14:29, Caleb Maclennan a écrit : Hi Caleb,

This is, unfortunately, not the case. I added this specific recommendation to the Rust package guidelines because there have been quite a few cases where the nightly toolchain will fail to build packages that depend on the stable one. The guideline is *only* applicable to local host builds and irrelevant in a chroot build, so when migrating things to [community] it can and should be dropped, but for the AUR it does help make more packages buildable for more people. It also helps given them useful errors when they have only non-stable toolchains enabled by default. It is actually quite common for people to default to something other than the stable toolchain because quite a number of upstream project give people instructions for how to reset the defaults to nightly in order to build themselves from source, but rarely also include instructions for how to do it while keeping stable as default.

Thanks for the precision, it makes sense! Since the related packages I currently maintain in the AUR does not depend on a specific toolchain to be built (as seen with upstream), is it safe for me to drop the toolchain definition in the PKGBUILD or you're suggesting putting it back to "stable" anyway?

On 2023-01-16 14:12, Jan Alexander Steffens (heftig) wrote:

...

Regarding malachite: You export 'RUSTUP_TOOLCHAIN=stable'. I think you should just let it use the default toolchain because the stable toolchain might not be installed and using a newer toolchain shouldn't break the build. (In general, I would expect the stable toolchain to be the default, to match the rust package.)

-- Regards, Robin Candau

Le 25/01/2023 à 11:56, Caleb Maclennan a écrit :

On 2023-01-17 14:40, Robin Candau wrote:

...

Since the related packages I currently maintain in the AUR does not depend on a specific toolchain to be built (as seen with upstream), is it safe for me to drop the toolchain definition in the PKGBUILD or you're suggesting putting it back to "stable" anyway?

My suggestion would be to *always* include the toolchain selection and choose stable for PKGBUILDs in the AUR even if the project nominally works with nightly. This goes along with also using the other arguments for freezing the dependencies against the upstream lockfile rather than dynamically building with whatever comes down the pipeline at the time of build.

This will be less brittle (even if it works at the moment you test it with nightly and dynamic dependency updates it might not work a month later for some random user that gets an updated dependency or a new restriction in the compiler). Also it will be more reproducible. Reproducible builds are not a requirement or even stated goal for AUR packages like they are for repository packages, but they are still a general purpose good. Your package is reproducible when you can build it and I can build it and we both come up with bit-for-bit the same binary results. Arch Linux has tooling for verifying built packages are reproducible or not that takes into account the version of dependencies being used. The data about which version of rust and cargo were used are logged in your package at the time you build it and can be used to recreate a test environment exactly like yours. If you allow packages to be built with rustup and unlocked dependencies they will not be reproducible. If you explicitly set the tooling to use the stable versioned packages at build time they will be. In almost all cases if you follow the Rust package guidelines in the wiki you'll get a reproducible package out of the deal.

Alright, thanks for the explanations! I'll adjust the concerned packages accordingly then.