On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote:

2019. 8. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general

ezt írta:

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them.

-- György Balló Trusted User

Well, you can always ask upstream. So far, we received exceptions for redistribution of more software than we got rejections for, I think.

On Fri, 16 Aug 2019 at 22:35, Oscar spacepluk@gmail.com wrote:

I'm currently maintaining unity-editor and unityhub and I don't think they will allow redistribution of binaries.

They even dropped the official Ubuntu packages in favor of their custom installers. And honestly it makes more sense to do it this way because the engine is a big self contained blob and users usually need to have several different versions installed at the same time to patch old projects etc.

On Fri, Aug 16, 2019, 22:20 Sven-Hendrik Haase via aur-general < aur-general@archlinux.org> wrote:

...

On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote:

...

2019. 8. 16, péntek keltezéssel 15.19-kor Jean Lucas via aur-general

ezt írta:

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them.

-- György Balló Trusted User

Well, you can always ask upstream. So far, we received exceptions for redistribution of more software than we got rejections for, I think.

...

Never hurts to ask. :)

Asking should also be done in the case of all the packages Jean mentioned.

On 2019-08-16 17:10:41 (-0400), Jean Lucas via aur-general wrote:

I would definitely be willing to very politely ask the five respective companies for redistribution permissions for Arch Linux.

In the case of reaper, I've already been in contact with Cockos to try and move that to [community] and they didn't reply to multiple requests through several channels. On its own, I have not been able to make sense out of the OEM distribution license [1] for that matter either. "... but I'm not a lawyer (TM)."

Best, David

[1] https://www.reaper.fm/dist-agreement.php

On August 16, 2019 10:05:54 PM GMT+02:00, "Balló György via aur-general" aur-general@archlinux.org wrote:

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them

Even if we could, is there a reason to flood arch repositories with these proprietary programs? In my opinion proprietary programs should be an exception, not the norm.

Josef Miegl

On Sat, 2019-08-17 at 02:00 +0200, Sven-Hendrik Haase via aur-general wrote:

On Sat, 17 Aug 2019 at 01:35, Josef Miegl josef@miegl.cz wrote:

...

On August 16, 2019 10:05:54 PM GMT+02:00, "Balló György via aur- general" < aur-general@archlinux.org> wrote:

...

anydesk, reaper, spotify, teamviewer, unity-editor and unityhub are proprietary software with restrictive license. I don't think that you can legally distribute them

Even if we could, is there a reason to flood arch repositories with these proprietary programs? In my opinion proprietary programs should be an exception, not the norm.

Josef Miegl

Whether they are proprietary or not has never been a large concern for Arch. What concerns us is whether they are useful or not and whether they'd actually be used by any amount of people. Arch is all about pragmatism.

Sometimes, binary blobs are inconvenient for us because if they break we can't fix them. However, that's an entirely separate can of worms which I don't want to open in this thread.

Bottom line: If it's legal to package and it's useful and popular software, there's really no reason not to package it.

This is the way I see it as well. Libre or open-source solutions can come along anytime to replace their proprietary counterparts, if someone or a group has enough will to do so; but until then, having the best tool available for the job, even if it is proprietary, seems like a decent idea to me.

On Fri, 2019-08-16 at 22:45 +0200, Levente Polyak via aur-general wrote:

On August 16, 2019 9:19:56 PM GMT+02:00, Jean Lucas via aur-general < aur-general@archlinux.org> wrote:

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

... , downgrade,...

It's never been official in the past as that's per definition partial upgrade when using anything but the version from the repo. We do not support partial upgrades and we should not officially provide an application whose very purpose is to deviate from the current repo state to any arbitrary version in the past.

Understood. Scratch downgrade.

On Fri, 2019-08-16 at 17:47 -0400, Eli Schwartz via aur-general wrote:

On 8/16/19 3:19 PM, Jean Lucas via aur-general wrote:

...

Hi all,

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

I've been an Arch Linux user since around a little before I registered my AUR account (January 2015, username "flacks" [1]), and I've recently had a few of my packages adopted into [community], namely "cage", "coturn", and "swaybg".

I'm currently a computer science student with a particular interest in software engineering ranging from low-level (with a few contributions to projects like coreboot and postmarketOS) all the way up to web development (my current focus), and as such, would love to help maintain Arch's [community] repo in an official capacity to be part of the team that gives Arch users a robust, high-quality Linux software experience; as well as to help maintain, manage, and watch over the operation of the AUR and it's vast sea of software packaging recipes.

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

In the case of Spotify specifically, the AUR maintainer is already a TU, and had you asked him before being eager to move it to community he'd have probably told you that you're not the first or even the second (or third? I lose track) person to propose moving it. I think someone may have also suggested it in a TU application before...

Understood. My apologies for not having researched this well enough beforehand.

Either way you should definitely ask the maintainer if it is okay to move it to community. If that maintainer is a TU, and they haven't moved it to community on their own, there is probably a reason.

Understood. My intention was to open a dialogue with the maintainer of any owned package before taking any action.

downgrade:

I'm quite hesitant to have "downgrade" in the repos, it seems to be an immense antipattern -- not quite as bad as an AUR helper in[community], but nearly. Also isn't even well written as it does a ton of parsing HTML files and pacman.conf in sed, instead of using either pacman- conf or an HTML parser. I really wish that people who wrote complex integrations around pacman/makepkg would follow pacman development -- in fact, many of the current crop of AUR helpers do exactly that, which is why I would even dare use some of them.

If we *were* going to add a program to pander to the desire to have partially updated systems, I would prefer to create a new tool from scratch.

Also "downgrade" indexing archive.archlinux.org (with sed or anything else) is problematic due to the fact that we no longer store many versions of packages but upload them to archive.org and delete them from our own server (and use rewrite rules to let users download the files, but that doesn't help to build an HTML index). So I'm decidedly unsure how useful it's supposed to be even at fulfilling its desired goal.

Understood. downgrade can be scratched until a better solution everyone agrees with comes along.

...

Additionally, I would express my willingness to help co-maintain "firejail" (already in [community]), as its a project I have a higher interest in and contribute to occasionally; as well as to help get "ghidra" in good enough shape to propose moving it into [community], since I've had lots of fun building it [2], its a phenomenal piece of open-source software, and it'd be nice to have it officially supported by the Arch community (it also has a nice number of votes in the AUR)!

Thank you for your time, and thank you to all who help make Arch a great OS!

Best regards,

Jean Lucas

[1] https://aur.archlinux.org/account/flacks [2] https://aur.archlinux.org/cgit/aur.git/log/?h=ghidra-git

Hi Robin,

On Sat, 2019-08-17 at 10:13 +0200, Robin Broda via aur-general wrote:

On 8/16/19 9:19 PM, Jean Lucas via aur-general wrote:

...

Hi all,

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

How many TUs did you ask for sponsorship, and how many declined? For the record, flacks has approached me a few weeks ago and asked for sponsorship. I had reviewed his PKGBUILDs and suggested many fixes at the time, and also explained that I do not think it is time yet to move forward with a TU application. I offered reviewing his future things, and helping with general mentoring, however it seems like my offer was not taken - instead you just found someone else to sponsor you without batting an eye... Off to a great start.

In totality, I asked 4 TUs - Alexander, Sergej, Alad, and you. Alexander reached out to me about taking over my "swaybg" package, so after a few chat sessions, he agreed to sponsor me. Sergej had taken over my "coturn" package, so I reached out to him to review my profile, and he also agreed to sponsor me. I reached out to Alad sometime in between, but he never responded to my profile review request; and after chatting with you and going over the various things you wanted me to look into w.r.t. my packages, after a follow-up, you declined sponsorship for the moment.

In your follow-up with me about a month and a half ago, I was happy you let me know that you'd be checking up on my packages every now and then to see whether their quality would improve without your intervention, and that if I had any questions I could ask you. I know I could've reached out to you more directly, but I did my best to get my packages up to snuff - I'd been using your PKGBUILD review service, as you know, for all my packages; over our first chats, you helped me resolve a few of my doubts and mistakes; I reviewed a lot of documentation on the wiki; I rebuilt everything making full use of clean chroots and namcap; and I got help in the IRC/Matrix channels every so often. In fact, I tried reaching out to you over IRC last Sunday, but alas, I probably should have done so over email instead.

That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye - asking Alexander and Sergej seemed appropriate as they'd both adopted one of my packages, I had worked with you to resolve some of my issues, I've gone over all of my packages with a fine-toothed comb many times now, and got more help as needed. I didn't suppose that having you decline sponsorship should deter me from eventually applying until getting your approval. I regret that we didn't have better communication, though.

...

If I were accepted to become a TU, I'd like to adopt and move the following packages (all having over 10 votes in the AUR) from the AUR into [community]:

anydesk, downgrade, exercism, flutter, godot, itch, mattermost- desktop, nvm, reaper, spotify, teamviewer, thermald, unity-editor, and unityhub, for starters!

As explained by others, most of these cannot be moved. Have you talked to your sponsors about this? What have they said about this?

I did not discuss the moving of those packages with my sponsors. I was hoping to get the community's feedback on the ideas.

...

Best regards,

Jean Lucas

[1] https://aur.archlinux.org/account/flacks [2] https://aur.archlinux.org/cgit/aur.git/log/?h=ghidra-git

xyproto, sergej - have you reviewed this application before? Given that there hasn't been an ACK from any of you guys after the application was posted, i doubt it...

They did not review my application. I composed it all myself, for which I take full responsibility. I had worked on their willingness to sponsor me and sent what I considered to be a fair application ready for community feedback.

Best regards, Jean

On Sat, 2019-08-17 at 21:58 +0200, Robin Broda wrote:

On 8/17/19 8:49 PM, Jean Lucas wrote:

...

Hi Robin,

On Sat, 2019-08-17 at 10:13 +0200, Robin Broda via aur-general wrote:

...

On 8/16/19 9:19 PM, Jean Lucas via aur-general wrote:

...

My name is Jean Lucas, and I'm sending this email to submit my candidacy for Trusted User member. As per the latest TU bylaws, I'm being sponsored by both Alexander Rødseth and Sergej Pupykin.

How many TUs did you ask for sponsorship, and how many declined?

In totality, I asked 4 TUs - Alexander, Sergej, Alad, and you.

Why did you not make this clear in your application?

Since there is no formal guideline for writing an application AFAICT, I thought it sufficient to include the names of those who agreed to sponsor me.

I'm sure you've read the wiki article on Trusted Users[1] -

...

*Note*: Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.

Have you at least told xyproto & sergej that you have approached alad and me, and the reason for me declining sponsorship?

I have not. I contacted Alexander before you something like 2 months ago, and your formal refusal for sponsorship came in about 2 weeks later. Admittedly, I forgot to mention that you'd declined my sponsorship to both of them.

...

after a follow-up, you declined sponsorship for the moment.

Indeed, I did however offer to review any new things.

You offered to answer any questions I had, and that you'd be checking up on my packages every now and then to see whether the quality improved without your intervention. You had already pointed out most of the errors I had in my packages when we first chatted, so I opted for mostly researching everything else on my own, reaching out to the IRC/Matrix channels for a few missing bits every so often.

...

I tried reaching out to you over IRC last Sunday, but alas, I probably should have done so over email instead.

This is the last i received from you, FWIW

I guess Matrix interaction with IRC is still a little wonky, then. :(

...

0507201 9:00:00 <flacks> thank you for your feedback! all good points That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye - asking Alexander and Sergej seemed appropriate as they'd both adopted one of my packages, I had worked with you to resolve some of my issues, I've gone over all of my packages with a fine-toothed comb many times now, and got more help as needed. I didn't suppose that having you decline sponsorship should deter me from eventually applying until getting your approval. I regret that we didn't have better communication, though.

I don't think that's how it's supposed to work.

Can you please elaborate?

...

...

As explained by others, most of these cannot be moved. Have you talked to your sponsors about this? What have they said about this?

I did not discuss the moving of those packages with my sponsors. I was hoping to get the community's feedback on the ideas.

But they're the perfect people to talk to about this!

You're right. Our communication has been a bit sparse, though, so it didn't occur to me to run the package choices by them beforehand.

...

...

xyproto, sergej - have you reviewed this application before?

They did not review my application. I composed it all myself, for which I take full responsibility. I had worked on their willingness to sponsor me and sent what I considered to be a fair application ready for community feedback.

Welp, we cannot really move forward with this unless your sponsors are willing to sign off on your application, anyways.

All in all I'm fairly disappointed in how rushed you are with this. You went through 4 people, and at least one has brought up concerns, the others likely being unaware...

My apologies for the disappointment. I thought I'd give an application a shot sooner rather than later despite your refusal to sponsor me, since I thought I was generally doing good in terms of package management, after having taken your and Alexander's feedback into account, as well as doing more research on my own to produce more high- quality packages.

[1] https://wiki.archlinux.org/index.php/Trusted_Users

On Sat, 2019-08-17 at 23:46 -0400, Eli Schwartz via aur-general wrote:

On 8/17/19 2:49 PM, Jean Lucas via aur-general wrote:

...

That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye - asking Alexander and Sergej seemed appropriate as they'd both adopted one of my packages, I had worked with you to resolve some of my issues, I've gone over all of my packages with a fine-toothed comb many times now, and got more help as needed. I didn't suppose that having you decline sponsorship should deter me from eventually applying until getting your approval. I regret that we didn't have better communication, though.

I don't see anyone implying you aren't allowed to apply until the person who declined to sponsor you says it is okay.

All that anyone is saying is that you're supposed to provide fair disclosure of the fact that it happened.

I agree.

On 8/17/19 6:59 PM, Jean Lucas via aur-general wrote:

...

On Sat, 2019-08-17 at 21:58 +0200, Robin Broda wrote:

...

On 8/17/19 8:49 PM, Jean Lucas wrote:

...

In totality, I asked 4 TUs - Alexander, Sergej, Alad, and you.

Why did you not make this clear in your application?

Since there is no formal guideline for writing an application AFAICT, I thought it sufficient to include the names of those who agreed to sponsor me.

...

I'm sure you've read the wiki article on Trusted Users[1] -

...

*Note*: Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU.

Have you at least told xyproto & sergej that you have approached alad and me, and the reason for me declining sponsorship?

I have not. I contacted Alexander before you something like 2 months ago, and your formal refusal for sponsorship came in about 2 weeks later. Admittedly, I forgot to mention that you'd declined my sponsorship to both of them.

Hmm, did you contact him about sponsorship, specifically? You say that he offered to sponsor you "after a few chat sessions", and that your first contact with him (about him adopting your package) was before your first contact with Robin. If you only contacted him about sponsorship after Robin declined, I'm not even sure why it is relevant if you contacted Alexander about unrelated things. If you were in discussion with Alexander about sponsorship before you asked Robin, I could at least understand how such forgetfulness happened.

Alexander and I initially talked over IRC about my package he wanted to adopt. About a day later, I pinged him on IRC about the TU role, shortly (about a half-day or another day later) after which I solicited a review of my profile for sponsoring. I think it was either that same day or one or two days later that I poked Alad and Robin on IRC about the same, one after the other, soliciting review of my profile for sponsorship. As mentioned, Alad never saw my solicitation, so the conversations only proceeded with Alexander and Robin.

About two weeks after the IRC chats, after having previously sent a follow-up email to both Alexander and Robin requesting an update on their willingness to sponsor me, I emailed Sergej asking if he would review my profile for purposes of sponsorship, after which a whole 30 minutes passed, and Robin's formal refusal for sponsorship landed in my inbox.

On 8/17/19 8:46 PM, Jean Lucas via aur-general wrote:

...

For the record, it says "Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU." - that should be reworded to something similar to what you said instead, given the recent amendment to the TU bylaws of needing two sponsors instead of one.

Either way, I had forgotten about that part, so I failed to bring it up with the TUs I was in contact with. My apologies. In hindsight, it would've been a pragmatic idea.

I... really don't see what is confusing or ambiguous about the wiki?

The wiki says "[...] the first step is to find a TU who agrees to sponsor you. Once sponsored, you should write a witty application [...]", as well as "Should *the TU* you contact [...]", all still indicative of a one-TU requirement.

My reading of the wiki does not say that you must acknowledge it to the whole world on this mailing list (it may or may not be a good idea to do so) but you sure had better acknowledge this to the TUs who you later approach for sponsorship. At least in that much, the wiki is very, very clear.

I agree. My point is that needing to mention any previous sponsors I contacted to other TUs - we can assume this means regardless of whether or not they accepted or declined sponsorship - is not what is said on the wiki, is all.

I think it's more than pragmatic. It's required. It's a matter of trust: you want the community to trust you and put you in a position where a great many Arch users trust you by default, and part of that is that if someone had objections in the past to your being on the team, then you should at least let your sponsors know the position you are in, which you are asking them to stake their reputation on. They will want to have the opportunity to evaluate and hopefully decide that those reasons no longer apply (or they disagree with the other prospective sponsor's reasoning, which is also okay, because we are allowed to have differences of opinion).

Frankly, even if it wasn't an official rule of the application process, I would still consider it to be common courtesy.

No contest there.

In hindsight, I think that I indeed should've mentioned to the 3 TUs that I was in contact with all of them. As for mentioning that I attempted to reach out to Alad to no avail, I suppose I could've as well. I was caught between the uncertainties of sponsorship from Alexander and Robin, so I opted to not mention the other to both of them or to Sergej. Their formal answers came a lot later, and it did not occur to me then to notify Alexander and Sergej of Robin's decline for sponsorship after the fact. I now do see that I should've.

On Sun, 2019-08-18 at 02:12 +0200, Alad Wenter via aur-general wrote:

...

I reached out to Alad sometime in between, but he never responded to my profile review request;

While I don't claim to be the most apt in responding to emails, I see no Jean Lucas orjean@4ray.co in my mailbox. I guess that's why I did not respond then.

I contacted Alexander, you and Robin over IRC, you must've just not seen my message. I don't blame you, though - IRC isn't exactly the best place to leave messages for others if they're AFK, unless the recipient is an avid IRC user, IMO.

...

That said, I think its a bit unfair to say that I went off and found another sponsor without batting an eye

That doesn't really matter - the admission guidelines [1] cleary say that you should mention any previous sponsors you've contacted.

]1] https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU ?

For the record, it says "Should the TU you contact decline to sponsor your application, you should make this fact known if you seek sponsorship from another TU." - that should be reworded to something similar to what you said instead, given the recent amendment to the TU bylaws of needing two sponsors instead of one.

Either way, I had forgotten about that part, so I failed to bring it up with the TUs I was in contact with. My apologies. In hindsight, it would've been a pragmatic idea.

On 8/17/19 10:51 PM, Santiago Torres-Arias via aur-general wrote:

On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:

...

Hi all,

Thank you for your time, and thank you to all who help make Arch a great OS!

Always happy to help! :)

It's customary to review PKGBUILDS for new applicants. This is somewhat of a quick/cursory review over 3 random packages as I've been in conferences for the whole week.

I haven't looked at Jean's packages myself, but I'm not sure some of these things you point to are actually problems.

== Overall ==

• It appears you need quote strings way more everywhere, from deps, to licenses to variables....

Quote strings are only necessary for variable expansions which could potentially undergo word splitting. For declaring an array (deps, licenses) it's completely unnecessary as you know when writing the PKGBUILD if there are spaces (and most makepkg fields don't permit spaces anyway).

Admittedly I think single-quoting array keys looks prettier. That's a personal opinion though.

• Consider that base-devel is assumed to exist for makedepends and (iirc).

This is not great if it is in makedepends, but honestly we still haven't fully fixed the official repos for this.

== Beaker ==

• This depends array has to be wrong
• This makedepends array too. you should make sure things aren't depending on py2 anymore

What's necessarily wrong with this? I don't like py2 either, but just because something uses it doesn't mean it has no reason to. What specifically made you think it isn't needed?

What is wrong with the dependencies that it "must" be wrong? From a cursory inspection it seems to be some sort of electron thingy, which would hopefully use community/electron but life isn't perfect.

Depending on glibc and gcc-libs is a bikeshed topic that TUs/Devs don't agree on. The rest of the dependencies could plausibly be linked to by whichever version of prebuilt electron is being downloaded by the build system.

• I'm also a little confused, did you take over the namespace of another project called beaker? Why not just call this beaker browser?

== Oxy ==

• I think you should document why you're cherry-picking that commit rather than using a tag. Admittedly this is probably upstream's fault, but still, better to be clear.

Upstream is amazing and doesn't use git tag. The cherry-picked commit has the commit message "Call it a version". This is obvious enough causes that I don't actually feel bad about the lack of comments. :)

• Again, I think your depends are either too verbose or wrong.

There's exactly one depends, which is gcc-libs. Again, a bikeshed topic. I will loudly proclaim my own belief in not depending on gcc-libs or anything else in *base*, but I won't tell anyone they are *wrong* for doing so themselves.

(Obviously makedepends on base-devel is still against the packaging guidelines.)

== stf ==

• This appears to me it's a -bin package

Why? It looks like some sort of standard js-based source package on the NPM registry.

• npm -i -g --prefix seems like a good way to overwrite a bunch of system files and/or cause a bunch of file conflicts

npm install -g --prefix="$pkgdir" is actually how you are supposed to install npm stuff -- it "globally" installs it to the packaging directory so that pacman will install it to /usr, so it should never conflict with anything. This seems fine to me.

(I have personal issues with npm as a technology, and prefer to npm install into $srcdir then use cp because it feels at least mildly cleaner -- see my rapydscript-ng package -- but stf doesn't seem any less valid and some official packages do the same thing he does).

• I think you can use $pkgname more often, namely when resolving the url and resolving the tgz file

I've seen it both ways extremely often. I think some people actually insist on hardcoding $pkgname everywhere, because they want to preserve the possibility of users forking the PKGBUILD, modifying the pkgname, and still have everything work without having to fix up all pkgname references.

• I'm curious to know where you got those depends arays, they seem to be a little off... do you really need python, graphicksmagic and protobuf to basically extract a tarball?

Not to extract a tarball. This is npm. It's not just extracting a tarball, it is also probably downloading half the internet during build, and maybe compiling G-d-knows-what after the unauthenticated download. Because npm. And npm sucks. But the package itself seems fine, and I'd need to actually look in depth at the build in order to decide if those makedepends raise a red flag.

• I'm also not sure why *everything* is just blindly put on /usr

It's not? npm install (like make install except that npm is obviously terrible because javascript desktop programming) is responsible when given --prefix="$pkgdir/usr" to place "everything" in the places where npm thinks they should go. It's like passing DESTDIR="$PKGDIR" PREFIX=/usr to a Makefile. It seems totally like the correct thing to do for an npm project.

== Conclusion ==

• I think you are on the right path, but some decisions made me wonder whether your sponsors actually reviewed the PKGBUILDS with you.

If this is the worst that the applicant has, then that's not very bad at all. :D :D

On 8/18/19 12:26 AM, Santiago Torres-Arias wrote:

...

...

• This appears to me it's a -bin package

Why? It looks like some sort of standard js-based source package on the NPM registry.

well, judging from the lack of build() I'd assume so. I'm not too familiar with npm, but if t is running build commands (as you concede down in the email it may be happening) then that probably should happen inside of build()?

That's what I do for rapydscript-ng. If you try to npm install in build() and then npm install --prefix="$pkgdir/usr" in package(), I'm pretty sure it will just build a second copy all over again, during the package() step.

Repeat after me: "curse you, npm".

It is very, very, very difficult to provide meaningful criticism of an npm PKGBUILD. There aren't a lot of options when it comes to packaging this language.

On Sat, 2019-08-17 at 22:51 -0400, Santiago Torres-Arias wrote:

On Fri, Aug 16, 2019 at 03:19:56PM -0400, Jean Lucas via aur-general wrote:

...

Hi all,

Thank you for your time, and thank you to all who help make Arch a great OS!

Always happy to help! :)

It's customary to review PKGBUILDS for new applicants. This is somewhat of a quick/cursory review over 3 random packages as I've been in conferences for the whole week.

Thank you for the review!

== Overall ==

• It appears you need quote strings way more everywhere, from deps,

to licenses to variables....

• Consider that base-devel is assumed to exist for makedepends and

(iirc).

As Eli explained, the quotes are unnecessary unless you need to do variable expansion, and makepkg yells at you if you include a space somewhere. As for array keys, I think that no quotes looks way prettier

:)

And yes, I've been working on the assumption that base-devel is installed for makedepends.

== Beaker ==

• This depends array has to be wrong

I've been working on parsing namcap output to make my life a little easier, so I'm basically throwing what namcap outputs w.r.t. deps at a script I wrote that looks up the missing libraries and spits out the needed packages, and I throw that into the depends of pkgbuilds. I do know that some dependencies are subdependencies of more higher-level packages (i.e. the higher-level packages already pull the subdependencies in) but I haven't yet scripted a way to intelligently omit those subdependencies.

I don't think it is harmful to be very verbose on those dependencies, but I do make sure I work from an empty depends array to exactly what namcap tells me, as well as interpreting readmes and reading through the actual software being packaged. Then I test all my packages in clean chroots (especially graphical applications) to ensure I have the minimal amount of deps needed.

As for depending on Electron, Beaker builds a self-contained Electron app, hence the specific need for all the dynamic dependencies (that something like wire-desktop can leave for community/electron to resolve, since it does not bundle Electron).

As for glibc/gcc-libs, yes this seems like quite an involved topic with a lot of angles. Arch is glibc-based, they're both in base, so they could *probably* be omitted - I'm working on the fact that namcap tells me I need them :X

• This makedepends array too. you should make sure things aren't

depending on py2 anymore

Py2 isn't officially EOL *yet* - that's in January 2020 :) but I prefer to let upstream switch their dependency to Py3 because - I'm not a Python expert here so please correct me if I'm wrong - there could be some form of incompatibility when manually hacking in a Py3 build, especially for something as complex as a browser.

• I'm also a little confused, did you take over the namespace of

another project called beaker? Why not just call this beaker browser?

I don't have an airtight answer for this - I liked the named beaker more, and saw it used officially just about everywhere except the domain name and the GitHub user name. I also followed the train of logic that Firefox isn't named firefox-browser, nor Chromium chromium- browser - but then again, I was also unaware of the existence of an existing project called Beaker. I didn't see it in the AUR nor the official repos, so I went ahead and solicited the namespace change.

== Oxy ==

• I think you should document why you're cherry-picking that commit

rather than using a tag. Admittedly this is probably upstream's fault, but still, better to be clear.

You're right - better to be clear. I will document my cherry-picks from now on. But yeah, not tagging your releases is kind of annoying.

• Again, I think your depends are either too verbose or wrong.

This goes back to the glibc/gcc-libs point above :)

== stf ==

• This appears to me it's a -bin package

I use this package every day - its definitely not a bin / it builds the platform.

• npm -i -g --prefix seems like a good way to overwrite a bunch of

system files and/or cause a bunch of file conflicts

As Eli mentioned, this is basically the standard way of building NPM packages. I customarily check the file tree of my packages and make sure things are neat and don't collide.

• I think you can use $pkgname more often, namely when resolving the

url and resolving the tgz file

After reading Eli's reply to this point, I can see a point for why one would want to hardcore $pkgname everywhere (for namespace changes). I basically use $pkgname if its shorter than typing the actual pkgname, haha. But I really think a package maintainer should always be reviewing build/packaging instructions, and a $pkgname change, as normally glacial/infrequent as that is, should be very obvious to a maintainer during rebuild.

For URLs - those can change a lot, and be radically different e.g. switching from PyPI to GitHub, so hardcoding $pkgname there is IMO a bad idea, and should be evaluated on a case-by-case basis.

For source naming schemas, you do want the source tarball to be $pkgname, so I could see the usage there.

• I'm curious to know where you got those depends arays, they seem to

be a little off... do you really need python, graphicksmagic and protobuf to basically extract a tarball?

So yes, since this is a full build and not just a tarball extraction, those are precisely the minimal amount of dependencies needed for build.

• I'm also not sure why *everything* is just blindly put on /usr

So this is basically the only pattern I've seen for Arch NPM packages, it seems correct to me because system-wide node_modules go in /lib. As Eli mentioned, its basically akin to the DESTDIR="$pkgdir" PREFIX=/usr for Makefile pattern. Either way, as mentioned, I check my packages in case of any lingering other-Linux-distro-specific files or otherwise, although thats not so common IME, especially for NPM packages.

== Conclusion ==

• I think you are on the right path, but some decisions made me

wonder whether your sponsors actually reviewed the PKGBUILDS with you.

I believe that my profile was posted for review among the TUs when I solicited Alexander's sponsorship, and he and Robin (although later confirmed not a sponsor) relayed to me one package with more obvious errors - generating keys which affected reproducible builds, as well as grepping the system for a binary which was considered questionable from a security POV - in searx-git. Robin also relayed to me a few other less troublesome issues (like removing -git/-bin package variants from conflicts, source naming and pkgver schema fixes).

I believe Sergej went over a few of my packages at least before giving an OK for sponsorship, but that was 2 weeks after I had requested sponsorship, at which point I had cleaned up a lot of the errors that were raised :)

Still - I do acknowledge that I could've had much better communication with everyone involved, and if I don't get accepted for TU this time around, if I try again later, I'll be sure to do my best to not commit the same mistakes again.

Hope this helps, -Santiago

Em agosto 19, 2019 9:05 Sergej Pupykin escreveu:

I have nothing against this application. I use parsedmarc package (slightly modified for my needs) which maintained by Jean.

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Regards, Giancarlo Razzolini

On Mon, 2019-08-19 at 16:49 +0300, Sergej Pupykin wrote:

Giancarlo Razzolini via aur-general wrote:

...

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Ok, I am not sure about "actively" :) but I want to see parsedmarc package bundle in community. As well as ghidra and coturn (which is already in community), so I sponsor him.

I'd like for checkdmarc/parsedmarc to get rewritten in Rust or Go so dependencies are easily resolvable... Python packages with a ton of version-specific dependencies are kind of crazy to package.

...and upstream seems to be allergic to tags. :)

On Tue, 2019-08-20 at 11:01 +0200, Bert Peters via aur-general wrote:

Hi Jean Lucas,

I've been reading your TU application and I wish you the best of luck. However, I can't seem to find the GPG key you're using on any keyservers. Did you happen to forget to submit it somewhere?

Best,

Bert.

Hi Bert, and thank you!

My (latest) key can be found at https://keys.openpgp.org/search?q=jean%404ray.co and https://pool.sks-keyservers.net/pks/lookup?search=jean%404ray.co&fingerp... (as well as the servers SKS Keyservers gossips with).

On SKS Keyservers, I had originally submitted 2 keys in 2015, and they've both since been revoked. So my latest, active key has fingerprint 553C C0A1 134A 2E77 145B E12D 7416 2644 B297 6F6C, as posted on my AUR profile at https://aur.archlinux.org/account/flacks/.

Best regards, Jean

On 2019-08-19 16:49 +0300 Sergej Pupykin wrote:

Giancarlo Razzolini via aur-general wrote:

...

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Ok, I am not sure about "actively" :) but I want to see parsedmarc package bundle in community. As well as ghidra and coturn (which is already in community), so I sponsor him.

Sponsorship is supposed to be an active advocacy of the applicant based on the sponsor's evaluation of the applicant's skills and trustworthiness. It should be based on a strong positive opinion of the applicant and the sponsor essentially vouches for the applicant by sponsoring them.

The lackadaisical approach to sponsorship is one of the main reasons that we've moved to a system with two sponsors. Maybe I missed the joke, but having nothing against someone and wanting to see a particular package in community is not a good enough reason to sponsor someone. A TU application may not be a matter of life and death but the process should be taken somewhat seriously nevertheless given how many people could be potentially impacted if a malicious candidate is accepted. If TUs start sponsoring anyone who asks based on these latter criteria, the system is broken. Especially when we have candidates who just ask different TUs until they get two to agree. We need to agree to set the bar a little higher.

I am only reacting to the apparent indifference of sponsorship here, which is independent of Jean Lucas' application. The latter will be discussed if and when Alexander confirms his sponsorship.

Regards, Xyne

Hello,

Sorry for the late response, I was on vacation followed by a period of having little spare time, with regards to work and family.

I did agree to sponsor the TU application of Jean Lucas, provided he found another sponsor, but was not aware that he had sent his application without any mentoring on my part.

I am not in favor of how the TU application process turned out, nor the idea of moving proprietary software packages to [community], but I'll stand by my word and sponsor him if there is another sponsor.

In general, we need more TUs and Devs and I think we should have a process that feels less judgemental on the applicants (ref. the application from Drew DeVault that sadly did not join us as a TU).

If someone dislikes a TU application, it's easy to vote "no" in the vote that follows.

Best regards, Alexander F. Rødseth

On September 4, 2019 4:37:42 PM GMT+02:00, Giancarlo Razzolini via aur-general aur-general@archlinux.org wrote:

Em setembro 4, 2019 9:54 Alexander Rødseth via aur-general escreveu:

...

I did agree to sponsor the TU application of Jean Lucas, provided he

found

...

another sponsor, but was not aware that he had sent his application

without

...

any mentoring on my part.

Well, I think it should be the other way around, you first mentor someone and look with them into their packages and then decided about sponsorship.

...

I am not in favor of how the TU application process turned out, nor

the

...

idea of moving proprietary software packages to [community], but I'll

stand

...

by my word and sponsor him if there is another sponsor.

Sergej already confirmed sponsorship. But it seems neither of you actually mentored the applicant.

...

In general, we need more TUs and Devs and I think we should have a

process

...

that feels less judgemental on the applicants (ref. the application

from

...

Drew DeVault that sadly did not join us as a TU).

While I agree that we should have a more on point discussion with less bikeshedding regarding other stuff, I don't think that simply foregoing the discussion period is the way to go.

...

If someone dislikes a TU application, it's easy to vote "no" in the

vote

...

that follows.

That's not how this should be faced. Ideally all the applications should have two sponsors that are actively mentoring the applicant and are vested into their success. If we had that, applications would be voted "yes".

ps: I'm not making any judgment on the applicant here. I've talked with him privately regarding this application process. While he failed to disclose that he had asked another TU before, I don't think it was in bad faith.

Regards, Giancarlo Razzolini

I agree with grazzolini, sponsors pretty much agreed themselves that there was zero mentoring happening plus xyproto obviously is even surprised so many proprietary blobs are about to be added.

Not judging here by any means about the applicant himself, but I consider the current state as void as we frankly did not go through long discussions and bylaw changes to implement two sponsors if at the end it doesn't provide more value than having a bigger number and "having nothing against because someone wants a package in the repo" .

I'm happy to cast votes after the sponsors did what sponsors shall do and take care of their applicant - obviously there is much room for discussing intends etc with sponsors.

On Thu, Sep 5, 2019 at 3:45 AM Alexander F Rødseth via aur-general < aur-general@archlinux.org> wrote:

...

Sergej already confirmed sponsorship.

I read his reply twice, but I could not see a confirmation of sponsorship. Sergej, could you please clarify?

...

Have Sergej confirmed his sponsorship, though?

For the record, it looks like Sergej has explicitly stated that he will sponsor in a signed message:

On Mon, Aug 19, 2019 at 9:49 AM Sergej Pupykin ml@sergej.pp.ru wrote:

Giancarlo Razzolini via aur-general wrote:

...

Having nothing against is not the same as actively sponsoring it. All this discussion is kind of pointless until we hear from both sponsors telling us they actively sponsor Jean's application. Then the discussion period can begin.

Ok, I am not sure about "actively" :) but I want to see parsedmarc package bundle in community. As well as ghidra and coturn (which is already in community), so I sponsor him.

I believe this marks the beginning of the discussion period.

I'm reading carefully through the TU bylaws, and I think they need some clarifications:

The addition of a TU may occur at any time.

In order to become a TU, one must first find two sponsoring TUs following

the guidelines outlined below, and arrange privately with them

to announce their candidacy on the aur-general mailing list. Following

the announcement, standard voting procedure commences with a

discussion period of 14 days, a quorum of 66%, and a voting period of 7

days.

SVP( addition_of_TU, 14, 0.66, 7 );

If a candidate is rejected by SVP, they may not reapply to become a

Trusted User for a period of three months.

* It's unclear if the "arrange privately with them to announce their candidacy" part is a requirement or not, but it seems like it is. * It's unclear if "the announcement" starts when the candidate announces it, or when two TUs have confirmed the sponsorship. * It's unclear if "the announcement" is part of the "standard voting procedure", and/or if the confirmation of sponsorship is part of the "standard voting procedure".

Since the announcement of the candidacy was done without it having been arranged privately (unless Sergej did this), I believe the current process is void (but possible to start again later: the addition of a TU may occur at any time).

Best regards, Alexander F. Rødseth