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 http://bpiotrowski.pl/
signature.asc
Description: OpenPGP digital signature
