Re: [aur-general] Trusted user application: Drew DeVault
On Wed, 6 Mar 2019 at 18:04, Brett Cornwall via aur-general
wrote:
> I feel that by conflating applicant vetting with political correctness
> you're letting your own political viewpoints get in the way of a proper
> applicant screening. Some of the criteria of a TU involve interfacing
> with the community; What users will think of Arch. How is it 'political
> correctness' to judge fitness of a position based on past behavior?
It is, when the focus of judgement lingers disproportionately on
something that happened years ago and which was smaller than small
potatoes. Additionally, your initial comment "I am also not in any
sort of witch hunt, just thought this would be relevant" is an awful
politically correct adaptation of the "I'm not a racist, but" excuse.
> I agree that he held himself well during the application process... but
> anyone that's been in a hiring position can tell you that applicants can
> be very good at hiding their faults when in a position of scrutiny.
> That's the process, after all: Applicants dress themselves up and the
> hiring staff look for the cracks.
This weak analogy, which presumes all applicants are guilty until
proven innocent, cuts both ways; if you extend it further then when
those applicants become hiring staff themselves, they unleash their
hitherto well-hidden faults and lash out upon new applicants. Wait,
what?
> The TUs with questionable behavior are being discussed at this very
> moment - how can you suggest that DeVault was given unfair treatment?
Unfair is when you're getting a laptop for free and make a big deal
about a scratch on the lid.
> Just because a developer is well-known doesn't mean that they're fit for
> every role.
I pointed out a repeat pattern of behaviour with regard to TU
applications. And if a couple of a- or f-words over the years weigh
more than one's technical prowess and intent of being a good TU, then
you should reconsider your criteria.
> Please provide examples of bullying and slander towards the applicant
> during the TU process.
I wasn't only referring to this applicant: see
https://lists.archlinux.org/pipermail/aur-general/2018-October/thread.html
The mere fact that Lukas Fleischer had to step in on behalf of the
Arch team and acknowledge the problem[0], should tell everyone
something. I thought it to be the best possible conclusion.
The problem is that his closing words ("We will work it out
internally. People make mistakes. We learn from it, try to improve and
move on.") apparently meant nothing to some people.
> As a recent TU addition, I felt that my "inquisitors" treated me quite well
> during the process.
Well, you have to admit that you had got way less surface of exposure
than DeVault for "the hiring staff to look for cracks".
[0] https://lists.archlinux.org/pipermail/aur-general/2018-October/034488.html
--
X
https://aur.archlinux.org/packages/?SeB=m=nous
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-03-06 17:27, Christos Nouskas wrote: This thread has started giving political correctness the bad name it deserves. Not so long ago another applicant had to go through a humiliating interrogation, strong words and insults included, and not many apologies were issued by his accusers; now some others are demanding (politically correctly, thankyouverymuch) from Drew DeVault to act as others before him haven't. Drew DeVault handled all that pressure with overly due composure and high professionalism, a strong token of his ethos, rarely found in some of his impeccable inquisitors, which obviously wasn't enough because they kept coming back for more. Even his sponsoring TUs had a hard time defending such an apparent felon. Next time, demand a copy of the applicant's juvenile criminal record, a signed forgiveness from the Vatican and a sworn statement of adherence to The Rules. Oh, and ten hand-written pages of "I shall be a good boy", because nobody wants to work with a degenerate like https://gfycat.com/ambitiousfluidkrill This whole "TU application" procedure has proven itself flawed because it allows anybody, in full impunity and immunity, to slander, bully and abuse applicants, to the point of making them regret they had applied in the first place. I feel that by conflating applicant vetting with political correctness you're letting your own political viewpoints get in the way of a proper applicant screening. Some of the criteria of a TU involve interfacing with the community; What users will think of Arch. How is it 'political correctness' to judge fitness of a position based on past behavior? I agree that he held himself well during the application process... but anyone that's been in a hiring position can tell you that applicants can be very good at hiding their faults when in a position of scrutiny. That's the process, after all: Applicants dress themselves up and the hiring staff look for the cracks. The TUs with questionable behavior are being discussed at this very moment - how can you suggest that DeVault was given unfair treatment? Just because a developer is well-known doesn't mean that they're fit for every role. Please provide examples of bullying and slander towards the applicant during the TU process. Addressing each instance would be helpful in dissecting the issue. As a recent TU addition, I felt that my "inquisitors" treated me quite well during the process. signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
I had the following sitting in my drafts and, after seeing Mr DeVault's TU application withdrawal, regretted not having sent it. Edited to refer to the unfortunate conclusion. On Wed, Feb 27, 2019, 16:10 Darren Wu via aur-general < aur-general@archlinux.org> wrote: > > Instead I'd like to ask this: if I'm to be damned by my past behaviors, > is there a path to redemption? As a complete newbie I might not have the rights to chime in here. > > But isn't it never too late if Mr. DeVault may add an apologetic comment to > @noobpurple under https://github.com/swaywm/sway/issues/1227 now? > This thread has started giving political correctness the bad name it deserves. Not so long ago another applicant had to go through a humiliating interrogation, strong words and insults included, and not many apologies were issued by his accusers; now some others are demanding (politically correctly, thankyouverymuch) from Drew DeVault to act as others before him haven't. Drew DeVault handled all that pressure with overly due composure and high professionalism, a strong token of his ethos, rarely found in some of his impeccable inquisitors, which obviously wasn't enough because they kept coming back for more. Even his sponsoring TUs had a hard time defending such an apparent felon. Next time, demand a copy of the applicant's juvenile criminal record, a signed forgiveness from the Vatican and a sworn statement of adherence to The Rules. Oh, and ten hand-written pages of "I shall be a good boy", because nobody wants to work with a degenerate like https://gfycat.com/ambitiousfluidkrill This whole "TU application" procedure has proven itself flawed because it allows anybody, in full impunity and immunity, to slander, bully and abuse applicants, to the point of making them regret they had applied in the first place.
Re: [aur-general] Trusted user application: Drew DeVault
Note: your email reminded me to commit to what I had been preparing to do for a while, but was not the reason I withdrew my TU application. On 2019-03-04 , Levente Polyak via aur-general wrote: > I wanted to poke you how things are going? Would love to see my review > being incorporated, it took quite a while to look everything up. > This applies to the first batch as well, not just the list you wanted to > look up later. For example python-sshpubkeys build issue, the FHS > changes and the unit tests from the first batch are not yet in AUR. I've been travelling since your email came in, and I'm away from my Arch workstation at the moment. I intend to finish working on your feedback when I get home next week.
Re: [aur-general] Trusted user application: Drew DeVault
Hey Drew, I wanted to poke you how things are going? Would love to see my review being incorporated, it took quite a while to look everything up. This applies to the first batch as well, not just the list you wanted to look up later. For example python-sshpubkeys build issue, the FHS changes and the unit tests from the first batch are not yet in AUR. cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 4:49 PM, Drew DeVault via aur-general wrote: > The AUR is not community. The expectations are higher for trusted users > - hence the trust. Naturally responding to emails, keeping up with new > releases, etc, is part of the role. That's why it's a *role* - it serves > to define the responsibilities. There is no role for AUR package > maintainer outside of a column in the database. There's no formal > process for becoming an AUR package maintainer, and Arch Linux > explicitly disavows AUR packages as having any standard of quality. You > can't have it both ways - either they're unsupported and maintaining > them as such isn't a problem, or they are supported and we have to > address that can of worms. > > And in my opinion, this represents the AUR working as intended. The low > barrier to entry encourages users who may be novices at packaging or > have limited time to invest in their package to give it a shot, then > other users to download these packages and improve the PKGBUILDs, > hopefully sending their improvements back to the maintainer. We already > stress that users need to read and evaluate AUR PKGBUILDs for > themselves. We should be proud that we have a community which encourages > every user to make packages and devote any amount of time they can to > supporting them. In short, part of the AUR's value proposition is its > fast-and-loose criteria for inclusion and maintenance. > > The purpose of community and the trusted user system, as far as I > understand, is to provide binary packages from the community that meet a > baseline of quality - wholey different from the AUR. Any packages I > bring on from the AUR will first be improved to meet these standards, > and I commit to a higher degree of responsibility in their maintenance. > I also naturally recognize the value in improving my AUR packages and > intend to do so over time, but I feel that an approach which is > non-committal and less urgent is appropriate here. > > I understand the utility in having a history of good AUR packages in > evaluating someone's potential as a trusted user. To this end I'm > happily incorporating your feedback into improving my AUR packages. I > also encourage you to review my history of contributions to Alpine > Linux, where I am the maintainer of a number of binary packages and have > established a history of quality packages, fast updates, and engagement > with the community. > > I feel that this thread has devolved considerably into this rabbit hole, > even to the point of ad hominem in some replies. I hope that this has > explained my opinion more clearly and responded to the criticism. If you > still disagree, I think at this point it should just influence your vote > rather than continue the argument. > With all the following I'm speaking in general and don't explicitly try to discredit your examples and facts of maintainership but to show why it matters. The problem here is that the initial trust for someone to be classified as a trusted user does not magically come from the amount of non backed claims of doing everything differently and properly once its about official packages, trust comes from facts and examples. In general its also lot more meaningful or obvious to make a judgement about things in the domain of Arch instead of other distros where the insights are less obvious, which doesn't mean its not a bonus. An ideal trusted user, who is also responsible for the AUR as a platform, should lead the community by example in terms of behavior and packaging quality. If even our official members don't care because its "just wild west" then how and why should it ever improve? Or let's make it more dramatic: If the AUR itself should be considered void then a bunch of garbage packages in the AUR plus the claim "but if I'm elected I will only do super high quality shizzle" shall be enough to make a judgement to _trust_ someone doing the right thing? I'm not saying there is no difference in the official repositories and the AUR, there is! But TUs are responsible to operate the AUR platform and its really a non nice example for others if even the official's of that platform just do it for nothing but "personal pride". We are not talking about random AUR maintainers, but about someone who wants to be considered a trusted entity of the community and hence it matters to lead by example. cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
The AUR is not community. The expectations are higher for trusted users - hence the trust. Naturally responding to emails, keeping up with new releases, etc, is part of the role. That's why it's a *role* - it serves to define the responsibilities. There is no role for AUR package maintainer outside of a column in the database. There's no formal process for becoming an AUR package maintainer, and Arch Linux explicitly disavows AUR packages as having any standard of quality. You can't have it both ways - either they're unsupported and maintaining them as such isn't a problem, or they are supported and we have to address that can of worms. And in my opinion, this represents the AUR working as intended. The low barrier to entry encourages users who may be novices at packaging or have limited time to invest in their package to give it a shot, then other users to download these packages and improve the PKGBUILDs, hopefully sending their improvements back to the maintainer. We already stress that users need to read and evaluate AUR PKGBUILDs for themselves. We should be proud that we have a community which encourages every user to make packages and devote any amount of time they can to supporting them. In short, part of the AUR's value proposition is its fast-and-loose criteria for inclusion and maintenance. The purpose of community and the trusted user system, as far as I understand, is to provide binary packages from the community that meet a baseline of quality - wholey different from the AUR. Any packages I bring on from the AUR will first be improved to meet these standards, and I commit to a higher degree of responsibility in their maintenance. I also naturally recognize the value in improving my AUR packages and intend to do so over time, but I feel that an approach which is non-committal and less urgent is appropriate here. I understand the utility in having a history of good AUR packages in evaluating someone's potential as a trusted user. To this end I'm happily incorporating your feedback into improving my AUR packages. I also encourage you to review my history of contributions to Alpine Linux, where I am the maintainer of a number of binary packages and have established a history of quality packages, fast updates, and engagement with the community. I feel that this thread has devolved considerably into this rabbit hole, even to the point of ad hominem in some replies. I hope that this has explained my opinion more clearly and responded to the criticism. If you still disagree, I think at this point it should just influence your vote rather than continue the argument.
Re: [aur-general] Trusted user application: Drew DeVault
On Thu, Feb 28, 2019 at 02:58:06PM +0100, Jerome Leclanche wrote: > No, it is not, and please don't expect this of volunteers. Right, I don't expect that from AUR volunteers, but that doesn't mean the AUR shouldn't be taken seriously. If the maitainer has not interest in updating and seeking out the latest versions of his packages, then the maintainer should just abandon them. > The responsibility goes as far as security (being made aware ASAP of > security issues in packages), but knowing in general when a release > happens is not (and/or shouldn't be) the TU's responsibility. Knowing when a release happens shouldn't be the TU's responsibility but making sure that the packages that the TU maintains are relatively up to date should. > If this sounds pointed, that's because I'm not amused by this idea > that anyone who puts a package on the AUR should be at the service of > those who download it. That's not what I was trying to say, please forgive my wording skills. Not taking package maintainership seriously when becomming a TU is probably not the best sign of interest. TU's are expected to produce high quality PKGBUILDs and keep them updated. (They are trusted after all) J. Miegl
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 3:43 PM, Jerome Leclanche wrote: > On Thu, Feb 28, 2019 at 3:36 PM Levente Polyak via aur-general > wrote: >> >> On 2/28/19 3:33 PM, Jerome Leclanche wrote: >>> >>> We have TUs with hundreds of packages. Beyond automatic checks, do you >>> really expect they keep up with every single release? >>> I've myself updated several packages that were out of date (and >>> unflagged) in [community]. I'm not saying the attitude *should* be "I >>> don't give a damn", but in practice, I don't believe this expectation >>> you mention is in place (and moreover, I reiterate that I do not think >>> there should be such an expectation when it can very efficiently be >>> offloaded to scripts and users). >>> >>> J. Leclanche >>> >> >> Indeed I am, there are tools like urlwatch, nvchecker and other to >> easily get diffs of what changed and those are in the responsibility of >> the maintainer to be aware of until our automatic system spec is not >> finished and finalized. >> >> TL;DR: yes, i do. >> >> sincerely, >> Levente > > Those are "automatic checks". I'm not sure what you're getting at. If > they fail for whatever reason, your packages will still be out of > date; I highly doubt you also manually keep up with all of them. > > J. Leclanche > Thats exactly what i meant by why the system to manually flag it is useful, even if we have a centralized solution to flag packages automatically. Then lets phrase it with your working, yes "automatic checks" are the responsibility of the maintainer, which in no way makes the manual crowdsourced system non-useful as previously already stated. Levente
Re: [aur-general] Trusted user application: Drew DeVault
On Thu, Feb 28, 2019 at 3:36 PM Levente Polyak via aur-general wrote: > > On 2/28/19 3:33 PM, Jerome Leclanche wrote: > > > > We have TUs with hundreds of packages. Beyond automatic checks, do you > > really expect they keep up with every single release? > > I've myself updated several packages that were out of date (and > > unflagged) in [community]. I'm not saying the attitude *should* be "I > > don't give a damn", but in practice, I don't believe this expectation > > you mention is in place (and moreover, I reiterate that I do not think > > there should be such an expectation when it can very efficiently be > > offloaded to scripts and users). > > > > J. Leclanche > > > > Indeed I am, there are tools like urlwatch, nvchecker and other to > easily get diffs of what changed and those are in the responsibility of > the maintainer to be aware of until our automatic system spec is not > finished and finalized. > > TL;DR: yes, i do. > > sincerely, > Levente Those are "automatic checks". I'm not sure what you're getting at. If they fail for whatever reason, your packages will still be out of date; I highly doubt you also manually keep up with all of them. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 3:33 PM, Jerome Leclanche wrote: > > We have TUs with hundreds of packages. Beyond automatic checks, do you > really expect they keep up with every single release? > I've myself updated several packages that were out of date (and > unflagged) in [community]. I'm not saying the attitude *should* be "I > don't give a damn", but in practice, I don't believe this expectation > you mention is in place (and moreover, I reiterate that I do not think > there should be such an expectation when it can very efficiently be > offloaded to scripts and users). > > J. Leclanche > Indeed I am, there are tools like urlwatch, nvchecker and other to easily get diffs of what changed and those are in the responsibility of the maintainer to be aware of until our automatic system spec is not finished and finalized. TL;DR: yes, i do. sincerely, Levente
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 9:26 AM, Levente Polyak via aur-general wrote: > On 2/28/19 2:58 PM, Jerome Leclanche wrote: >> On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl wrote: >>> Although I don't have high expectations when dealing with AUR packages, it >>> is absolutely the maintainers job to keep track of upstream updates. This >>> mindset is probably the reason why there is so much out of date stuff on >>> the AUR. It strikes me that a maintainer who doesn't keep track of his own >>> packages wants to become a TU. >> >> No, it is not, and please don't expect this of volunteers. The >> responsibility goes as far as security (being made aware ASAP of >> security issues in packages), but knowing in general when a release >> happens is not (and/or shouldn't be) the TU's responsibility. >> Most TUs do know when a release happens in at least a portion of their >> packages, by nature of often maintaining packages they have some >> working relationship with. But the flagging system is very useful in >> crowdsourcing the non-security-sensitive portion of package >> maintenance. > > > I very strongly disagree on this, nobody forces a volunteer to > _maintain_ a certain package, but If it is chosen by choice then keeping > it up to date is a responsibility as well. > As long as we do not have an automatic system in place it is one of the > responsibilities to track it as good as possible! > This doesn't make the out-of-date flag system non-useful, even when we > would have our automatic flagging system in place, as it could slip > through the radar or tracking like upstream may change the location for > future releases. > I frankly don't like the habit of "i don't give a darn to track, someone > will flag it", this is bad practice, and the best we could agree on is > that we strongly disagree. This is indeed the ideal. Of course even with the flagging system, 412 / 10691 packages are marked out of date. It is true that over half of these were flagged within the past month. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On Thu, Feb 28, 2019 at 3:26 PM Levente Polyak via aur-general wrote: > > On 2/28/19 2:58 PM, Jerome Leclanche wrote: > > On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl wrote: > >> Although I don't have high expectations when dealing with AUR packages, it > >> is absolutely the maintainers job to keep track of upstream updates. This > >> mindset is probably the reason why there is so much out of date stuff on > >> the AUR. It strikes me that a maintainer who doesn't keep track of his own > >> packages wants to become a TU. > > > > No, it is not, and please don't expect this of volunteers. The > > responsibility goes as far as security (being made aware ASAP of > > security issues in packages), but knowing in general when a release > > happens is not (and/or shouldn't be) the TU's responsibility. > > Most TUs do know when a release happens in at least a portion of their > > packages, by nature of often maintaining packages they have some > > working relationship with. But the flagging system is very useful in > > crowdsourcing the non-security-sensitive portion of package > > maintenance. > > > I very strongly disagree on this, nobody forces a volunteer to > _maintain_ a certain package, but If it is chosen by choice then keeping > it up to date is a responsibility as well. > As long as we do not have an automatic system in place it is one of the > responsibilities to track it as good as possible! > This doesn't make the out-of-date flag system non-useful, even when we > would have our automatic flagging system in place, as it could slip > through the radar or tracking like upstream may change the location for > future releases. > I frankly don't like the habit of "i don't give a darn to track, someone > will flag it", this is bad practice, and the best we could agree on is > that we strongly disagree. > > sincerely, > Levente > We have TUs with hundreds of packages. Beyond automatic checks, do you really expect they keep up with every single release? I've myself updated several packages that were out of date (and unflagged) in [community]. I'm not saying the attitude *should* be "I don't give a damn", but in practice, I don't believe this expectation you mention is in place (and moreover, I reiterate that I do not think there should be such an expectation when it can very efficiently be offloaded to scripts and users). J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 8:58 AM, Jerome Leclanche wrote: > On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl wrote: >> Although I don't have high expectations when dealing with AUR packages, it >> is absolutely the maintainers job to keep track of upstream updates. This >> mindset is probably the reason why there is so much out of date stuff on the >> AUR. It strikes me that a maintainer who doesn't keep track of his own >> packages wants to become a TU. > > No, it is not, and please don't expect this of volunteers. The > responsibility goes as far as security (being made aware ASAP of > security issues in packages), but knowing in general when a release > happens is not (and/or shouldn't be) the TU's responsibility. > Most TUs do know when a release happens in at least a portion of their > packages, by nature of often maintaining packages they have some > working relationship with. But the flagging system is very useful in > crowdsourcing the non-security-sensitive portion of package > maintenance. > > As for being frustrated with the OOD packages on the AUR, I encourage > you to make use of the flagging system yourself. It's present there as > well. And if you think you can do better than the package's > maintainer, ask to co-maintain it, or adopt it if it's abandoned. And > in the mean time, you get to be able to download the PKGBUILD and > modify it to your liking, that's the whole point of that system. > If this sounds pointed, that's because I'm not amused by this idea > that anyone who puts a package on the AUR should be at the service of > those who download it. Arch philosophy goes above and beyond to drive > in people's heads that the AUR is unsupported, to the point of > rejecting any AUR helper in official packages. Expectations should be > set accordingly. I'm less concerned about people who don't keep track of OOD packages in the AUR, and more concerned about: "I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers." This would be because I, um, respectfully disagree and believe that the memetic lack of quality in the AUR is something to be overcome by a community working together, not something to brag about. It is generally assumed that someone maintains a package because they care about it at least somewhat. An out od date package in the official repos *or* in the AUR, probably at least still works, right? -ENOTENOUGHTIME is an understandable issue to have. Quality of the package is a different story, though, and it likewise (IMO) applies in all cases. - Do we actually *want* people to say "I don't dare trust AUR packages to even build correctly without personal scrutiny"? - One of the purposes of the AUR is to serve as an initial testing ground so good, popular packages can be elevated to community. It's depressing when in order to move nice software to community, the AUR PKGBUILD needs to be thrown in the dumpster and rewritten from scratch. It is, contrarily, pleasant when the PKGBUILD is well-written and can be copied to community intact (with #Contributor lines etc.). Moreover, TUs are meant to be an example to the community: what does it say if a TU candidate has packages that are a bad example, not because they are a constantly-improving work in progress and one or two mistakes were made across most packages, but because: "I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos." This feels like totally the wrong attitude to approach anything. It reads as though the limited amount of time has resulted in a belief that "I feel proud if my packages are quality, but if they're not, I won't try to make them better without being bugged by someone else, because I have better things to do with my time". Disclaimer: when I initially mentioned I generally admire Drew's open-source work, this did not take into account his AUR packaging standards, as I had not looked at any of them. I can 100% see why people are looking at this and wondering if maybe his impressive work elsewhere in the Linux community is only impressive elsewhere, where he feels his time is a worthwhile investment. I'm sure most if not all Devs and TUs can tell similar stories about being overworked. I would hope that we all still invested in devoting at least some of that time to improving our packages even when they're not official repo candidates. After all, packaging, and being a good example of it, is ostensibly one of the jobs of a TU. There is a reason the job description includes "people who oversee the AUR". > On Thu, Feb 28, 2019 at 2:16 PM alad via aur-general > wrote: >> Generally, while expectations are naturally not as high as with >> community packages, lacking quality of PKGBUILDs in AUR remains >> problematic when
Re: [aur-general] Trusted user application: Drew DeVault
On 2/28/19 2:58 PM, Jerome Leclanche wrote: > On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl wrote: >> Although I don't have high expectations when dealing with AUR packages, it >> is absolutely the maintainers job to keep track of upstream updates. This >> mindset is probably the reason why there is so much out of date stuff on the >> AUR. It strikes me that a maintainer who doesn't keep track of his own >> packages wants to become a TU. > > No, it is not, and please don't expect this of volunteers. The > responsibility goes as far as security (being made aware ASAP of > security issues in packages), but knowing in general when a release > happens is not (and/or shouldn't be) the TU's responsibility. > Most TUs do know when a release happens in at least a portion of their > packages, by nature of often maintaining packages they have some > working relationship with. But the flagging system is very useful in > crowdsourcing the non-security-sensitive portion of package > maintenance. I very strongly disagree on this, nobody forces a volunteer to _maintain_ a certain package, but If it is chosen by choice then keeping it up to date is a responsibility as well. As long as we do not have an automatic system in place it is one of the responsibilities to track it as good as possible! This doesn't make the out-of-date flag system non-useful, even when we would have our automatic flagging system in place, as it could slip through the radar or tracking like upstream may change the location for future releases. I frankly don't like the habit of "i don't give a darn to track, someone will flag it", this is bad practice, and the best we could agree on is that we strongly disagree. sincerely, Levente signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On Thu, Feb 28, 2019 at 12:51 PM Josef Miegl wrote: > Although I don't have high expectations when dealing with AUR packages, it is > absolutely the maintainers job to keep track of upstream updates. This > mindset is probably the reason why there is so much out of date stuff on the > AUR. It strikes me that a maintainer who doesn't keep track of his own > packages wants to become a TU. No, it is not, and please don't expect this of volunteers. The responsibility goes as far as security (being made aware ASAP of security issues in packages), but knowing in general when a release happens is not (and/or shouldn't be) the TU's responsibility. Most TUs do know when a release happens in at least a portion of their packages, by nature of often maintaining packages they have some working relationship with. But the flagging system is very useful in crowdsourcing the non-security-sensitive portion of package maintenance. As for being frustrated with the OOD packages on the AUR, I encourage you to make use of the flagging system yourself. It's present there as well. And if you think you can do better than the package's maintainer, ask to co-maintain it, or adopt it if it's abandoned. And in the mean time, you get to be able to download the PKGBUILD and modify it to your liking, that's the whole point of that system. If this sounds pointed, that's because I'm not amused by this idea that anyone who puts a package on the AUR should be at the service of those who download it. Arch philosophy goes above and beyond to drive in people's heads that the AUR is unsupported, to the point of rejecting any AUR helper in official packages. Expectations should be set accordingly. On Thu, Feb 28, 2019 at 2:16 PM alad via aur-general wrote: > Generally, while expectations are naturally not as high as with > community packages, lacking quality of PKGBUILDs in AUR remains > problematic when trying to promote AUR packages to community. Due to > this, a complete rewrite of the PKGBUILD is usually required, rather > than making some minor adjustments. > > https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html OT: We should maybe have the AUR lint PKGBUILDs on git push (and reject really bad ones) if we want to improve that situation. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
Am 28.02.2019 um 04:25 schrieb Drew DeVault via aur-general: On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote: For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community. Well, to be honest its the maintainers responsibility to keep track of upstream and not outsource out of date flagging to someone else. There is no difference between [community] and AUR for something that is a maintainer responsibility. I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers. I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos. Considering there's a wiki page on what packages should be submitted and which not, there's definitely *some* expectation of quality... The way you put it, there'd be no point in TUs taking AUR requests or addressing emails, and we'd all be out of a job. https://wiki.archlinux.org/index.php/Arch_User_Repository#Rules_of_submission Generally, while expectations are naturally not as high as with community packages, lacking quality of PKGBUILDs in AUR remains problematic when trying to promote AUR packages to community. Due to this, a complete rewrite of the PKGBUILD is usually required, rather than making some minor adjustments. https://lists.archlinux.org/pipermail/aur-general/2016-October/032845.html
Re: [aur-general] Trusted user application: Drew DeVault
> From: Drew DeVault via aur-general > Sent: Thu Feb 28 04:25:10 CET 2019 > To: Discussion about the Arch User Repository (AUR) > > Cc: Drew DeVault > Subject: Re: [aur-general] Trusted user application: Drew DeVault > > > On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote: > > > For the AUR I don't keep up with upstream releases, I just wait for > > > someone to mark the package as outdated. For Alpine Linux I use a > > > combination of subscribing to the upstream -announce mailing list and > > > subscribing to GitHub releases as appropriate; would do something > > > similar for Arch Linux community. > > > > Well, to be honest its the maintainers responsibility to keep track of > > upstream and not outsource out of date flagging to someone else. There > > is no difference between [community] and AUR for something that is a > > maintainer responsibility. > > I respectfully disagree. The barrier to entry for the AUR is almost > nonexistent and there's no expectation of support or quality - from Arch > Linux or from the maintainers. I take some degree of personal pride in > having nice AUR packages, but I also have a limited amount of time. Of > course, I take my responsibility as maintainer much more seriously when > working with packages in official repos. > >From TU candidates there is very high expectation of support and quality and >AUR is the place where they can prove it. If the lack of time is a problem then it will still be a problem after promotion. Saying that you will treat your maintainer work seriously only after you get promoted doesn't earn you much trust. Yours sincerely G. K.
Re: [aur-general] Trusted user application: Drew DeVault
Hello Drew, I am a fan of your work on Sway and wlroots, but some of your statements left me pretty disappointed. >For the AUR I don't keep up with upstream releases, I just wait for >someone to mark the package as outdated. For Alpine Linux I use a >combination of subscribing to the upstream -announce mailing list and >subscribing to GitHub releases as appropriate; would do something >similar for Arch Linux community. Although I don't have high expectations when dealing with AUR packages, it is absolutely the maintainers job to keep track of upstream updates. This mindset is probably the reason why there is so much out of date stuff on the AUR. It strikes me that a maintainer who doesn't keep track of his own packages wants to become a TU. J. Miegl
Re: [aur-general] Trusted user application: Drew DeVault
On February 27, 2019 10:47:59 PM EST, Drew DeVault via aur-general wrote: >On 2019-02-27 10:42 PM, Eli Schwartz via aur-general wrote: >> I guess the difference between PyPI and Github sources could be >> clarified, but really I'd much rather upstreams would get in the >habit >> of using a MANIFEST.in which ensured the license and testsuite was >> correctly included in the source dist. > >This is the main bit that I feel can be clarified. The wiki page today >is written like there's One True Way to specify sources=() for a Python >package, and that way has some serious defects (lack of tests, license >file, etc) - to the point where if you can get the package another way, >you probably should. All the upstreams for my Python packages have agreed to merge these additions, though there were those that took a bit of convincing. I still have to use non-PyPI sources for some as they haven't yet made new releases, don't manage their own PyPI pages (and one could wait indefinitely for the release), or use PGP signing. Apparently there's a way to sign PyPI packages, but I haven't really looked into that yet. -- Best, polyzen
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-27 10:42 PM, Eli Schwartz via aur-general wrote: > I guess the difference between PyPI and Github sources could be > clarified, but really I'd much rather upstreams would get in the habit > of using a MANIFEST.in which ensured the license and testsuite was > correctly included in the source dist. This is the main bit that I feel can be clarified. The wiki page today is written like there's One True Way to specify sources=() for a Python package, and that way has some serious defects (lack of tests, license file, etc) - to the point where if you can get the package another way, you probably should.
Re: [aur-general] Trusted user application: Drew DeVault
On 2/27/19 10:25 PM, Drew DeVault via aur-general wrote: > Aye, this is first I've heard of namcap. Is there a reason that this > isn't included with makepkg by default? It brings a hard dependency on python, and its output is often useful but also often not -- for example when it tries to calculate "needed dependencies", it will more or less accurately tell you what you need for shared library linkage, then tell you that all other dependencies are "unnecessary" (this does not work out remotely well for any python software). However, devtools does utilize namcap as an optional post-build step in makechrootpkg, and enforces it when using the extra-x86_64 build wrapper (so you will always see namcap warnings when building official repository packages). There are also thoughts about reimplementing it as libmakepkg extensions. > I updated several of the packages you mentioned to address your > feedback, and ran namcap on them. Can you take another look when you > have time? > > Regarding your Python feedback in particular, I appreciate the tips - I > have a lot of Python packages I need to make but have found resources > for making Arch Linux packages for Python software to be somewhat > lacking. I put a note on my todo list to take the feedback on these AUR > packages and summarize them for the Arch Wiki. > > https://wiki.archlinux.org/index.php/Python_package_guidelines It can often be difficult to know from an inside perspective, what needs to be documented -- I thought that that Python page was pretty decent though. It definitely mentions the setuptools bit. I guess the difference between PyPI and Github sources could be clarified, but really I'd much rather upstreams would get in the habit of using a MANIFEST.in which ensured the license and testsuite was correctly included in the source dist. Maybe it would help to add a section on how to parse dependencies from a setup.py or requirements.txt? > It may be abandoned but I actually do remember why I need this package - > and I still do. The test suite runs on Python 3 but you have to jump > through some hoops - setup.py runs the whole codebase through 2to3 > before installing. Jumped through said hoops and updated the package. Ancient software written back when people thought 2to3 was a good idea is the bane of us all. :D -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-28 2:22 AM, Levente Polyak via aur-general wrote: > > For the AUR I don't keep up with upstream releases, I just wait for > > someone to mark the package as outdated. For Alpine Linux I use a > > combination of subscribing to the upstream -announce mailing list and > > subscribing to GitHub releases as appropriate; would do something > > similar for Arch Linux community. > > Well, to be honest its the maintainers responsibility to keep track of > upstream and not outsource out of date flagging to someone else. There > is no difference between [community] and AUR for something that is a > maintainer responsibility. I respectfully disagree. The barrier to entry for the AUR is almost nonexistent and there's no expectation of support or quality - from Arch Linux or from the maintainers. I take some degree of personal pride in having nice AUR packages, but I also have a limited amount of time. Of course, I take my responsibility as maintainer much more seriously when working with packages in official repos. > Really no offense, but I really had high expectations and got very > surprised: At some point I started wondering if you read error and log > output while trying to package or run tests? > Some of this findings indicates you don't (when you change some stuff) > or at least stop any investigation if f.e. a test suite doesn't run > straight. I would like to see more investigative behavior of a > maintainer in getting things sorted out the correct way instead of just > abandon if it requires a bit of patience and thinking plus time. > > Also i encountered some examples of non working pkg build of very recent > changes that make me think changes are pushed straight to the AUR before > any build/test ever happened. > > If there is stuff to rule out and you need ideas and another pair of > eyes, just ask for it... that's what a team and a community should be > for, nobody knows everything. > Also some of the packages don't work as they are not python 3.7 > compatible at all so i wonder if anyone uses them a all? Hmm, sorry to disappoint. I definitely built and did at least a basic sanity test on every package. I did update a whole bunch of packages at once, so it's possible I missed a few things... many of which I presume are the problems you pointed out. Also, note that I haven't yet taken the time to clean up my sr.ht-pkgbuilds packages, if you were reviewing those. Many of those are also adoptions from the AUR where I imported someone else's package so I could build a binary package - and left their PKGBUILD intact to make pulling down updates easier. Might rethink that policy. > Also i noticed you may maybe not know 'namcap' because of so many > missing licenses plus stuff like Non-FHS man page violations. Aye, this is first I've heard of namcap. Is there a reason that this isn't included with makepkg by default? I updated several of the packages you mentioned to address your feedback, and ran namcap on them. Can you take another look when you have time? Regarding your Python feedback in particular, I appreciate the tips - I have a lot of Python packages I need to make but have found resources for making Arch Linux packages for Python software to be somewhat lacking. I put a note on my todo list to take the feedback on these AUR packages and summarize them for the Arch Wiki. https://wiki.archlinux.org/index.php/Python_package_guidelines > patchrom mktiupgrade mkrom kpack genkfs > - Non-FHS man page in /usr/man/man1 I could fix this in the package, but this is an upstream bug, so I filed a ticket... on my own project. https://github.com/KnightOS/KnightOS/issues/381 > sass: > > - did you test building this package before pushing > an added LICENSE dist line 2 days ago? Because this > indicates something went wrong: > install: cannot stat 'LICENSE': No such file or directory > ==> ERROR: A failure occurred in package(). Ah, I had thought I did, but it seems I only tested scas. sass is legacy software, and scas is its replacement. I think I just got mixed up. > - do you use proper clean environments for building? asking because: > ==> ERROR: A failure occurred in build(). > ModuleNotFoundError: No module named 'setuptools'et > This packages requires setuptools makedepends > doesn't your CI or AUR testing use clean/isolated and non polluted > environments for building? My CI uses fresh build environments, but my AUR packages aren't built with it. Just finished setting up makechrootpkg so I can do this locally. > Btw: please use github sources, the pypi re-distribution doesn't > contain any tests in the first place Damn, I was really happy to have a consistent sources URL I could reuse for Python packages. > python-spam-blocklists: > nice indicator: Latest commit on Jun 15, 2012, this stuff is just > dead, nuke Agreed, and I don't even remember what I needed this for. Filed a deletion request. > python-pystache: > - there is a test runner using python
Re: [aur-general] Trusted user application: Drew DeVault
On 2/25/19 5:55 PM, Drew DeVault wrote: > Thanks for all the feedback! I went through and cleaned up all of my AUR > packages - something a wiser man would have done before submitting the > TU application. > You're welcome, but from me this was just the travel version... here comes the full unleashed feature set of xxarhtna For now reduced to python only and some random picks, If i find time I will take a look at the other packages as well. > >> Out of curiosity, what kind of upstream watch are you using to be made >> aware of new releases? > > For the AUR I don't keep up with upstream releases, I just wait for > someone to mark the package as outdated. For Alpine Linux I use a > combination of subscribing to the upstream -announce mailing list and > subscribing to GitHub releases as appropriate; would do something > similar for Arch Linux community. > Well, to be honest its the maintainers responsibility to keep track of upstream and not outsource out of date flagging to someone else. There is no difference between [community] and AUR for something that is a maintainer responsibility. Back to packages: Really no offense, but I really had high expectations and got very surprised: At some point I started wondering if you read error and log output while trying to package or run tests? Some of this findings indicates you don't (when you change some stuff) or at least stop any investigation if f.e. a test suite doesn't run straight. I would like to see more investigative behavior of a maintainer in getting things sorted out the correct way instead of just abandon if it requires a bit of patience and thinking plus time. Also i encountered some examples of non working pkg build of very recent changes that make me think changes are pushed straight to the AUR before any build/test ever happened. If there is stuff to rule out and you need ideas and another pair of eyes, just ask for it... that's what a team and a community should be for, nobody knows everything. Also some of the packages don't work as they are not python 3.7 compatible at all so i wonder if anyone uses them a all? Also i noticed you may maybe not know 'namcap' because of so many missing licenses plus stuff like Non-FHS man page violations. patchrom: - Non-FHS man page in /usr/man/man1 mktiupgrade: - Non-FHS man page in /usr/man/man1 mkrom: - Non-FHS man page in /usr/man/man1 kpack: - Non-FHS man page in /usr/man/man1 genkfs: - Non-FHS man page in /usr/man/man1 sass: - did you test building this package before pushing an added LICENSE dist line 2 days ago? Because this indicates something went wrong: install: cannot stat 'LICENSE': No such file or directory ==> ERROR: A failure occurred in package(). python-sshpubkeys: - what does the 1.0.5 do in the URL? :P - do you use proper clean environments for building? asking because: ==> ERROR: A failure occurred in build(). ModuleNotFoundError: No module named 'setuptools'et This packages requires setuptools makedepends doesn't your CI or AUR testing use clean/isolated and non polluted environments for building? - what does check() do, build the package? that should be 'test' instead of 'build' Btw: please use github sources, the pypi re-distribution doesn't contain any tests in the first place PS: to avoid setuptools download checkdepends it needs: cffi, asn1crypto, pycparser (take a look on log output) - this package doesn't provide LICENSE.txt as github contains, please use github sources and include it PS: do you use namcap on your packages to find some frequent mistakes? python-spam-blocklists: - what does the 0.9.3 do in the URL? - what does the comment mean about "only py2"? if you run the tests reality shows it just doesn't work at all: ModuleNotFoundError: No module named 'urlparse' sources show from urlparse import urlparse which can't be fulfilled anywhere nice indicator: Latest commit on Jun 15, 2012, this stuff is just dead, nuke python-pystache: - doesnt distribute the MIT license which exists in the sources - there is a test runner using python ./test_pystache.py which pretty much shows this is dead non working stuff as well: File "/build/python-pystache/src/pystache-0.5.4/pystache/parser.py", line 15 NON_BLANK_RE = re.compile(ur'^(.)', re.M) SyntaxError: invalid syntax Latest commit 17a5dfd on Sep 30, 2014 python-patreon: - license is wrong, if you look at upstream its apache2 - this projects depends on python-six to run - must depend on setuptools as makedepends instead of distribute as thats the correct module it requires - no tests run, by adding checkdepends for python-mock python-pytest python-pytest-cov you can easily run a check() via python setup.py test which successfully runs 52 passed in 0.82 seconds python-lark: - misses python-js2py depends - "# upstream tests fail due to path resolution errors" what exactly do you mean by that? If you investiate the files
Re: [aur-general] Trusted user application: Drew DeVault
Em fevereiro 27, 2019 10:53 Drew DeVault via aur-general escreveu: On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: I would also chip in with the following from early 2017: https://github.com/swaywm/sway/issues/1227 (I am also not in any sort of witch hunt, just thought this would be relevant.) It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for. Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet. I don't think that's needed, you have proven so far that you can handle criticism, which is a good indicative. As I said, I was just surprised. You never know, sometime you might get someone on a bad mood or something like that. I stand by what I said though, that everything should be taken into consideration. Including past behavior and present, which doesn't mean to focus on the bad stuff, or just wash it away with good stuff. After all, we're all a sum of all that, good or bad. I appreciate that your sponsors are also backing you up in this, not just technically. Thanks and I wish you luck. Regards, Giancarlo Razzolini pgp8FCZAVasBq.pgp Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Hey, let me just quickly thank all people who have participated in this thread thus far. I'm seeing a very polite, respectful and constructive discussion from all sides, which I very much enjoyed reading. On 27.02.19 08:53, Drew DeVault via aur-general wrote: > Instead I'd like to ask this: if I'm to be damned by my past behaviors, > is there a path to redemption? Is there any criteria we could establish > for demonstrating good behavior? Or, would I have to live with a forever > vague sense of unease among the voters? Not to say that the unease isn't > justified - it may in fact by the right answer to reject applications > based on that unease. If any concerned can think of more tangible > criteria, though, it would make it easier for me to dispell your > concerns or give me some personal development goals to meet. Personally I think that you have already shown in this thread, that you are capable of handling criticism and that you are willing to improve in areas where there are concerns. When I was a fresh TU I had some minor frictions with some of the long-term devs and TUs, which affected my mood and motivation. Fortunately, after talking to the people in question and expressing my displease, this situation improved very quickly and there were no hurt feelings. Just seeing that you are actively seeking out ways to improve your attitude and social behaviour seems like a very good sign to me. We are all human individuals and certainly not perfect. Communication is both cause and solution to most issues, thus we should always just try to be open to ideas, be respectful and polite to others and be willing to make compromises. Most of the time someone is not even aware that their phrasing might offend someone and just needs to made aware of that. I'm looking forward to further replies in this thread and you possibly being voted in. :) Cheers, Thore -- Thore Bödecker GPG ID: 0xD622431AF8DB80F3 GPG FP: 0F96 559D 3556 24FC 2226 A864 D622 431A F8DB 80F3 signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2/27/19 3:10 PM, Darren Wu via aur-general wrote: > As a complete newbie I might not have the rights to chime in here. As a member of the community, regardless of how long you've been around, you are absolutely entitled to post to threads on aur-general :) All we ask is everyone keeps things civil in nature ;) > > But isn't it never too late if Mr. DeVault may add an apologetic comment to > @noobpurple under https://github.com/swaywm/sway/issues/1227 now? > > Sincerely yours, > Darren Wu >I honestly think Necroposting on that GitHub issue would not be a good idea. In reading this thread so far it's clear to me that Drew just lost his temper, as we all sometimes do. By observing his efforts to explain, acknowledge (the first step towards correcting something undesirable in oneself), and take actions to adjust his behavior, I'd say I'm personally okay with his current demeanor. It goes without saying that there is an expectation amongst Dev's and TU's to be professional with user requests, bug reports, etc. I am of the opinion that if Drew decides to "turn" and revert back, then we as TU's address it then. However, until then, I think the behavior in the application should represent who he is now. Regards, Andrew > On Wed, Feb 27, 2019, 21:53 Drew DeVault via aur-general < > aur-general@archlinux.org> wrote: > >> On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: >>> I would also chip in with the following from early 2017: >>> >>> https://github.com/swaywm/sway/issues/1227 >>> >>> (I am also not in any sort of witch hunt, just thought this would be >>> relevant.) >> >> It should go without saying that I regret what I said here as well. I >> was going some stressful financial problems when those comments were >> written. Doesn't excuse anything, and I'm sure we could find examples >> of my jerkitude that I can't say the same for. >> >> Instead I'd like to ask this: if I'm to be damned by my past behaviors, >> is there a path to redemption? Is there any criteria we could establish >> for demonstrating good behavior? Or, would I have to live with a forever >> vague sense of unease among the voters? Not to say that the unease isn't >> justified - it may in fact by the right answer to reject applications >> based on that unease. If any concerned can think of more tangible >> criteria, though, it would make it easier for me to dispell your >> concerns or give me some personal development goals to meet. >> signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
As a complete newbie I might not have the rights to chime in here. But isn't it never too late if Mr. DeVault may add an apologetic comment to @noobpurple under https://github.com/swaywm/sway/issues/1227 now? Sincerely yours, Darren Wu On Wed, Feb 27, 2019, 21:53 Drew DeVault via aur-general < aur-general@archlinux.org> wrote: > On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: > > I would also chip in with the following from early 2017: > > > > https://github.com/swaywm/sway/issues/1227 > > > > (I am also not in any sort of witch hunt, just thought this would be > > relevant.) > > It should go without saying that I regret what I said here as well. I > was going some stressful financial problems when those comments were > written. Doesn't excuse anything, and I'm sure we could find examples > of my jerkitude that I can't say the same for. > > Instead I'd like to ask this: if I'm to be damned by my past behaviors, > is there a path to redemption? Is there any criteria we could establish > for demonstrating good behavior? Or, would I have to live with a forever > vague sense of unease among the voters? Not to say that the unease isn't > justified - it may in fact by the right answer to reject applications > based on that unease. If any concerned can think of more tangible > criteria, though, it would make it easier for me to dispell your > concerns or give me some personal development goals to meet. >
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-26 11:37 PM, Brett Cornwall via aur-general wrote: > I would also chip in with the following from early 2017: > > https://github.com/swaywm/sway/issues/1227 > > (I am also not in any sort of witch hunt, just thought this would be > relevant.) It should go without saying that I regret what I said here as well. I was going some stressful financial problems when those comments were written. Doesn't excuse anything, and I'm sure we could find examples of my jerkitude that I can't say the same for. Instead I'd like to ask this: if I'm to be damned by my past behaviors, is there a path to redemption? Is there any criteria we could establish for demonstrating good behavior? Or, would I have to live with a forever vague sense of unease among the voters? Not to say that the unease isn't justified - it may in fact by the right answer to reject applications based on that unease. If any concerned can think of more tangible criteria, though, it would make it easier for me to dispell your concerns or give me some personal development goals to meet.
Re: [aur-general] Trusted user application: Drew DeVault
On Wed, Feb 27, 2019 at 4:47 AM Giancarlo Razzolini via aur-general < aur-general@archlinux.org> wrote: > Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: > > > > If the only thing we can find to complain about is his attitude towards > > Manjaro, then we obviously cannot find anything to complain about. :) > > > > I was surprised by this attitude since all my interactions with Drew in the > past were quite friendly. Most (all?) were on IRC. I don't recall him being > this aggressive on IRC. > > Having said that, I don't think we should ever treat anyone like this, > regardless > of distro. I have very little to say on the AUR packages that has not been > said, > but those interactions with users are something we need to also take in > consideration. > > Regards, > Giancarlo Razzolini I'd like to say this, be careful not to get into a "I'm perfect, I can do no wrong" attitude. Be mindful that everyone makes mistakes in their pasts and they can change, Yes, Consider the past, but also consider the present. Has the person changed for the better? If so, then base the application on that merit. No one is perfect, but don't let Drew's past sins affect his application for trusted user. Let his recent interactions speak louder than his past interactions. Very Respectfully, Taylor Lookabaugh
Re: [aur-general] Trusted user application: Drew DeVault
On Wed, Feb 27, 2019 at 11:47 AM Giancarlo Razzolini via aur-general wrote: > > Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: > > > > If the only thing we can find to complain about is his attitude towards > > Manjaro, then we obviously cannot find anything to complain about. :) > > > > I was surprised by this attitude since all my interactions with Drew in the > past were quite friendly. Most (all?) were on IRC. I don't recall him being > this aggressive on IRC. > > Having said that, I don't think we should ever treat anyone like this, > regardless > of distro. I have very little to say on the AUR packages that has not been > said, > but those interactions with users are something we need to also take in > consideration. > > Regards, > Giancarlo Razzolini I'll chime in to say that having known Drew for several years, I've experienced some friction in the past but I would not be sponsoring this application if I thought his attitude hadn't changed. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
Em fevereiro 27, 2019 3:56 Eli Schwartz via aur-general escreveu: If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :) I was surprised by this attitude since all my interactions with Drew in the past were quite friendly. Most (all?) were on IRC. I don't recall him being this aggressive on IRC. Having said that, I don't think we should ever treat anyone like this, regardless of distro. I have very little to say on the AUR packages that has not been said, but those interactions with users are something we need to also take in consideration. Regards, Giancarlo Razzolini pgp4X5r5V6QrH.pgp Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Am 27.02.2019 um 07:56 schrieb Eli Schwartz via aur-general: On 2/27/19 1:37 AM, Brett Cornwall via aur-general wrote: On 2019-02-27 02:09, alad via aur-general wrote: Considering some recent issues regarding team behavior [1] in Arch, I'm going to have to ask on some of your previous interactions with the community, and open-source in general. I had two examples in particular, the MineTest community [2], and interaction with other Arch users on ArchWiki [3]. [1] https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html [2] https://news.ycombinator.com/item?id=18156980 [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 By definition, a TU has to interact with users of community packages (bug reports, emails, coordination with the rest of the Arch team, ...), and users of the AUR in general (AUR requests, peace-keeping, interactions with previous maintainers when promoting packages, ...). This means that if aggressive behavior such as the above is part of some general theme, there is a clear problematic. Note that this is _not_ meant as a witch-hunt of any sort - nor do I have any kind of personal involvement here. I do however value healthy communication in the Arch community, and believe any TU candidate should value it as well. I would also chip in with the following from early 2017: https://github.com/swaywm/sway/issues/1227 (I am also not in any sort of witch hunt, just thought this would be relevant.) If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :) It's not about the _what_, but about the _how_. The issue could have been easily closed with "I don't support Manjaro", rather than a series of insults. What if a Manjaro user files a bug on the bugtracker for one of the Arch packages? I hope no package maintainer in Arch would act the same. I get that emotions fly high whenever Manjaro gets involved, but I just don't see the point in addressing (public!) bug reports like this.
Re: [aur-general] Trusted user application: Drew DeVault
On 2/27/19 1:37 AM, Brett Cornwall via aur-general wrote: > On 2019-02-27 02:09, alad via aur-general wrote: >> Considering some recent issues regarding team behavior [1] in Arch, I'm >> going to have to ask on some of your previous interactions with the >> community, and open-source in general. I had two examples in particular, >> the MineTest community [2], and interaction with other Arch users on >> ArchWiki [3]. >> >> [1] >> https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html >> >> [2] https://news.ycombinator.com/item?id=18156980 >> [3] >> https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 >> >> >> By definition, a TU has to interact with users of community packages >> (bug reports, emails, coordination with the rest of the Arch team, ...), >> and users of the AUR in general (AUR requests, peace-keeping, >> interactions with previous maintainers when promoting packages, ...). >> This means that if aggressive behavior such as the above is part of some >> general theme, there is a clear problematic. >> >> Note that this is _not_ meant as a witch-hunt of any sort - nor do I >> have any kind of personal involvement here. I do however value healthy >> communication in the Arch community, and believe any TU candidate should >> value it as well. > > > I would also chip in with the following from early 2017: > > https://github.com/swaywm/sway/issues/1227 > > > (I am also not in any sort of witch hunt, just thought this would be > relevant.) If the only thing we can find to complain about is his attitude towards Manjaro, then we obviously cannot find anything to complain about. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-27 02:09, alad via aur-general wrote: Considering some recent issues regarding team behavior [1] in Arch, I'm going to have to ask on some of your previous interactions with the community, and open-source in general. I had two examples in particular, the MineTest community [2], and interaction with other Arch users on ArchWiki [3]. [1] https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html [2] https://news.ycombinator.com/item?id=18156980 [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 By definition, a TU has to interact with users of community packages (bug reports, emails, coordination with the rest of the Arch team, ...), and users of the AUR in general (AUR requests, peace-keeping, interactions with previous maintainers when promoting packages, ...). This means that if aggressive behavior such as the above is part of some general theme, there is a clear problematic. Note that this is _not_ meant as a witch-hunt of any sort - nor do I have any kind of personal involvement here. I do however value healthy communication in the Arch community, and believe any TU candidate should value it as well. I would also chip in with the following from early 2017: https://github.com/swaywm/sway/issues/1227 (I am also not in any sort of witch hunt, just thought this would be relevant.) signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Am 27.02.2019 um 02:30 schrieb Drew DeVault: > On 2019-02-27 2:09 AM, alad via aur-general wrote: >> [2] https://news.ycombinator.com/item?id=18156980 > I said my piece in the thread and I encourage anyone concerned to read > through the comments here. For what it's worth, the concerns are over > incidents which occured 4-5 years ago. > >> [3] >> https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 > To add some context which is missing here, the editor here followed me > from GitHub to IRC to the Arch wiki to make a stink over XDG support in > a project which was, at the time, 13 days old. This edit was made at the > height of the argument and I regret the rude message I left there. > > I have often been a jerk in the past, but I recognize the problem and > sought support from friends and family. I believe that I have improved > significantly in the past few years. I understand if your concerns > prevent you from supporting my TU application, though. No hard feelings. I tend to decide on whether to support an application or not at the end of the discussion, not before it. (Applicants positively responding to PKGBUILD reviews typically win my favor, so that's a start.) > >> I haven't read all the documentation for this project, but noticed some >> oddities. Your build service appears to build AUR packages in full >> automation using "yay -Syu --noconfirm". [4] While I'm sure you took the >> necesseary precautions to protect your _servers_ from arbitrary code >> execution, users are still at risk. > I trust my users to understand the risks of the AUR and make educated > decisions when using this tool. I personally utilize the AUR in some of > my builds on this service, but only with packages maintained by myself > or people I trust - or with no sensitive information at risk. Builds > with sensitive information (which are recorded in a way that gives me > data-driven insights) are actually in the minority on builds.sr.ht, and > builds with both secrets and AUR packages are exceptionally rare. In > most cases, the worst a bad AUR package could do is give you a false > negative/positive on your test suite. I think it would be a good idea to make such a trust system explicit. See for example [6], [7], [8]. But yes, I guess the service can be used strictly to test some given AUR packages, rather than their installation or distribution. [6] https://xyne.archlinux.ca/projects/bauerbill/ [7] https://github.com/alexheretic/aurto [8] https://github.com/seblu/aurbot > >> Not to mention how your service hit the AUR rate limit, due to the >> choice of the one (from 18!) AUR helpers inefficient enough to cause >> this. [5] I guess this is "fixed" now, but it leaves a bad taste >> nonetheless. > It is fixed, no quotes needed :) the AUR rate limit is pretty agressive > and there was no service disruption caused by my mistake. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
Am 27.02.2019 um 02:17 schrieb Jerome Leclanche: > On Wed, Feb 27, 2019 at 2:10 AM alad via aur-general > wrote: >> I haven't read all the documentation for this project, but noticed some >> oddities. Your build service appears to build AUR packages in full >> automation using "yay -Syu --noconfirm". [4] While I'm sure you took the >> necesseary precautions to protect your _servers_ from arbitrary code >> execution, users are still at risk. >> >> For example, even when the build happens on your server, the .install >> file contains arbitrary code, which is run by pacman as root, on >> installation of the built package on the user's host. And it's unlikely >> a user will extract a .pkg.tar.xz, just to verify that the .install file >> does nothing strange. > Sorry for jumping in here but that feels like a discussion about the > merits of idempotent and declarative package management more than a > discussion about TU practices. The security and technical concerns for > CI/build services are different to end-user desktops… Drew has made some suggestions about handling of packages/dbscripts in the official repositories before (the reference to which is now unfortunately deleted). As such the way he deals with CI is definitely something I'm interested in. Most importantly, a TU represents the AUR and any good practices accompanying it. A project which encourages users to install AUR packages without inspection is definitely not a good practice. For the record: I don't dismiss the idea of some "build service" for AUR off-hand. It's that the concerns for users should be well-regarded - after all, the "U" in AUR stands for "User". > >> Not to mention how your service hit the AUR rate limit, due to the >> choice of the one (from 18!) AUR helpers inefficient enough to cause >> this. [5] I guess this is "fixed" now, but it leaves a bad taste >> nonetheless. > I'm curious why a user/developer reaching out about an issue leaves a bad > taste. Here I didn't mean the reaching out, but how it makes the whole idea look like an after-thought. In the vein of, "I want AUR for my build service, so let's run this popular command for building AUR packages automatically". I may be more sensitive to this particular point though, since I've dealt more with AUR helpers than most. :) > > J. Leclanche signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-27 2:09 AM, alad via aur-general wrote: > [2] https://news.ycombinator.com/item?id=18156980 I said my piece in the thread and I encourage anyone concerned to read through the comments here. For what it's worth, the concerns are over incidents which occured 4-5 years ago. > [3] > https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 To add some context which is missing here, the editor here followed me from GitHub to IRC to the Arch wiki to make a stink over XDG support in a project which was, at the time, 13 days old. This edit was made at the height of the argument and I regret the rude message I left there. I have often been a jerk in the past, but I recognize the problem and sought support from friends and family. I believe that I have improved significantly in the past few years. I understand if your concerns prevent you from supporting my TU application, though. No hard feelings. > I haven't read all the documentation for this project, but noticed some > oddities. Your build service appears to build AUR packages in full > automation using "yay -Syu --noconfirm". [4] While I'm sure you took the > necesseary precautions to protect your _servers_ from arbitrary code > execution, users are still at risk. I trust my users to understand the risks of the AUR and make educated decisions when using this tool. I personally utilize the AUR in some of my builds on this service, but only with packages maintained by myself or people I trust - or with no sensitive information at risk. Builds with sensitive information (which are recorded in a way that gives me data-driven insights) are actually in the minority on builds.sr.ht, and builds with both secrets and AUR packages are exceptionally rare. In most cases, the worst a bad AUR package could do is give you a false negative/positive on your test suite. > Not to mention how your service hit the AUR rate limit, due to the > choice of the one (from 18!) AUR helpers inefficient enough to cause > this. [5] I guess this is "fixed" now, but it leaves a bad taste > nonetheless. It is fixed, no quotes needed :) the AUR rate limit is pretty agressive and there was no service disruption caused by my mistake.
Re: [aur-general] Trusted user application: Drew DeVault
On Wed, Feb 27, 2019 at 2:10 AM alad via aur-general wrote: > I haven't read all the documentation for this project, but noticed some > oddities. Your build service appears to build AUR packages in full > automation using "yay -Syu --noconfirm". [4] While I'm sure you took the > necesseary precautions to protect your _servers_ from arbitrary code > execution, users are still at risk. > > For example, even when the build happens on your server, the .install > file contains arbitrary code, which is run by pacman as root, on > installation of the built package on the user's host. And it's unlikely > a user will extract a .pkg.tar.xz, just to verify that the .install file > does nothing strange. Sorry for jumping in here but that feels like a discussion about the merits of idempotent and declarative package management more than a discussion about TU practices. The security and technical concerns for CI/build services are different to end-user desktops… > Not to mention how your service hit the AUR rate limit, due to the > choice of the one (from 18!) AUR helpers inefficient enough to cause > this. [5] I guess this is "fixed" now, but it leaves a bad taste > nonetheless. I'm curious why a user/developer reaching out about an issue leaves a bad taste. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
Am 25.02.2019 um 00:24 schrieb Drew DeVault via aur-general: > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > > I'm a generalist that works on free software full time. I maintain the > following AUR packages: > > https://aur.archlinux.org/packages/?SeB=m=sircmpwn Considering some recent issues regarding team behavior [1] in Arch, I'm going to have to ask on some of your previous interactions with the community, and open-source in general. I had two examples in particular, the MineTest community [2], and interaction with other Arch users on ArchWiki [3]. [1] https://lists.archlinux.org/pipermail/aur-general/2018-October/034461.html [2] https://news.ycombinator.com/item?id=18156980 [3] https://wiki.archlinux.org/index.php?title=XDG_Base_Directory=prev=391411 By definition, a TU has to interact with users of community packages (bug reports, emails, coordination with the rest of the Arch team, ...), and users of the AUR in general (AUR requests, peace-keeping, interactions with previous maintainers when promoting packages, ...). This means that if aggressive behavior such as the above is part of some general theme, there is a clear problematic. Note that this is _not_ meant as a witch-hunt of any sort - nor do I have any kind of personal involvement here. I do however value healthy communication in the Arch community, and believe any TU candidate should value it as well. > I also maintain a third-party Arch repo and oversee some automation for > helping to build and publish new packages: > > https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds I haven't read all the documentation for this project, but noticed some oddities. Your build service appears to build AUR packages in full automation using "yay -Syu --noconfirm". [4] While I'm sure you took the necesseary precautions to protect your _servers_ from arbitrary code execution, users are still at risk. For example, even when the build happens on your server, the .install file contains arbitrary code, which is run by pacman as root, on installation of the built package on the user's host. And it's unlikely a user will extract a .pkg.tar.xz, just to verify that the .install file does nothing strange. Not to mention how your service hit the AUR rate limit, due to the choice of the one (from 18!) AUR helpers inefficient enough to cause this. [5] I guess this is "fixed" now, but it leaves a bad taste nonetheless. [4] https://git.sr.ht/~sircmpwn/builds.sr.ht/commit/0.7.5 [5] https://lists.archlinux.org/pipermail/aur-general/2018-December/034730.html Alad signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
Hey Christian! On 2019-02-25 6:21 PM, Christian Rebischke via aur-general wrote: > 1. Can you describe in a few sentences how you build your packages for > the AUR and for your own repository? For the AUR: I just run makepkg -i and makepkg --printsrcinfo > .SRCINFO. I keep it pretty casual for the AUR. For my own repository: I have a script called pkgkit[0] which automates some of the work. It automatically takes care of things like bumping pkgrel & checksums, common sources of human error. Then I submit it to my CI with this[1] build manifest, which boots up a fresh Arch Linux VM to build the package on, and uploads it to my repo. [0] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/pkgkit [1] https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/tree/master/build.yml > 2. How do you keep track of updates of upstream software? Do you use a > specific software for it? Which one? For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community. > 3. Do you plan to socialize with the community? If yes: on which > plattforms? If no: why? Sure, and I already do some. Just on IRC. > 4. What do you like about Arch Linux at most? What do you hate about it? > (You can be open here, I will not judge ^___^) I like that everything is up to date and for the most part Just Werks. I dislike glibc and systemd, but we needn't take that particular flamewar any further than that. > 5. Are you willing to attend real-life meetups on conferences like > FrosCon, CCC, etc? Yep. I met many Arch Linux developers at FOSDEM a few weeks ago. > 6. Do you have any experience with security? This is a pretty broad and open ended question. I suppose my answer is "yes"? > 7. A user opens a bug report, where the user reports a security > vulnerability in one of your packages. The security vulnerability is > unknown and seems to be a 0-day. How do you react? I let upstream know about the issue and then hand them the reins. I consider security vulnerability an upstream problem and delegate authority on how to proceed to them. When a fix is available I'll ship it in my Arch package. I'm not really into the whole responsible disclosure aka pressuring upstream into fixing it yesterday kind of approach. > Thats all from me. Thanks for your hard work with sway btw :) :)
Re: [aur-general] Trusted user application: Drew DeVault
On Sun, Feb 24, 2019 at 06:24:59PM -0500, Discussion about the Arch User Repository (AUR) wrote: > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > [...] > As a long time fan and user of Arch Linux, I'm looking forward to the > chance to give back to the community. If anyone has any questions, > please let me know. > > -- > Drew DeVault Hi Drew, I have a few questions to you: 1. Can you describe in a few sentences how you build your packages for the AUR and for your own repository? 2. How do you keep track of updates of upstream software? Do you use a specific software for it? Which one? 3. Do you plan to socialize with the community? If yes: on which plattforms? If no: why? 4. What do you like about Arch Linux at most? What do you hate about it? (You can be open here, I will not judge ^___^) 5. Are you willing to attend real-life meetups on conferences like FrosCon, CCC, etc? 6. Do you have any experience with security? 7. A user opens a bug report, where the user reports a security vulnerability in one of your packages. The security vulnerability is unknown and seems to be a 0-day. How do you react? Thats all from me. Thanks for your hard work with sway btw :) best regards, chris / shibumi signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
Thanks for all the feedback! I went through and cleaned up all of my AUR packages - something a wiser man would have done before submitting the TU application. Note that in some cases I disowned packages I was no longer interested in maintaining, and in the case of vgo both disowned and filed a deletion request; rather than normalize the PKGBUILDs. On 2019-02-24 6:40 PM, Brett Cornwall wrote: > I must jokingly admit that my first instinct is to vote against your > application so that you'd spend more time on wlroots and Sway. You're not > allowed to work on anything else, slave! Hehe, don't worry, this wouldn't be much more work than I already take on for Arch Linux - it'd just be formalizing that relationship. > * Prefer sha256sums over sha1sums and md5sums > * "$srcdir" can often be omitted as the PKGBUILD functions all begin > in "$srcdir" already - this will make PKGBUILDs much more readable > * MIT-licensed packages are not installing their licenses. > * i386/i686 architectures should be removed. > * update python-distribute makedeps to python-setuptools > * source= lines should save sources to a "$pkgname-$pkgver.tar.gz" file > * Python distutil packages should be built and packaged separately [3]: > * python-spam-blocklists - fill that depends() list, I'm sure it needs > something. Fixed on all counts. > ## python-flask-markdown, python-haxor > * source has https, so use it! Fixed - I normalized all of my Python package's source URLs to the pypi source, using variable substitution to rejigger the names. On 2019-02-25 9:46 AM, Morten Linderud via aur-general wrote: > ## python-asyncio_redis > * I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 > clause BSD`. After some searching from the repos it seems like `BSD` should > be > enough(?) Updated to use the SPDX identifier. > Also want to stress the lack of MIT license being places in > `/usr/share/licenses/`, along with source not currently enforcing shared > SRCDEST as Brett pointerd out. Fixed this everywhere I found it. On 2019-02-25 9:58 AM, Levente Polyak via aur-general wrote: > Your build script on the CI does not produce reproducible packages as > it uses a own simple wrapper to call makepkg. F.e. If there is no > SOURCE_DATE_EPOCH defined to now or the value already passed it does > not create uniform mtimes. Filed a ticket to address this at a later date: https://todo.sr.ht/~sircmpwn/sr.ht/165 This shouldn't be an issue for community, though. > Out of curiosity, what kind of upstream watch are you using to be made > aware of new releases? For the AUR I don't keep up with upstream releases, I just wait for someone to mark the package as outdated. For Alpine Linux I use a combination of subscribing to the upstream -announce mailing list and subscribing to GitHub releases as appropriate; would do something similar for Arch Linux community. > Vgo-git should use go-pie as makedepends like all packages that work I dropped vgo, but fixed this for my other Go-based packages. > None of your python packages, neither in aur nor in your repo build CI > are running any unit tests while most of them provide tests upstream. Fixed in many places in my AUR packages. Will do this for sr.ht-pkgbuilds later: https://todo.sr.ht/~sircmpwn/sr.ht/167
Re: [aur-general] Trusted user application: Drew DeVault
On 25/02/2019 00.23, Drew DeVault wrote: > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > > I'm a generalist that works on free software full time. I maintain the > following AUR packages: > > https://aur.archlinux.org/packages/?SeB=m=sircmpwn > > I also maintain a third-party Arch repo and oversee some automation for > helping to build and publish new packages: > > https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds > > I'm also the upstream maintainer for several packages in community, > including wlroots, sway, and scdoc; and I maintain numerous packages for > Alpine Linux as well. I maintain many other free software projects, > most notably sourcehut, and I also contribute to many projects > maintained by others as well. > > I think Jerome has been hoping for some relief from the packages I > maintain the upstream for, so I may start by relieving that burden. I'd > also like to move the samuari package into community, and likely some > of the Python packages from my third-party repository as well. > > Outside of packaging, I have also been doing some exploratory work that > I hope will lead to finally moving Arch Linux from SVN to git. > > As a long time fan and user of Arch Linux, I'm looking forward to the > chance to give back to the community. If anyone has any questions, > please let me know. > > -- > Drew DeVault I confirm my co-sponsorship. Let the discussion period begin! signature.asc Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
Hi, Your build script on the CI does not produce reproducible packages as it uses a own simple wrapper to call makepkg. F.e. If there is no SOURCE_DATE_EPOCH defined to now or the value already passed it does not create uniform mtimes. What I have noticed as well, f.e where you are upstream plus downstream, there is CPPFLAGS as well which, at least downstream, we must ensure finds its way into the compilation flags. Out of curiosity, what kind of upstream watch are you using to be made aware of new releases? Vgo-git: Should use go-pie as makedepends like all packages that work it should respect LDFLAGS via extflags like gitea does. Does not contain git makedepends, you should build in clean chroot via makechroot aka extra- wrapper from devtools to catch such case python: None of your python packages, neither in aur nor in your repo build CI are running any unit tests while most of them provide tests upstream. Using github sources and running unit tests to catch regressions is highly recommended, please go through them :-) Cheers, Levente
Re: [aur-general] Trusted user application: Drew DeVault
On Sun, Feb 24, 2019 at 06:40:13PM -0700, Brett Cornwall via aur-general wrote: > Here's a PKGBUILD review: Some additional points! > ## madonctl * This package needs to drop `go get` as we have vendored deps. > ## python-activipy-git * "v" should be removed from the pkgver as we are dealing with versioned tags. > ## vgo-git * This package has support for go modules. So it can drop all of the voodoo it is currently doing. ## python-asyncio_redis * I'm a bit unsure what 2 clause BSD is traditionally called. But it's not `2 clause BSD`. After some searching from the repos it seems like `BSD` should be enough(?) Also want to stress the lack of MIT license being places in `/usr/share/licenses/`, along with source not currently enforcing shared SRCDEST as Brett pointerd out. Else the review from Brett seems decent :) Great work. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2/24/19 8:40 PM, Brett Cornwall via aur-general wrote:
> Here's a PKGBUILD review:
>
> ## In general
> * Prefer sha256sums over sha1sums and md5sums [1]
> * "$srcdir" can often be omitted as the PKGBUILD functions all begin in
> "$srcdir" already - this will make PKGBUILDs much more readable
> * MIT-licensed packages are not installing their licenses. [2]
> * i386/i686 architectures should be removed.
To be fair, the AUR covers the use case of archlinux32 users as well as
archlinuxarm (and even, I suppose, parabola and antergos). Officially
the package must be useful to the archlinux.org distribution, but is
permitted to include additional arch support at the maintainer's discretion.
It is worth noting that unsupported arches should be removed from
PKGBUILDs in the official archlinux svn tree, yes.
...
This is generally described at
https://wiki.archlinux.org/index.php/PKGBUILD#arch
With enhanced wording due to recent edits at
https://wiki.archlinux.org/index.php?title=PKGBUILD=next=564920
https://wiki.archlinux.org/index.php?title=PKGBUILD=564976=564975
> * update python-distribute makedeps to python-setuptools
> * source= lines should save sources to a "$pkgname-$pkgver.tar.gz" file,
> e.g.
>
>
> source=("$pkgname-$pkgver.tar.gz::https://github.com/KnightOS/genkfs/archive/${pkgver}.tar.gz;)
>
>
>
> ## knightos-sdk
> Python distutil packages should be built and packaged separately [3]:
>
> build() {
> python setup.py build
> }
>
> package() {
> python setup.py install --root="$pkgdir/" --optimize=1 --skip-build
> }
>
>
> ## madonctl
> * I'm never fond of overly abstracting random things in $_variables
> unless it serves a purpose. This is more style/opinion, though.
In that case I'd just use
source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")
>
> ## python-activipy-git
> * No need to include the GPL3 text, it's one of the included licenses in
> arch.
> * Quote your variables!
> * makedepends should include python-setuptools
> * source and url have https, so use it!
> * I'm seeing an apache license in the repo as well as gpl3
>
>
> ## python-flask-markdown, python-haxor
> * source has https, so use it!
>
>
> ## python-pystache
> * see madonctl.
> * `|| exit 1` is useless here.
> * URL should use https
>
>
> ## python-spam-blocklists
> * fill that depends() list, I'm sure it needs something.
>
>
> ## vgo-git
> What's with these custom functions? Why not just put this stuff in
> prepare() like the packaging guidelines? [4]
>
>
>
> [1] https://wiki.archlinux.org/index.php/PKGBUILD#Integrity
> [2] https://wiki.archlinux.org/index.php/PKGBUILD#license
> [3]
> https://wiki.archlinux.org/index.php/Python_package_guidelines#distutils
> [4]
> https://wiki.archlinux.org/index.php/Go_package_guidelines#PKGBUILD_with_GOPATH_and_dep
>
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-24 18:24, Drew DeVault via aur-general wrote:
Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik
agreed to co-sponsor my application (both Cc'd).
I must jokingly admit that my first instinct is to vote against your
application so that you'd spend more time on wlroots and Sway. You're
not allowed to work on anything else, slave!
I maintain the following AUR packages:
https://aur.archlinux.org/packages/?SeB=m=sircmpwn
Here's a PKGBUILD review:
## In general
* Prefer sha256sums over sha1sums and md5sums [1]
* "$srcdir" can often be omitted as the PKGBUILD functions all begin in
"$srcdir" already - this will make PKGBUILDs much more readable
* MIT-licensed packages are not installing their licenses. [2]
* i386/i686 architectures should be removed.
* update python-distribute makedeps to python-setuptools
* source= lines should save sources to a "$pkgname-$pkgver.tar.gz" file, e.g.
source=("$pkgname-$pkgver.tar.gz::https://github.com/KnightOS/genkfs/archive/${pkgver}.tar.gz;)
## knightos-sdk
Python distutil packages should be built and packaged separately [3]:
build() {
python setup.py build
}
package() {
python setup.py install --root="$pkgdir/" --optimize=1 --skip-build
}
## madonctl
* I'm never fond of overly abstracting random things in $_variables
unless it serves a purpose. This is more style/opinion, though.
## python-activipy-git
* No need to include the GPL3 text, it's one of the included licenses in arch.
* Quote your variables!
* makedepends should include python-setuptools
* source and url have https, so use it!
* I'm seeing an apache license in the repo as well as gpl3
## python-flask-markdown, python-haxor
* source has https, so use it!
## python-pystache
* see madonctl.
* `|| exit 1` is useless here.
* URL should use https
## python-spam-blocklists
* fill that depends() list, I'm sure it needs something.
## vgo-git
What's with these custom functions? Why not just put this stuff in
prepare() like the packaging guidelines? [4]
[1] https://wiki.archlinux.org/index.php/PKGBUILD#Integrity
[2] https://wiki.archlinux.org/index.php/PKGBUILD#license
[3] https://wiki.archlinux.org/index.php/Python_package_guidelines#distutils
[4]
https://wiki.archlinux.org/index.php/Go_package_guidelines#PKGBUILD_with_GOPATH_and_dep
signature.asc
Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On Mon, Feb 25, 2019 at 12:23 AM Drew DeVault wrote: > > Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik > agreed to co-sponsor my application (both Cc'd). > > I'm a generalist that works on free software full time. I maintain the > following AUR packages: > > https://aur.archlinux.org/packages/?SeB=m=sircmpwn > > I also maintain a third-party Arch repo and oversee some automation for > helping to build and publish new packages: > > https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds > > I'm also the upstream maintainer for several packages in community, > including wlroots, sway, and scdoc; and I maintain numerous packages for > Alpine Linux as well. I maintain many other free software projects, > most notably sourcehut, and I also contribute to many projects > maintained by others as well. > > I think Jerome has been hoping for some relief from the packages I > maintain the upstream for, so I may start by relieving that burden. I'd > also like to move the samuari package into community, and likely some > of the Python packages from my third-party repository as well. > > Outside of packaging, I have also been doing some exploratory work that > I hope will lead to finally moving Arch Linux from SVN to git. > > As a long time fan and user of Arch Linux, I'm looking forward to the > chance to give back to the community. If anyone has any questions, > please let me know. > > -- > Drew DeVault I confirm my sponsorship for this application. o/ I indeed currently maintain sway and one of its dependencies, would be handing that off to Drew as he's better suited to package it. J. Leclanche
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-24 7:09 PM, Drew DeVault wrote: > P.S. You pointed out on IRC that my first email wasn't signed, so I > signed this one to be sure. Man. I have this habit of writing the whole email, then reading through and making edits and forgetting about any important promsises I made like signatures or attachments. signature.asc Description: PGP signature
Re: [aur-general] Trusted user application: Drew DeVault
On 2019-02-24 7:01 PM, Eli Schwartz via aur-general wrote:
> Your application sounds interesting and I generally admire your
> open-source work.
Thank you!
> What is samurai, exactly? It claims to be "a ninja-compatible build
> tool" but I'm not sure what the comparative advantages are supposed to be.
> (Aside: If I wanted another build tool rewrite, it would probably be
> meson because it would actually be super interesting to have a meson
> generator that could be used for bootstrapping an OS without requiring
> python as a prerequisite.)
Aye, I have the same opinion about Meson. Ninja is written in C++, which
is easier to port, but I similarly don't like and isn't invited to my
dream OS bootstrapping party. Samurai is the simpler of the two
components to replace in C, so I see it as the first step towards
correcting Meson's Python problem.
Personally I don't think that even Meson is the end-all be-all of build
systems, but it's definitely the best to come so far, so if I ever get
around to replacing it with something written in C I will probably take
a lot of its ideas but not attempt to be compatible.
> What are your thoughts on things like
> https://todo.sr.ht/%7Esircmpwn/scdoc/17
> As you've mentioned scdoc, I recollect that it builds statically against
> libc, and ("by design") does not respect the makepkg.conf LDFLAGS -- we
> currently override this:
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/scdoc#n16
Sometimes I'm an opinionated upstream, but it's (usually) my right to
be. I'm not an opinionated downstream, because it isn't my right to be.
I won't push my personal opinions about software into the packages or
make packages which rock the boat. Opinions as big as LDFLAGS aside, if
I have any novel ideas I'll put them to the community and seek consensus
first.
But you can still expect me to be an annoying upstream from time to time
:)
P.S. You pointed out on IRC that my first email wasn't signed, so I
signed this one to be sure.
Re: [aur-general] Trusted user application: Drew DeVault
On 2/24/19 6:24 PM, Drew DeVault via aur-general wrote:
> Hiya! Jerome convinced me to finally apply for TU, and Sven-Hendrik
> agreed to co-sponsor my application (both Cc'd).
>
> I'm a generalist that works on free software full time. I maintain the
> following AUR packages:
>
> https://aur.archlinux.org/packages/?SeB=m=sircmpwn
>
> I also maintain a third-party Arch repo and oversee some automation for
> helping to build and publish new packages:
>
> https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds
>
> I'm also the upstream maintainer for several packages in community,
> including wlroots, sway, and scdoc; and I maintain numerous packages for
> Alpine Linux as well. I maintain many other free software projects,
> most notably sourcehut, and I also contribute to many projects
> maintained by others as well.
Your application sounds interesting and I generally admire your
open-source work.
> I think Jerome has been hoping for some relief from the packages I
> maintain the upstream for, so I may start by relieving that burden. I'd
> also like to move the samuari package into community, and likely some
> of the Python packages from my third-party repository as well.
What is samurai, exactly? It claims to be "a ninja-compatible build
tool" but I'm not sure what the comparative advantages are supposed to be.
(Aside: If I wanted another build tool rewrite, it would probably be
meson because it would actually be super interesting to have a meson
generator that could be used for bootstrapping an OS without requiring
python as a prerequisite.)
> Outside of packaging, I have also been doing some exploratory work that
> I hope will lead to finally moving Arch Linux from SVN to git.
<3
> As a long time fan and user of Arch Linux, I'm looking forward to the
> chance to give back to the community. If anyone has any questions,
> please let me know.
What are your thoughts on things like
https://todo.sr.ht/%7Esircmpwn/scdoc/17
As you've mentioned scdoc, I recollect that it builds statically against
libc, and ("by design") does not respect the makepkg.conf LDFLAGS -- we
currently override this:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/scdoc#n16
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
