[aur-general] TU Application - Chih-Hsuan Yen

[Chih-Hsuan Yen]

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

Fixed!

> 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
package, which comes with different header files.
> - 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
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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20180827/34958e12/attachment-0001.asc>