Re: [aur-general] TU membership application
> > 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. > > That's your opinion, and here's mine: I don't think that's important. If a > candidate looks promising and there is an intention to both sponsor > (confirming by e-mail that the applicant is sponsored when they apply) and > an intention to mentor (at least look through the AUR packages and give > them helpful hints), I don't think the order matters, as long as everyone > is honest with each other and both things happens before the application is > sent. > > That's not what happened in this case, though, since the application was > sent before there were any mentoring. Through work, I've had the chance to train about ten employees and interns. I've also mentored two peers of mine. All of these people *looked* promising. They all either got through the job application process or struck me as someone I wanted to mentor. Furthermore, all of them professed a great interest in learning about QE, virtualization, software engineering, and whatever other topics were relevant to them. However, there have been a broad spectrum of outcomes. I'm going to be intentionally vague and say that some were brilliantly successful; others struggled but succeeded after *years* of intense efforts; others realized that they weren't actually that interested in the topic at hand, but only after investing much time and effort; and others failed due to incompetence and/or self-sabotage. Do I trust someone to be trustworthy and competent because they "[look] promising and there is an intention [...] to mentor"? Not at all. This is a comment on the sponsorship for this TU application, not a comment on this TU application itself (which has already been rescinded anyway).
Re: [aur-general] TU membership application
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
Re: [aur-general] TU membership application
On 9/5/19 3:21 PM, Aaron Laws via aur-general wrote: > 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 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. Regardless of when the discussion period begins - the TU bylaws are not exactly clear about this - I'm not sure what's left to discuss. Concerns with this application have already been raised, and the applicant's packages have already been reviewed. Alad
Re: [aur-general] TU membership application
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 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.
Re: [aur-general] TU membership application
Hi, Giancarlo wrote: > 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. That's your opinion, and here's mine: I don't think that's important. If a candidate looks promising and there is an intention to both sponsor (confirming by e-mail that the applicant is sponsored when they apply) and an intention to mentor (at least look through the AUR packages and give them helpful hints), I don't think the order matters, as long as everyone is honest with each other and both things happens before the application is sent. That's not what happened in this case, though, since the application was sent before there were any mentoring. > Sergej already confirmed sponsorship. I read his reply twice, but I could not see a confirmation of sponsorship. Sergej, could you please clarify? > But it seems neither of you actually mentored the applicant. It did not happen. I explicitly wrote that I was not aware that he had sent his application without any mentoring on my part. > I don't think that simply foregoing the discussion period is the way to go. If Sergej also confirms his sponsorship, the discussion period can begin. >> 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". This is disregarding that I was first on vacation and then didn't have the time to do any mentoring. I did not know that an application was sent. Please, be more generous in your interpretations. Levente wrote: > 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". Have Sergej confirmed his sponsorship, though? -- Sincerely, Alexander F Rødseth / xyproto
Re: [aur-general] TU membership application
On September 4, 2019 4:37:42 PM GMT+02:00, Giancarlo Razzolini via aur-general 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.
Re: [aur-general] TU membership application
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 pgp5E50PKzsYr.pgp Description: PGP signature
Re: [aur-general] TU membership application
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
Re: [aur-general] TU membership application
On Sunday, September 1, 2019 9:39:37 AM EDT Xyne wrote: > 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. > We need to agree to set the bar a little higher. That kinda speaks to the 'trust' in 'Trusted User'. It's not just "Oh hey, I want to contribute, give me the keys to the kingdom". You need to be vetted and checked out. Not just because of the potential for bad actors, but I think you also need to show you're actually capable of doing the job being asked of you. Sponsoring a TU applicant that you're friendly with, but has no real experience in packaging or any sort of development background, does a disservice to the community. It's not just, "Does the sponsor Trust this person" But "Can the community Trust this person?" I'm not saying that this is the case for this application, but that's the reason, I feel, why the process is involved as it is. Heck, it could be more intensive and I'd still say "Yeah, that's appropriate." Like Xyne said, not commenting on the TU application at all. Just responding with my thoughts to his comments. signature.asc Description: This is a digitally signed message part.
Re: [aur-general] TU membership application
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
Re: [aur-general] TU membership application
Em agosto 20, 2019 13:16 Jean Lucas via aur-general escreveu: 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=on=vindex (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/. Hi Jean, Can you as your second sponsor to reply to this thread so we can start the discussion period? Ideally, Alexander should also sign his email, like Sergej did. Our bylaws unfortunately do not mention this, neither does our wiki. Regards, Giancarlo Razzolini pgpGexMuoxU2c.pgp Description: PGP signature
Re: [aur-general] TU membership application
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=on=vindex (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 signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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. :) signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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. signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
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 pgpGE6wYuDNv9.pgp Description: PGP signature
Re: [aur-general] TU membership application
> 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 have nothing against this application. I use parsedmarc package (slightly modified for my needs) which maintained by Jean.
Re: [aur-general] TU membership application
On Sun, 2019-08-18 at 01:14 -0400, Eli Schwartz via aur-general wrote: > 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. I'm not a makepkg expert so please correct me if I'm wrong, but from reading the PKGBUILD man page (and knowing build() is considered optional), it doesn't seem like build() has any particularly different configuration that would affect the build of the package vis-à-vis building within package(). > > Repeat after me: "curse you, npm". Repeating that is the only way I fall asleep. > > 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. > signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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.
Re: [aur-general] TU membership application
On Sun, 2019-08-18 at 17:56 +0200, David Runge wrote: > 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 > Yeah the legalese is a bit hard to interpret, its much better to get a clear answer from them directly, and have them explicitly add a redistribution-by-linux-distros-ok clause to the license, like Valve did with Steam. I suppose more people could contact them to see if they'll budge. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [aur-general] TU membership application
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,
Re: [aur-general] TU membership application
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. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
> > - 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()? -Santiago. signature.asc Description: PGP signature
Re: [aur-general] TU membership application
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
Re: [aur-general] TU membership application
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. 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. 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? 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 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. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
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. == 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). == Beaker == - This depends array has to be wrong - This makedepends array too. you should make sure things aren't depending on py2 anymore - 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. - Again, I think your depends are either too verbose or wrong. == stf == - This appears to me it's a -bin package - npm -i -g --prefix seems like a good way to overwrite a bunch of system files and/or cause a bunch of file conflicts - I think you can use $pkgname more often, namely when resolving the url and resolving the tgz file - 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? - I'm also not sure why *everything* is just blindly put on /usr == Conclusion == - I think you are on the right path, but some decisions made me wonder whether your sponsors actually reviewed the PKGBUILDS with you. Hope this helps, -Santiago signature.asc Description: PGP signature
Re: [aur-general] TU membership application
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 orj...@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. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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 orj...@4ray.co in my mailbox. I guess that's why I did not respond then. 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?
Re: [aur-general] TU membership application
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 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 > signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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? 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? > after a follow-up, you declined > sponsorship for the moment. Indeed, I did however offer to review any new things. > 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 > 0507201 9:00:00 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. >> 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! >> 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... [1] https://wiki.archlinux.org/index.php/Trusted_Users -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
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 signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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. > > 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? > > 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... -- Rob (coderobe) O< ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
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 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. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
On Sat, 17 Aug 2019 at 01:35, Josef Miegl 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.
Re: [aur-general] TU membership application
On August 16, 2019 10:05:54 PM GMT+02:00, "Balló György via aur-general" 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
Re: [aur-general] TU membership application
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 > > > > signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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... 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. 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. > 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 > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU membership application
On Fri, 2019-08-16 at 22:40 +0200, Sven-Hendrik Haase via aur-general wrote: > On Fri, 16 Aug 2019 at 22:35, Oscar 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. 08. 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. I would definitely be willing to very politely ask the five respective companies for redistribution permissions for Arch Linux. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
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. signature.asc Description: This is a digitally signed message part
Re: [aur-general] TU membership application
On August 16, 2019 9:19:56 PM GMT+02:00, Jean Lucas via aur-general 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.
Re: [aur-general] TU membership application
On Fri, 16 Aug 2019 at 22:35, Oscar 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. 08. 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.
Re: [aur-general] TU membership application
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. 08. 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. > > > >
Re: [aur-general] TU membership application
On Fri, Aug 16, 2019, 22:06 Balló György via aur-general < aur-general@archlinux.org> wrote: > 2019. 08. 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. >
Re: [aur-general] TU membership application
2019. 08. 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 signature.asc Description: This is a digitally signed message part
[aur-general] TU membership application
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! 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
Re: [aur-general] TU Membership Application
On 11/16/18 08:11pm, David Runge wrote: The results are in (the vote ended nearly an hour ago)! Thank you all. To those that voted 'No': Feel free to send me a message with your feedback. Your concerns would be a valuable asset for me to keep in mind. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 2018-11-09 19:05:58 (+0100), David Runge wrote: > Let's vote! :) The results are in (the vote ended nearly an hour ago)! Yes: 26 No:9 Abstain: 12 Participation 90.38% (come on, don't drop the ball on this! ;-)) I have just updated your account status in the AUR to 'Trusted User'. Congratulations! Please follow up on the TODO for new Trusted Users [1]. See you on IRC :) Bests, David [1] https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_for_new_Trusted_Users -- https://sleepmap.de signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 2018-11-09 13:11:19 (-0500), Eli Schwartz via aur-general wrote: > This definitely lists the right time period: > https://aur.archlinux.org/trusted-user/TUbylaws.html#_addition_of_a_tu Yep, sorry, that was just a brainfart from my side. ;-) Here's the link to the vote btw: https://aur.archlinux.org/tu/?id=112 -- https://sleepmap.de signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/9/18 1:05 PM, David Runge wrote: > As the (newish, but still not updated [1]) discussion period of 14 days > is now over, I have started the vote. > > Thanks again to all reviewers and active TUs in this discussion period! > I think Brett will make a good TU! > > Let's vote! :) > > [1] > https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure I got worried for a second there, but the section you're looking at is the default "procedure for general proposals" when another section doesn't override the five-day discussion period. This definitely lists the right time period: https://aur.archlinux.org/trusted-user/TUbylaws.html#_addition_of_a_tu -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
As the (newish, but still not updated [1]) discussion period of 14 days is now over, I have started the vote. Thanks again to all reviewers and active TUs in this discussion period! I think Brett will make a good TU! Let's vote! :) [1] https://aur.archlinux.org/trusted-user/TUbylaws.html#_standard_voting_procedure -- https://sleepmap.de signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
Le 08/11/2018 à 04:34, Santiago Torres-Arias via aur-general a écrit : >>>- I noticed that you didn't add a LICENSE file for this package. >> Artistic2.0 is a uncommonly used common license! >> (/usr/share/licenses/common/Artistic2.0/license.txt) >> >> > Yes, my bad. I was told about this on MIT, and I assumed this was the > case for most licenses... We have a instructions here: https://wiki.archlinux.org/index.php/PKGBUILD#license (which redirects to the actual licenses package for a list of what is common). ;) >>> - hib-dlagent: >>>- I see that you backported a patch on this and ags. I was rather >>> surprised to see that neither patches were added to new >>> tags/releases. You could, however, cherry pick the commits rather >>> than depending on the github api (which can change) to compute the >>> diff for you. For this, you could use the git transport on >>> makepkg. >> That would bring another dependency on git, though. I can surely do if if >> it's more 'correct' but I wouldn't imagine that Github would change that API >> anytime soon. >> >> Or would it be better to just carry the patch locally in the repo? > True, I didn't consider the dependency on git. I'd say you could check > it in. I do not agree with Eli that you should rely on api's like this > to get a simple patch. It has been my experience that api's like this > move around and leave you trying to debug weird errors. Please don’t start cloning a repo just for some small patches that can be retrieved by this stable and long-lived GitHub API. And @Brett, no, you should not carry the patch locally. No reason to clobber our tree with that. ;) Regards, Bruno signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
On Wed, Nov 07, 2018 at 11:04:43PM -0500, Eli Schwartz via aur-general wrote: > Because their tarballs used to be insane. And giving you the tarball for > master is a regression they fixed, not an API they dropped. :p It's an API url they dropped. They moved it around and instead of 404'd they just left it broken. True though, probably github is not prone to things like this... > > It should be owned by root unless some process uses something like > install -o username -g groupname. Ah, I'm still not sure if the executable should setuid to update than when run as a user (although it shouldn't be able if it's just a script). > >> Looks like it just copies a couple python modules into a directory and > >> then creates a wrapper script to run them. What would you suggest > >> running in build(), exactly? > > > > I'm not entirely sure, I see that there's a buildscript using > > pyinstaller, although I'm not sure why exactly... > > Most likely in order to create some giant windows executable that ships > the entire python application runtime, plus the gam source code, in > order to spare Windows users the need to install Python. > I think you're right, but I'm still confused as to why there's a linux vaiant of it... https://github.com/jay0lee/GAM/blob/master/src/linux-build.sh Probably for the same reason as you pointed out though... -Santiago signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/7/18 10:44 PM, Santiago Torres-Arias via aur-general wrote: > It happened to me with gitlab and their releases url, which started > defaulting to "I don't recognize this branch parameter, so here's the > tarball for master"[1] Yes, gitlab is prone to bugs like this. :p gitlab also includes the version of git(1) inside the patch file, and moved the tarball endpoint for legitimately good reasons in https://gitlab.com/gitlab-org/gitlab-ce/issues/38830 Because their tarballs used to be insane. And giving you the tarball for master is a regression they fixed, not an API they dropped. :p >>> - I'm not sure if this would work when built in a chroot due to >>> those touch calls. >> ... >> Are you referring to the ones in package()? Not sure why upstream code >> needs such weird things but AFAICT it should not break just because of a >> chroot. >> > > Hmm, I see they are named as noupdatecheck and nobrowser. I assume these > are to store the program state and thus need be user read-writeable? > This is just speculation, hence the "I'm not sure". It should be owned by root unless some process uses something like install -o username -g groupname. >> Looks like it just copies a couple python modules into a directory and >> then creates a wrapper script to run them. What would you suggest >> running in build(), exactly? > > I'm not entirely sure, I see that there's a buildscript using > pyinstaller, although I'm not sure why exactly... Most likely in order to create some giant windows executable that ships the entire python application runtime, plus the gam source code, in order to spare Windows users the need to install Python. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
> > - I noticed that you didn't add a LICENSE file for this package. > > This checks out, Artistic2.0 is a common license. Yes, my bad. For this and the rest of the licenses below I assumed it was the same case as MIT and such. > > - hib-dlagent: > > - I see that you backported a patch on this and ags. I was rather > > surprised to see that neither patches were added to new > > tags/releases. You could, however, cherry pick the commits rather > > than depending on the github api (which can change) to compute the > > diff for you. For this, you could use the git transport on > > makepkg. > > I don't see why you'd need the overhead of git for this, and that url is > not going to change. They "document" it here: > https://blog.github.com/2011-10-21-github-secrets/#diff-patch They are not even using an API stable url here. I hope it doesn't change, but it wouldn't be the first time I get biten by api's like this[1]. > They've provided it for a very long time specifically in order to let > people do this, they're not going to change the scheme and render it > useless for the very purpose it was created for. :p It happened to me with gitlab and their releases url, which started defaulting to "I don't recognize this branch parameter, so here's the tarball for master"[1] > > - I'm not sure if this would work when built in a chroot due to > > those touch calls. > ... > Are you referring to the ones in package()? Not sure why upstream code > needs such weird things but AFAICT it should not break just because of a > chroot. > Hmm, I see they are named as noupdatecheck and nobrowser. I assume these are to store the program state and thus need be user read-writeable? This is just speculation, hence the "I'm not sure". > > - After reviewing the package I doubt this doesn't need a build() > > step. Otherwise I'd label this package a -bin. This is something > > that we should take special consideration of, since we could be > > unwittingly be introducing binaries that aren't hardened when > > building> > Looks like it just copies a couple python modules into a directory and > then creates a wrapper script to run them. What would you suggest > running in build(), exactly? I'm not entirely sure, I see that there's a buildscript using pyinstaller, although I'm not sure why exactly... > > - I'm confused as to why gam.py needs to be put inside > > /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The > > file seems to have a shebang and be executable... > I'm not sure what the script does either. gam.py does do: > > import utils > from var import * > > Which should really be explicit relative imports, but it's actually > legal in python2, and there doesn't seem to be any other reason to want > to cd to the directory, but the script does not cd there anyway. [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/45507 signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
> >- I marked the package as out-of-date, as there appears to be a new > > version (3.1.4.15) as of almost two months ago. > > Long story short, that was pretty much exactly during the time when I > accidentally clobbered my urlwatch file. Thanks for bringing that up to me. > > >- I noticed that you didn't add a LICENSE file for this package. > > Artistic2.0 is a uncommonly used common license! > (/usr/share/licenses/common/Artistic2.0/license.txt) > > Yes, my bad. I was told about this on MIT, and I assumed this was the case for most licenses... > > - hib-dlagent: > >- I see that you backported a patch on this and ags. I was rather > > surprised to see that neither patches were added to new > > tags/releases. You could, however, cherry pick the commits rather > > than depending on the github api (which can change) to compute the > > diff for you. For this, you could use the git transport on > > makepkg. > > That would bring another dependency on git, though. I can surely do if if > it's more 'correct' but I wouldn't imagine that Github would change that API > anytime soon. > > Or would it be better to just carry the patch locally in the repo? True, I didn't consider the dependency on git. I'd say you could check it in. I do not agree with Eli that you should rely on api's like this to get a simple patch. It has been my experience that api's like this move around and leave you trying to debug weird errors. > > >- I noticed that you didn't add a LICENSE file for this package. > > Yikes, the project doesn't even have a license! I should have checked that > when I inherited it (the packager just slapped a GPL2 on it). Really, I had > just uploaded it so it wouldn't have been lost after the AUR 4 migration. > > I'll bug upstream about it. > > > - gam-git: > > ... > Of all the packages you had to click on that one. :( > > I know it doesn't really excuse it but gam is sort of a "WIP" because > it's... oddly written. I've been meaning to set aside some time to get some > patches in to make it more palatable for packaging. The patch is a complete > hack right now just to make the package "work" (when I inherited it it was > FUBAR). Yes, granted I'm rather confused when I read the repository and see things like build-linux.sh that pulls pyinstaller. I didn't know exactly what of all was happening there... > > > I will probably send more feedback, but I also don't want to overwhelm > > you with this and all the other reviews around. > > I really appreciate the feedback! It always sucks when so many little things > become so glaring after the fact but Lol I've been there, no worries :) -Santiago. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/07/18 09:28pm, Santiago Torres-Arias wrote: Hello Brett. I took some time to randomly sample your PKGBUILDs and give some feedback: - ags: - it appears that you use sed to change CFLAGS in the makefile definition, although it appears that the Makefile itself lets you overwrite them. I'd advice trying to use native tooling as possible, and to try to get familiar with the toolchain of each package as much as possible. I will admit that I didn't think to go through those lines when I inherited it. You're totally right, there's no reason to do it that way. - The optdepends description on wine is a bit confusing in my opinion. I removed it. There's little reason to have it there anyway. The optdepends isn't a good place to inform people about that anyway. - I marked the package as out-of-date, as there appears to be a new version (3.1.4.15) as of almost two months ago. Long story short, that was pretty much exactly during the time when I accidentally clobbered my urlwatch file. Thanks for bringing that up to me. - I noticed that you didn't add a LICENSE file for this package. Artistic2.0 is a uncommonly used common license! (/usr/share/licenses/common/Artistic2.0/license.txt) - hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg. That would bring another dependency on git, though. I can surely do if if it's more 'correct' but I wouldn't imagine that Github would change that API anytime soon. Or would it be better to just carry the patch locally in the repo? - I noticed that you didn't add a LICENSE file for this package. Yikes, the project doesn't even have a license! I should have checked that when I inherited it (the packager just slapped a GPL2 on it). Really, I had just uploaded it so it wouldn't have been lost after the AUR 4 migration. I'll bug upstream about it. - gam-git: - I'm not sure if this would work when built in a chroot due to those touch calls. - After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building. (I could be wrong on this one, since it for some reason vendors many well-known packages inside of it. Good job for not pulling it those vendored deps :D) - I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable... - I see that here you *also* are providing a patch. I also could find that you submitted an issue upstream for said patch (but not the patch itself)[1]. I like your initiative! Do try to keep the number of backported patches to a minimum to keep things manageable. - I noticed that you didn't add a LICENSE file for this package. Of all the packages you had to click on that one. :( I know it doesn't really excuse it but gam is sort of a "WIP" because it's... oddly written. I've been meaning to set aside some time to get some patches in to make it more palatable for packaging. The patch is a complete hack right now just to make the package "work" (when I inherited it it was FUBAR). I will probably send more feedback, but I also don't want to overwhelm you with this and all the other reviews around. I really appreciate the feedback! It always sucks when so many little things become so glaring after the fact but signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/7/18 9:28 PM, Santiago Torres-Arias via aur-general wrote: > Hello Brett. > > I took some time to randomly sample your PKGBUILDs and give some > feedback: > > - ags: > - it appears that you use sed to change CFLAGS in the makefile > definition, although it appears that the Makefile itself lets you > overwrite them. I'd advice trying to use native tooling as > possible, and to try to get familiar with the toolchain of each > package as much as possible. > - The optdepends description on wine is a bit confusing in my > opinion. > - I marked the package as out-of-date, as there appears to be a new > version (3.1.4.15) as of almost two months ago. > - I noticed that you didn't add a LICENSE file for this package. This checks out, Artistic2.0 is a common license. > - hib-dlagent: > - I see that you backported a patch on this and ags. I was rather > surprised to see that neither patches were added to new > tags/releases. You could, however, cherry pick the commits rather > than depending on the github api (which can change) to compute the > diff for you. For this, you could use the git transport on > makepkg. I don't see why you'd need the overhead of git for this, and that url is not going to change. They "document" it here: https://blog.github.com/2011-10-21-github-secrets/#diff-patch They've provided it for a very long time specifically in order to let people do this, they're not going to change the scheme and render it useless for the very purpose it was created for. :p ... cgit and gitweb let you download patch files too, GitHub just doesn't expose a visible link for it. > - I noticed that you didn't add a LICENSE file for this package. PKGBUILD claims to be GPL2, which is a common license, but upstream has no licensing information I can find... > - gam-git: Am I missing something? I only see a "gam" package. > - I'm not sure if this would work when built in a chroot due to > those touch calls. Are you referring to the ones in package()? Not sure why upstream code needs such weird things but AFAICT it should not break just because of a chroot. > - After reviewing the package I doubt this doesn't need a build() > step. Otherwise I'd label this package a -bin. This is something > that we should take special consideration of, since we could be > unwittingly be introducing binaries that aren't hardened when > building.> (I could be wrong on this one, since it for some > reason vendors > many well-known packages inside of it. Good job for not pulling it > those vendored deps :D) Looks like it just copies a couple python modules into a directory and then creates a wrapper script to run them. What would you suggest running in build(), exactly? Devendoring looks good to me too, though. > - I'm confused as to why gam.py needs to be put inside > /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The > file seems to have a shebang and be executable... I'm not sure what the script does either. gam.py does do: import utils from var import * Which should really be explicit relative imports, but it's actually legal in python2, and there doesn't seem to be any other reason to want to cd to the directory, but the script does not cd there anyway. > - I see that here you *also* are providing a patch. I also could > find that you submitted an issue upstream for said patch (but not > the patch itself)[1]. I like your initiative! Do try to keep the > number of backported patches to a minimum to keep things > manageable. I see two mostly similar issues, the other one has a diff referenced. https://github.com/jay0lee/GAM/issues/created_by/ainola Worth noting, it's much easier to get upstream projects to accept these if you provide a button they can click on to implement it -- that means pull requests. > - I noticed that you didn't add a LICENSE file for this package. Once again, Apache license is a common license and doesn't need to be installed. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
Hello Brett. I took some time to randomly sample your PKGBUILDs and give some feedback: - ags: - it appears that you use sed to change CFLAGS in the makefile definition, although it appears that the Makefile itself lets you overwrite them. I'd advice trying to use native tooling as possible, and to try to get familiar with the toolchain of each package as much as possible. - The optdepends description on wine is a bit confusing in my opinion. - I marked the package as out-of-date, as there appears to be a new version (3.1.4.15) as of almost two months ago. - I noticed that you didn't add a LICENSE file for this package. - hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg. - I noticed that you didn't add a LICENSE file for this package. - gam-git: - I'm not sure if this would work when built in a chroot due to those touch calls. - After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building. (I could be wrong on this one, since it for some reason vendors many well-known packages inside of it. Good job for not pulling it those vendored deps :D) - I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable... - I see that here you *also* are providing a patch. I also could find that you submitted an issue upstream for said patch (but not the patch itself)[1]. I like your initiative! Do try to keep the number of backported patches to a minimum to keep things manageable. - I noticed that you didn't add a LICENSE file for this package. I will probably send more feedback, but I also don't want to overwhelm you with this and all the other reviews around. Cheers! -Santiago. [1] https://github.com/jay0lee/GAM/issues/791 signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 07 Nov 2018, at 5:41 pm -0700, Brett Cornwall via aur-general wrote: > On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: > > - don't think pkgdesc should ever end with a dot > The descriptions are often sentences, so would it not reason to end them > with a period? In the case of actual sentences, it's just convention to be consistent with the packages whose descriptions are sentence fragments. It's a bit arbitrary, granted. > > - not a big fan of fiddling with PKGEXT even if its "just the AUR" but > > well > > For a package destined for the repositories I would not fiddle and endeavor > to reverse such fiddling; however, the compression time for large games is > enormous only to decompress right after. Should it, for the sake of > correct-ness, be reversed even for the packages doomed forever to live in > the AUR? It's just not the prerogative of the AUR contributor to make that decision for the end-user who's going to be building the package. They can very easily configure their own makepkg.conf to use uncompressed tarballs if they so desire. Basically, a PKGBUILD shouldn't override makepkg.conf unless there's a very good reason. Cheers, Ivy signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On Wed, Nov 07, 2018 at 05:45:01PM -0700, Brett Cornwall via aur-general wrote: > On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: > > creeper-world2 > > I've had two AUR requests queued up for some time now; deleting this package > is one of them. Quick update: I addressed your request of deleting the package. That simplifies everyone's review queue :) Thanks, -Santiago signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: creeper-world2 I've had two AUR requests queued up for some time now; deleting this package is one of them. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: some small questions and hints first: I'm nearly done with following your excellent suggestions but I have responses and questions. It looks like several packages have different issues preventing to build in clean chrooted environments properly. Did you take a look at the devtools package and building packages in clean chroots so far? I must sheepishly apologize. These new tools simplify everything. What software/tool do you using to track all the new ustream releases? urlwatch on a daily timer. You still seem to use `mksrcinfo` for generating SRCINFO files, it was deprecated in favor of native `makepkg --printsrcinfo` you may want to use that in the future. Thank you, switched! I have noticed that mostly all git packages lack sufficient provides/conflicts on the basic non-git name schema and/or makedepends on git itself, would be nice to keep in mind A silly oversight that will be enforced now that I'm learned in the ways of proper tooling. Also i notices there are multiple packages that store a tarball in the AUR source repo that contain things like icons, please don't miss-use the AUR as a storage for tarball artifacts. I should have known better and - at the very least - removed them before submitting my application. I've taken care of nearly all of them and have bowed my head in shame. - don't think pkgdesc should ever end with a dot The descriptions are often sentences, so would it not reason to end them with a period? - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well For a package destined for the repositories I would not fiddle and endeavor to reverse such fiddling; however, the compression time for large games is enormous only to decompress right after. Should it, for the sake of correct-ness, be reversed even for the packages doomed forever to live in the AUR? interception-ctrl2esc-git - is there a reason to have interception- prefix? imo ctrl2esc-git would be the better naming here plus provides/conflicts on ctrl2esc I normally agree (and I originally had it named that way), however... - This is an 'interception tools' plugin... not reason enough to have the package name change, but.. - caps2esc is an older X program, so interception's variant had to be named 'interception-caps2esc'. Naming this 'interception-ctrl2esc' follows the pattern for consistency/less confusion. With that said, should it still be named ctrl2esc? signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: Hi Brett, some small questions and hints first: Thank you for such a thorough vetting, Levente! I'm fixing these ASAP. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/5/18 1:48 PM, Levente Polyak via aur-general wrote:
> gnome-xcf-thumbnailer
> - prepare() shall never package into $pkgdir
That's a write error, makepkg explicitly runs chmod on "${pkgdir}" in
order to strip read/write permissions and forbid you from touching it
before package() is run:
https://git.archlinux.org/pacman.git/tree/scripts/makepkg.sh.in#n1679
...
Actually, come to think of it, if you try touching "${pkgdir}" during
prepare() then it won't exist yet, and then after prepare() does its
thing we forcibly remove the directory anyway, recreate it, and set the
restrictive permissions. I wonder if it's a bug that we don't error out
harder on this...
But depending on whether/how makepkg errors in the previous makepkg
attempt, this directory will still exist and it will indeed be chmod
a-rw at the time prepare is executed.
The rest of the time, install -d has hidden the fact that the directory
simply does not exist at all.
Either way, this file is definitely not being packaged.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
On 10/25/18 4:26 PM, Brett Cornwall via aur-general wrote: > I am being sponsored by dvzrv. > > I've been working in the AUR since 2014 as 'Ainola'. Hi Brett, some small questions and hints first: It looks like several packages have different issues preventing to build in clean chrooted environments properly. Did you take a look at the devtools package and building packages in clean chroots so far? What software/tool do you using to track all the new ustream releases? You still seem to use `mksrcinfo` for generating SRCINFO files, it was deprecated in favor of native `makepkg --printsrcinfo` you may want to use that in the future. I have noticed that mostly all git packages lack sufficient provides/conflicts on the basic non-git name schema and/or makedepends on git itself, would be nice to keep in mind Also i notices there are multiple packages that store a tarball in the AUR source repo that contain things like icons, please don't miss-use the AUR as a storage for tarball artifacts. some findings after reading your PKGBUILDS, can you please take a look and process the following feedback: ags - upstream Makefile doesn't seem to respect CPPFLAGS try to either get a patch upstream or if that fails extend CFLAGS with CPPFLAGS in the PKGBUILD. creeper-world - upstream source/url provides a https endpoint - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - don't think pkgdesc should ever end with a dot creeper-world2 - upstream source/url provides a https endpoint - don't think pkgdesc should ever end with a dot - unzip to prepare the env is more of a prepare() candidate creeper-world3 - upstream source/url provides a https endpoint - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well csound-blue - please don't use the AUR to store a tar.gz as a source - provides/conflicts on itself doesn't do anything useful - is there a reason for not stripping? - this looks like a -bin package as you are re-distributing pre-compiled files, why not just build from source instead? :) gam - don't think pkgdesc should ever end with a dot - there is some unused client_secrets.patch sitting around in the source repo - python2-oauth2client dependency is missing - this package create cluttering files across the filesystem if you run gam as root, it will have untracked pyc files in /usr/share/gam/ you need to compile them if no distutils is provided gnome-xcf-thumbnailer - prepare() shall never package into $pkgdir gtk-theme-adwaita-tweaks - don't think pkgdesc should ever end with a dot gtk-theme-adwaita-tweaks-git - lack of provides/conflicts - should pull via git+https:// - don't think pkgdesc should ever end with a dot - git makedepends is missing - the dark variant isn't published as "Adwaita Tweaks Dark" i don't think this works compared to the non git variant, it should honor the assets-dark folders and mimic what the release tarballs provide gtk-theme-minwaita - don't think pkgdesc should ever end with a dot hib-dlagent - none-url.patch is not a very unique name for a remote soruce, it could potentially clash, prepend with $pkgname can help imv-git - lack of provides imv i3lock-media-keys - don't think pkgdesc should ever end with a dot interception-ctrl2esc-git - don't think pkgdesc should ever end with a dot - git makedepends is missing - provides/conflicts not proper - is there a reason to have interception- prefix? imo ctrl2esc-git would be the better naming here plus provides/conflicts on ctrl2esc - you should use CMAKE_INSTALL_PREFIX=/usr and DESTDIR for $pkgdir invada-studio-plugins-lv2 - don't think pkgdesc should ever end with a dot lazy-ips-git - don't think pkgdesc should ever end with a dot - git makedepends is missing - you can't reference the PKGBUILD like in prepare(), try building in a clean chroot via extra-x86_64-build - lack of provides/conflicts linkchecker - don't think pkgdesc should ever end with a dot minecraft-technic-launcher - don't think pkgdesc should ever end with a dot nexuiz - don't think pkgdesc should ever end with a dot - upstream source/url both provides a https endpoint - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well - extracting and patching should be done in prepare() - please don't use the AUR to store a tar.gz as a source, there is also an orphan bin-links.tar.gz file additionally to the used nex-icons.tar.gz checked into the AUR pam_encfs - doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure this is always applied for c/cpp pd-extended - non unique filename that only contains the $pkgname, must always be unique including the pkgver so avoid clashes - doesn't respect neither CFLAGS, CPPFLAGS, LDFLAGS please make sure this is always applied for c/cpp - orphan file makefile.am.patch in the
Re: [aur-general] TU Membership Application
On 10/26/18 08:44pm, Levente Polyak via aur-general wrote: can you please fix this and make your gpg key available somewhere? I've pushed 0F8E620A up. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
Hi Brett On 10/25/18 8:22 PM, David Runge wrote: > > P.S.: As you've just created a new pgp key pair for your address, please > make sure to upload the pubkey to the keyservers! > can you please fix this and make your gpg key available somewhere? signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Membership Application
On 10/25/18 10:22pm, Jelle van der Waa wrote: What kind of tasks/roles do you handle for LibreOffice in the infrastructure team? I've been working with the team for a few years now. I'd say the majority of my work would be converting the legacy, manually-configured environments to Saltstack states and de-dockerizing some stuff. I've also been helping out with overhauling monitoring/alerting since it was previously not functioning very well. A good overview can be seen in our monthly meeting minutes: https://pad.documentfoundation.org/p/infra Our git repos are private, unfortunately - more of a precaution than damning us for bad security practices. :) signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 10/25/18 at 08:26am, Brett Cornwall via aur-general wrote: > I am being sponsored by dvzrv. > > I've been working in the AUR since 2014 as 'Ainola'. I've had a few of my > packages adopted into [community], such as gnome-mpv, csound, and qutecsound > (the latter two being adopted by dvzrv). > > I am also an active contributor to the LibreOffice infrastructure team. What kind of tasks/roles do you handle for LibreOffice in the infrastructure team? > I would like to get valuable tools promoted into [community], such as > residualvm or the 'pass' plasmoid (after prodding upstream to have a formal > release). Other packages that I do not maintain in the AUR would be ripe for > picking as well, such as sc-controller or ttf-lato. I would also work with > dvzrv on maintaining pro-audio packages, many of which were abandoned when > SpepS left. I always like it when applicants want to improve/work on orphan/neglected packages in the repos! Couldn't find much issues in your packages! -- Jelle van der Waa signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 2018-10-25 08:26:11 (-0600), Brett Cornwall via aur-general wrote: > I am being sponsored by dvzrv. I hereby ACK that and apologize for the confusion the last time (again). > I would like to get valuable tools promoted into [community], such as > residualvm or the 'pass' plasmoid (after prodding upstream to have a formal > release). Other packages that I do not maintain in the AUR would be ripe for > picking as well, such as sc-controller or ttf-lato. I would also work with > dvzrv on maintaining pro-audio packages, many of which were abandoned when > SpepS left. That would be very awesome! The best of luck to you and let the discussion begin! This seems to be a good month for TU applications. Best, David P.S.: As you've just created a new pgp key pair for your address, please make sure to upload the pubkey to the keyservers! -- https://sleepmap.de signature.asc Description: PGP signature
[aur-general] TU Membership Application
I am being sponsored by dvzrv. I've been working in the AUR since 2014 as 'Ainola'. I've had a few of my packages adopted into [community], such as gnome-mpv, csound, and qutecsound (the latter two being adopted by dvzrv). I am also an active contributor to the LibreOffice infrastructure team. I would like to get valuable tools promoted into [community], such as residualvm or the 'pass' plasmoid (after prodding upstream to have a formal release). Other packages that I do not maintain in the AUR would be ripe for picking as well, such as sc-controller or ttf-lato. I would also work with dvzrv on maintaining pro-audio packages, many of which were abandoned when SpepS left. signature.asc Description: PGP signature
