Eli Schwartz via aur-general 於 2018/8/23 下午12:20 寫道:

On 8/15/18 9:10 AM, Chih-Hsuan Yen via aur-general wrote:

...

Hi all,

My name is Chih-Hsuan Yen. I'm also known as yan12125.

I am applying to be a Trusted User with Felix Yan's sponsorship.

I'm currently a PhD student in Taiwan. My Linux journey started when I met Ubuntu in 2011. Soon after that, I jumped to Arch Linux in 2012 for its simplicity. During my spare time, I'm active in open source stuffs. You may find some interesting bits on my GitHub [1] and GitLab [2] accounts.

Most of my Arch contributions can be found on AUR [3]. Besides that, I'm also an Arch Linux tester and a member of Arch Linux China community, keeping some binary packages in the unofficial repo [archlinuxcn] up-to-date [4]. Are you active on IRC by any chance, and if so, do you idle in any of our official channels: https://wiki.archlinux.org/index.php/IRC_channel

Most of time I'm on the Chinese channel #archlinux-cn. I've also joined the main channel #archlinux recently.

...

If I'm accepted as a TU, I'd like to improve the ecosystem for Arch users speaking Chinese. Specifically, I'll keep an eye on Chinese IME (Input Method Engine) and font packages, including but not limited to the following ones:

- libchewing - the core library for a Chinese input method "Chewing" - scim-chewing - the SCIM adaptor for the chewing input method - ttf-arphic-ukai - a popular font in Taiwan - ttf-arphic-uming - another popular font in Taiwan

Both libchewing and scim-chewing are in [extra] now. As they have no other reverse dependencies in [extra], I assume it's possible to move them to [community] for further maintenance. I'm sure they could be, I cannot think of any compelling reason to keep them in [extra] and we're usually open to moving packages if that's what it takes to get someone who can actively maintain them.

Great to hear that!

...

Also, as a Python developer, I'm interesting in making Python packages in Arch Linux even better. I'd like to bring the following packages to [community]:

- buildbot - the main program of a continuous integration framework [5] - buildbot-worker - running commands dispatched by the master - python-buildbot-{www,console-view,grid-view,waterfall-view,wsgi-dashboards,badges} - buildbot plugins - python-buildbot-pkg - an auxiliary package for building buildbot plugins from sources. I'll create a stable version from my buildbot-pkg-git package. - python-{aws-xray-sdk,jsondiff,klein,moto,nose-random,pathlib2,pyjade,setuptools-trial,txrequests} - direct or indirect runtime/build-time/check-time dependencies for buildbot-related packages

I'd like to improve dependency handling for Python packages in Namcap as well. You can do that even without becoming a TU by the way. :) People shouldn't be afraid to contribute to these projects even as a relative outsider! We absolutely welcome contributions on the arch-projects mailing list.

Sure! I'm just a little less motivated to touch Namcap if I can't touch official Python packages :)

...

Furthermore, I'm interested in move some other useful packages to [community]. Here are some packages coming out of my head:

- pcmanx-gtk2 - A popular BBS/Telnet client in Taiwan (29 votes on AUR) - qps - the GUI process monitor recommended by LXQt (2% on pkgstats) - cmst - a Qt frontend for connman recommended by LXQt (49 votes on AUR)

I'd like to stop here. Thanks for reading such a long mail. I'm passionately looking forward an oppurtunity to extend my Arch contributions to a new scope! Good luck. ;)

And now on to the thing everyone has been waiting for: the ztrawhcse review! I've looked at your AUR packages, and since no one is perfect (especially when I'm on the case) I've found a few issues...

Thank you very much! As a newcomer in Arch Linux packaging, I'm sure I've learnt a lot from "a few issues"! During the last weekend, I've fixed some trivial issues of them.

android-ndk-beta: - kind of a small thing since it doesn't support i686 in any way, but arch-specific sources should be source_x86_64

android-ndk: - kind of a small thing since it doesn't support i686 in any way, but arch-specific sources should be source_x86_64 - packages should never provides=("$pkgname") Fixed! android-sdk-cmake: - kind of a small thing since it doesn't support i686 in any way, but arch-specific sources should be source_x86_64 - what is the utility of android's specific build artifacts for some random cmake release -- why can't this use the system cmake Android NDK does not work with upstream CMake yet. Hopefully it will be fixed soon - https://github.com/android-ndk/ndk/issues/463 - license agreement post-install is pointless, especially repeated post upgrade

buildbot-git: - license is GPL2, not GPL -- the latter implies 2-or-later Thanks! I was confused by the symlink /usr/share/licenses/common/{GPL -> GPL2} and thought that GPL is an alias of GPL2 in PKGBUILDs. - the patch to fix test errors should be upstreamed by getting them to use the 'distro' module or something else that respects optional os-release(5) attributes Using 'distro' or the like sounds a good idea! The patch was hold as I don't think it's upstream-ready. - setup.py build should be done in build - old workarounds for maybe-missing git tags can be removed from pkgver()

buildbot-worker-git: - license is GPL2, not GPL -- the latter implies 2-or-later Fixed! - setup.py build should be done in build - old workarounds for maybe-missing git tags can be removed from pkgver()

buildbot-www-git: - license is GPL2, not GPL -- the latter implies 2-or-later Fixed! - setup.py build should be done in build - old workarounds for maybe-missing git tags can be removed from pkgver() - try asking upstream to use proper environment markers for the cairosvg dependency, rather than applying patches

ceiba-dl-git: - instead of NOCONFIGURE=1 ./autogen.sh, use autoreconf -fi directly as the autotools developers recommend - old workarounds for maybe-missing git tags can be removed from pkgver()

darling-dmg-git: - enoattr patch should be pushed upstream Yep, I need to find time to create a patch working for new and old attr

- old workarounds for maybe-missing git tags can be removed from pkgver()

ext4fuse-git: fcitx-chewing-git: - old workarounds for maybe-missing git tags can be removed from pkgver()

gpac-git: - what is the reason why you forbid MAKEFLAGS from makepkg.conf - staticlibs only affects packages that contain *both* shared and static libraries - use git+https:// in sources to take advantage of TLS certificate verification

heimdall-nogui-git: - inconsistently fails to quote srcdir - includes commands to duplicate the effects of makepkg --cleanbuild (and breaks incremental builds for no clearly defined reason?) - renames source clone using a variable then hardcodes the name in several other places - patch included without accompanying rationale, not used by 'heimdall' package, not upstreamed???

kalu-cli: - don't create groups in install scripts, use sysusers.d(5) and definitely don't delete them on removal; problem originates with 'kalu' PKGBUILD - groff is in base-devel and should not be in makedepends, perl is a dependency of groff and required by many things including base, and shouldn't be in makedepends either; problem originates with 'kalu' PKGBUILD

libav-no-libs-git: - old workarounds for maybe-missing git tags can be removed from pkgver() - pkgver() should strip leading 'v' from git tag

libchewing-git: - consider submitting a PR to fix issue219, rather than maintaining a downstream patch -- maintainers may have lost track of your comment on the issue Done - https://github.com/chewing/libchewing/pull/294 - old workarounds for maybe-missing git tags can be removed from pkgver() - instead of ./autogen.sh, use autoreconf -fi directly as the autotools developers recommend - use autoreconf in prepare() not build()

lximage-qt-git: lxqt-notificationd-git: - pkgver does not use recommended git describe format so the revision count is not prepended with 'r'; this would need either an upstream release or an epoch to fix

macports-base-git: - old workarounds for maybe-missing git tags can be removed from pkgver() - man is not a dependency because of the help system, any more than man is a dependency for git, which does the same thing

macports-base: - man is not a dependency because of the help system, any more than man is a dependency for git, which does the same thing

nbuexplorer-bin: - wrapper script should quote "" - GPL2 is a common license and does not need to be installed

nextcloud-app-markdown: - should build from source

nodejs-web-ext: - build should happen in build() then be cp'ed in package()

pulse-secure: - try to see if it can avoid installing in /usr/local... As jsimonetti commented on 2017-10-24 18:00 on https://aur.archlinux.org/packages/pulse-secure/, there are apparently

Fixed! package, which comes with different header files. plugins (hostchecker) looking into /usr/local/pulse :/

- unquoted pkgdir -- yes, if INSTALLDIR="$pkgdir"/foo then it still needs to be quoted - the grep and awk can be combined into one awk '/pattern/{print }' pushd and popd in a single one-shot prepare function is unnecessary, the working directory is reset by makepkg itself

python2-pylzma: - unquoted srcdir/pkgdir - should have split build and package functions

python-buildbot-pkg-git: - should have split build and package functions - old workarounds for maybe-missing git tags can be removed from pkgver()

python-git: - why does this enforce debug info - why does this not debundle the vendored libmpdec like extra/python does - curious to understand the precise reason for divergences from extra/python, e.g. configure flags - why isn't the testsuite being run

python-hashpumpy-git: - 'install -d ... && install -D ... ...' is like 'sleep 2 && install -D ... ...' - pkgver should strip leading 'v'

python-pyjade: - testsuite runs some shellscript that hardcodes python3 nosetests when testing both python2 and python3, just run this in the check() function directly - 'install -d ... && install -D ... ...' is like 'sleep 2 && install -D ... ...' - pinned commit hashes could be replaced by $url/archive /${_commit}.tar.gz no different from $pkgver - should have split build and package functions

python-txrequests: - should have split build and package functions

socat2-git: - last commit is a tagged release from two years ago, it would probably make sense to retire this package in favor of a non-git version - find loop to rename *one* file seems like very overkill, especially when introducing the whitespace-breaking fragility of a read loop; -print0 and read -rd '' would be preferred, or even shopt -s globstar - unquoted pkgdir -- yes, if manfile="/foo" then needs to be quoted autoconf should be moved to prepare() - mandir should default to $prefix/share/man already - trailing escape after last configure argument is confusing

spim-svn: - unquoted srcdir/pkgdir

version-control-tools-hg: - source is explicitly renamed to what it already is

After checking some of mentioned packages, I find there are much more issues than ones listed here, and the time needed in fixing them all is much longer than I expected. I'll look into them soon. Sorry for the long waiting. Regards, Chih-Hsuan Yen

On 8/30/18 11:20 AM, Felix Yan via aur-general wrote:

On 8/23/18 4:22 PM, Felix Yan wrote:

...

I'm starting the vote while Chih-Hsuan work on the Elint :)

https://aur.archlinux.org/tu/?id=108

Voting period is over, and the results are in!

Yes No Abstain Total Voted Participation 31 8 7 46 Yes 93.88%

So congrats, you are now a TU :)

Congratulations! Welcome to the team. :)

I have modified your bug tracker and AUR accounts to the TU group.

You forgot to modify his group to be "member" in the internal Keyring project, thus allowing him to see and create keyring issues. I've taken care of that. :) -- Eli Schwartz Bug Wrangler and Trusted User

Felix Yan via aur-general 於 2018/08/30 23:20 寫道:

On 8/23/18 4:22 PM, Felix Yan wrote:

...

I'm starting the vote while Chih-Hsuan work on the Elint :)

https://aur.archlinux.org/tu/?id=108 Voting period is over, and the results are in!

Yes No Abstain Total Voted Participation 31 8 7 46 Yes 93.88%

So congrats, you are now a TU :) Thank you and all other TUs for this oppurtunity :) I have modified your bug tracker and AUR accounts to the TU group.

Please refer to https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#TODO_list_f... and take care of any remaining items.

Will do ASAP. Cheers, Chih-Hsuan Yen