On Sun, 16 Jul 2023 at 17:30 Fabio Loli wrote:

Il 16/07/23 14:37, Tomaz Canabrava ha scritto:

...

Hello,

My name is Tomaz Canabrava, Im a kde developer and mostly focus on Konsole. Other than that, I use arch Linux for the past 10 years, as my only Linux distro.

I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :)

My sponsors are Gian and Antonio Rojas.

This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email.

Best, Tomaz - kde ev member

Hello Tomaz

Which packages would you like to maintain on Arch?

The kde stack, together with Antonio.

Do you maintain any pkgbuild? On AUR I've seen you are listed as co-maintainer of sqlpp11 which need several fixes;

I used to work with the developer of sqlpp11, and I started to move things around, but I stopped using that library years ago. I can package the new version without problems. I do not actively maintain anything on arch, but since I’m kde upstream, I want to make kde a first class citizen on arch. also its dependecy

date-git need a couple of changes, just reported them in the comments

On Mon, 17 Jul 2023 at 10:25 Jonathan Steel wrote:

On Sun 16 Jul 2023 at 15:37, Tomaz Canabrava wrote:

...

I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :)

Why not show this by maintaining some air packages?

Mostly because there is nothing in aur that I use that lacks a maintainer. But I do have a software that is not packaged yet that I can port to aur.

...

This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email.

Why is it not signed?

Because I don’t have a gpg key, and when the dkim features on the email already are enough to validate that the email I send is from me.

I think you should read https://wiki.archlinux.org/title/Trusted_Users and re-submit a signed application showing the minimum requirements are met.

I have read the wiki and I have applied to a packager position following the wiki rules or explaining why I didn’t follow a part of it, i won’t re-apply because that’s a waste of everyone’s time just for the sake of ticking boxes. Summary: - [x] known on the opensource community with multiple, and used, programs - [x] packaging experience - [ ] aur / arch package experience - [x] contributes directly to upstream - [ ] signed the mail with gpg Best, Tomaz

-- Jonathan Steel

On Mon, 17 Jul 2023 at 11:18 Jonathan Steel wrote:

On Mon 17 Jul 2023 at 10:44, Tomaz Canabrava wrote:

...

Because I don’t have a gpg key, and when the dkim features on the email already are enough to validate that the email I send is from me.

You will need a GPG key to package. Arch has rules about applying and you are openly not following them.

I’ll create a gpg key when/if I need, to sign the packages, if arch Linux votes for me.

i won’t re-apply because that’s a waste of everyone’s time just for the sake

...

of ticking boxes.

I consider an application that does not meet the requirements and has had very little effort put in to be a waste of time.

That’s true, and I guess I already have your -1 on the votes. Great meeting you :) Besides not following rules, I help to maintain with patches upstream as a maintainer, co-maintainer or just a random person sending patches fixing bugs the following software set: - kde plasma - plasma firewall - dolphin - ark - kde system settings - Konsole - qgroundcontrol - konversation - kio - kde partition manager - subsurface - kde frameworks - codevis - kconfigxt But in the end it’s the maintainers role to see if someone from upstream would be useful for arch as a packager, or if he just wants to waste more time of a non-paid position for no glory just for the sake of helping a distro he uses daily. Best. --

Jonathan Steel

On Mon, Jul 17, 2023 at 12:50 PM Matthew Sexton wrote:

On 7/17/23 04:27, Tomaz Canabrava wrote:

...

On Mon, 17 Jul 2023 at 11:18 Jonathan Steel mailto:jsteel@archlinux.org> wrote:

On Mon 17 Jul 2023 at 10:44, Tomaz Canabrava wrote: > Because I don’t have a gpg key, and when the dkim features on the email > already are enough to validate that the email I send is from me.

You will need a GPG key to package. Arch has rules about applying and you are openly not following them.

I’ll create a gpg key when/if I need, to sign the packages, if arch Linux votes for me.

> i won’t re-apply because that’s a waste of everyone’s time just for the sake > of ticking boxes.

I consider an application that does not meet the requirements and has had very little effort put in to be a waste of time.

That’s true, and I guess I already have your -1 on the votes. Great meeting you :)

Besides not following rules, I help to maintain with patches upstream as a maintainer, co-maintainer or just a random person sending patches fixing bugs the following software set:

So which is it, (co/)maintainer or random person sending patches?

Both, but, let me clarify: - I am a KDE developer, you can check my credentials and my name is on the KDE ev Members list here: https://ev.kde.org/members/ I'm one of the most active developers on Konsole, and one of the core deelopers of Plasma Firewall. I also worked with Subsurface for many years porting the software from Gtk to Qt - and I'm one of the top 5 developers there. The other softwares in the list that *are not* from kde software I'm just a random person contributing on my spare time because I like it. I have never - on my 18 years of coding - worked with opensource because it was paid, and I contribute since my university days because I *sincerely* like it. I've

sent patches for Pacman and other Arch Projects but that does not make me an Archlinux Developer. (I mean, I can call myself whatever I want so I suppose it does but that is irrelevant.)

...

- kde plasma - plasma firewall - dolphin - ark - kde system settings - Konsole - qgroundcontrol - konversation - kio - kde partition manager - subsurface - kde frameworks - codevis - kconfigxt

But in the end it’s the maintainers role to see if someone from upstream would be useful for arch as a packager, or if he just wants to waste more time of a non-paid position for no glory just for the sake of helping a distro he uses daily.

I'll gladly waste time on a non-paid position for no glory for the sake of helping the distro I use daily. It's called "contributing".

That's what I do for more than 18 years. We know that written text lacks tone, so I'll clarify that thing too: "if we are too strict about following all the rules we will let go people that would be a good fit for the project, for the sake of folloing the process correctly", but processes also are a thing that should evolve.

https://wiki.archlinux.org/title/Getting_involved

I maintain AUR packages, troll #aot on IRC, report bugs and try to help track them down, use the testing repos and sign off on newly updated packages.. None of these things is difficult or overly time consuming and making yourself known by doing any one of them will have a significant positive impact on your application.

I fix bugs upstream, work on opensource on my day to day life and on my vacations I travel to teach programming to students with low income. We all work for the common goal, and while the list of things that are not time consuming, they will add and will be time consuming in the end.

...

Today I’ll create an aur component for Codevis, a software to visualize large architectures Im developing for the past three years (that just got opensourced)

And I’ll also create a GPG key, and sign some email on this thread with it.

I like seeing new stuff going into the AUR. I forgot to mention the handful of packages i found on github just to put in the AUR. For nothing more than funsies, but they're being used by people which is awesome. (And entirely the point.)

I guess my overall point is.. WHY do you want to be a Package Maintainer for Archlinux?

To improve the relationship between KDE & Archlinux, having more people that are on those two communities at the same time, to move things faster and help decrease the maintenance burden of a single person taking care of around ~400 pieces of software.

On Sun, Jul 16, 2023 at 03:37:31PM +0300, Tomaz Canabrava wrote:

Hello,

My name is Tomaz Canabrava, Im a kde developer and mostly focus on Konsole. Other than that, I use arch Linux for the past 10 years, as my only Linux distro.

I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :)

Hi Tomaz. When there are established, documented guidelines for how to do something in Arch Linux, they need to be followed. With no regard for how the application process works, with no Arch packaging experience at all, and with an attitude like this...

I’ll create a gpg key when/if I need, to sign the packages, if arch Linux votes for me.

...

I consider an application that does not meet the requirements and has had very little effort put in to be a waste of time.

That’s true, and I guess I already have your -1 on the votes. Great meeting you :)

...I'm not sure what kind of result you're expecting. You started off your application without any interest in doing things the way they're always done here, and then refused to fix that behavior when corrected. Consider it a -2 now. "Great meeting you :)"

Dear Tomaz and fellow community members, I wanted to take a moment to address the recent discussion on the mailing list regarding Tomaz's application as a package maintainer for our distro (First of all, thank you Tomaz for your interest). As I have followed the conversation closely, I believe it is important to approach this matter from a neutral standpoint that encourages constructive dialogue and reinforces the values we uphold as a community. First and foremost, I want to emphasize that we are a community of individuals with diverse perspectives and opinions. It is only natural that we encounter situations where different viewpoints arise. However, it is crucial that we maintain a respectful tone throughout our discussions, even when faced with conflicting ideas. Responding in a snarky and passive-aggressive manner does not contribute positively to our collective growth no matter who used such a language first. While it is exemplary to seek clarification and avoid blindly following procedures, it is equally important to recognize the value of our established processes. When applicants deviate from these procedures, it can lead to unnecessary conflicts and consume significant time and energy from our dedicated volunteers. Considering the cumulative effort required to dicuss a deliberate deviation from established processes on list, it is instead advisable to consult with the sponsors first to ensure a smoother experience for everyone involved. Regarding the PGP aspect of the application procedure, it is essential to understand that it serves a purpose beyond mere formality. Establishing cryptographic trust through this process enables streamlined authentication for various aspects, such as later on providing service usernames, SSH keys, and secure communication via encrypted emails to receive channel passwords etc. By adhering to this procedure from the outset, we overall simplify the verification process even if it could mean one applicant needs to create a key even when not getting accepted. Let us remember that we are more than just a group of technicians performing individual tasks. We are a social construct, united in our dedication to Arch Linux. As representatives of our distro, it is essential to lead by example, fostering an environment where respectful communication and cooperation thrives. While it is understandable to encounter language that may not align with our personal preferences, it is outmost important to respond with factual information in a friendly manner, trusting that others will recognize the overall tone of one's own message themselves. This does not mean your opinion should be witheld or that you should let everyone in you disagree with, but it means to always approach our discussions with an open mind and empathy. Let's all grab a cool beverage, breath some fresh air and get back to this discussion with a clear mind. Warm regards, Levente

I was expecting an e-mail such as the one sent by Carsten Haitzler, not the one sent by Mr. Steel. When we are too strict about rules - without stating the reasons behind those rules, we will drive good people away. Mr. Steel didn't bother to search about the things I did or who I was nor did he wanted anything to know about myself or why I wanted to join Archlinux, his e-mail was basically a box-ticking-procedure-checking. That's not just how people should behave within communities, as different people behave differently and it's way more important to have an human-factor when dealing with people.

Hi Tomaz, Let me start by saying I see your passion for it and understand your point of view. I believe this is my first time ever replying to this mailing list, by the way. I have read many threads of people discussing TU Applications. I felt the need to reply because I recently argued with someone about similar issues to this and did so starting from a similar point of view as you I believe, where I was against the seemingly corporate-like checklists/procedures. The person knew me and I felt insulted that they were making me go through with something that seemingly implied that I was lying. I have actually changed my point of view on this though after discussing it with coworkers several times. The real importance of following checklists/procedures like this, as I was convinced to realize, is that they force fairness and transparency. It prevents nepotism, or even possibly people being deceived and getting someone they thought was a friend online past the normal procedures, and having them turn out to be malicious. It is not accusing you or anyone of it, but it is to make things fair. I think that is important in a community like this. Treat people fairly. This way we don't have to try to guess who has malicious intent and treat them differently than someone else 1 person thought they knew. All community members, on a side note, although I haven't read much into it, I think it is great to see the role is now "package maintainer". I have said to myself after reading many of these applications and seeing the current TUs interview the person applying mostly about their technical ability, that all of these technical questions are not really confirming the part I worry more about with the AUR, and what is in the name of a "TU", _TRUST_. A person with malicious intent, could, and most likely would be, technically capable. They could easily pass that part of it with minimal effort. Very few of these applications seem to have a way to actually confirm that the person applying is TRUSTED. Now, I know everywhere it says the AUR is not to be trusted, and we must confirm all PKGBUILDs during build, but let's be real, with git packages and sources being pulled from many unheard of remote websites, that can be tough. I do review almost every PKGBUILD I use from the AUR, but I often wonder about the git url it is pulling from, and only sometimes do I go there and take a quick look at it. This can be a tough balance between confirming trust, and keeping people's privacy though. I am not sure though if more investigation is done behind closed doors to confirm those things but keep people's private information, well, private. Sorry to go off on a bit of a rant there on the side note. I hope my formatting was satisfactory for everyone (plain text and bottom-replying, right? haha.). I see there have also been a couple emails pop up since I typed this up. Sorry if this has now become repetitive, out of place, or further derailed the conversation on the actual application process. Kind regards, Dan

Excerpts from Giancarlo Razzolini's message of julho 17, 2023 9:18 am:

Excerpts from Tomaz Canabrava's message of julho 16, 2023 9:37 am:

...

Hello,

My name is Tomaz Canabrava, Im a kde developer and mostly focus on Konsole. Other than that, I use arch Linux for the past 10 years, as my only Linux distro.

I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :)

My sponsors are Gian and Antonio Rojas.

This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email.

Best, Tomaz - kde ev member

Hi All,

I have been trying to lure Tomaz to Arch for years now. I think he would be an awesome addition to our KDE packaging and overall general packaging too.

As for the lack of GPG signature, I'm working with him to get it signed. I'm hereby confirm my sponsorship, pending the GPG signed email.

Regards, Giancarlo Razzolini

Also, one important thing to mention: Tomaz would be our first junior maintainer. While he doesn't have any package on the AUR, he's more than capable of building and maintaining software. So we would review and work with them in the beginning. Regards, Giancarlo Razzolini

So, I downloaded thunderbird (after years using gmail as my only mail client), setup my new gpg key on thunderbird, and hope that this message is digitally signed. I'm much better with bash than I am fiddling with weird programs to send e-mail :) Best, Tomaz On 7/17/23 19:32, Antonio Rojas wrote:

El domingo, 16 de julio de 2023 14:37:31 (CEST) Tomaz Canabrava escribió:

...

My sponsors are Gian and Antonio Rojas.

This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email.

Best, Tomaz - kde ev member I confirm my sponsorship (modulo complying with the application process requirements), I've known about Tomaz for a long time as a KDE developer. There's a lot of work ahead for KDE packaging with the upcoming Qt 6 port and it would be great to have more hands to help Felix and me with it.

On Monday 17 July 2023 21:01:28 CEST Giancarlo Razzolini wrote:

Thank you Tomaz for the signed email. Now that both sponsors have replied and we have a signed email, we can officially start the discussion period.

Hello Tomaz, First of all, I'm not a TU/developer, so I can't vote, but good luck! ;) I just wanted to say that, as a KDE user, I'm very happy to see Antonio and Felix trying to recruit some extra hands for KDE packaging. Since I switched from Chakra Linux to Arch Linux (wow, it's been a while!), I've had an extremely good experience with KDE on Arch Linux. So, if you are accepted, I hope you will maintain the high-quality standards that Antonio and Felix have set. Here I leave two questions for you, but remember I have no vote, so feel free to skip them.

So, I downloaded thunderbird (after years using gmail as my only mail client), setup my new gpg key on thunderbird, and hope that this message is digitally signed.

1. Why Thunderbird and not KMail?! :O 2. Last week, someone asked [1] if Plasma 6 would be available in [kde- unstable]. Would you be willing to package something similar to what KDE Neon is doing in their unstable releases before KDE releases a Plasma 6 Beta? Thanks for all your contributions to KDE, and good luck with this process. Iyán [1]: https://lists.archlinux.org/archives/list/arch-general@lists.archlinux.org/t... -- Iyán Méndez Veiga GPG 0x422E3694311E5AC1

Excerpts from Giancarlo Razzolini's message of julho 24, 2023 1:38 pm:

Hi All,

We're halfway through the discussion period and there were no discussion whatsoever on the actual application.

Another important thing to mention is, I have discussed with Levente how the voting will work, and given we don't have things established yet, I think we will need to use aurweb itself for the voting procedure, but given it's for a maintainer role, all maintainers should vote, not just former TU's. This would entail giving voting rights to non TU devs on the aurweb (like myself).

After a brief discussion on IRC, we have determined a new RFC will be required to further consolidate the package maintainer role, so all maintainers can vote. The vote for Tomaz package maintainer application will proceed as a regular TU voting used to happen. Regards, Giancarlo Razzolini

Le 17/07/2023 à 20:58, Tomaz Canabrava a écrit :

So, I downloaded thunderbird (after years using gmail as my only mail client), setup my new gpg key on thunderbird, and hope that this message is digitally signed.

I'm much better with bash than I am fiddling with weird programs to send e-mail :)

Best,

Tomaz

Hi Tomaz, Thanks for your application as a package maintainer! Forced to admit that the lack of Arch packaging experience makes it a bit hard to evaluate on that front but, as you said in your original message, I have no doubt you'll be able to handle that. I noticed that you recently created two AUR packages [1][2] though, thanks for taking the time to do so! If you allow me, I have a few feedback about those: --bde-tools-- - Since you're using git sources, your PKGBUILD misses the `git` make dependency. - You don't need to rename the source "bde-tools" as the cloned repo is already named that way. - Speaking of sources, any reason why you `git clone` the repo against a specific tag instead of using a tag's archive? [3] Using a tag's archive would allow you to check the integrity of the downloaded sources (rather than skipping it). If you do so, I suggest using a stronger hash algorithm than md5. Using `sha256` or stronger is the standard now. You could also drop the `git` make dependency. - No need to `rm -rf ".git". As it is a hidden folder, it won't be copied by the `cp -r *` later in the PKGBUILD. - Don't forget to bump the `pkgrel` [4] when you modify the PKGBUILD in between a `pkgver` bump [5]. --bde-- - The correct variable name for make dependencies is "makedepends", not "makedeps". In it's current state, the necessary make dependencies will be ignored. - Since you're using git sources, your PKGBUILD misses the `git` make dependency. - The `make` and `gcc` packages are both members of the `base-devel` metapackage [6], so they shouldn't be listed as make dependencies because the `base-devel` metapackage is assumed installed at buildtime. See the related "Note" paragraph in the PKGBUILD's Arch wiki page [7]. - Any reason why you `git clone` the repo against a specific tag instead of using a tag's archive? [8] (Same question as the package above). - You don't have to `cd` to `${srcdir}` at the beginning of the `build()` and `package()` functions. Every functions are executed within that folder already. - The package doesn't build on my side (built in a clean chroot via `pkgctl build -I ../bde-tools/bde-tools-3.117.0.0-1-any.pkg.tar.zst --repo extra`). See the build logs [9]. I would suggest to build your packages in a clean chroot [10] to test your PKGBUILDs before pushing them and prevent any common issues or missing dependencies. For what it's worth, building packages in a clean chroot is mandatory for Arch official repositories packages [11]. On another subject, I guess your involvement in open-source projects isn't questionable regarding your work in KDE. It's nice to see an "upstream" person applying to help the "downstream" side of things and that would be an undeniable plus for the KDE stack on Arch side. Mostly out of curiosity from my side, have you contributed to any other project in any way (Arch included)? Once again, thanks for applying and good luck for the rest of your application! [1] https://aur.archlinux.org/packages/bde-tools [2] https://aur.archlinux.org/packages/bde [3] https://github.com/bloomberg/bde-tools/archive/refs/tags/3.117.0.0.tar.gz [4] https://wiki.archlinux.org/title/PKGBUILD#pkgrel [5] https://aur.archlinux.org/cgit/aur.git/commit/?h=bde-tools&id=00e94574151da931419c44a1dce212f9e3342dbe [6] https://archlinux.org/packages/core/any/base-devel/ [7] https://wiki.archlinux.org/title/PKGBUILD#makedepends [8] https://github.com/bloomberg/bde-tools/archive/refs/tags/3.117.0.0.tar.gz [9] https://bpa.st/LEUQ [10] https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot [11] https://wiki.archlinux.org/title/DeveloperWiki:How_to_be_a_packager#Change_a... -- Regards, Robin Candau / Antiz

Excerpts from Tomaz Canabrava's message of julho 31, 2023 4:04 pm:

Hello Robin,

Thanks for having the time to review my pkgbuilds.

On Mon, 31 Jul 2023 at 19:27 Robin Candau wrote:

...

Le 17/07/2023 à 20:58, Tomaz Canabrava a écrit :

...

So, I downloaded thunderbird (after years using gmail as my only mail client), setup my new gpg key on thunderbird, and hope that this message is digitally signed.

I'm much better with bash than I am fiddling with weird programs to send e-mail :)

Best,

Tomaz

Hi Tomaz,

Thanks for your application as a package maintainer! Forced to admit that the lack of Arch packaging experience makes it a bit hard to evaluate on that front but, as you said in your original message, I have no doubt you'll be able to handle that.

I noticed that you recently created two AUR packages [1][2] though, thanks for taking the time to do so! If you allow me, I have a few feedback about those:

--bde-tools-- - Since you're using git sources, your PKGBUILD misses the `git` make dependency. - You don't need to rename the source "bde-tools" as the cloned repo is already named that way. - Speaking of sources, any reason why you `git clone` the repo against a specific tag instead of using a tag's archive? [3] Using a tag's archive would allow you to check the integrity of the downloaded sources (rather than skipping it). If you do so, I suggest using a stronger hash algorithm than md5. Using `sha256` or stronger is the standard now. You could also drop the `git` make dependency. - No need to `rm -rf ".git". As it is a hidden folder, it won't be copied by the `cp -r *` later in the PKGBUILD. - Don't forget to bump the `pkgrel` [4] when you modify the PKGBUILD in between a `pkgver` bump [5].

--bde-- - The correct variable name for make dependencies is "makedepends", not "makedeps". In it's current state, the necessary make dependencies will be ignored. - Since you're using git sources, your PKGBUILD misses the `git` make dependency. - The `make` and `gcc` packages are both members of the `base-devel` metapackage [6], so they shouldn't be listed as make dependencies because the `base-devel` metapackage is assumed installed at buildtime. See the related "Note" paragraph in the PKGBUILD's Arch wiki page [7]. - Any reason why you `git clone` the repo against a specific tag instead of using a tag's archive? [8] (Same question as the package above). - You don't have to `cd` to `${srcdir}` at the beginning of the `build()` and `package()` functions. Every functions are executed within that folder already. - The package doesn't build on my side (built in a clean chroot via `pkgctl build -I ../bde-tools/bde-tools-3.117.0.0-1-any.pkg.tar.zst --repo extra`). See the build logs [9].

Thanks for all of those hints, really appreciated.

...

I would suggest to build your packages in a clean chroot [10] to test your PKGBUILDs before pushing them and prevent any common issues or missing dependencies.

Will do.

...

For what it's worth, building packages in a clean chroot is mandatory for Arch official repositories packages [11].

Will do.

...

On another subject, I guess your involvement in open-source projects isn't questionable regarding your work in KDE. It's nice to see an "upstream" person applying to help the "downstream" side of things and that would be an undeniable plus for the KDE stack on Arch side.

Mostly out of curiosity from my side, have you contributed to any other project in any way (Arch included)?

Quite a few, besides my involvement with kde I also have:

Imaintained subsurface for almost 5 years (www.subsurface-develop.org)

Codevis - an application to visualize architectures of large codebases ( https://gitlab.com/CodethinkLabs/codevis/codevis)

Worked with drone control stations (www.qgroundcontrol.org)

And quite a few more libraries and smaller softwares, that are not on the kde stack.

Best, Tomaz

...

Once again, thanks for applying and good luck for the rest of your application!

[1] https://aur.archlinux.org/packages/bde-tools [2] https://aur.archlinux.org/packages/bde [3] https://github.com/bloomberg/bde-tools/archive/refs/tags/3.117.0.0.tar.gz [4] https://wiki.archlinux.org/title/PKGBUILD#pkgrel [5]

https://aur.archlinux.org/cgit/aur.git/commit/?h=bde-tools&id=00e94574151da931419c44a1dce212f9e3342dbe [6] https://archlinux.org/packages/core/any/base-devel/ [7] https://wiki.archlinux.org/title/PKGBUILD#makedepends [8] https://github.com/bloomberg/bde-tools/archive/refs/tags/3.117.0.0.tar.gz [9] https://bpa.st/LEUQ [10] https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot [11]

https://wiki.archlinux.org/title/DeveloperWiki:How_to_be_a_packager#Change_a...

-- Regards, Robin Candau / Antiz

Hi All, Given that this application was a different one (we're trying to get our first junior packager in), and also that the discussion was a little weird, I've waited one extra week before starting the voting. I'll create a voting on the AUR later today (provided I have rights to). Thank you everyone that chimed into this discussion, and thank you Tomaz, regardless of the outcome. I wish you luck! Regards, Giancarlo Razzolini

On Mon, Jul 31, 2023 at 7:28 PM Robin Candau wrote:

- Speaking of sources, any reason why you `git clone` the repo against a specific tag instead of using a tag's archive? [3] Using a tag's archive would allow you to check the integrity of the downloaded sources (rather than skipping it). If you do so, I suggest using a stronger hash algorithm than md5. Using `sha256` or stronger is the standard now. You could also drop the `git` make dependency.

The autogenerated archives aren't guaranteed to be stable. I would not use them at all. See: https://github.blog/2023-02-21-update-on-the-future-stability-of-source-code... I also dislike using refs, as they can be overwritten. I would recommend pinning to a specific commit.

Le 08/08/2023 à 14:30, Polarian a écrit :

Hello,

Just a small note about this, a large number of AUR packages pull tarballs from github (or other git platforms), including all of the source packages I maintain. [...]

A large number of packages from the official repo pull tarballs from GitHub as well. Heftig and I just gave our personal thought and recommendations about this but, as you said, there's no mention of this in the wiki because pointing sources to a specific {tag, tarball, commit} is currently a matter of personal preference. As far as I know, there's no defined standard regarding this on Arch side as of now. Each method have their pros and cons. As long as you're aware of them, you can use the method you like. So don't worry, you can still pull tarballs from GitHub in your packages :) If this is subject to change and if a standard is ever declared, I assume a proper discussion/announcement would be made. -- Regards, Robin Candau / Antiz