[aur-general] Fwd: AUR Cleanup Day September 20th

[Daniel M. Capella via aur-general]

Greetings,

Let's bring back AUR Cleanup Day. Several people have signed a blood
oath^w^w^w^wshowed an interest in participating, and as everyone knows, the
AUR needs all the love we can spare. If any TUs could attend, it would be
appreciated. See this[] wiki article for cleanup criteria and other details.

The event will be all day September 20th -- mark your calendars. Join
#archlinux-aur and BYOB.

[] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day

Best,
polyzen

PS: A duplicate of this email may show up on the ML in a day or so -- just
disregard it. I initially sent this through archlinux.info a day or so ago,
and got tired of waiting for it.

Re: [aur-general] Become TU

[Daniel M. Capella via aur-general]

On October 13, 2018 9:25:31 AM EDT, Islam Bahnasy via aur-general 
 wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>
>Hello,
>
>I see that 'usbguard' is very useful tool and I depend on it my self so
>I hope if it's merged to the community repo.
>I never had a patch to any Arch project yet however I do have a lot of
>passion towards becoming a TU and maintaining usbguard.
>
>https://usbguard.github.io/
>
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCAAdFiEEZTuDEAsuVmnVQRUQ10eBRotj8oQFAlvB8koACgkQ10eBRotj
>8oQNKw//WIpNFGdOEqFCN6eKEr50XzleFZhAEkexa+iVq+gKxGyqwfnNRrXW+K2Q
>hkP42G0okpIb3Q2PEL+7VLxARMVUSGtMByKHGZfx/SGsjOKbA5XWCoQxVBD9A/ZA
>CB2hugkZpbW+qajv8jow92poYPOLgnUQfADMJ0c+rRbSdhu7I/+XjSfV8LA6agmR
>uoLRZDfagEky5UOJhATG+2oQyxqrwpHB4r6CC/+avlNhg/OhHRaYeKo908NmOBMy
>AOBSHdjWJFbaO7wlnwCjEymhoeNCgUly/NdugBYLzeSV1Vi+ZUGkgXj8jirgndVQ
>BntW9Zmr/lRu3TU+tByO2jFV4mPtZeCKY/IAsWRfm6rmquzXKqbOS4zAxyX8fIjx
>PdnDyR2AfTqpuYhJyFVBi9pCsTX9a94BRms9I0exkE6LwVGKfNvJww65+MTjvme/
>U/4A/Qyu7D1UoG87mw23quqSu5evdjgGpM+0cB9WaVKVMTduObnDl7RQT+RhD1cL
>uE/vxC5qgjghtTDBLKXN5WsxHRtZvbSgIeMaSsfYJQ5USNWJoQV+xTMUvFC8Zb/G
>bKlCZ3MGwOXWGbLFuHHZPncSS21nHIi9VHjI2GU99LfLBvvsh62juMy6FbT07jhF
>xco9zI63feLzOXgkdHpNM1xIXSKm8EtqHe623WfL7wONHDtcl4o=
>=q2MX
>-END PGP SIGNATURE-

https://wiki.archlinux.org/index.php/Trusted_Users#How_do_I_become_a_TU.3F

-- 
Best,
polyzen

Re: [aur-general] TU Application - Konstantin Gizdov

[Daniel M. Capella via aur-general]

On October 28, 2018 2:42:31 PM EDT, Baptiste Jonglez 
 wrote:
>On 28-10-18, Eli Schwartz via aur-general wrote:
>> (endless rambling)
>
>Can we please stop this futile bike-shedding exercise?  It does little
>outside of discrediting you and the Arch community as a whole.
>
>I already said so in previous discussions, but I am still dismayed at
>your
>and Doug's tendency to aggressively gang up on anybody crossing your
>way,
>assuming from the start that they are lying bastards with devious
>motives,
>without ever questioning your own assumptions or actions.  You
>desperately
>want to always be right and to always have the final word, but I'm
>sorry
>to say that life does not work this way.
>
>Regarding the TU application itself, the discussion period is nearly
>over.
>Since the bylaws mention that the period lasts 14 "full days", I will
>open
>the vote tomorrow morning.
>
>Baptiste

It's upsetting and embarrassing that the only staffer to stand against this 
behavior directly in the ML is the applicant's sponsor. This disrespectful 
behavior occurs all the time. Can we enforce our Code of Conduct or is it just 
for show?

-- 
Best,
polyzen

Re: [aur-general] TU Application - Konstantin Gizdov

[Daniel M. Capella via aur-general]

On October 28, 2018 6:42:09 PM EDT, Santiago Torres-Arias 
 wrote:
>Hello everyone.
>
>I've been following this email thread quite closely and without
>participating as I was hoping to keep opinions to myself --- I don't
>think I have much questions other than what's already asked for
>Konstantin --- and make up my mind for voting.
>
>It's clear that it is time to take a step back and stop fanning the
>flames. We are all passionate people, and sometimes this passion leads
>us to the type of arguments we are having right now. I agree with Eli,
>this is not a toy operating system and there are things at stake.
>However, I'm completely convinced that no ill intention is coming from
>everyone involved, and that, if we consider this optic, it's clear that
>this is just a non-technical quarrel that should've been shelved a
>while
>ago.
>
>Personally, I think this is a good opportunity to tone it down for a
>second, leave the 10+ emails behind us and try to go back to the things
>that make this community friendly and welcoming.
>
>Baptiste, Konstantin, Eli, and Doug. Please take a deep breath and
>extend a friendly handshake. I'm sure everyone else following this
>exchnage thinks this is the reasonable way to move forward.
>
>-Santiago.

I appreciate the sentiment, but Please don't downplay known toxic behavior that 
needs to come to an end. That doesn't help the cause of making this a friendly 
and welcoming community. Konstantin has clearly extended an olive branch time 
and time again.

-- 
Best,
polyzen

Re: [aur-general] TU Application - Konstantin Gizdov

[Daniel M. Capella via aur-general]

On October 28, 2018 6:42:09 PM EDT, Santiago Torres-Arias 
 wrote:
>Hello everyone.
>
>I've been following this email thread quite closely and without
>participating as I was hoping to keep opinions to myself --- I don't
>think I have much questions other than what's already asked for
>Konstantin --- and make up my mind for voting.
>
>It's clear that it is time to take a step back and stop fanning the
>flames. We are all passionate people, and sometimes this passion leads
>us to the type of arguments we are having right now. I agree with Eli,
>this is not a toy operating system and there are things at stake.
>However, I'm completely convinced that no ill intention is coming from
>everyone involved, and that, if we consider this optic, it's clear that
>this is just a non-technical quarrel that should've been shelved a
>while
>ago.
>
>Personally, I think this is a good opportunity to tone it down for a
>second, leave the 10+ emails behind us and try to go back to the things
>that make this community friendly and welcoming.
>
>Baptiste, Konstantin, Eli, and Doug. Please take a deep breath and
>extend a friendly handshake. I'm sure everyone else following this
>exchnage thinks this is the reasonable way to move forward.
>
>-Santiago.

I appreciate the sentiment, but Please don't downplay known toxic behavior that 
needs to come to an end. That doesn't help the cause of making this a friendly 
and welcoming community. Konstantin has clearly extended an olive branch time 
and time again.

-- 
Best,
polyzen

[aur-general] TU Application: Daniel M. Capella

[Daniel M. Capella via aur-general]

Hello,

My name is Daniel M. Capella (aka polyzen), and I am applying to be a Trusted
User with Ivy Foster's sponsorship.

My current main interest lies in Rustlang-based blockchain/distributed
app/cryptocurrency implementations; half for the tech, half so I can escape the
world of indentured slavery, fearlessly. My dream for the future is to write
software that will help increase the pace it takes science to build the world
of tomorrow -- whatever that means. I watch too much sci fi.

I hope you like lists as much as I apparently do.



Stats:

- Arch vanilla user since 2013. ALARM user for my home servers since perhaps a
  year or two before then. For completion's sake, even before that I had used
  Ubuntu and Archbang. This year I will be getting the LPIC-2[1] certificate
  (may or may not be related to my LPIC-1 expiring this year ^^).

- Held a workshop called "Git for Gits"[2] with meskarune under the Arch Linux
  Classroom. The class is (very) slowly being revamped for further sessions.

- Coordinated AUR Cleanup Day 2017[3]. The original plan was for this to occur
  every other year, but the previous one was in 2010. I hope to continue the
  tradition of this occurring biennially.

- Co-maintainer of pacman-contrib. Funny story: when I requested Git access,
  Florian gave it to me thinking I was Kyrias. ^^ I had a habit of nick (IRC)
  hopping back then.

- Arch Linux Tester when I remember that's a thing I signed up for.

- Relatively active with IRC and bug tracker support.

- Very active with upstreams WRT packaging and then some.



Here follows the packages I'd like to move to and/or co-maintain in Community:

- Packages I already maintain:

  - Automatic exception:

- espeak-ng (accessibility)

  See also .

  - Popular:

- firefox-ublock-origin
- firefox-umatrix

- pulseaudio-dlna

- python-black 

  Maxim already plans to add this to the repos, but I would like to
  (co-)maintain this, being the original submitter (before it was merged
  into python-black due to the naming convention).

- razercfg/razerd

  - 1% usage on pkgstats:

- firefox-bookmarkdupes
- firefox-multiple-tab-handler
- firefox-referer-control
- firefox-stylus
- firefox-tab-flip-for-tree-style-tab
- Firefox-tree-style-tab

- termdown

- tty-solitaire

  See .

  - There was consensus from a few TU's in #archlinux-aur on considering the
popularity of release variants:

- Popular:

  - shaderc (-git)

See also .

- 1% usage on pkgstats:

  - gmailieer (-git)

  - termtosvg (-git)

- Other users' AUR packages:

  - Popular:

- alot

- hsetroot

- python-proselint

- ttf-symbola

- yamllint

  - 1% usage on pkgstats:

- python-vint

- skim

- Repo packages:

  - Orphans in Extra that I have installed:

- ttf-indic-otf

- vulkan-icd-loader

  - Packages I submitted to the AUR that were adopted or were added to the repos
without checking the AUR first :p:

- asp

- fd

- newsboat



Notes from Ivy that may come up in reviews:

- “These Node.js and mkchromecast packages give me nightmares.”:
  
  ..Okay, actually that was my response when he brought them up.

  mkchromecast has a setup.py for its next release. npm packages have no hope.
  I've had to change chown invocations far too many times. Please don't hate me.

- “This isn't a technical critique; more of an aesthetic one that you probably
  shouldn't listen to. It would be slightly amusing to add firefox as an
  optdepends to firefox-* (-:”:

  firefox was removed as a dep for these to make it easier for people to use
  them with Palemoon and such.

- Go package LDFLAGS:

  Will take care of this.

- “hangups: "sed -i 's/==/>=/g' setup.py" -- why? Also, has that change been
  submitted upstream? It's minor, but if it fixes something it's probably
  worthwhile”:

  Has to be done for pinned outdated dependencies.

- “razercfg: have you submitted that tmpfile.conf upstream? Also, re: the
  install file, I'm pretty sure that ldconfig happens automagically, and
  systemd-udev-reload.hook should handle reloading udev rules”:

  Will take care of this.

- “shaderc: there were a lot of patches in prepare(), which I can say from
  experience probably won't go over super well. I'm guessing these probably are
  waiting on acceptance or something?”:

  See 
  and .

- “no need for install -m755; -m755 is the default”:

  Taking care of this.



Some notes of my own that could be added to the guidelines:

- My Rust packages use published crates if available, eg.: 
  

Re: [aur-general] TU Application: Daniel M. Capella

[Daniel M. Capella via aur-general]

Quoting Eli Schwartz via aur-general (2018-11-15 00:52:50)
> On 11/14/18 11:50 PM, Daniel M. Capella via aur-general wrote:
> > Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
> >> - tests are awesome <3 run them whenever possible! more is better!
> >>   pulling sources from github is favorable when you get free tests
> >>   and sometimes manpages/docs
> > 
> > Will work with the upstreams to distribute these. I prefer to use published
> > offerings as they are what the authors intend to be used. GitHub 
> > autogenerated
> > tarballs are also subject to change:
> > https://marc.info/?l=openbsd-ports=151973450514279=2
> 
> I've seen the occasional *claim* that this happens, but I've yet to see
> any actual case where this happens and it isn't because of upstream
> force-pushing a tag.
> 
> GitHub is supposed to use git-archive(1) for this, which is guaranteed
> to be reproducible when generating .tar, although in theory
> post-filtering this through a compressor like gzip can result in changes
> from one version of git to another. I say in theory because I don't
> recall this ever happening, and git-archive uses the fairly boring defaults.
> 
> I don't see any reason to use substandard sources in order to avoid
> checksum problems I don't believe in.

"substandard" 樂 
https://wiki.archlinux.org/index.php/Python_package_guidelines#Source

> > For Rust sources there's also this problem:
> > https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries
> > 
> > Crates explicitly filter out lock files. `publish-lockfile` for binary 
> > crates
> > is still only available in Cargo nightly. Communication is already in
> > progress with the relevant upstreams.
> 
> I have no clue what this is even supposed to mean. I'm reading your link
> and it says that "it's conventional" for upstream developers of rust
> applications to commit their lockfiles to git, but not to do so for
> libraries. Given that one builds applications, and not libraries, I'm
> unsure what the problem is here.
> 
> Do you mean to say that crates.io doesn't ship all the files available
> in git? Okay, I agree that git is the superior source. I don't generally
> trust "intelligent" tools to decide what's important.
> 
> Still not sure what this doc describing the split between libraries and
> binaries, has to do with anything.

https://github.com/bluejekyll/trust-dns/issues/604#issuecomment-436510626

> >> python-soco:
> >> - there are tests available for check() via py.test
> > 
> > Requires jumping through hoops. See the note:
> > https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=test#running-the-unit-tests
> 
> Sounds like they have two sets of tests: some unittests for the code
> correctness, plus unittests to test the interaction with an online server.
> 
> Also sounds like the former, which are all we care about I suppose,
> should be easy to do without any hoops, just by running pytest?

Yeah, I tried that.

> >> - do we _really_ need to split razer mouse tool UI and daemon here?
> >> doubt it tbh.
> > 
> > The UI is completely optional. ¯\_(ツ)_/¯
> 
> Why does this mean they cannot be a single package?
> 
> -- 
> Eli Schwartz
> Bug Wrangler and Trusted User
> 

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] TU Application: Daniel M. Capella

[Daniel M. Capella via aur-general]

Quoting Levente Polyak via aur-general (2018-11-15 05:19:10)
> On 11/15/18 5:50 AM, Daniel M. Capella via aur-general wrote:
> >> - tests are awesome <3 run them whenever possible! more is better!
> >>   pulling sources from github is favorable when you get free tests
> >>   and sometimes manpages/docs
> > 
> > Will work with the upstreams to distribute these. I prefer to use published
> > offerings as they are what the authors intend to be used. GitHub 
> > autogenerated
> > tarballs are also subject to change:
> > https://marc.info/?l=openbsd-ports=151973450514279=2
> > 
> 
> Well source tree is the source of truth as that's where processed stuff
> comes from :P
> 
> If you can't convince all upstream do distribute their tests and
> especially not convince them to distribute the sources for generating
> docs I would still say please go for source tree instead as the value of
> such additional content is high. We love tests.

Agreed. Will do.

> Side note, nowadays there are lots of python and other project that git
> sign their latest tags and commits but have no other way of detatched
> signatures, this adds a big gain as well. Remember two of your packages
> had upstream tag signatures but i forgot to point them out.
> If I can't convince them to use detatched sinatures as well I nowadays
> just switch to pull git and use ?signed

Noted.

> 
> >> python-soco:
> >> - maybe distribute some docs as well like manpages from docs dir
> > 
> > I don't see any manpages there. This is a library.
> 
> make -C doc man
> Manpages are not exclusive for tools, they are for any kind of
> documentation like library APIs
> try running:
> man 3 sprintf

Done.

> > 
> >> razercfg:
> >> - do we _really_ need to split razer mouse tool UI and daemon here?
> >> doubt it tbh.
> > 
> > The UI is completely optional. ¯\_(ツ)_/¯
> 
> My point is, its the same source and the packages are not huge and it
> doesn't have crazy dependency hells.
> Only split up if it really makes sense, if there is no real reason we
> keep them combined, like tools + libs + headers and don't go as crazy as
> debian about splitting up everything.

It was split for people who don't need to change options on the fly.
Also because I thought it would be kinda neat. :p I don't mind merging
them back together.

> 
> > 
> >> - CPPFLAGS are not respected and should be populated properly
> >>   an upstream patch for that would be best
> > 
> > Will have to figure that out.
> 
> All you need in the PR is add $CPPFLAGS where you already see $CFLAGS.
> For time being either backport this patch or just export
> CFLAGS="${CFLAGS} ${CPPFLAGS} until its done.

This took me for a ride until I realized I just needed to switch to
`CPPFLAGS +=` in the config.mk. A lesson I won't soon forget.

> > 
> > Thank you very much for the review. Go LDFLAGS is still on the todo. 
> > Packaging
> > for Go has perhaps been more traumatizing than even Node.js.
> > 
> 
> 
> You're welcome, always a plesure if people are happy about it :-)
> 

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] TU Application: Daniel M. Capella

[Daniel M. Capella via aur-general]

Quoting Levente Polyak via aur-general (2018-11-14 17:00:38)
> Hi Daniel,
> 
> Small summary of things I repeatedly noticed:
> 
> - # Generated by mksrcinfo v8 Wed Nov 14 05:46:26 UTC 2018
>   I would say remove this ancient package from your system
>   and use makepkg --printsrcinfo instead

Done.

> - if a setup.py uses entry_points for scripts that
>   means setuptools is not just a make but a hard dependency

Totally forgot about this. Thank you for listing all the packages that
need the change; will roll this out.

> - tests are awesome <3 run them whenever possible! more is better!
>   pulling sources from github is favorable when you get free tests
>   and sometimes manpages/docs

Will work with the upstreams to distribute these. I prefer to use published
offerings as they are what the authors intend to be used. GitHub autogenerated
tarballs are also subject to change:
https://marc.info/?l=openbsd-ports=151973450514279=2

For Rust sources there's also this problem:
https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

Crates explicitly filter out lock files. `publish-lockfile` for binary crates
is still only available in Cargo nightly. Communication is already in
progress with the relevant upstreams.

> 
> [+] Running xxarhtna --verbose --pedantic
> 
> asciinema-rs:
> - provides asciinema, but where is the conflicts?

Done.

> black-git:
> - this should be called python-black
> - running unit tests is missing
> - setuptools is a hard dependency, setup.py uses entry_points
> - python-aiohttp should be a checkdepends otherwise tests
>   deactivate several things

Didn't request to be a co-maintainer for this, and haven't looked at the
pkgbuild yet. Will pass the notes along.

> espeak-ng:
> - That shouldn't provide espeak, its not a drop in replacement
>   and breaks stuff, this epoch on espeak is for a reason:
> 
> https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/espeak=fee824f6ed964b1bab1586fdc4342577f2a57bf2
> - autogen.sh should be a prepare() thing

Well then. Done.

> firefox-bookmarkdupes:
> - building from source will have nice signatures

I check these against upstream checksums:
`curl -I https://addons.mozilla.org/firefox/downloads/latest/bookmark-dupes/ | 
grep Digest`

Building Fx extensions is among the last things I want to do. :p Pretty sure I
would have to setup an AMO account to then also sign the extension myself.

> gitleaks:
> - there are tests available for check()

Done.

> mwic
> - the hack does upstream do, it will create .py files in usr/share/mwic/lib/
>   that lack the pyo/pyc files and if running as root the imports will
>   create untracked files in that directory that will remain forever

Will see what can be done.

> pcaudiolib
> - prepare() is a better place for autogen.sh

Done.

> pulldown-cmark
> - there is a Cargo.lock lets use --locked for reproducible builds
>   this requires to pull unstripped sources from github
> - there are also tests available but whatever upstream does, some of
>   them seem to fail? investigate?

https://github.com/raphlinus/pulldown-cmark/pull/152#issuecomment-435519277

> shaderc:
> - i'm sorry, i gonna need to pull this into [extra] as part
>   of an update. thanks for the work

C'est la vie.

> python-black:
> - setuptools is a hard dependency, setup.py uses entry_points
> - python-aiohttp should be a checkdepends otherwise tests
>   deactivate several things

Done.

> python-soco:
> - there are tests available for check() via py.test

Requires jumping through hoops. See the note:
https://soco.readthedocs.io/en/latest/development/unittests.html?highlight=test#running-the-unit-tests

> - maybe distribute some docs as well like manpages from docs dir

I don't see any manpages there. This is a library.

> razercfg:
> - razercfg.install could be removed, ldconfig systemd-tmpfiles and udevadm
>   are handled via hooks

Done.

> - do we _really_ need to split razer mouse tool UI and daemon here?
> doubt it tbh.

The UI is completely optional. ¯\_(ツ)_/¯

> speedtest-zpeters:
> - whats wrong with the tests? maybe comment?

Don't remember exactly. Either way, the packaged release reports the
wrong results, and a complete rewrite is in progress.

> spotify-adkiller-git:
> - i dont like file-type postfixes in /usr/bin they should be removed
>   and ADKILLER= be adjusted

Done.

> spt:
> - this needs a build() func, don't build implicitly in package()

Done.

> - CPPFLAGS are not respected and should be populated properly
>   an upstream patch for that would be best

Will have to figure that out.

> termtosvg:
> - there are nice manpages for this CLI tool in the upstream sourceso on GH

https://github.com/nbedos/termtosvg/pull/77

Poked upstream for a release.

> trust-dns-server:
> - there are tests that could be run via check()

Done. \o/

> 
> [*] xxarhtna report finished
> 
> cheers,
> Levente

Thank you very much for the review. Go LDFLAGS is still on the todo. 

[aur-general] Sourcing GitHub release tarballs without filename::url (was: Re: TU Application: Daniel M. Capella)

[Daniel M. Capella via aur-general]

>>> - The following can be used for GitHub releases (where $url is eg.
>>>   ):
>>>
>>>   - Before:
>>> `source=("$pkgname-$pkgver.tar.gz::$url/archive/v$pkgver.tar.gz")`
>>>   - After: `source=("$url/archive/v$pkgver/$pkgname-v$pkgver.tar.gz")`
>>
>>
>> Correction: $pkgname in the after line is only correct if it matches the
>> project name, tense included -- assuming you like it to match the name of
>> the downloaded tarball. Same goes for the version (eg. the "v" some
>> projects use). For ease of use, perhaps best to keep this out of the
>> guidelines.
>>
>
>Further correction: With the after line, the "v" is always stripped with
>the downloaded tarball. That would make this example:
>`source=("$url/archive/v$pkgver/$pkgname-$pkgver.tar.gz")`

Update(Correction?): You can put whatever you want between the last "/"
and ".tar.gz", and it will be named that.

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] TU Application_R: Metal A-wing (a-wing)

[Daniel M. Capella via aur-general]

On January 19, 2019 1:42:38 AM EST, Chih-Hsuan Yen via aur-general 
 wrote:
>
>On 2019/1/10 下午11:24, Jiachen YANG via aur-general wrote:
>> Dear all TUs
>>
>>
>> The disscussion period of 2 weeks is over! Let's start the voting
>period~
>>
>> https://aur.archlinux.org/tu/?id=116
>>
>>
>> --
>>
>> Jiachen YANG (farseerfc)
>>
>>
>Yes: 5
>No: 36
>Abstain: 8
>Voted: 87.50%
>
>Result: Rejected
>
>Sorry, A-wing, more TUs vote No than Yes and more than 66% of TUs
>voted, so your TU application is rejected this time per TU Bylaws [1].
>You're still welcome for contributions in other aspects of Arch Linux
>like improving Arch-related websites and the Ruby ecosystem. Hope to
>see you again the next time!
>
>Regards,
>
>Chih-Hsuan Yen
>
>[1]
>https://aur.archlinux.org/trusted-user/TUbylaws.html#_addition_of_a_tu

The language barrier is currently too high. Looking forward to your future 
application, if the interest is still there.

--
Best,
polyzen

[aur-general] Purge of packages orphaned, out-of-date, and last updated before 2017

[Daniel M. Capella via aur-general]

Based on the loosely defined "cleanup criteria"[], we're overdue for a
little purge. The candidates can be found here:

https://aur.archlinux.org/packages/?O=0=nd==on=l=a=250_Orphans=Orphans
https://aur.archlinux.org/packages/?O=250=nd=on=l=a=250_Orphans=Orphans

Please run `aurphan -a` to see if you have any orphaned AUR packages installed,
and do everyone a favor by adopting them.

If there are no objections, it will be done this weekend. A reply will
be sent for record-keeping with the list of packages prior to deletion.

[]: 
https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day#Possible_reasons

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] General PKGBUILD and Instalation help.

[Daniel M. Capella via aur-general]

On December 25, 2018 7:37:32 AM EST, hagar  wrote:
>Merry Christmas all,
>
>I have been looking for a general PKGBUILD forum to get some help with 
>some build problems.

There's #archlinux-aur on irc.freenode.net and an Arch forum:
https://bbs.archlinux.org/viewforum.php?id=38

>I have been trying to build the mingw packages using makechrootpkg -c
>
>I have built 436 out of 497 packages.
>
>There are a few corrections I have to submit.

If you didn't know, you could do this through comments on the AUR packages.


--
Best,
polyzen

Re: [aur-general] TU Application: Daniel M. Capella

[Daniel M. Capella via aur-general]

Quoting Ivy Foster via aur-general (2018-12-06 14:38:10)
> Hello, everyone!
> 
> The results are in! Congratulations, Daniel! Welcome to the team.
> 
> Stats:
> 34 Yes
> 6 No
> 7 Abstain
> 
> Cheers,
> Ivy ("escondida")
> 
> P.S.: Please forgive the broken threading; I foolishly cleaned out too
> much of my inbox last week!

Thank you, all! To those who voted no: I will do what I can to change
that senitment.

♪ ヾ(´▽｀*)ゝ ヾ(*´▽｀)ノ ヽ(´▽｀*)ゞ ヽ(*´▽｀)ツ♪

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] Purge of packages orphaned, out-of-date, and last updated before 2017

[Daniel M. Capella via aur-general]

Quoting David Runge (2019-01-26 05:23:37)
> On 2019-01-26 08:01:46 (+0100), Alad Wenter via aur-general wrote:
> > Not too long after I became TU I deleted something of ~2000 packages,
> > based on similar "criteria" and after seeing no "objections" on IRC
> > after a while. After the deed was done I got emails, angry shouting on
> > IRC and complaints for the following 6 months on BBS and other places. 
> "they took our packages" *rantyface* *screaming*
> 
> > tl;dr use requests like everyone else, or patch aurweb to have "batch 
> > requests"
> Yes, please requests! This way stuff at least gets to the mailing list
> and is somewhat documented.
> 
> -- 
> https://sleepmap.de

Thank you for your level-headed responses. More to add to my long list
of aurweb patch ideas.

I wonder if Johannes' "Make delete and merge links create an
auto-accepted request" patch[] being deployed would be sufficient. I
readily accept requests for this criteria, but couldn't imagine manually
accepting almost 500 of them with the current setup.

https://patchwork.archlinux.org/patch/911/

--
Best,
polyzen


signature.asc
Description: signature

Re: [aur-general] Is vlc-pause-click-plugin unmaintained now?

[Daniel M. Capella via aur-general]

On April 6, 2019 2:26:45 AM EDT, Frederick Zhang via aur-general 
 wrote:
>Hi,
>
>It seems that vlc-pause-click-plugin has been unlisted from AUR for
>quite a while. I just quickly went through aur-general and aur-requests
>but I didn't find any info about the reason.
>
>May I know whether it's now unmaintained and whether it's possible for
>me to adopt the package? Thanks.

Its upstream had a commit today, so that's still maintained. You could do:

ssh a...@aur.archlinux.org restore vlc-pause-click-plugin

--
Best,
Daniel (dmc/polyzen)
https://danielcapella.com

Re: [aur-general] Spammers in AUR user comments

[Daniel M. Capella via aur-general]

On April 5, 2019 7:54:44 AM EDT, NicoHood  wrote:
>Hello,
>lately i have noticed an increased percentage of spam comments in the
>AUR. Especially for the spotify package there were 4 accounts I had to
>block within a few weeks. Have you been able to make similar
>observations with your packages or is this an exception? Should and how
>can we better protect ourselves from spam comments?
>
>~Nico

Well, it would make sense that you'd notice that after becoming the 
co-maintainer for the 2nd-most popular AUR package. :P None of my packages have 
gotten spam. I've only recently become a TU, so I may just not have noticed the 
general trend, but it feels like there has been an increase.

--
Best,
Daniel (dmc/polyzen)
https://danielcapella.com

Re: [aur-general] plethora of spams

[Daniel M. Capella via aur-general]

On March 20, 2019 3:49:00 AM EDT, marnout  wrote:

~snip~

>P.S.
>I have a lot of free time and i can participate by doing certain tasks 
>for the community. For instance I can clean up in aur under the
>guidance 
>of a TU.

https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day

Of course requests[1] made outside of that day are also considered. :)

[1]: https://wiki.archlinux.org/index.php/Arch_User_Repository#Other_requests

--
Best,
polyzen

Re: [aur-general] AUR spam accounts

[Daniel M. Capella via aur-general]

Quoting Luca Weiss via aur-general (2019-03-30 07:01:32)
> Hello,
> the account https://aur.archlinux.org/account/charlizekrish/ left a spam 
> account on one of my packages.
> 
> After looking through the most popular packages I found a few more:
> https://aur.archlinux.org/account/hendrikb
> https://aur.archlinux.org/account/AngelaKinsey52
> https://aur.archlinux.org/account/arianapham
> https://aur.archlinux.org/account/johnkeo
> 
> Thanks,
> Luca

Taken care of, thank you.

--
Best,
Daniel (dmc/polyzen)
https://danielcapella.com


signature.asc
Description: signature

[aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)

[Daniel M. Capella via aur-general]

On February 28, 2019 8:58:06 AM EST, Jerome Leclanche  wrote:



>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

I've been thinking enforcing the use of makechrootpkg and namcap on package 
submission should be introduced, and maybe even on major (and minor?) version 
bumps for packages following semver. Inb4 yes I'm aware of the number of 
false-positives in namcap.

--
Best,
polyzen

Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)

[Daniel M. Capella via aur-general]

On February 28, 2019 11:33:36 AM EST, "brent s."  wrote:
>On 2/28/19 11:22 AM, Daniel M. Capella via aur-general wrote:
>> On February 28, 2019 8:58:06 AM EST, Jerome Leclanche
> wrote:
>> 
>> 
>> 
>>> 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
>> 
>> I've been thinking enforcing the use of makechrootpkg and namcap on
>package submission should be introduced, and maybe even on major (and
>minor?) version bumps for packages following semver. Inb4 yes I'm aware
>of the number of false-positives in namcap.
>> 
>> --
>> Best,
>> polyzen
>> 
>
>you could get around the namcap false-positives by maybe assigning a
>"quality score" instead of a pass/fail, with a certain required
>threshold set.
>
>there aren't really enough data points for a really useful scoring in
>namcap alone, though, so you'd want to implement other scoring points
>too.
>e.g.:
>- 50 for a successful makechrootpkg
>- 10 for each namcap test pass
>- 10 for proper comment per spec[0] (i.e. '#\s*(M|m)aintainer:', etc.)
>
>and anything higher than, i dunno, 70 or 80 is considered pass and
>below
>is fail.
>
>or just attach a warning for each namcap failure to the package's info
>in the AUR.
>
>
>[0]
>https://wiki.archlinux.org/index.php/Arch_package_guidelines#PKGBUILD_prototype

Listing the false-positives could be good, especially as that would point out 
what needs to be improved in namcap.

--
Best,
polyzen

Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)

[Daniel M. Capella via aur-general]

On February 28, 2019 11:34:08 AM EST, Jerome Leclanche  wrote:
>On Thu, Feb 28, 2019 at 5:22 PM Daniel M. Capella via aur-general
> wrote:
>>
>> On February 28, 2019 8:58:06 AM EST, Jerome Leclanche
> wrote:
>>
>> 
>>
>> >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
>>
>> I've been thinking enforcing the use of makechrootpkg and namcap on
>package submission should be introduced, and maybe even on major (and
>minor?) version bumps for packages following semver. Inb4 yes I'm aware
>of the number of false-positives in namcap.
>>
>> --
>> Best,
>> polyzen
>
>Can we give namcap's outputs error codes and blacklist some of the
>false positives?

That seems in line with well-established linters. It would also be nice if a 
linting plugin for an editor (eg. ALE for Vim) could utilize namcap someday.

>I was mostly thinking about things that can be done just by static
>analysis of the PKGBUILD, rather than anything requiring packages to
>be built, so that they can be rejected immediately during git push.
>Things such as running mksrcinfo, verifying local sources (and their
>hashes), etc.

The tool mentioned in alad's reply seems interesting. Will have to check it out.

>J. Leclanche



--
Best,
polyzen

Re: [aur-general] Enforcing AUR package quality (was Re: Trusted user application: Drew DeVault)

[Daniel M. Capella via aur-general]

On February 28, 2019 12:43:02 PM EST, Eli Schwartz via aur-general 
 wrote:
>On 2/28/19 11:22 AM, Daniel M. Capella via aur-general wrote:
>> On February 28, 2019 8:58:06 AM EST, Jerome Leclanche 
>>  wrote:
>> 
>> 
>> 
>>> 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
>> 
>> I've been thinking enforcing the use of makechrootpkg and namcap on 
>> package submission should be introduced, and maybe even on major
>> (and minor?) version bumps for packages following semver.
>
>LMAO no.
>
>What part of
>
>> I would eagerly welcome any way to reliably do exactly that in an 
>> automated fashion, with the caveat that doing so more or less 
>> inevitably involves arbitrary code execution -- this is the reason 
>> why we in fact do not read the PKGBUILD at all, but created the 
>> .SRCINFO instead.
>
>was not clear? We are not introducing arbitrary remote code execution
>by
>building all AUR packages before accepting them for upload?

You misread.

>Furthermore if we were going to do this, we might as well host the
>binary results and not bother with this whole "AUR" thing at all.
>
>> Inb4 yes I'm aware of the number of false-positives in namcap.
>
>If you explicitly state you're aware of the exact, in-depth reason why
>this is completely a no-go from the start, then... why did you say
>anything?
>
>In case it wasn't obvious... namcap is an interactive review tool and
>completely unsuitable for automated judgment of *anything*. I also
>severely dislike the idea of enforcing ridiculous and inescapable
>restrictions *for any reason* on users who are doing nothing wrong,
>which most "namcap is God" victims will be.
>
>In summary, I am putting on my aurweb maintainer hat and saying "no, we
>shall not enforce any such thing".
>
>Further emails in this irrelevant tangent subthread derail of the TU
>application process are not necessary and I shall not bother responding
>to them, or reading further.

Every single reply you've given my emails since ignoring me on IRC has been as 
rude and oppressive as this one. As such, again I won't bother with a proper 
response. Please just treat the mailing lists like IRC and ignore me here as 
well. Also, grow up.


--
Best,
polyzen

Re: [aur-general] Trusted user application: Drew DeVault

[Daniel M. Capella via aur-general]

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] Account Status

[Daniel M. Capella via aur-general]

On February 12, 2019 5:47:00 PM EST, "Gonçalo Pereira via aur-general" 
 wrote:
>Hello,
>
>My account was suspended a few months ago. I would like to continue 
>helping to fix packages even though I haven't been decent in previous 
>incidents.
>
>Can I get my account unsuspended?
>
>Hope you can understand,
>
>Regards,
>
>Gonçalo Pereira

It's actually been one month. Given the tensions during the suspension, you 
should give it more time before discussing a possible reversal.

--
Best,
polyzen

Re: [aur-general] Spammers in AUR user comments

[Daniel M. Capella via aur-general]

On April 5, 2019 7:54:44 AM EDT, NicoHood  wrote:
>Should and how can we better protect ourselves from spam comments?

Perhaps we should add CAPTCHA for account registrations.

On April 10, 2019 7:35:14 AM EDT, Oscar via aur-general 
 wrote:
>I'm also receiving comments from lots of different spam accounts in
>unity-editor.  I'm not a TU and the web gui doesn't seem to have an
>option
>to deal with it.
>
>What's the protocol for these cases?

Shoot us an email here.

>Thanks,
>Oscar.


--
Best,
Daniel 

Re: [aur-general] spam messages, cndrvcups-lb

[Daniel M. Capella via aur-general]

On April 19, 2019 8:31:00 AM EDT, Georg Pfahler  
wrote:
> and another one:
> 
> https://aur.archlinux.org/account/alvinrr/

Account suspended. Will delete comments later as I'm on my phone and there is 
no batch deletion yet. It made 15 comments last night within 40 minutes.

--
Best,
Daniel 

Re: [aur-general] Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

[Daniel M. Capella via aur-general]

Quoting Lone_Wolf (2019-05-04 18:24:28)
> I have decided how to proceed with mesa trunk / llvm trunk building.
> 
> There are now 6 lone_wolf-* packages in AUR that show how I want to do 
> things.
> 
> 
> Although Scimmia intensely disliked it, I have implemented the 
> environment variable idea in lone_wolf-mesa-git .
> 
> First tests are promising, I could succesfully build mesa trunk against 
> stable llvm with this command :
> 
> lone_wolf_use_llvm=4 makepkg -Crs
> 
> After some more testing I'll use the same method in 
> lone_wolf-lib32-mesa-git .
> 
> 
> Whether those PKGBUILDs will be used in future aur mesa-git , 
> exclusively in aur lone_wolf-* packages or not present in AUR at all is 
> a decision TUs must take.
> 
> 
> I uploaded my first AUR package somewhere in 2006 and would hate to have 
> to take my packages elsewhere.
> 
> However TUs have always been the people that administer AUR not the 
> users. IF TUs tell me my packages are not wanted in AUR I have to follow 
> my own personal standards and remove the packages.
> 
> Waiting for a decision, Lone_Wolf

https://lists.archlinux.org/pipermail/aur-requests/2019-May/031274.html

https://lists.archlinux.org/pipermail/aur-requests/2019-May/031310.html

v_v

--
Best,
Daniel 


signature.asc
Description: signature

Re: [aur-general] Question about creating AUR package

[Daniel M. Capella via aur-general]

On July 13, 2019 11:56:29 AM EDT, "joão marcos pereira bezerra via aur-general" 
 wrote:
> Hello, i'm new to this mailing list, here because i want to submit a
> AUR Package
> 
> It's called "corrupter-bin", an alternative to "corrupter-git" that
> avoids installing Go-Lang package (400MB)
> 
> What are the steps? after creating the PKGBUILD what do i do?

https://wiki.archlinux.org/index.php/AUR_submission_guidelines

--
Best,
Daniel 

Re: [aur-general] spam account: harveyjones

[Daniel M. Capella via aur-general]

On April 22, 2019 7:43:46 PM EDT, Rafael Fontenelle  wrote:
> Offending account: https://aur.archlinux.org/account/harveyjones
> 
> This account was created today (Apr 22, 2019) and maintain no package
> and the only comment was a spam in skyperforlinux-stable-bin:
> 
> https://aur.archlinux.org/packages/skypeforlinux-stable-bin#comment-690933
> 
> Can this be removed?
> 
> Best regards,
> Rafael Fontenelle

Taken care of, thank you.

--
Best,
Daniel 

Re: [aur-general] Spam users: garrlee and harrywepich9

[Daniel M. Capella via aur-general]

On September 4, 2019 6:04:29 PM EDT, Mark Weiman  wrote:
> My turn!
> 
> I've got a couple of spam comments on [1] from the latest two
> comments.
> 
> Mark Weiman
> 
> [1] https://aur.archlinux.org/packages/python-latex/

Deleted, thank you.

--
Best,
Daniel 

[aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

Do you like popping other people's pimples? Gross, me neither.

Anyways, next Friday is our bi-yearly AUR Cleanup Day -- join
#archlinux-aur and BYOB.

The wiki article[1] has instructions for how to proceed and space to
compile our list of candidates. Here's[2] an example from a previous
rendition of Purge Day.

[1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
[2] https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010=353326

--
Good hunting,
Daniel 


signature.asc
Description: signature

Re: [aur-general] spam comments

[Daniel M. Capella via aur-general]

On September 7, 2019 9:52:15 AM EDT, Lone_Wolf  wrote:
> Hi,
> 
> please remove some spam comments from cndrvcups-lb package .
> 
> 
> https://aur.archlinux.org/packages/cndrvcups-lb/#comment-704963
> 
> https://aur.archlinux.org/packages/cndrvcups-lb/#comment-704962
> 
> 
> user account is https://aur.archlinux.org/account/shandireza , please 
> disable.
> 
> 
> I'm 99% sure I've seen that homepage listed with many other spam 
> accounts, is there a way to block certain homepages from registering ?
> 
> 
> Lone_Wolf

Deleted, thank you.

--
Best,
Daniel 

Re: [aur-general] Naming issue of mysql-shell and (possibly) request for adoption

[Daniel M. Capella via aur-general]

Quoting Frederick Zhang via aur-general (2019-09-10 02:31:15)
> 1. rename mysql-shell to mysql-shell-bin
> 2. allow current mysql-shell users to upgrade to mysql-shell-bin by
> default like how 'replaces' works
> 3. ...and I can submit a new mysql-shell package

I suggest you file an adoption request, and if it's accepted, pin
something in the comment section about the change. If people still want
a -bin version, let them take care of that.

--
Best,
Daniel 


signature.asc
Description: signature

Re: [aur-general] TU application: kpcyrd

[Daniel M. Capella via aur-general]

Quoting kpcyrd (2019-09-20 16:09:31)
> Hello,
> 
> My name is kpcyrd and I'm applying to become a Trusted User with anthraxx', 
> sangys and jelles sponsorship.

Glad to see you're finally applying.

Package review:

narnia, tr1pd{,-git}: Could use `--locked`?

python-fints: Missing `--skip-build` in `package()`.

Only nit I have aside from those is you don't need to specify 755
permissions for `install` as that's the default. Something I learned
during my own Tu application process ^^.

--
Best,
Daniel 


signature.asc
Description: signature

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

_Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got a
head start -- much appreciated.

> The wiki article[1] has instructions for how to proceed and space to
> compile our list of candidates. Here's[2] an example from a previous
> rendition of Purge Day.
>
> [1] https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
> [2] 
> https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010=353326
> --
> Good hunting,
> Daniel 


signature.asc
Description: signature

Re: [aur-general] AUR Cleanup Day September 20th 2019

[Daniel M. Capella via aur-general]

On September 20, 2019 12:20:31 PM EDT, Michael Straube via aur-general 
 wrote:
> 
> 
> Am 20.09.19 um 18:06 schrieb Michael Straube via aur-general:
> > Am 20.09.19 um 06:41 schrieb Daniel M. Capella via aur-general:
> >> _Today_ is our bi-yearly AUR Cleanup Day. It seems a few of us got
> a
> >> head start -- much appreciated.
> >>
> >>> The wiki article[1] has instructions for how to proceed and space
> to
> >>> compile our list of candidates. Here's[2] an example from a
> previous
> >>> rendition of Purge Day.
> >>>
> >>> [1]
> https://wiki.archlinux.org/index.php/DeveloperWiki:AUR_Cleanup_Day
> >>> [2]
> https://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010=353326
> >>> -- 
> >>> Good hunting,
> >>> Daniel <https://danielcapella.com>
> > 
> > Below is a list of python/python2 split packages whose python3
> versions are in [community].
> > So the python3 versions in AUR are duplicates, but not the python2
> versions.
> > 
> > I think the split packages should be removed from AUR and re-added
> as python2 only
> > versions. (Or perhaps just re-add the python2 versions that are
> dependencies for
> > other packages..)
> > 
> > https://aur.archlinux.org/packages/python-dominate/
> > https://aur.archlinux.org/packages/python-funcparserlib/
> > https://aur.archlinux.org/packages/python-inflection/
> > https://aur.archlinux.org/packages/python-pipreqs/
> > https://aur.archlinux.org/packages/python-rstr/
> > https://aur.archlinux.org/packages/python-tomlkit/
> > 
> 
> Oh sorry, I missed this one:
> 
> https://aur.archlinux.org/packages/python-yarg/
> 
> > Cheers,
> > Michael

Filed deletion requests for the rest of these.

--
Best,
Daniel <https://danielcapella.com>

Re: [aur-general] [PRQ#16805] Deletion Request for the-darkmod-tweaked

[Daniel M. Capella via aur-general]

On November 26, 2019 9:46:41 AM EST, "Iyán Méndez Veiga"  
wrote:
> De verdad... pásame tu cuenta, que te hago una transferencia para
> pagarte el 
> psicólogo... 
> 
> En serio que te creo que en tu cabeza todos vayan en contra de ti, el
> mundo 
> esté alineado perfectamente en tu contra, y la comunidad de Arch,
> Ubuntu, 
> etc., etc. te atacan, pero esa NO ES LA REALIDAD.
> 
> Cuanto antes te des cuenta, mejor para ti. Así que reflexiona unos
> minutos (en 
> vez de hacer otro vídeo demente en tu canal de Youtube) y piensa cómo
> puedes 
> cambiar para que tu percepción del mundo se ajuste más con la
> realidad.
> 
> Sinceramente,
> Un usuario de Arch harto de leer tus comentarios agresivos, tu spam en
> las 
> listas de correo, y tus video-respuestas delirantes.

When replying through the mailing list (not directly to him), please 
communicate in English.

--
Best,
Daniel 

Re: [aur-general] Package Rename Requests (2) - waterfox-git and waterfox-alpha-git

[Daniel M. Capella via aur-general]

Quoting Matt Parnell via aur-general (2019-10-07 01:16:31)
> I request that my git PKGBUILDs for Waterfox be renamed thusly to
> reflect the current release naming scheme that Waterfox is now using:
> 
> waterfox-git -> waterfox-classic-git
> 
> waterfox-alpha-git -> waterfox-current-git
> 
> Thank you!
> 
> 

Upload packages[1] with the new names and then file merge requests[2].

[1]: 
https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Creating_package_repositories
[2]: https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Requests

--
Best,
Daniel 


signature.asc
Description: signature

Re: [aur-general] Spam comments

[Daniel M. Capella via aur-general]

On October 8, 2019 4:53:43 PM EDT, fg-devel+archmail--- via aur-general 
 wrote:
> Hi,
> 
> there are some spam messages in the comments section of AUR package
> akira-git:
> 
> https://aur.archlinux.org/packages/akira-git#comment-704048
> 
> https://aur.archlinux.org/packages/akira-git#comment-703169
> 
> Greetings,
> Felix

Deleted.

--
Best,
Daniel 

Re: [aur-general] Question about AUR submission guidelines rule #1

[Daniel M. Capella via aur-general]

On February 27, 2020 11:19:20 AM EST, Chris Billington via aur-general 
 wrote:
> Apologies, Lone_Wolf already mentioned the case of older versions of
> packages.
> 
> I suppose my only additions then are that "modified build process"
> should
> be allowed, and that maybe the criterion for older versions to be
> allowed
> should be that they do not conflict with the corresponding newer
> package in
> the repo.
> 
> -Chris
> 
> On Thu, Feb 27, 2020 at 11:12 AM Chris Billington <
> chrisjbilling...@gmail.com> wrote:
> 
> > My AUR packages (pkgbase: linux-versioned-bin and
> linux-lts-versioned-bin)
> > are identical to the repo kernels, but with renamed packages/files
> so as to
> > allow multiple versions to be installed simultaneously without
> conflict.
> > They are an experiment in resolving bug 16702 (
> > https://bugs.archlinux.org/task/16702), and I think should be
> allowed to
> > exist, though they would seem to fall afoul of the rules too! There
> are no
> > patches to the upstream for example - merely packaging differences.
> >
> > Another AUR package of mine, mercurial-python3 is the same as the
> official
> > repos except built with Python 3 instead of Python 2. Again this
> isn't a
> > patch, it's a change in the build process. (This package is required
> for
> > other AUR packages - specifically tortoisehg, but will be superseded
> by the
> > official repos once [community]/mercurial builds with Python 3 which
> I
> > expect to occur soon - I think it was held back due to a specific
> bug).
> >
> > It seems like the rules are trying to say what *is* allowed instead
> of
> > what isn't, when the latter might be clearer. It seems that what is
> > intended is something like:
> >
> > "AUR packages may not comprise unmodified official upstream releases
> of
> > packages in the official repositories, regardless of version.
> Packages
> > whose source or build are modified compared to the official
> repositories
> > are allowed, but must reflect those modifications in the package
> name.
> > "
> >
> > There likely need to be further exceptions even to that though -
> Qt4,
> > gcc7, Python2 (the latter still in the official repos but sometime
> soon
> > will be AUR only) - these are unmodified different versions of
> packages
> > available in the official repositories. But they are the kind of
> "different
> > version" that have crossed the threshold of meriting being separate
> > packages. This should be allowed too (otherwise the Qt4 package
> would be
> > violating the rules already). Other older versions of Python such as
> 3.5,
> > 3.6, 3.7 are also available in the AUR. Are they in violation of the
> > intention behind the rules, or should exceptions be carved out for
> them as
> > well? If so, maybe the criterion for an exception should be if the
> package
> > is : a) an older release than in the repos and b) does not conflict
> with
> > the package in the official repos. My impression of the rule is that
> it is
> > intended to focus efforts on improving repository packages, rather
> than
> > having a "mutiny" of sorts and people moving to an AUR package just
> because
> > a repository package is out of date. But *older* packages don't
> exacerbate
> > that issue, so perhaps they should be allowed to.
> >
> > After that the rule would be something like:
> >
> > "AUR packages may not comprise unmodified official upstream releases
> of
> > packages in the repositories, regardless of version. Packages whose
> source
> > or build are modified compared to the official repositories are
> allowed,
> > but must reflect those modifications in the package name. An AUR
> package
> > for an *older* upstream release of a package than that in the
> repositories
> > is allowed, provided it does not conflict with the corresponding
> package in
> > the official repositories. "
> >
> > Perhaps I've misunderstood the intent behind the rule, but it seems
> like
> > it would need to be much more limited than at present, unless one
> bites the
> > bullet and says many of these AUR packages should be removed.
> >
> > -Chris
> >
> >
> > On Thu, Feb 27, 2020 at 10:43 AM Lone_Wolf
> 
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> Scimmia pointed me to [1] in answer of  a request by me on forum. I
> >> re-read the page and realised the exception to the first rule
> leaves
> >> some things open.
> >>
> >> text quoted from wiki for reference :
> >>
> >>   * The submitted PKGBUILDs must not build applications *already in
> any*
> >> of the *official* binary *repositories* under any
> circumstances.
> >> Check the official package database
> >>  for the package. If any
> >> version of it exists, *do not* submit the package. If the
> official
> >> package is out-of-date, flag it as such. If the official
> package is
> >> broken or is lacking a feature, then please file a bug report
> >> .
> >>
> >> *Exception* to this strict rule may 

Re: [aur-general] chirp-daily

[Daniel M. Capella via aur-general]

On January 31, 2020 5:14:58 PM EST, Zion Zero  wrote:
> Greetings
> 
> I'd like to contribute to the Arch community by updating the
> chirp-daily
> AUR pkgbuild. I've updated the pkgbuild, added my ssh key to my AUR
> account
> and tested this on my local system with success. After reviewing the
> wiki
> I'm unsure of how to become the maintainer. I've emailed the current
> maintainer and received his blessing to take over the package.
> Otherwise
> I'm unable to push the changes as I do not have the proper ssh origin.
> 
> Thanks!
> Kayin

Hi Kayin,

Ask the maintainer to add you as a co-maintainer or to disown the package.

--
Best,
Daniel 

Re: [aur-general] chirp-daily

[Daniel M. Capella via aur-general]

On February 2, 2020 9:02:48 PM EST, Zion Zero  wrote:
> Unfortunately the current maintainer (gearshift
> <https://aur.archlinux.org/account/gearshift>) cannot be contacted via
> the
> AUR page as his email is hidden.
> 
> On Sun, Feb 2, 2020 at 2:31 PM Daniel M. Capella via aur-general <
> aur-general@archlinux.org> wrote:
> 
> > On January 31, 2020 5:14:58 PM EST, Zion Zero 
> wrote:
> > > Greetings
> > >
> > > I'd like to contribute to the Arch community by updating the
> > > chirp-daily
> > > AUR pkgbuild. I've updated the pkgbuild, added my ssh key to my
> AUR
> > > account
> > > and tested this on my local system with success. After reviewing
> the
> > > wiki
> > > I'm unsure of how to become the maintainer. I've emailed the
> current
> > > maintainer and received his blessing to take over the package.
> > > Otherwise
> > > I'm unable to push the changes as I do not have the proper ssh
> origin.
> > >
> > > Thanks!
> > > Kayin
> >
> > Hi Kayin,
> >
> > Ask the maintainer to add you as a co-maintainer or to disown the
> package.
> >
> > --
> > Best,
> > Daniel <https://danielcapella.com>
> >

Then you can attempt to contact him through the AUR comments for this package 
and/or file an orphan request.

--
Best,
Daniel <https://danielcapella.com>

Re: [aur-general] Review of clickhouse-static PKGBUILD

[Daniel M. Capella via aur-general]

On February 10, 2020 5:02:08 AM EST, Felixoid via aur-general 
 wrote:
> Hello, dear TUs and Arch developers.
> 
> I'd like to ask relative the package clickhouse-static[1]. The
> officially supported way to build ClickHouse binaries is static
> linking[2]. And my question: is it possible that the package with the
> current building structure (getting contribs like submodules in
> upstream, static linking etc.) would theoretically come to [community]
> repository?
> 
> Best regards,
> Mikhail f. Shiryaev
> 
> [1] https://aur.archlinux.org/packages/clickhouse-static/
> [2] https://clickhouse.tech/docs/en/development/style/#platform

Unlikely, but not really worth the conversation unless a team member wants to 
add it to the repos.

--
Best,
Daniel 

Re: [aur-general] Change package name?

[Daniel M. Capella via aur-general]

On Tue Jan 7, 2020 at 10:56 PM, brent s. wrote:
> It's a pretty simple process, just not really documented anywhere to my
> knowledge.

It's documented here, but certainly could be expanded upon:
https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Requests

--
Best,
Daniel 

Re: [aur-general] AUR requests not handled anymore?

[Daniel M. Capella via aur-general]

On May 6, 2020 1:55:55 AM EDT, Christoph Gysin via aur-general 
 wrote:
> I have made two deletion requests on my packages 2 weeks ago, that
> were
> never handled:
> 
> https://lists.archlinux.org/pipermail/aur-requests/2020-April/039815.html
> https://lists.archlinux.org/pipermail/aur-requests/2020-April/039825.html
> 
> Has the process changed? What can I do to get these handled?
> 
> Thanks,
> Chris

I'm actually currently trying to take care of a bit of the queue; will look at 
those for you.

The queue has been a bit overloaded. Lately I myself generally focus on tickets 
that have hit the 2 week mark and people will have had time to resolve or argue 
against them.

--
Best,
Daniel 

Re: [aur-general] PKGBUILD submission: osrs-launcher

[Daniel M. Capella via aur-general]

On Sat May 2, 2020 at 2:21 PM EDT, Nick Shvelidze wrote:
> On Sat, May 2, 2020, 17:43 Rafael Fontenelle  wrote:
>
> > Hi Nick,
> >
> > Em sáb., 2 de mai. de 2020 às 07:41, Nick Shvelidze
> >  escreveu:
> > >
> > > Hi, I couldn't find the official Old School RuneScape launcher in the
> > > AUR, so I decided to package it, using the official mac client as
> > > source.
> > > I have written a simple sh script to launch the included jar file
> > > (with options extracted from  Info.plist file). I'm also extracting
> > > the icons from mac icns
> > > The pkgver I also got from the Info.plist file, I don't know if it's
> > > possible to extract programmatically.
> > >
> > > I couldn't find the official license for this anywhere, except a
> > > generic terms and conditions page of Jagex, which is in HTML format, I
> > > don't know if I should scrape it as text and include in package.
> > >
> > > # Maintainer: Nikoloz Shvelidze 
> > > pkgname=osrs-launcher
> > > pkgver=1.2
> > > pkgrel=1
> > > epoch=
> > > pkgdesc="Official OldSchool RuneScape launcher"
> > > arch=(any)
> > > url="https://oldschool.runescape.com/;
> > > license=('unknown')
> > > groups=()
> > > depends=(java-runtime bash)
> > > makedepends=(p7zip libicns)
> > > checkdepends=()
> > > optdepends=()
> > > provides=()
> > > conflicts=()
> > > replaces=()
> > > backup=()
> > > options=()
> > > install=
> > > changelog=
> > > source=("https://www.runescape.com/l=1/downloads/OldSchool.dmg;
> > > "osrs-launcher" "osrs-launcher.desktop")
> > > noextract=()
> > > md5sums=(af345cb11c7e392c15e4d2681d9de17f SKIP SKIP)
> > > validpgpkeys=()
> > >
> > > prepare() {
> > > cd "$srcdir"
> > > 7z e "OldSchool.dmg" -o"$pkgname-$pkgver" -aoa "Old School
> > > RuneScape/Old School
> > > RuneScape.app/Contents/Java/jagexappletviewer.jar"
> > > 7z e "OldSchool.dmg" -o"$pkgname-$pkgver" -aoa "Old School
> > > RuneScape/Old School RuneScape.app/Contents/Resources/OSRS.icns"
> > > cd "$pkgname-$pkgver"
> > > icns2png -x "OSRS.icns"
> > > }
> > >
> > > package() {
> > > mkdir -p "$pkgdir/usr/share/osrs-launcher"
> > > mkdir -p "$pkgdir/usr/share/pixmaps"
> > > mkdir -p "$pkgdir/usr/share/applications"
> > > mkdir -p "$pkgdir/usr/bin"
> > >
> > > install -Dm644 "$pkgname-$pkgver/OSRS_512x512x32.png"
> > > "$pkgdir/usr/share/pixmaps/osrs-launcher.png"
> > > install -Dm644 "$pkgname-$pkgver/jagexappletviewer.jar"
> > > "$pkgdir/usr/share/osrs-launcher/jagexappletviewer.jar"
> > > install -Dm755 "osrs-launcher" "$pkgdir/usr/bin/osrs-launcher"
> > > install -Dm644 "osrs-launcher.desktop"
> > > "$pkgdir/usr/share/applications/osrs-launcher.desktop"
> > > }
> >
> > openosrs-launcher-appimage [1] seems to already provide OldSchool
> > RuneScape launcher in AppImage file.  How do your PKGBUILD differ from
> > that one in terms of resulting software? (your PKGBUILD has
> > "official", not sure if this appimage's source is official)
> >
> > [1] https://aur.archlinux.org/packages/openosrs-launcher-appimage
> >
> > Besides that, some comments on your PKGBUILD:
> > 1. You can remove fields not used, like options=(), backup=(), etc.
> > 2. In package(), there is no need for using "mkdir" and then "install
> > -D"; -D flag already creates all the directory tree for that file.
> > 3. Regarding license, it could be proprietary. If that so, maybe
> > Jagex's "Terms and Conditions" apply to this source. I can't tell for
> > sure.
> > 3. Using MacOS binary in Linux? I didn't run your PKGBUILD, but I hope
> > you tested and made sure it works. :)
> >
> > Cheers,
> > Rafael Fontenelle
> >
>
> Hi Rafael, my PKGBUILD extracts the Java launcher jar from the official
> MacOS app. It's a cross-platform jar and I'm sure the Windows app uses
> the
> same one, just it's distributed as Windows Installer msi and harder to
> extract.
>
> The appimage you linked seems to be a third-party application.
>
> I'll remove the mkdir lines and unused files from my PKGBUILD.
>
> I'm also thinking if I should make this a -bin package since it doesn't
> build anything.
>
> >

Java packages are exempt from having to use -bin:
https://wiki.archlinux.org/index.php/AUR_submission_guidelines#Rules_of_submission

--
Best,
Daniel 

Re: [aur-general] Commercial spam

[Daniel M. Capella via aur-general]

On July 29, 2020 2:44:29 PM EDT, stefan-husm...@t-online.de wrote:
> 
> Hello TUs,
> 
> there is a unrelated comment for [1] which offers a service for lazy
> students. 
> 
> [1] https://aur.archlinux.org/pkgbase/ucdavisthesis/
> 
> Thanks for regarding.
> 
> Stefan Husmann

Justin (hashworks) took care of this. Thanks for the report.

--
Best,
Daniel 

Re: [aur-general] Requirements to apply for TU?

[Daniel M. Capella via aur-general]

On Fri Aug 7, 2020 at 12:05 AM EDT, Ram Kumar via aur-general wrote:
> yeah, me too curious about this topic.. by the way, what does Trusted
> User
> mean? and some details like purpose of one, responsibilities, facilities
> etc..
>
> On Fri, 7 Aug 2020 at 07:39, Angel Pérez  wrote:
>
> > Wich ones are the requirements for apply to be a Trusted User?
> > I know there are some on the ArchWiki, but I want some suggestions from
> > aur-general users.
> > Thanks

https://wiki.archlinux.org/index.php/Trusted_Users

--
Best,
Daniel 

Re: [aur-general] account creation confimation email missing

[Daniel M. Capella via aur-general]

On December 28, 2020 6:43:51 PM EST, "Ryan S. Elliott via aur-general" 
 wrote:
> Hello,
> 
> I created an account a few hours ago and have not received a
> confirmation
> email to reset my password.  Using the
> https://aur.archlinux.org/passreset/
> page also does not seem to work.
> 
> Can someone help me get my account confirmed?
> 
> Thanks!
> 
> Ryan Elliott

The devops team have fixed this. IIUC you should have received the email by now.

--
Best,
Daniel