Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 23/1/19 12:11 am, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 16:10: On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight. That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used. If the Environment variable is actually the problem, why not just unset them before proceeding? unset GEM_HOME unset BUNDLE_PATH `$(gem env gemdir)` Thanks Macca
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 16:10: On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config Fair enough, I did not know about that option. In that case the wiki (and my setup) needs some updating, since it explicitly recommends using GEM_HOME for this. I'll see if I can do something about that tonight. That said, I'm not convinced there's any harm in using the longer method, since it's slightly more compatible (and technically faster! although not by enough to count it as a benefit). Looking through the community repo both are used.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On January 22, 2019 4:03:29 PM GMT+01:00, Bert Peters via aur-general wrote: >Levente Polyak via aur-general schreef op 2019-01-22 13:40: >> On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general >> wrote: >>> David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: > On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: > Why is use > `$(gem env gemdir)` > > Instead of > > `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. >>> >>> I'm not a TU so take my this with a grain of salt, but I don't think >>> this is the best advice. >>> >>> It's shorter, admittedly, but `gem` spawns a ruby process just as >the >>> `ruby` version does. Using gem doesn't work however when `$GEM_HOME` > >>> is >>> >>> set, since then it reports the contents of that variable. >>> >>> Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` > >>> is >>> >>> more convenient since most users do not build in a clean chroot, and >>> the >>> wiki actually recommends settings that environment variable so quite >a >>> few will have it. >>> >>> Best, >>> >>> Bert Peters. >> >> Which seems silly and the whole section should be removed in the >first >> place. >> Thats what --user-install switch should be for and that should be >> default via /etc/gemrc >> Therefor setting that is just useless fiddling with the system and >> your gems will be searched there as well as it's default gem path >> besides /usr/lib. > >While `gem` obeys that default, `bundle` (ruby-bundler) does not, and >does not >have that default, opting for a global install by default. You can >override >this by manually adding `--path=~/.gem` to every invocation. That's >hardly an >elegant solution compared to setting an environment variable. Which is why "bundle config path" exists. A sane way would be to use that to define BUNDLE_PATH in ~/.bundle/config
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Levente Polyak via aur-general schreef op 2019-01-22 13:40: On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib. While `gem` obeys that default, `bundle` (ruby-bundler) does not, and does not have that default, opting for a global install by default. You can override this by manually adding `--path=~/.gem` to every invocation. That's hardly an elegant solution compared to setting an environment variable.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On January 22, 2019 1:25:20 PM GMT+01:00, Bert Peters via aur-general wrote: >David Runge schreef op 2019-01-22 12:30: >> On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: >>> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: >>> Why is use >>> `$(gem env gemdir)` >>> >>> Instead of >>> >>> `$(ruby -e'puts Gem.default_dir')` >> It's shorter and you don't have to spawn a ruby process to print >> something, if you can use the gem command directly. > >I'm not a TU so take my this with a grain of salt, but I don't think >this is the best advice. > >It's shorter, admittedly, but `gem` spawns a ruby process just as the >`ruby` version does. Using gem doesn't work however when `$GEM_HOME` is > >set, since then it reports the contents of that variable. > >Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is > >more convenient since most users do not build in a clean chroot, and >the >wiki actually recommends settings that environment variable so quite a >few will have it. > >Best, > >Bert Peters. Which seems silly and the whole section should be removed in the first place. Thats what --user-install switch should be for and that should be default via /etc/gemrc Therefor setting that is just useless fiddling with the system and your gems will be searched there as well as it's default gem path besides /usr/lib.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
David Runge schreef op 2019-01-22 12:30: On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote: On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote: Why is use `$(gem env gemdir)` Instead of `$(ruby -e'puts Gem.default_dir')` It's shorter and you don't have to spawn a ruby process to print something, if you can use the gem command directly. I'm not a TU so take my this with a grain of salt, but I don't think this is the best advice. It's shorter, admittedly, but `gem` spawns a ruby process just as the `ruby` version does. Using gem doesn't work however when `$GEM_HOME` is set, since then it reports the contents of that variable. Especially for AUR packages using `$(ruby -e'puts Gem.default_dir')` is more convenient since most users do not build in a clean chroot, and the wiki actually recommends settings that environment variable so quite a few will have it. Best, Bert Peters.
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 2019-01-22 17:09:35 (+0800), Metal A-wing wrote:
> On Tue Jan 8 20:19:43 UTC 2019, David Runge wrote:
> > * pkgname: avoid composition
> What should I do?
It's more readable and less error-prone to do `pkgname=name` instead of
`pkgname="name${something_else}"`.
> Why is use
> `$(gem env gemdir)`
>
> Instead of
>
> `$(ruby -e'puts Gem.default_dir')`
It's shorter and you don't have to spawn a ruby process to print
something, if you can use the gem command directly.
> > LICENSE.md can be installed using 'install -t'
>
> Why is use
> `install -t`
The upside is, that you can ommit the specific destination (unless you
want to rename the destination file).
e.g. `install -vDm 644 LICENSE -t
"${pkgdir}/usr/share/licenses/${pkgname}/"` creates the directory
"${pkgdir}/usr/share/licenses/${pkgname}/" for you, if it doesn't exist
and will install the source file to that directory, without you having
to specifically name the destination file.
Whereas the following requires you to specify the destination file as
well: `install -vDm 644 LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
Not using the `-t` flag is only useful, if you need to rename the
destination file, e.g.:
`install -vDm 644 WEIRDNAME_FOR_A_LICENSE
"${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
In short: This is shorter and implies the creation of the destination
directory.
Closing: Please use a mail client, that doesn't break threads (i.e.
replies to the thread that was initially created, instead of creating a
new one.
Mailman is somewhat able to order these threads in the list archive, but
in mail clients this is horrible to follow up on (there are now 4
separate threads [1] [2] [3] [4]). Compare the 'In-Reply-To' header in
the messages with those of others.
Aside from that, happy packaging! :)
David
[1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034744.html
[2] https://lists.archlinux.org/pipermail/aur-general/2018-December/034758.html
[3] https://lists.archlinux.org/pipermail/aur-general/2019-January/034799.html
[4] https://lists.archlinux.org/pipermail/aur-general/2019-January/034848.html
--
https://sleepmap.de
signature.asc
Description: PGP signature
Re: [aur-general] TU Application_R: Metal A-wing (a-wing)
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
Re: [aur-general] TU Application_R: Metal A-wing (a-wing)
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 signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application_R: Metal A-wing (a-wing)
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) signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU Application_R: Metal A-wing (a-wing)
On Thu, Dec 27, 2018 at 03:35:28PM +0800, Metal A-wing wrote: > I started using Ubuntu in high school. > And I use Debian at university. > In 2017, I started Archlinux > > I also tried other distributions. linux mint, deepin linux, gentoo, centos This seems fairly rushed. The AUR registration occured in April of 2018, and there is only a handfull of commits to actual AUR packages. Let alone there are not any popular packages what so ever here. The archlinuxcn repository is cool and all, but that doesn't help at all if the AUR contributions are lacking. Thats what the role is for after all. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Besides what has been outlined by Eli and JereBear, there are some more general remarks I would like to make. I'll start with the first (or "second", since the actual first application was a single sentence) application email. [1] > I think dpkg package manage is too complicated (...) I think that introducing yourself to the community with inconstructive remarks on other distributions is a bad start. Sure, people like to complain (myself included!) and the grass is always greener on the other side. TUs are however members of the Arch development team and are expected to work hand-in-hand with other distributions. The recent iniative on reproducible builds [2] which was started by Debian is an example of that. Arbitrary remarks like "if your computer CPU too little" or "packaging is too complicated" don't help here, nor are we flattered when Arch supposedly does these things better. > Also I developped a build status webpage, both the backend and the frontend, for archlinuxcn build server (lilac web status frontend). I certainly believe that you are apt at communicating and working with the archlinuxcn team. However, if you are interested at becoming TU we need to look at Arch as a whole. For example, if you plan on (assisting with) maintaing the ruby toolchain, how would the rest of team communicate with you on this? Your response to Davis's email gave me the impression of a severe language barrier, and having to use other TUs from archlinuxcn as intermediaries does not seem ideal to me. (Please note that I am not a native English speaker either, nor do I expect anyone to be. However, some control of the English language is expected when it is is used as the main means of communication in a development team.) [1] https://lists.archlinux.org/pipermail/aur-general/2018-December/034758.html [2] https://reproducible-builds.org/ -- Alad Wenter
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
> > - [ ] source_x86_64: should be source, don't upload binary data to the > > AUR, > > > > About source binary. Improve the build speed of AUR, Reduce makedependence > The result of the build is the same This is a fundamental mis-understanding of both the purpose of the AUR and the purpose of source control: * The AUR absolutely should not be used to host binary files. Only source files should be hosted. This is documented on the wiki on the obvious page. [1] Hosting only sources has several advantages, most notably in the form of improving security: users can read the source of packages being compiled. * As a general rule, git/bzr/hg/etc repositories should only contain source code. This rule isn't specific to the AUR. It's a general software engineering principle. As a community member: this application *worries* me. [1] https://wiki.archlinux.org/index.php/Arch_User_Repository
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
First of all, your email client has broken the email thread. ;)
On 1/9/19 11:20 AM, Metal A-wing wrote:
> Oh. yes
https://github.com/archlinux/archweb/ and
https://git.archlinux.org/aurweb.git/about/ (both are python, not ruby)
But these are community projects that can be contributed to even without
becoming a Trusted User.
>> * [ ] depends: single quotes missing
> ??? What ?
This is a style preference and therefore subjective.
>> * [ ] source_x86_64: should be source, don't upload binary data to the
>> AUR,
> About source binary. Improve the build speed of AUR, Reduce makedependence
> The result of the build is the same
Okay, this is a big issue. And it's not enough to say that you'll do
better in the official repos. This is a -bin package, plain and simple,
and users have an expectation that software is built from a vetted
source, not repackaged as some shady prebuilt binary. The AUR is not an
exception to this.
You cannot just say "Oh I've personally tested it and it's the same
byte-for-byte identical result, I promise". That's the exact opposite of
vetting software, and I doubt you're verifying it in private on every
single release when your CI bot rebuilds the package.
https://github.com/archlinuxcn/repo/commit/4182ad8ba05c9f6aa1944fb17b07f07fbc18ced9
This package shows and continues to show a lack of understanding about
what it means to be a Trusted User. And honestly it shows a lack of
understanding about what it means to be a community member with an AUR
account. You received a review that the package should build from source
and instead you change from source_x86_64=() to source=() and set the
package as an arch=('any') package even though it contains:
dbus.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV),
dynamically linked,
BuildID[sha1]=b641f5b2dd3faa26e9620add7eaf60b9a75d5a7a, not stripped
You neither understood the message that David was telling you, nor
bothered to check how your package worked when modifying it. Now your
package is more broken than it was yesterday, and you still haven't
fixed the main issue.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Hi, Le 09/01/2019 à 17:20, Metal A-wing a écrit : >> * [ ] source_x86_64: should be source, don't upload binary data to the >> AUR, > About source binary. Improve the build speed of AUR, Reduce makedependence > The result of the build is the same What do you mean by “same” and how did you checked that? Regards, Bruno signature.asc Description: OpenPGP digital signature
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 2018-12-27 15:50:49 (+0800), Metal A-wing wrote: > I'm sorry, my last application was bad a few days ago. Not so easy for reviews, if you're applying between Christmas and New Years (lots of people are not home and/or busy hanging out with people then). > I am a Web Developer. uav cloud management system dev in UAV company. > (not DJI) Would you also be interested in improving the AUR, and website? > I use ruby on rails web-application framework Or express.js, Koa.js, > and Frontend Single Page Application（SPA）use vue.js Probably helps maintaining ruby /rails stuff then! > In 2017, I started Archlinux That's not true! :-P https://wiki.archlinux.org/index.php/Arch_Linux#History > About my involvement in Arch Linux, I have 11 packages on AUR [1]. vrzvd 0.0.1 starting up... * electron-netease-cloud-music * electron-netease-cloud-music.sh: just call `/usr/bin/electron /usr/lib/electron-netease-cloud-music/electron-netease-cloud-music.asar` and remove the rest * electron-netease-cloud-music.png: remove and download from upstream if necessary * pkgdesc: clinet should be client * arch: not set! should be 'any' * license: should be 'GPL3' (see `pacman -Ql licenses`) * depends: single quotes missing * source_x86_64: should be source, don't upload binary data to the AUR, * md5sums_x86_64: should be md5sums * prepare(): use gendesk to create the missing XDG desktop file instead of adding it to the repository * package(): cd to $srcdir is unnecessary, remove commented line installing svg, asar should be called in prepare() to extract LICENSE, LICENSE can be installed using 'install -t' * ruby-actionable * pkgname: avoid composition * arch: single quote * url: use double quotes and a correct upstream url... ERROR: upstream missing: https://rubygems.org/gems/actionable but part of rails: https://github.com/rails/rails/tree/master/actioncable * license: single quotes missing * depends: differs from rubygems information ( https://rubygems.org/gems/actionable ), single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), MIT-LICENSE can be installed using 'install -t' * ruby-activejob * pkgname: avoid composition * arch: single quote * url: use double quotes and a correct upstream url... ERROR: upstream missing: https://rubygems.org/gems/activejob but part of rails: https://github.com/rails/rails/tree/master/activejob * license: single quotes missing * depends: single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), MIT-LICENSE can be installed using 'install -t' * ruby-activestorage * pkgname: avoid composition * arch: single quote * url: use double quotes and a correct upstream url... ERROR: upstream missing: https://rubygems.org/gems/activestorage but part of rails: https://github.com/rails/rails/tree/master/activestorage * license: single quotes missing * depends: single quotes missing * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), MIT-LICENSE can be installed using 'install -t' * ruby-bacon * pkgname: avoid composition * pkgdesc: start with capital letter * arch: single quote * url: use double quotes and a correct upstream url... ERROR: upstream missing: https://rubygems.org/gems/activejob but part of rails: https://github.com/rails/rails/tree/master/activestorage * license: must not be empty! * depends: single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), COPYING can be installed using 'install -t' * ruby-erubi * pkgname: avoid composition * arch: single quote * url: use double quotes * license: single quotes missing * depends: single quotes missing * makedepends: single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), MIT-LICENSE can be installed using 'install -t' * ruby-globalid * pkgname: avoid composition * arch: single quotes missing * url: use double quotes and a correct upstream url https://github.com/rails/globalid * license: single quotes missing * depends: single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir), MIT-LICENSE can be installed using 'install -t' * ruby-marcel * pkgname: avoid composition * arch: single quotes missing * url: use double quotes * license: single quotes missing * depends: single quotes missing * makedepends: single quotes missing * build(): not building from source! * check(): no check is run * package(): _gemdir can be derived from $(gem env gemdir),
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
Metal A-wing 於 2018/12/27 下午3:50 寫道: > Hi everyone, > > I'm sorry, my last application was bad a few days ago. > > I (nickname a-wing) would like to apply to be a Trusted User. > Chih-Hsuan Yen (yan12125) && Jiachen Yang (farseerfc) will be my sponsor. > > Some basic information about myself, > My Chinese name is YongXin SHI. I am 23 years old, and I'm living in > shenzhen, China. > I am a Web Developer. uav cloud management system dev in UAV company. (not > DJI) > I mainly do programming in Ruby, JavaScript, PHP > I use ruby on rails web-application framework Or express.js, Koa.js, and > Frontend Single Page Application（SPA）use vue.js > I use Chinese and English. > > My Blog is https://a-wing.top (Chinese) > > I started using Ubuntu in high school. > And I use Debian at university. > In 2017, I started Archlinux > > I also tried other distributions. linux mint, deepin linux, gentoo, centos > > I think dpkg package manage is too complicated, But .deb init did a lot of > things that should not be done > For example: > Debian (deb) > - If install postgresql, dpkg is help init DB to /var/lib/postgres , But I > might migrate other databases. > - I remember. once I install a dpkg pkg. but Always in the installing. > Because detection /dev/** to init. > - The complexity of dpkg makes problems difficult to fix manually > - Packaging is too complicated, I have never learned how to packaging a > standard deb > > Gentoo > - If your computer CPU && mem too little _(:з」∠)_ > - And C compile, python too coupling > > Centos (rpm) > - No comment > > Archlinux > - Easy to packaging > - Makes problems easy to fix manually > - wiki is very good > > > About my involvement in Arch Linux, I have 11 packages on AUR [1]. > I also maintains 52 packages in the unofficial [archlinuxcn] repo [2]. > Also I developped a build status webpage, both the backend and the frontend, > for archlinuxcn build server (lilac web status frontend).[3][4][5] > > About the packages I want to maintain in [community] > 1.- ruby-rails > - ruby-actioncable > - ruby-websocket-driver > - ruby-websocket-extensions > - ruby-actionpack > - ruby-rack-test > - ruby-rails-dom-testing > - ruby-rails-html-sanitizer > - loofah > - ruby-crass > - ruby-nokogiri > - ruby-activejob > - ruby-globalid > - ruby-activerecord > - ruby-arel > - ruby-activesupport > - ruby-concurrent-ruby > - ruby-i18n > - ruby-minitest > - ruby-tzinfo > - ruby-actionmailer > - ruby-actionview > - ruby-builder > - ruby-erubi > - ruby-activemodel > - ruby-activestorage > - ruby-marcel > - ruby-mimemagic > - ruby-railties > - ruby-method_source > - ruby-sprockets-rails > - ruby-sprockets > > 2.- ruby-pry > - ruby-coderay > - ruby-method_source > > 3.- frp > > Many Web app rely on ruby-rails: mastodon, discourse, redmine, gitlab(But. > gitlab need special version), so I think packaging ruby-rails will greatly > benefit arch linux users to do development and deployment on their favorite > distro more easily. > > About frp, I think frp should split as frpc and frps > Because. client and server will not be on the same computer > > > I will also take over some packages from Felix Yan > - ruby-bundler > - trojan > > Thank you for your attention! > > > [1] https://aur.archlinux.org/packages/?SeB=m=a-wing > [2] https://github.com/archlinuxcn/repo/graphs/contributors > [3] https://build.archlinuxcn.org/packages/ > [4] https://github.com/a-wing/KISS2U > [5] https://github.com/a-wing/KISS2UI > Dear all, I'm also hereby confirming my sponsorship for Metal A-wing! Besides Yang's supplementary descriptions about A-wing's continuous efforts on establishing a packager-friendly environment via his awesome KISS2U/KISS2UI project, I would like to provide my observations, too. I applied as a member of Arch Linux Chinese community in the same month as A-wing (April 2018). During these months I work together with him (and quite a few other packagers) on maintaining the unofficial [archlinuxcn] repository, I notice that he not only tries his best on maintaining his own packages, but also spends much time on improving overall packaging quality. Concretely, he reports packaging issues and provides possible fixes for packages of other packagers in [archlinuxcn] as well as on AUR, and works with upstream for packaging issues. Recently, the configuration file of lilac (the build bot for [archlinuxcn]) migrates from only one Python file to a YAML file with an optional Python file to allow easier management of packages. During the time he provides many useful ideas and develops some new functions in lilac to make the migration simpler. Above all, his contributions take care of both a global view and details, and thus I believe he will be yet another good source of energy on evolving Arch Linux. So,
Re: [aur-general] TU application_R: Metal A-wing (a-wing)
On 2018/12/27 16:50, Metal A-wing wrote: > Hi everyone, > > I'm sorry, my last application was bad a few days ago. > > I (nickname a-wing) would like to apply to be a Trusted User. > Chih-Hsuan Yen (yan12125) && Jiachen Yang (farseerfc) will be my sponsor. Dear All, I confirm my sponsorship for a-wing! I would also want to appologize for the previous application letter. After that I discussed with him about his willingness for this TU application and I can confirm his passion. A-wing is quite active at Arch Linux CN (Chinese) community in recent years on our Telegram group (bridged to #archlinux-cn freenode channel), and from April 2018 as a packager for the unofficial [archlinuxcn] repo. I saw him gaining experience in writing PKGBUILDs and fixing package issues. In this 2018, he was quite passionate about archlinuxcn's build server infrastructure, leading the KISS2U and KISSUI development under the mentorship of lilac's original developer. For some background knowledge, "lilac" is a CI-style building bot running on archlinuxcn's build server, to automatically getting updates from upstreams and build daily packages in [archlinuxcn] repo. Originally lilac is only a crontab service, with building logs sent through emails. Before KISS2UI project, packagers for [archlinuxcn] can only commit on github and have to wait for email notifications to get any bad results. A-wing is quite passionate about improving this workflow, and indeed his KISS2U and KISS2UI provide the [archlinuxcn] packagers a better tool to understand the building status. From this experience of developping KISS2UI, I can also say that A-wing gained a lot of knowledge about PKGBUILD building, nvchecker and devtools knowhows in general. This knowledge will surely help him become a good TU for our [community] repo. About the packages he want to maintain in [community], a-wing have already been testing `ruby-rails` related packages in [archlinuxcn] repo. His discussion of `ruby-rails` in Arch Linux CN telegram group with yan12125 was started from the beginning of this December, and this discussion finally leads to this TU application. Both yan12125 and me agree that having these packages in [community] will benefit the whole Arch Linux, not just the CN community. The relatively low number of Ruby packages (compared to Python ones) also made me believe that having A-wing in our TU team will definitely benefit our community. Besides Ruby, A-wing also showed his skills of python and javascript, because the original lilac codebase is written in python and KISS2UI is a web frontend with heavy javascript usage. From his involvement in discussion on our Arch Linux CN Telegram group, my own impression about A-wing is that, A-wing is the kind of "talk less and do more" type of person. His discussion always focuses on the techical aspect, and seldomly take part in any flamewars, which I think is a precious characteristics on the internet. Both yan12125 and me will be his sponors, and as the recent discussion of TU application process goes, we will take part in the mentorship for A-wing as much as we can. I think the discussion period will begin after yan12125 confirmed his sponsorship. -- Jiachen YANG (farseerfc) signature.asc Description: OpenPGP digital signature
