TU Application - Chih-Hsuan Yen

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

TU Application - Chih-Hsuan Yen

tur-users mailing list
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].

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.

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.

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!

Regards,

Chih-Hsuan Yen

[1] https://github.com/yan12125
[2] https://gitlab.com/yan12125
[3]
https://aur.archlinux.org/packages/?O=0&SeB=M&K=yan12125&SB=p&SO=d&PP=50&do_Search=Go
[4]
https://github.com/archlinuxcn/repo/blob/80adbb5dbee28591f95babf4aed91b0791dc6e3a/nvchecker.ini#L2531-L2617
[5] https://buildbot.net/


signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
On 8/15/18 9:10 PM, 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].
>
> 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.
>
> 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.
>
> 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!
>
> Regards,
>
> Chih-Hsuan Yen
>
> [1] https://github.com/yan12125
> [2] https://gitlab.com/yan12125
> [3]
> https://aur.archlinux.org/packages/?O=0&SeB=M&K=yan12125&SB=p&SO=d&PP=50&do_Search=Go
> [4]
> https://github.com/archlinuxcn/repo/blob/80adbb5dbee28591f95babf4aed91b0791dc6e3a/nvchecker.ini#L2531-L2617
> [5] https://buildbot.net/
>
I confirm my sponsorship. Let the discussion begin!

--
Regards,
Felix Yan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
In reply to this post by tur-users mailing list
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

> 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.

> 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.

> 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...

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")

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
- license agreement post-install is pointless, especially repeated post
  upgrade

buildbot-git:
- license is GPL2, not GPL -- the latter implies 2-or-later
- 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
- 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
- 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
- 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
- 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
- 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...
- 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

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
In reply to this post by tur-users mailing list
I believe the discussion period is a bit longer than needed.

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

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

--
Regards,
Felix Yan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
In reply to this post by tur-users mailing list

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



signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
On 8/26/18 10:55 PM, Chih-Hsuan Yen wrote:

>> 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

Hmm. :/

I cannot immediately find their modified sources either, sadly.

>> 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.

I can see why that could potentially be confusing. We describe that
policy here, FWIW: https://wiki.archlinux.org/index.php/PKGBUILD#license


>> 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 :/

Ouch.

In theory this can be binary patched as the preferred paths are shorter,
but... yeah.

:(

> 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.

No problem. :)

--
Eli Schwartz
Bug Wrangler and Trusted User


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
In reply to this post by tur-users mailing list
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 :)

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_for_new_Trusted_Users
and take care of any remaining items.

--
Regards,
Felix Yan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
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


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
On 8/30/18 11:35 PM, Eli Schwartz via aur-general wrote:
> 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. :)

Oops thanks. I'll remember it next time!

--
Regards,
Felix Yan


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TU Application - Chih-Hsuan Yen

tur-users mailing list
In reply to this post by tur-users mailing list

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_for_new_Trusted_Users
> and take care of any remaining items.
>
Will do ASAP.

Cheers,

Chih-Hsuan Yen



signature.asc (235 bytes) Download Attachment