[aur-general] TU application sponsored by David Reisner

Bartłomiej Piotrowski b at bpiotrowski.pl
Tue Feb 4 07:56:12 EST 2014

On 02/04/2014 01:55 PM, Ike Devolder wrote:
> On Tue, Feb 04, 2014 at 04:24:56AM -0800, Anatol Pomozov wrote:
>> Hi
>> On 2/4/14, 12:54 AM, Ike Devolder wrote:
>>> On Mon, Feb 03, 2014 at 11:26:22AM -0800, Anatol Pomozov wrote:
>>>> Hi everyone
>>>> I would like to apply for a Arch Trusted User position. It is
>>>> sponsored by my co-worker and bright engineer David Reisner.
>>>> My name is Anatol Pomozov, I grew up in Belarus but live in USA now. I
>>>> am an open-source enthusiast who uses Linux since about 2005. I've
>>>> been using several distros mostly Debian based. About 2.5 years ago,
>>>> when Ubuntu in-place upgrade killed my system once again, I've decided
>>>> to give a try to a rolling-release distro.
>>>> I had heard that Arch was difficult to use and unstable so I've been
>>>> skeptical that Arch would survive at my computers for a long time. At
>>>> my surprise Arch installation was easy and system was fast and stable.
>>>> Documentation is clean and very helpful. And package manager is
>>>> *FAST*! Yeah!  I fell in love with Arch from the very first day. A few
>>>> months later all my home computers were moved to Arch. And despite
>>>> that I usually do crazy experiments at my home machines I've never had
>>>> serious problems with Arch. Well, the only problem with Arch was in
>>>> systemd-207 that prevented my btrfs-root machine from booting.
>>>> About a year ago I started playing more active role in Arch community.
>>>> I adopted a lot of broken and out-of-date packages. Currently I own
>>>> 350+ packages [1]. A lot of packages are for ruby gems that previously
>>>> were out-of-date or had broken dependencies. I improved existing
>>>> gem2arch tool [2] and it helps me with ruby packages herding.
>>>> At my day job I work on Linux kernel development/support at a large
>>>> server farm. My daily activity includes a lot of debugging,
>>>> performance profiling, code archaeology both for linux kernel and
>>>> in-house userspace code. Some of my linux changes went upstream, here
>>>> are few of them:
>>>> https://lkml.org/lkml/2013/4/12/391
>>>> http://marc.info/?l=linux-fsdevel&m=134750749009884&w=2
>>>> https://lkml.org/lkml/2013/4/1/171
>>>> Google Chromebook developers reported that my last patch fixed one of
>>>> their top kernel crashes!
>>>> Recently me and my 6 y/o son started learning microelectronics and
>>>> digital design. Maybe some day we'll create MIPS-like CPU.
>>>> Why do I want to become a TU? I like Arch and would like to keep it
>>>> improving. It means making packages better, participate in important
>>>> discussions that define where the distro moves.
>>>> The short/mid terms plans for me are:
>>>>  - move some of my aur packages to community: rethinkdb, codespell,
>>>> tup, mldonkey, v8. There are some other aur packages that I use and
>>>> would also like to see in [community]: fatsort, digital design related
>>>> tools, ...
>>>>  - add android-sdk-* packages. Current AUR packages download binaries
>>>> and install binaries to /opt/bin. The binaries are 32-bit. Instead we
>>>> should build SDK from sources and provide proper 64/32-bit binaries.
>>>> This might be tricky as Android build system is complicated.
>>>>  - request moving Apache to [community] and finally update this package to 2.4
>>>> I can help with linux kernel issues, especially if they are related to
>>>> storage/block subsystem.
>>>> I also have experience with Ruby. This is my favorite scripting
>>>> language that I use for 10 years now and I'll be glad to help with
>>>> Ruby in Arch as well.
>>>> [1] aur.archlinux.org/packages/?SeB=m&K=anatolik
>>>> [2] https://github.com/anatol/gem2arch
>>> WOW, many packages :)
>>> I just found something somewhat fishy in your subtle package:
>>> patch -p1 < ../do_not_relink_binaries_on_install.diff
>>> I'm not entirely sure i can break the build but i think it would be best
>>> practice to do "$srcdir/do_not_relink_binaries_on_install.diff"
>> The only thing that comes to my mind is if the folder where we 'cd'
>> before doing 'patch' is a symlink. In this case '..' will differ from
>> $srcdir. But unpacked source directory can't be a symlink, is it?
>> I do not mind to change it to the longer version "$srcdir/foo" if this
>> is a recommended way to do, but first I want to know why it is recommended.
> I thought the recommended way was using "$srcdir/patch.diff", correct me
> if I'm wrong

There is no recommended way.

Bartłomiej Piotrowski

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20140204/6a8d86eb/attachment-0001.asc>

More information about the aur-general mailing list