TU Application - Antiz
Hello,
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>.
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&SeB=M&K=Antiz&outdated=&a... [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
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 <artafinde> and T.J. Townsend <blakkheim>.
I confirm my sponsorship.
Cheers,
Hello,
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>.
I'm looking forward to contribute more to Arch Linux. Thanks for reading my application!
Confirming my sponsorship too.
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.
On Tue, Jan 03, 2023 at 11:03:07AM +0000, 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 <artafinde> and T.J. Townsend <blakkheim>.
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.
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.
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.
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.)
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=&...
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.
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=&...
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.)
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 +0000, 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
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 +0000, 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.)
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.)
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
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.
On Tue, Jan 3, 2023 at 12:03 PM Robin Candau RobinCandau@protonmail.com 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=&a...
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
Le 16/01/2023 à 12:12, Jan Alexander Steffens (heftig) a écrit :
On Tue, Jan 3, 2023 at 12:03 PM Robin Candau RobinCandau@protonmail.com 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
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.)
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.)
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
Hello
On 18/01/2023 09:43, Leonidas Spyropoulos wrote:
Discussion period is over and the vote is live. Please cast your votes
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,
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.
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.
participants (8)
-
Caleb Maclennan
-
Jan Alexander Steffens (heftig)
-
Leonidas Spyropoulos
-
Levente Polyak
-
Morten Linderud
-
Robin Candau
-
Robin Candau
-
T.J. Townsend