Re: [aur-general] TU application - bastelfreak
On 2020-10-18 17:39, Tim Meusel via aur-general wrote: [...] * puppet [1] * puppet5 [2] * facter [3] * libwhereami [4] * ruby-deep_merge [5] * ruby-httpclient [6] * ruby-sync [7] * ruby-puppet-resource_api [8] * ruby-semantic_puppet [9] [...] As a trusted user I would like to co-maintain those packages, enable tests on the PKGBUILDs where tests are currently missing (for example ruby-puppet-resource_api, ruby-semantic_puppet and Puppet), fix the remaining namcap warnings (for example on facter and libwhereami) and also import some other Puppet related tools into the official repository. Some of them are already in the AUR (not all maintained by myself): * fluent-bit (not Puppet related) [10] * ruby-gettext-setup [11] * ruby-minitar [12] * ruby-puppet_forge [13] * ruby-rr [14] * ruby-cri [15] * ruby-test-unit-rr [16] * ruby-fast_gettext [17] * ruby-gettext [18] * ruby-locale [19] * ruby-text [20] * ruby-colored2 [21] * r10k [22] [...] It's great that you'd like to improve the quality of the Ruby ecosystem! Do you have any experience with documentation? I think it'd be nice to have someone experienced make sure the Ruby/Puppet documentation is up to snuff. Are you also interested in maintaining any other types of packages, or only the Ruby ecosystem? signature.asc Description: PGP signature
Re: [aur-general] TU application - bastelfreak
On 2020-10-22 23:24, Tim Meusel via aur-general wrote: Hey, On 21.10.20 23:41, Jelle van der Waa wrote: On 18/10/2020 17:39, Tim Meusel via aur-general wrote: [...] Some notes on your AUR packages: [...] * choria-io [...] - systemd unit could have some systemd hardening applied, see the wiki or 'man systemd.exec' https://wiki.archlinux.org/index.php/Arch_package_guidelines/Security#Systemd_services thanks for the hint about hardening. To get this working I only copied the unit file that upstream uses as well (but it's not bundled in the source code). I will take a look here and see which options make sense in the unit file and submit them to upstream and the AUR. I greatly appreciate the upstream-first attitude: Any hardening done will benefit all distributions. signature.asc Description: PGP signature
Re: [aur-general] SGE Orphaning
On 2020-10-19 12:59, Manhong Dai via aur-general wrote: Dear Trust User, I submitted an Orphaning request in both comment area and ticket system. Feel free to let me know if there is anything I need to do to follow up. My email address is da...@umich.edu , just in case I missed any emails. Best, Manhong It's been made clear that you're not willing to listen to TUs and would rather engage in what appears to be bordering on harassment with the new maintainer. If you had demonstrated a clear attempt to actually understand the responses to your mails in this list then there might have been recourse. As it stands, you're merely digging your own grave. If the new maintainer wants your help, he'll add you as a co-maintainer. If they do not, then leave them be and put your PKGBUILD elsewhere. signature.asc Description: PGP signature
Re: [aur-general] TU application - raster
On 2020-08-23 21:34, David C. Rankin wrote: On 8/23/20 8:47 AM, Eli Schwartz via aur-general wrote: I approve this TU application. Looking forward to seeing you on the team soon. :) I have no approval authority, but the age, history and experience is the exact type that is beneficial (if not outright mandatory) for maintaining and advancing a disto (smartly). Though it means little, +1 here. Could you elaborate on what you meant by what you meant by "age"? signature.asc Description: PGP signature
Re: [aur-general] Being an asshole to package maintainers is a bannable offense, and that's okay (Was: EQ And Community Kindness)
On 2020-01-15 17:09, Eli Schwartz via aur-general wrote: On 1/15/20 4:17 PM, michael Bostwick via aur-general wrote: Hi, This is my first time writing the mailing list, to be honest I would have preferred anther way of bringing this up, but *I didn't see an easy way to bring my concern to someone who's empowered to fix this strong comment or make it better.* I was looking into a package to solve a complex programming task when I encountered a rather jarring pinned comment . ( https://aur.archlinux.org/packages/libc%2B%2B/#pinned-678768 ) " Hi people, this is your regular reminder to SHUT UP about validpgpkeys checks and complaints about the fact that test suites exist. This package is doing the correct thing, and there has been a great deal of pointless moaning and whining about it, but there is also multiple pinned comments explaining why every one of those complaints is not only null and void, but retroactively ridiculous. The banhammer is ready and waiting in case you *still* want to ignore all this on top of the Trusted User warning." I really hope no one was banned by the writer of this comment,and I really hope as trusted users in the future you guys would *be a little more kind* to members of the aur community. The package in question has suffered to a very surprising degree from tremendous quantities of abuse heaped upon the maintainer. Since that pinned comment was added, users have stopped being mean to the maintainer. As a result, no one has needed to be banned. If you had moderator privileges on the AUR and could see the contents of the deleted comments -- of which there are many -- I suspect you'd rapidly understand why people are at the end of their tether. The only directly mean comment I see is one from 2018-09-30 where someone elegantly wrote: Stop beeing arrogant , and help, if not shut up! Sometimes talk toa human is a lot better way of learning ! All the other comments seem to be the typical fare for those that expect Arch to support AUR helpers/make the experience "easier". Perhaps I missed some. It appears that the pinned comment in question was indeed added after a small uptick in the undesirable comments. I have doubts as to whether it has actually stopped any sort of behavior - adding one more comment atop a pile doesn't seem effective to me, and comments have since occurred despite the new pin. I'm not discounting the probable possibility that the maintainers received some nasty emails, but the deleted comments I can see are tame (if tiring to look through). The Arch Linux community has issues with interacting like human beings; however, I find the pinned comment in question to be tame (if colorful). Many linux users may be familiar with Linus Torvalds writings on his mistakes with EQ, I hope no one in aur has to experience that. I'm not even sure I recognize the abbreviation "EQ", but given it's some sort of Linus Torvalds reference I'm fairly positive no one has been personally attacked or called names on that AUR page. I came across https://en.wikipedia.org/wiki/Emotional_intelligence Some people who were behaving very impolitely indeed, were given an ultimatum that their behavior was not an acceptable way to treat people, but more on that later. Hmm, I wonder: does that make me the champion of community kindness, here? Is my attempt to enforce that, now being met with objections from you, who would like to defend the right of users to be as offensive as they want without having to suffer the consequences of being banned for their behavior? While I think that your pinned comment is acceptable, I'm not sure that deriding a user from trying to help the community is. I see where this is going, and it'd be good to just stop it now before it becomes another drama train. For those trusted AUR members that have been kind I say *thank you for your hard work*, and for those that mean well but are harsh please keep in mind when you see a package the first thing you see in the pinned comment (and alot of context that is missed), and that speaks loudly to your impressions of aur. I have been kind... to the AUR package maintainer. This is more important than being kind to users, because the package maintainer is the one who does the work, and therefore we would like him to continue doing the work rather than being chased away by ungrateful users heaping abuse upon him because he wrote a PKGBUILD for software that takes a while to compile, and users apparently hate maintainers that don't offer instant gratification. Futhermore: the so-called "unkindness" you speak of is simply a warning stating that users are not permitted to complain about two very specific things which are simultaneously correct to do *and* which the package maintainer has very patiently explained the purpose of and the makepkg options to disable them if the user optionally chooses that they don't wish these things to happen. Despite these very patient,
[aur-general] Packages that include other project code
I'd like a sanity check! Waybar has a dependency on a C++ logging library called spdlog. This project depends on fmt and by default uses an included copy. I've raised a ticket about removing this but it doesn't look like the developer is interested [2]. In this case, I feel it expedient to patch out the logic to use the bundled headers [2] and outright remove the directories [3]. Am I correct in this conclusion or is this too far-reaching? [1] https://github.com/gabime/spdlog/issues/1146 [2] https://git.archlinux.org/svntogit/community.git/tree/spdlog/trunk/rm_bundled_fmt.patch [3] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/spdlog#n50 signature.asc Description: PGP signature
Re: [aur-general] Spam account
On 2019-06-16 20:24, stefan-husm...@t-online.de wrote: Hello, this account is spamming the AUR with stupid unrelated online game invotations. https://aur.archlinux.org/account/sunny007 ssvv17...@gmail.com Please consider deletion and ban Done. Thanks for reporting. signature.asc Description: PGP signature
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] rfc: pkgbuild for prospect releng-tool
On 2019-03-05 23:53, Brett Cornwall wrote:
url='https://releng.io/'
arch=('any')
license=('BSD')
I don't see this license in the project. It needs to be in the
project, and if it is indeed BSD licensed you need to copy the license
to "$pkgdir/usr/share/licenses/$pkgname/" [1]
Oops... I suck at computers and managed to end up in the
releng-tool-examples repo. I should go to bed. So I see that the license
is indeed in upstream and you've included it in the package. Derp.
source=("$pkgname-$pkgver::git+https://github.com/releng-tool/releng-tool.git#tag=v$pkgver;)
I see that you're the maintainer of upstream; Why not create a release
on Github and then download the tarball here? Typically, pulling
sources via git is for '-git' packages.
You should use the release tarball instead of relying on git then, which
would be another dependency in this package.
sha512sums=('SKIP')
Having a tarball release will mean that you can have checksum
verification as well.
^Still applies.
signature.asc
Description: PGP signature
Re: [aur-general] rfc: pkgbuild for prospect releng-tool
On 2019-03-06 01:24, James Knight via aur-general wrote:
Hello -- new user to AUR and hoping if anyone is willing to review a
PKGBUILD [1] definition for me. I have been reading PKGBUILD [2] and
"AUR - Submitting packages" [3] documents, which the latter document
suggests to "... submit the PKGBUILD to the AUR mailing list ... for
public review before adding it to the AUR".
Hello, and welcome!
Great job doing your research. You've already gone above and beyond with
the above.
pkgname=releng-tool
pkgver=0.1
I don't see any releases on the upstream github. Where'd you get this
0.1?
pkgrel=1
pkgdesc='tool to assist in the release engineering of a project'
Capitalize the T!
url='https://releng.io/'
arch=('any')
license=('BSD')
I don't see this license in the project. It needs to be in the project,
and if it is indeed BSD licensed you need to copy the license to
"$pkgdir/usr/share/licenses/$pkgname/" [1]
makedepends=(
'python'
)
You're using python-setuptools, so you'll want to set that in
makedepends instead of python.
source=("$pkgname-$pkgver::git+https://github.com/releng-tool/releng-tool.git#tag=v$pkgver;)
I see that you're the maintainer of upstream; Why not create a release
on Github and then download the tarball here? Typically, pulling sources
via git is for '-git' packages.
sha512sums=('SKIP')
Having a tarball release will mean that you can have checksum
verification as well.
[...]
package() {
depends=('python')
The depends() should just go to the top alongside makedepends for this
package. You probably saw this in the examples for the python packaging
standards, but this is typically used for a 'split package', i.e. using
one PKGBUILD to build versions for both python2 and python3. Since
you're only building for python 3 depends() should go to the top.
cd "$pkgname-$pkgver"
python setup.py install --root="$pkgdir" --optimize=1
Go ahead and add a --skip-build here since you already built earlier.
[...]
install -dm 755 "$pkgdir/usr/share/bash-completion/completions"
install -m644 scripts/releng-tool-completion
"$pkgdir/usr/share/bash-completion/completions/releng-tool"
No need to create the directory beforehand; This can be shortened into:
install -Dm644 scripts/releng-tool-completion
"$pkgdir/usr/share/bash-completion/completions/releng-tool"
Check out the 'namcap' package in [extra] if you haven't already. It's
certainly a fallible tool but it can help with maintenance quality.
Also, check out the Python packaging guidelines:
https://wiki.archlinux.org/index.php/Python_package_guidelines#setuptools
[1] https://wiki.archlinux.org/index.php/PKGBUILD#license
signature.asc
Description: PGP 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
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
[aur-general] Policing AUR content (Was: Handling coincidental name collisions)
On 2019-02-09 14:49, Xyne wrote: On 2019-02-09 14:36 +0100 alad via aur-general wrote: The "original" lsf looks like a joke/troll package to me, rather than "trivial". I'd have deleted it even without community duplicate. Alad To me it just looks like the package of someone discovering bash programming with ANSI escape codes and wanting to share. The fact that it's on github with a README.md and a preview is an argument against it being a joke/troll. Agreed. This is pretty clearly not a troll package. It's an easy-to-run script that could easily be featured in one of those 'Top 5 things the Linux terminal can do' articles. The discussion is important because we need to have a general consensus on deletion criteria. Rogue TUs can't be allowed to roam the AUR deleting whatever they personally don't find useful on a given day. "All art is quite useless." -Oscar Wilde I'd propose that malicious/spam packages get deleted in this manner, and nothing else. We can't police what people want to do with their installation. Scripts like this may be trivial but they're bound to give enough people joy. Occasionally I zen out to asciiquarium (admittedly a much more involved program but no more useful than lsd) every now and then. The point is, it was a legitimate program and should be welcomed in the AUR like any other (with the naming conflicts resolved). signature.asc Description: PGP signature
Re: [aur-general] Spam comments on lltag
On 2019-01-19 20:40, Cedric Girard wrote: The user williamdthomas [1] is making spam comments on lltag page [2]. Thanks for the report. Comments are deleted and accounts suspended.
Re: [aur-general] [PATCH][tu-bylaws]: raise threshold of sponsors to two
I apologize for contributing to this sturm und drang. On 2019-01-08 12:33, Eli Schwartz via aur-general wrote: Rules without a process to ensure they actually achieve a useful result don't do the thing they are intended to do. I guess if people are dissatisfied with the application process, then a moratorium might be considered a valid alternative, but I think most will agree it is not a *good* alternative. Historically, reviews happen by a maximum of one person, and it's almost always either me or Levente. And I'm no longer interested in the pressure. Now we're getting recent cases where no one reviews at all, or someone does but only on the last day of the discussion period. Bottom line is that perceptions of inefficiencies in the application process can only be solved by changing the people doing the voting. I agree. I will help share the load and hope the wider TU community will join. The original sponsors should have done this and more in the first place. I don't want to vote for a candidate simply because I cannot find any compelling objections -- I want to vote for a candidate because s/he and sponsor(s) gave me a passionate reason to believe in them. I would like to highlight dvzrv for being very effective - well before my application he was helping improve my PKGBUILDs, during my application he helped me prep, and even after my acceptance he has continued to give great feedback.
Re: [aur-general] TU application: a-wing
On December 25, 2018 12:50:41 AM MST, Metal A-wing <1@233.email> wrote: >I want to push `ruby-rails` and `ruby-*` packages to the official repo Who is your sponsor? Can you tell us more about why you should be a TU? https://wiki.archlinux.org/index.php/Trusted_user#How_do_I_become_a_TU?
Re: [aur-general] TU Membership Application
On 11/16/18 08:11pm, David Runge wrote: The results are in (the vote ended nearly an hour ago)! Thank you all. To those that voted 'No': Feel free to send me a message with your feedback. Your concerns would be a valuable asset for me to keep in mind. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/07/18 09:28pm, Santiago Torres-Arias wrote: Hello Brett. I took some time to randomly sample your PKGBUILDs and give some feedback: - ags: - it appears that you use sed to change CFLAGS in the makefile definition, although it appears that the Makefile itself lets you overwrite them. I'd advice trying to use native tooling as possible, and to try to get familiar with the toolchain of each package as much as possible. I will admit that I didn't think to go through those lines when I inherited it. You're totally right, there's no reason to do it that way. - The optdepends description on wine is a bit confusing in my opinion. I removed it. There's little reason to have it there anyway. The optdepends isn't a good place to inform people about that anyway. - I marked the package as out-of-date, as there appears to be a new version (3.1.4.15) as of almost two months ago. Long story short, that was pretty much exactly during the time when I accidentally clobbered my urlwatch file. Thanks for bringing that up to me. - I noticed that you didn't add a LICENSE file for this package. Artistic2.0 is a uncommonly used common license! (/usr/share/licenses/common/Artistic2.0/license.txt) - hib-dlagent: - I see that you backported a patch on this and ags. I was rather surprised to see that neither patches were added to new tags/releases. You could, however, cherry pick the commits rather than depending on the github api (which can change) to compute the diff for you. For this, you could use the git transport on makepkg. That would bring another dependency on git, though. I can surely do if if it's more 'correct' but I wouldn't imagine that Github would change that API anytime soon. Or would it be better to just carry the patch locally in the repo? - I noticed that you didn't add a LICENSE file for this package. Yikes, the project doesn't even have a license! I should have checked that when I inherited it (the packager just slapped a GPL2 on it). Really, I had just uploaded it so it wouldn't have been lost after the AUR 4 migration. I'll bug upstream about it. - gam-git: - I'm not sure if this would work when built in a chroot due to those touch calls. - After reviewing the package I doubt this doesn't need a build() step. Otherwise I'd label this package a -bin. This is something that we should take special consideration of, since we could be unwittingly be introducing binaries that aren't hardened when building. (I could be wrong on this one, since it for some reason vendors many well-known packages inside of it. Good job for not pulling it those vendored deps :D) - I'm confused as to why gam.py needs to be put inside /usr/share/gam and add a .sh entrypoint for it in /usr/bin. The file seems to have a shebang and be executable... - I see that here you *also* are providing a patch. I also could find that you submitted an issue upstream for said patch (but not the patch itself)[1]. I like your initiative! Do try to keep the number of backported patches to a minimum to keep things manageable. - I noticed that you didn't add a LICENSE file for this package. Of all the packages you had to click on that one. :( I know it doesn't really excuse it but gam is sort of a "WIP" because it's... oddly written. I've been meaning to set aside some time to get some patches in to make it more palatable for packaging. The patch is a complete hack right now just to make the package "work" (when I inherited it it was FUBAR). I will probably send more feedback, but I also don't want to overwhelm you with this and all the other reviews around. I really appreciate the feedback! It always sucks when so many little things become so glaring after the fact but signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: creeper-world2 I've had two AUR requests queued up for some time now; deleting this package is one of them. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: some small questions and hints first: I'm nearly done with following your excellent suggestions but I have responses and questions. It looks like several packages have different issues preventing to build in clean chrooted environments properly. Did you take a look at the devtools package and building packages in clean chroots so far? I must sheepishly apologize. These new tools simplify everything. What software/tool do you using to track all the new ustream releases? urlwatch on a daily timer. You still seem to use `mksrcinfo` for generating SRCINFO files, it was deprecated in favor of native `makepkg --printsrcinfo` you may want to use that in the future. Thank you, switched! I have noticed that mostly all git packages lack sufficient provides/conflicts on the basic non-git name schema and/or makedepends on git itself, would be nice to keep in mind A silly oversight that will be enforced now that I'm learned in the ways of proper tooling. Also i notices there are multiple packages that store a tarball in the AUR source repo that contain things like icons, please don't miss-use the AUR as a storage for tarball artifacts. I should have known better and - at the very least - removed them before submitting my application. I've taken care of nearly all of them and have bowed my head in shame. - don't think pkgdesc should ever end with a dot The descriptions are often sentences, so would it not reason to end them with a period? - not a big fan of fiddling with PKGEXT even if its "just the AUR" but well For a package destined for the repositories I would not fiddle and endeavor to reverse such fiddling; however, the compression time for large games is enormous only to decompress right after. Should it, for the sake of correct-ness, be reversed even for the packages doomed forever to live in the AUR? interception-ctrl2esc-git - is there a reason to have interception- prefix? imo ctrl2esc-git would be the better naming here plus provides/conflicts on ctrl2esc I normally agree (and I originally had it named that way), however... - This is an 'interception tools' plugin... not reason enough to have the package name change, but.. - caps2esc is an older X program, so interception's variant had to be named 'interception-caps2esc'. Naming this 'interception-ctrl2esc' follows the pattern for consistency/less confusion. With that said, should it still be named ctrl2esc? signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 11/05/18 07:48pm, Levente Polyak via aur-general wrote: Hi Brett, some small questions and hints first: Thank you for such a thorough vetting, Levente! I'm fixing these ASAP. signature.asc Description: PGP signature
Re: [aur-general] About bullying in our community (Was: TU Application)
On 10/30/18 02:51pm, Ethan Rakoff wrote: Remember that as technical people working on a project that spans the world, we communicate almost exclusively through text, and it can be easy to misinterpret the tone of someone else. We should all make an effort to remember this in writing and in reading. Never attribute to malice that which can be attributed to ignorance or misunderstanding. This went beyond a simple misunderstanding in medium. It's dripping with anger! I understand - and actually prefer - truth and correctness when soliciting help from others. Blunt is fine: It's quick and to-the-point. I am not fond of overly-inclusive communities that effectively censor criticism because it might hurt feelings. However... I spent so long formally submitting my application after the initial mix-up because I wasn't sure I wanted to get reamed in a similar manner - "Does everyone react this way?", I thought. I had urges to speak out but I was afraid that this was just 'how it is'. When things went off the rails I considered withdrawing. Perhaps I won't make TU status but it might be of value to this community to know that this made an applicant think twice about joining. I do appreciate Eli apologizing on the other thread. I can relate to the anger stemming from caring too much - I sometimes have to walk away from my keyboard for the same reason. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 10/26/18 08:44pm, Levente Polyak via aur-general wrote: can you please fix this and make your gpg key available somewhere? I've pushed 0F8E620A up. signature.asc Description: PGP signature
Re: [aur-general] TU Membership Application
On 10/25/18 10:22pm, Jelle van der Waa wrote: What kind of tasks/roles do you handle for LibreOffice in the infrastructure team? I've been working with the team for a few years now. I'd say the majority of my work would be converting the legacy, manually-configured environments to Saltstack states and de-dockerizing some stuff. I've also been helping out with overhauling monitoring/alerting since it was previously not functioning very well. A good overview can be seen in our monthly meeting minutes: https://pad.documentfoundation.org/p/infra Our git repos are private, unfortunately - more of a precaution than damning us for bad security practices. :) signature.asc Description: PGP signature
[aur-general] TU Membership Application
I am being sponsored by dvzrv. I've been working in the AUR since 2014 as 'Ainola'. I've had a few of my packages adopted into [community], such as gnome-mpv, csound, and qutecsound (the latter two being adopted by dvzrv). I am also an active contributor to the LibreOffice infrastructure team. I would like to get valuable tools promoted into [community], such as residualvm or the 'pass' plasmoid (after prodding upstream to have a formal release). Other packages that I do not maintain in the AUR would be ripe for picking as well, such as sc-controller or ttf-lato. I would also work with dvzrv on maintaining pro-audio packages, many of which were abandoned when SpepS left. signature.asc Description: PGP signature
Re: [aur-general] Greetings and Documentation Proposals
On 10/09/18 01:09am, David Runge wrote: On 2018-10-07 20:06:47 (+0200), David Runge wrote: I hereby ACK my sponsorship! Let the discussion begin :-) As there has been quite a misunderstanding on my side, regarding when and how Brett wanted to apply to become a TU, please disregard my last e-mail. (I should stop replying to mails on my phone, when only half-awake). In case he does apply in the future though, I'd be happy to be the sponsor. I can happily apply right now :) As I said earlier in the thread, I'm interested in raising the general availability of packages for the average Archer. I'm also interested in helping David out with some of the pro audio packages - there are a lot of them! My first migration over to arch was slowed because the tools that I wanted (namely csound) was non-functional (Speps had started to disappear at that time, IIRC). It's great to see csound (and by extension, qutecsound) availability into [community]! Vote for me and we can make the world a better place [1]. [1] https://www.youtube.com/watch?v=fRUAJVKlUZQ (Did I do it right?) signature.asc Description: PGP signature
[aur-general] Greetings and Documentation Proposals
Hello, fellow Archers. My name is Brett and I've been making PKGBUILDs for the AUR for some time under the moniker 'Ainola'. A number of these packages have been kindly pulled into [community] by David Runge. I've since had a desire to get some of my other packages into [community], so I'm interested in working towards getting TU status. I'm also involved in the LibreOffice community (I just got back from the conference in Albania). David has been kind enough to give suggestions to my current packages; I'd love to nab some other packages throughout the AUR, improve them, and get them included in the repositories for mass consumption. I would also like to improve the documentation for the devtools: There are no manpages, /usr/share/docs/ items, or wiki articles. Unless I'm mistaken it appears that the only documentation that currently exists is just invoking the program with -h. I'd like to fix that. :)
