[aur-general] TU application_R: Metal A-wing (a-wing)
On Tue Jan 8 20:19:43 UTC 2019, David Runge 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? Oh. yes
In 2017, I started Archlinux That's not true! :-P https://wiki.archlinux.org/index.php/Arch_Linux#History Sorry: In 2017, I started using archlinux
About my involvement in Arch Linux, I have 11 packages on AUR [1]. vrzvd 0.0.1 starting up...
* electron-netease-cloud-music * [x] 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 * [x] pkgdesc: clinet should be client * [x] arch: not set! should be 'any' * [x] license: should be 'GPL3' (see `pacman -Ql licenses`) * [ ] depends: single quotes missing ??? What ?
* [ ] 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
* [x] 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-rails * ruby-actionable * ruby-activejob * ruby-activestorage Upstream https://github.com/rails/rails Need split package ?
I also maintains 52 packages in the unofficial [archlinuxcn] repo [2]. Unfortunately it's not easy to see which, only by contribution: https://github.com/archlinuxcn/repo/commit/e16a5eafc54f3b67c1805919a3b0af659... Do you have a list?
ruby-actioncable flite1 acme.sh-git ruby-actionmailer annie ruby-railties hmcl ruby-erubi ruby-nokogiri ruby-erubis ruby-rack-test ruby-activejob ruby-minitest ruby-i18n electron-netease-cloud-music ruby-rails ruby-builder i3lock-color ruby-rails-dom-testing ruby-coderay ruby-rails-html-sanitizer ruby-arel ruby-websocket-extensions ruby-activerecord ruby-tzinfo frps ruby-actionview ruby-crass ruby-actionpack ruby-loofah python-hsaudiotag3k caddy ruby-sprockets-rails qgroundcontrol ruby-activemodel ruby-thread_safe frpc ruby-websocket-driver ruby-activesupport ruby-bacon ruby-method_source ruby-activestorage apm_planner ruby-marcel mattermost-desktop polybar ruby-pry websocketd ruby-hoe ruby-globalid ruby-sprockets ruby-mimemagic
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. How do you plan on packaging ruby-rails? Would some of the gems maintained by you be part of the package or separate gems? I don't know too much about ruby and gems, which is why I'm asking ;-) Separate gems, looks like debian ruby-rails
What do you use to keep up-to-date with upstream releases? Use lilac, nvchecker. Automatically detect updates every day
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
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/4182ad8ba05c9f6aa1944fb17b07f07fb... 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
- [ ] 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
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
participants (5)
-
Alad Wenter
-
Bruno Pagani
-
Eli Schwartz
-
JereBear
-
Metal A-wing