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
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:
- 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.
- 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.
- 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
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.
- 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
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:
- 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
- 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.
- 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
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."
Ionut Biru schrieb:
On 12/05/2009 01:46 AM, Ray Rashif wrote:
- 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
On 12/05/2009 02:35 PM, Stefan Husmann wrote:
Ionut Biru schrieb:
On 12/05/2009 01:46 AM, Ray Rashif wrote:
- 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.
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:
- 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.
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
2009/12/6 Ronald van Haren pressh@gmail.com
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.
Ahh alright, that clears things up.
Firstly, thanks to everyone for the warm encouragement. Secondly, thanks for diligently answering my questions :)
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
aur-general@lists.archlinux.org