FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux User Repository

 
 
LinkBack Thread Tools
 
Old 12-04-2009, 10:46 PM
Ray Rashif
 
Default TU Application: Ray Rashif (schivmeister)

Hello list

I know there's been a couple of applications in the last few days, and
another has just started, so please don't be annoyed. The unlucky TU this
time is Chris Brannon (I flipped a coin, the other side being "try
again..next time"). He's been great and has sacrificed time to check my
packages out, so thank you once again Chris!

I have split the following autonetography into parts for selective
digestion; you guys can read only what matters. Yeah, right..? (hint:
ctrl+f, "=", ENTER | whatmattersmost: "Usage")

== Preamble ==
I started with Arch Linux not too long ago, from early-mid 2007. Linux
itself, somewhere around 2006. My first stop was the IRC, at which point of
time I used to hang out on #gentoo and #sabayon (now you know my previous
poison). Just for a little fun, I vaguely recall it went something like
this:

schiv: does arch have anything like USE flags?
Xilon: no
$someone_else: compiling has absolutely zero benefit
schiv: ok

As you can see, people were not very hostile back then (probably because a
lot of questions have become reccuring over time). Anyway, I liked my system
immediately and started picking on beginners like myself on IRC. "Pick on
someone your own size" - that's exactly what I did and I even picked on a
certain user going by the handle of "Daenyth".

== Getting Started ==
My next stop was AUR, the first package being "wicd", which thanks to
then-developer Varun is now in [extra] and serving the community well. Then
I took to the forums to help aid others in trying to get wicd working, and
that marked the beginning of my "time on Arch".

For the rest of the year I almost-regularly visited the forums, and on
occasions edited wiki articles, reported bugs. I uploaded and maintained AUR
packages which I used, so even up til now, there aren't that many. I began
helping out with a "pro audio" initiative, of which the current ArchAudio [
http://archaudio.org ] is a direct result. I co-maintain and manage the
project along with other keen individuals.

>From mid 2008 through mid 2009, I was a little inactive due to hardware
failure, and something misleading called "real life", but nevertheless had
Arch running on a Windows machine through VirtualBox.

I thought of applying for TUship one or two times before, but it was either
time or "there's enough help already" that kept me from going ahead. There
was a TU "Shinlun" who I wanted to request for sponsorship because I could
take some load off, but he went inactive and ultimately stepped down. I
don't think lack of time is an excuse for me, and I now realise that even a
little dedication helps the community. One for all, all for one, but don't
quote me on this.

== Usage ==
My main packaging interest, as you might've guessed by now, is multimedia;
audio/video. Other than that, I would love to maintain popular and/or
important packages and ensure that users continue to have access to a bigger
arsenal and wider range of tools on Arch Linux. Hopefully, I will also be
working on getting the Sugar environment packaged (it's been on my TODO for
a while). I might occasionally send in useless patches for makepkg, as I
have done before, only to be struck down by Xavier's mighty roar. However, I
can't be of much help with the development of pacman itself, the AUR
internals, or anything else related to C or Web Development. Not yet, at
least.

== History ==
I come from a non-IT academic background, if such information needs to be
known. I'm "from the Arts and not Sciences" by society's standards, but in
fact I'm "neither or either". I'm from a tiny island-nation called
Singapore, and there is very little convergence of the two areas here.
Currently I'm pursuing DSP, in particular CSc Music, but not until I
complete my National Service which should start next year and end two and a
half after. I used to be a Philosophy student, and then Audio Engineering. I
hope to be able to get into Cosmology/Astrophysics eventually, but
competition here is tough and I was always lazy in class, lectures and Math
(I won't say I was "bad" at it). Professionally, I'm busy..I mean I'm "in
the business sector". Biologically, I'm a noob adult born in the Year of the
Snake (1989).

== Troubelshooting ==
So on to some questions of my own:

1) I remember we used to tell each other that we don't need to state
dependencies from [core] in AUR, how true is this? Are we looking at just
the base group or is it totally a matter of consistency?

2) How are cross-repository buildtime and optional dependencies handled? For
example, can we have a package in [extra] makedepend and/or optdepend on
another in [community]?

3) Unfortunately, it is time for a nice facepalm. I don't do x86_64. So do I
get access to the build machine in the event this application is accepted?

I would greatly appreciate any and all kinds of feedback with regards to my
packages. Even if a quorum is not reached, I put a very high value on advice
and opinion (!). Thank you for reading.

Regards


--
GPG/PGP ID: B42DDCAD
 
Old 12-04-2009, 10:52 PM
Daenyth Blank
 
Default TU Application: Ray Rashif (schivmeister)

On Fri, Dec 4, 2009 at 18:46, Ray Rashif <schivmeister@gmail.com> wrote:
> that's exactly what I did and I even picked on a
> certain user going by the handle of "Daenyth".
lol wut. I honestly have no memory of this :P

> So on to some questions of my own:
>
> 1) I remember we used to tell each other that we don't need to state
> dependencies from [core] in AUR, how true is this? Are we looking at just
> the base group or is it totally a matter of consistency?
It's never heard anyone say that core isn't required to list. For
depends you don't need to list base. and for makedepends you don't
need to list base or base-devel.

> 2) How are cross-repository buildtime and optional dependencies handled? For
> example, can we have a package in [extra] makedepend and/or optdepend on
> another in [community]?
Optdepend maybe, makedepend is highly discouraged or disallowed,
strict depend is off limits.

> 3) Unfortunately, it is time for a nice facepalm. I don't do x86_64. So do I
> get access to the build machine in the event this application is accepted?
There isn't one right now. Ask in the IRC channel and someone will get
to it before long.

> I would greatly appreciate any and all kinds of feedback with regards to my
> packages. Even if a quorum is not reached, I put a very high value on advice
> and opinion (!). Thank you for reading.
>
Good luck
 
Old 12-04-2009, 11:26 PM
Chris Brannon
 
Default TU Application: Ray Rashif (schivmeister)

> I know there's been a couple of applications in the last few days, and
> another has just started, so please don't be annoyed. The unlucky TU this
> time is Chris Brannon

I'm glad to sponsor Ray's application. His packaging skills are
excellent. He's competent, and he has a good attitude.
Ray will make a great addition to the team.

This begins the discussion period.

> 1) I remember we used to tell each other that we don't need to state
> dependencies from [core] in AUR, how true is this? Are we looking at just
> the base group or is it totally a matter of consistency?

I've heard arguments in favor of including dependencies from the base
and base-devel groups.
Some constrained environments, such as live CDs, might not have all of
base and base-devel installed.
Perhaps it's better to specify things explicitly.
This topic seems to be perennial.

-- Chris
 
Old 12-04-2009, 11:28 PM
Ionut Biru
 
Default TU Application: Ray Rashif (schivmeister)

On 12/05/2009 01:46 AM, Ray Rashif wrote:

Hello list


hello

<snip>

nice background!



== Troubelshooting ==
So on to some questions of my own:

1) I remember we used to tell each other that we don't need to state
dependencies from [core] in AUR, how true is this? Are we looking at just
the base group or is it totally a matter of consistency?


we tend not to include dependency from base and/or base-devel



2) How are cross-repository buildtime and optional dependencies handled? For
example, can we have a package in [extra] makedepend and/or optdepend on
another in [community]?


no. all packages that depend has the be in the same repo.



3) Unfortunately, it is time for a nice facepalm. I don't do x86_64. So do I
get access to the build machine in the event this application is accepted?



we don't have a build machine but we help each other every time on this
matter.



I would greatly appreciate any and all kinds of feedback with regards to my
packages. Even if a quorum is not reached, I put a very high value on advice
and opinion (!). Thank you for reading.

Regards


good luck in your application

--
Ionut
 
Old 12-04-2009, 11:43 PM
Ray Rashif
 
Default TU Application: Ray Rashif (schivmeister)

> we tend not to include dependency from base and/or base-devel
>

Ahh yes thanks, that's the one, base-devel. Previously during installation
there was a warning to not remove base-devel, but it's not done anymore. I
recall the reasoning behind exclusion of base itself in [unsupported] was
the assumption:

"If you're building from AUR, you already have Arch Linux, you already have
base."


--
GPG/PGP ID: B42DDCAD
 
Old 12-05-2009, 03:12 AM
Allan McRae
 
Default TU Application: Ray Rashif (schivmeister)

Ray Rashif wrote:


I might occasionally send in useless patches for makepkg, as I
have done before, only to be struck down by Xavier's mighty roar.


Yeah, Xavier ruins all the fun :P

I have talked with Ray at some point regarding fixing some of our audio
packages and he seems to know what he is doing. I think he will be a
good addition to the TUs.


Allan
 
Old 12-05-2009, 11:35 AM
Stefan Husmann
 
Default TU Application: Ray Rashif (schivmeister)

Ionut Biru schrieb:

On 12/05/2009 01:46 AM, Ray Rashif wrote:


2) How are cross-repository buildtime and optional dependencies
handled? For

example, can we have a package in [extra] makedepend and/or optdepend on
another in [community]?


no. all packages that depend has the be in the same repo.



Well, that cannot be true. There are lots of packages in extra that (make-)depend on
packages in core, and packages in community that (make-)depend on packages in core or
extra. Only the other way around is forbidden. Read the "->" as "may deliver
(make-)dependencies for"


core -> extra -> community

Regards Stefan
 
Old 12-05-2009, 12:02 PM
Ionut Biru
 
Default TU Application: Ray Rashif (schivmeister)

On 12/05/2009 02:35 PM, Stefan Husmann wrote:

Ionut Biru schrieb:

On 12/05/2009 01:46 AM, Ray Rashif wrote:



2) How are cross-repository buildtime and optional dependencies
handled? For
example, can we have a package in [extra] makedepend and/or optdepend on
another in [community]?


no. all packages that depend has the be in the same repo.



Well, that cannot be true. There are lots of packages in extra that
(make-)depend on packages in core, and packages in community that
(make-)depend on packages in core or extra. Only the other way around is
forbidden. Read the "->" as "may deliver (make-)dependencies for"
core -> extra -> community

Regards Stefan


thanks for explaining better. what i wanted to say is that a package
from core can't depend on o package from extra or community. or a
package from extra cannont dependend on one from community.


he asked that exact type of dependency and that's why i said is not allowed.
 
Old 12-05-2009, 02:14 PM
Ray Rashif
 
Default TU Application: Ray Rashif (schivmeister)

2009/12/5 Ionut Biru <ibiru@archlinux.org>

> On 12/05/2009 02:35 PM, Stefan Husmann wrote:
>
>> Ionut Biru schrieb:
>>
>>> On 12/05/2009 01:46 AM, Ray Rashif wrote:
>>>
>>
>> 2) How are cross-repository buildtime and optional dependencies
>>>> handled? For
>>>> example, can we have a package in [extra] makedepend and/or optdepend on
>>>> another in [community]?
>>>>
>>>
>>> no. all packages that depend has the be in the same repo.
>>>
>>>
>> Well, that cannot be true. There are lots of packages in extra that
>> (make-)depend on packages in core, and packages in community that
>> (make-)depend on packages in core or extra. Only the other way around is
>> forbidden. Read the "->" as "may deliver (make-)dependencies for"
>> core -> extra -> community
>>
>> Regards Stefan
>>
>
> thanks for explaining better. what i wanted to say is that a package from
> core can't depend on o package from extra or community. or a package from
> extra cannont dependend on one from community.
>
> he asked that exact type of dependency and that's why i said is not
> allowed.
>

Yes, correct, that's exactly what I wanted to know. In terms of
dependencies, it's obvious they have to be in the same repo since a user may
want to just use one. But what I was concerned about was makedepends and
optdepends, since they don't affect the user when he downloads the binary.


--
GPG/PGP ID: B42DDCAD
 
Old 12-05-2009, 05:08 PM
Ronald van Haren
 
Default TU Application: Ray Rashif (schivmeister)

On Sat, Dec 5, 2009 at 4:14 PM, Ray Rashif <schivmeister@gmail.com> wrote:
> 2009/12/5 Ionut Biru <ibiru@archlinux.org>
>
>> On 12/05/2009 02:35 PM, Stefan Husmann wrote:
>>
>>> Ionut Biru schrieb:
>>>
>>>> On 12/05/2009 01:46 AM, Ray Rashif wrote:
>>>>
>>>
>>> *2) How are cross-repository buildtime and optional dependencies
>>>>> handled? For
>>>>> example, can we have a package in [extra] makedepend and/or optdepend on
>>>>> another in [community]?
>>>>>
>>>>
>>>> no. all packages that depend has the be in the same repo.
>>>>
>>>>
>>> Well, that cannot be true. There are lots of packages in extra that
>>> (make-)depend on packages in core, and packages in community that
>>> (make-)depend on packages in core or extra. Only the other way around is
>>> forbidden. Read the "->" as "may deliver (make-)dependencies for"
>>> core -> extra -> community
>>>
>>> Regards Stefan
>>>
>>
>> thanks for explaining better. what i wanted to say is that a package from
>> core can't depend on o package from extra or community. or a package from
>> extra cannont dependend on one from community.
>>
>> he asked that exact type of dependency and that's why i said is not
>> allowed.
>>
>
> Yes, correct, that's exactly what I wanted to know. In terms of
> dependencies, it's obvious they have to be in the same repo since a user may
> want to just use one. But what I was concerned about was makedepends and
> optdepends, since they don't affect the user when he downloads the binary.
>
>
> --
> GPG/PGP ID: B42DDCAD
>

For makedepends applies the same, though if you search carefully
you'll find some package which don't follow this rule of thumb if I'm
correct. An example would be if a makedepends of a core package would
bring a shitload of packages to core. Either way, these cases are
really rare and when come up they should be discussed what the best
course of action would be in that particular caes.

Ronald
 

Thread Tools




All times are GMT. The time now is 09:49 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org