Re: TU Application - Antiz

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




OpenPGP_0xD33FAA16B937F3B2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Caleb Maclennan]

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.

Re: TU Application - Antiz

[Leonidas Spyropoulos]

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_new_Trusted_Users 




Regards,

--
Leonidas Spyropoulos
PGP: 59E43E106B247368



OpenPGP_0x59E43E106B247368.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Leonidas Spyropoulos]

Hello,

On 03/01/2023 17: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.

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

https://aur.archlinux.org/tu/142


-- 
Leonidas Spyropoulos
PGP: 59E43E106B247368

Re: TU Application - Antiz

[Robin Candau]

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



OpenPGP_0xD33FAA16B937F3B2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Caleb Maclennan]

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.


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

Re: TU Application - Antiz

[Robin Candau]

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=M=Antiz==p=d=50=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



OpenPGP_0xD33FAA16B937F3B2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Jan Alexander Steffens (heftig)]

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=M=Antiz==p=d=50=Go


Hi Robin,

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?

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

Greetings,
Jan

Re: TU Application - Antiz

[Leonidas Spyropoulos]

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


OpenPGP_0x59E43E106B247368.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Levente Polyak]

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

Le 03/01/2023 à 21:29, Robin Candau a écrit :

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 
properly signed mail.


Regards,
Antiz (Robin C.)


Can confirm it produced a valid and working signatures :)

Thanks for trying to debug this :)

Cheers,
Levente


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Robin Candau]

Le 03/01/2023 à 21:29, Robin Candau a écrit :

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 
properly signed mail.


Regards,
Antiz (Robin C.)


OpenPGP_0xD33FAA16B937F3B2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Robin Candau]

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


OpenPGP_0xBE9EDC422FD6DD9B.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature

Re: TU Application - Antiz

[Levente Polyak]

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

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

On Tue, Jan 03, 2023 at 07:10:47PM +, Robin Candau wrote:

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

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


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[Robin Candau]

Le 03/01/2023 à 20:37, Morten Linderud a écrit :
> On Tue, Jan 03, 2023 at 07:10:47PM +, 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=nope=nope===
>
> 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.)

Re: TU Application - Antiz

[Morten Linderud]

On Tue, Jan 03, 2023 at 07:10:47PM +, 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=nope=nope===

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


signature.asc
Description: PGP signature

Re: TU Application - Antiz

[Robin Candau]

Le 03/01/2023 à 18:40, Morten Linderud a écrit :
> On Tue, Jan 03, 2023 at 11:03:07AM +, 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  and T.J. Townsend
>> .
> 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.

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

>> 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.
>> - 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/ab064974c931f49d84caa7d512178f4b2ec126db/CMakeLists.txt#L114
[2] https://unity.ruds.io/arch-unity/
[3] https://github.com/ProtonMail/proton-bridge/blob/master/COPYING_NOTES.md

Regards,
Antiz (Robin C.)




OpenPGP_0xBE9EDC422FD6DD9B.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP 

Re: TU Application - Antiz

[Morten Linderud]

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

Yo,

> My name's Robin Candau and I'd like to apply to become a Trusted User.
> My sponsors are Leonidas Spyropoulos  and T.J. Townsend
> .

Thanks for you application and good luck!

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

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

> 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?

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


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

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: TU Application - Antiz

[Leonidas Spyropoulos]

On 03/01/2023 18:14, T.J. Townsend wrote:
> Confirming my sponsorship too.

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.

-- 
Leonidas Spyropoulos
PGP: 59E43E106B247368


OpenPGP_0x59E43E106B247368.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: TU Application - Antiz

[T.J. Townsend]

> Hello,
> 
> My name's Robin Candau and I'd like to apply to become a Trusted User.
> My sponsors are Leonidas Spyropoulos  and T.J. Townsend
> .
> 
> I'm looking forward to contribute more to Arch Linux.
> Thanks for reading my application!

Confirming my sponsorship too.


signature.asc
Description: PGP signature

Re: TU Application - Antiz

[Leonidas Spyropoulos]

On 03/01/2023 13:03, Robin Candau wrote:
> Hello,
>
> My name's Robin Candau and I'd like to apply to become a Trusted User.
> My sponsors are Leonidas Spyropoulos  and T.J. Townsend
> .

I confirm my sponsorship.

Cheers,

-- 
Leonidas Spyropoulos
PGP: 59E43E106B247368


OpenPGP_0x59E43E106B247368.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

TU Application - Antiz

[Robin Candau]

Hello,

My name's Robin Candau and I'd like to apply to become a Trusted User.
My sponsors are Leonidas Spyropoulos  and T.J. Townsend
.

I'm 26 years old and I live in France. I'm working as a Linux system,
Infrastructure and DevOps engineer.
I've been using Linux for the last decade and been using Arch for a few
years now.

During my Arch journey, I started contributing to it in various ways:
- I subscribed to every "major" mailing lists and reply to users'
questions in it from time to time (mostly in the AUR-General one).
- I'm answering questions on the Arch subreddit (even though I'm aware
it is not an official Arch resource) and on the IRC channels from time
to time. I'm a bit less present on IRC though, but I'm still passing by
here and there.
- I contribute to some wiki pages.
- I maintain some packages on the AUR.
- I'm reviewing PKGBUILDs (both on aurweb and the AUR-General mailing list).
- I'm a member of the "Arch Testing Team" and I'm regularly testing and
signing off packages.
- I made rare contributions to the Arch DevOps Gitlab's issues (this is
something I'd like to do more in the future, I just haven't take the
time yet).

Since I started contributing to Arch, my interest for it kept growing
and I'd like to do more. This is why I'm applying to become a TU through
this mail.

For the minimum requirements:
- I'm fine with shell scripting.
- I maintain a few packages in the AUR with what I think are
high-quality/clean PKGBUILDs [1].
- I'm doing basic community involvement (as stated earlier).
- I can Google.
- Aside from Arch, I've been involved in a few open-source projects:
     - My own open-source projects are hosted on GitHub [2].
     - I'm a package and infrastructure maintainer for Crystal-Linux [3]
which is an Arch based distribution that promotes the use of current and
modern technologies and that brings an alternative to some widely used
software through its own tools such as "jade" (the Crystal Linux's
installer) or "amethyst" (the Crystal Linux's pacman wrapper and AUR
helper). I'm basically maintaining the Crystal's specific PKGBUILDs [4]
and helping them with infrastructure stuff.
     - 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].

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:
- protonmail-bridge
- distrobox
- unrar-free (which I currently maintain)
- ddgr (which I currently maintain)

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

Globally, my package interests are CLI tools and GTK apps, but I can
maintain anything else if needed. My primary goal is to help/contribute :)
Also, even though it has no direct link with the TU position, I'm
willing to take the time to bring some help and contributions to the
DevOps side of things in the future, as stated in the beginning of my
application.

I'm looking forward to contribute more to Arch Linux.
Thanks for reading my application!

[1]
https://aur.archlinux.org/packages?O=0=M=Antiz==p=d=50=Go
[2] https://github.com/Antiz96
[3] https://getcryst.al/site
[4] https://git.getcryst.al/crystal/pkgbuilds
[5] https://gitlab.com/users/Antiz96/activity

Regards,
Robin Candau - Antiz


OpenPGP_0xBE9EDC422FD6DD9B.asc
Description: application/pgp-keys


OpenPGP_signature
Description: PGP signature