[aur-general] Package Duplication / Orphaning (funpidgin/carrier)
Hi, funpidgin was renamed to carrier, additionally for some time carrier has been depending on a package not in a official repo or AUR, a working alternative has been provided in the comments along, with a request from a user for someone else to take over maintainer status, this happened on the 18 March 2009. I would like to volunteer myself to maintain this package. Funpidgin link http://aur.archlinux.org/packages.php?ID=15689 Carrier link http://aur.archlinux.org/packages.php?ID=17191
Re: [aur-general] TU application: Biru Ionut
Daenyth Blank wrote: Everything looks pretty good to me. The only thing I'd recommend is to use $srcdir and $pkgdir in place of $startdir/src and $startdir/pkg, as it makes PKGBUILDs easier to read. i've fixed all my packages that haven't used $srcdir and $pkgdir. also if you have other question feel free to ask me. -- Ionut
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 05, 2009 at 02:25:53AM +0200, Loui Chang wrote: On Sat, Apr 04, 2009 at 08:03:21PM -0400, Daniel J Griffiths wrote: Daenyth Blank wrote: In addition to this, the PKGBUILDs he maintained were generally of pretty low quality, at least from my perspective. Took the words right outta my mouth. I think a little elaboration there might have been appreciated. I personally do not need to know the person before the start of the application - yes, it helps, but this is not so assential for me. I rather look at the work done. What I seek for, are mostly self made and contributed PKGBUILDs in AUR. That is what counts for me. Adopting some orphaned packages in AUR is very easy - we have now ~1800 orphaned packages there! And I also didn't see any response to Allan's suggestion adn that surprised me a bit. Jens, in my eyes, there is absolutely no need to feel embarassed or something like that. Just gather some more experience, prepare some more self-made PKGBUILDs, respond when someone is talking to you and you can try again, I think there is no restriction about the number of tries to become a TU :) Cheers Jaroslav -- the man's whiteness walking in the house's shadow... summer moon pgpIYH9YIzApO.pgp Description: PGP signature
Re: [aur-general] TU appliance Jens Maucher (defcon)
Which suggestion? Am Sonntag, den 05.04.2009, 11:22 +0200 schrieb Jaroslav Lichtblau: snip And I also didn't see any response to Allan's suggestion adn that surprised me a bit. snap -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 05, 2009 at 11:32:42AM +0200, Jens Maucher wrote: Which suggestion? Am Sonntag, den 05.04.2009, 11:22 +0200 schrieb Jaroslav Lichtblau: snip And I also didn't see any response to Allan's suggestion adn that surprised me a bit. snap -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA To check the package you maintain(ed) - zattoo, of course. pgplQHKoN6lCA.pgp Description: PGP signature
Re: [aur-general] TU appliance Jens Maucher (defcon)
Well, one hour ago, i wrote that i fixed my packaes. Zattoo is no longer maintained by me, i switched completely to 64bit. Am Sonntag, den 05.04.2009, 12:05 +0200 schrieb Jaroslav Lichtblau: On Sun, Apr 05, 2009 at 11:32:42AM +0200, Jens Maucher wrote: Which suggestion? Am Sonntag, den 05.04.2009, 11:22 +0200 schrieb Jaroslav Lichtblau: snip And I also didn't see any response to Allan's suggestion adn that surprised me a bit. snap -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA To check the package you maintain(ed) - zattoo, of course. -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [aur-general] TU application: Biru Ionut
And here is my offical sponsorship message. As Allan said, wonder helped a lot on our bug day and on forums. Also, he have good packaging skils. So, let the discussion period officially begin. :) -- Hugo
Re: [aur-general] OneSwarm in AUR wants to update itself
Mathias Burén schrieb: Hi, I just created a package for OneSwarm [1] and uploaded it to the AUR [2]. The package works fine except that it has an auto-update feature, which of course doesn't work since the user does not have write access to /opt/OneSwarm. What is the correct way of dealing with this? Should I make /opt/OneSwarm writable by the users group? Thanks, Mathias [1] http://oneswarm.cs.washington.edu/ [2] http://aur.archlinux.org/packages.php?ID=25245 Hello, your package relies on the binary tarballs from upstream. Did you try to build from the sources? There may be more possibilities to influence the behaviour using that level. Regards Stefan
Re: [aur-general] TU appliance Jens Maucher (defcon)
I don't think zatoo should be that much criticized, it looks somewhat clean. On Sun, Apr 5, 2009 at 12:20 PM, Jens Maucher jensmauc...@online.de wrote: Well, one hour ago, i wrote that i fixed my packaes. Zattoo is no longer maintained by me, i switched completely to 64bit. Am Sonntag, den 05.04.2009, 12:05 +0200 schrieb Jaroslav Lichtblau: On Sun, Apr 05, 2009 at 11:32:42AM +0200, Jens Maucher wrote: Which suggestion? Am Sonntag, den 05.04.2009, 11:22 +0200 schrieb Jaroslav Lichtblau: snip And I also didn't see any response to Allan's suggestion adn that surprised me a bit. snap -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA To check the package you maintain(ed) - zattoo, of course. -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA
Re: [aur-general] TU appliance Jens Maucher (defcon)
Stefan Husmann wrote: the voting period for Defcon has ended, and he did not get the majority of votes. He got four times yes, eleven times no and four abstains. So, that is democracy, but it would be nice if there would be some discussion about the reasons for the failure. I looked at Defcon's PKGBUILDs. Here's a (hopefully constructive) suggestion. When applying, point out the work that *you* have done. Mention those packages that you contributed, I.E., those that aren't adopted. If you put some serious effort into an adopted package, mention that as well. What have you done that makes you proud? Tell us about it. -- Chris
Re: [aur-general] pkgconflict: a tool to find file conflicts when building packages
Abhishek Dasgupta wrote: Thanks for the useful script! But shouldn't this line: known_files[entry] =3D (repo, package) be known_files[entry].append((repo, package)) That is a nice suggestion! Using lists as hash values could make the tool useful for purposes other than checking packages built from unsupported. The program does quite a bit of I/O. I'm tempted to convert those file lists into a sqlite database, since it would really improve efficiency. -- Chris
Re: [aur-general] TU appliance Jens Maucher (defcon)
Ali H. Caliskan wrote: I don't think zatoo should be that much criticized, it looks somewhat clean. I am going to be fairly blunt here, but essentially you are wrong e.g. # Kerberos libs ln -s /usr/lib/libcrypto.so libk5crypto.so.3 ln -s /usr/lib/libkrb5.so libkrb5.so.3 ln -s /usr/lib/libkrb5.so libkrb5support.so.0 ln -s /usr/lib/libgssapi.so libgssapi_krb5.so.2 Symlinking libraries to different sonames is, in my opinion, the single worst thing you can do to your install. It can create bugs that are incredibly difficult to track down. The current libkrb5.so is .25! A lot has changed since .3... The correct way to deal with this is to find a version of the package that supplies these library versions and build it, either within the package or as a dep for the package. The former is probably cleaner in this case unless something else requires these versions. There is also the use of mkdir and cp instead of install to improve. As Jens pointed out, he no longer maintains this. But at this point, that is moot. He maintained it when he applied and the TUs did not know him very well in general so we needed to rely on his packaging skill to judge his application. The consensus opinion of the TUs was obviously that his package standards were not high enough and I have no doubt that this package was primarily to blame. So, for future reference, here is my subjectiveview of what should have happened after this package was pointed out as bad: 1) a reply to aur-general saying I will look into it. If it was fixable, good. If not then... 2) a reply saying, This is very difficult to fix. I am discussing this with my sponsor. Any suggestions on how to improve it?. 3) possibly delaying of voting until it is shown that the issue is fixed. I see the ability to know when you have a bad PKGBUILD or other problem and then asking for help to be far more important than the ability to produce perfect packages. Remember, once someone is a TU, they will be providing the community with binary packages. It is essential that the Trusted Users ensure any new applicant is up to standard. Any doubt is enough to say no. Allan
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 5, 2009 at 09:19, Chris Brannon cmbran...@cox.net wrote: When applying, point out the work that *you* have done. Mention those packages that you contributed, I.E., those that aren't adopted. If you put some serious effort into an adopted package, mention that as well. What have you done that makes you proud? Tell us about it. -- Chris +1 On Sun, Apr 5, 2009 at 09:25, Allan McRae al...@archlinux.org wrote: I am going to be fairly blunt here, but essentially you are wrong snip As Jens pointed out, he no longer maintains this. But at this point, that is moot. He maintained it when he applied and the TUs did not know him very well in general so we needed to rely on his packaging skill to judge his application. The consensus opinion of the TUs was obviously that his package standards were not high enough and I have no doubt that this package was primarily to blame. So, for future reference, here is my subjectiveview of what should have happened after this package was pointed out as bad: 1) a reply to aur-general saying I will look into it. If it was fixable, good. If not then... 2) a reply saying, This is very difficult to fix. I am discussing this with my sponsor. Any suggestions on how to improve it?. 3) possibly delaying of voting until it is shown that the issue is fixed. I see the ability to know when you have a bad PKGBUILD or other problem and then asking for help to be far more important than the ability to produce perfect packages. Remember, once someone is a TU, they will be providing the community with binary packages. It is essential that the Trusted Users ensure any new applicant is up to standard. Any doubt is enough to say no. Allan +1
Re: [aur-general] TU appliance Jens Maucher (defcon)
Am Sonntag, den 05.04.2009, 08:19 -0500 schrieb Chris Brannon: Stefan Husmann wrote: the voting period for Defcon has ended, and he did not get the majority of votes. He got four times yes, eleven times no and four abstains. So, that is democracy, but it would be nice if there would be some discussion about the reasons for the failure. I looked at Defcon's PKGBUILDs. Here's a (hopefully constructive) suggestion. When applying, point out the work that *you* have done. Mention those packages that you contributed, I.E., those that aren't adopted. Packages that are not adopted? Well, to find a package that is interesting is not easy, the more so as in AUR are already a lot of packages. So i adopt it, because it is important that the orphaned packages are evolved, i think. It's no use that in AUR are many many packages, and more of them are orphaned. If you put some serious effort into an adopted package, mention that as well. What have you done that makes you proud? Tell us about it. Proud? What has that got to do with the price of fish? Arch Linux is a wondeful distro, and i like it to build packages. Ok, some PKGBUILDs here and there needs improvement, but there is nothing that can't be learn. Cheers -- Chris -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 5, 2009 at 09:53, Jens Maucher jensmauc...@online.de wrote: Packages that are not adopted? Well, to find a package that is interesting is not easy, the more so as in AUR are already a lot of packages. So i adopt it, because it is important that the orphaned packages are evolved, i think. It's no use that in AUR are many many packages, and more of them are orphaned. Proud? What has that got to do with the price of fish? Arch Linux is a wondeful distro, and i like it to build packages. Ok, some PKGBUILDs here and there needs improvement, but there is nothing that can't be learn. Cheers Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA While it's true that it's not anything that can't be learned, the way to go about it is to learn how to do it before applying, which seems to be the missing step here.
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Mon, Apr 6, 2009 at 10:55 AM, Ali H. Caliskan ali.h.calis...@gmail.com wrote: One thing, mkdir is not something bad to use, I use it all the time, and install isn't also not required, since the developers of install command argue that a package manager should be used instead of install, so what's the big deal here? I mean as long as the code is working, why should it be that much trouble to maintain a package. Are we code fascists here? Isn't about code fascism is about to do our best effort, working code isn't enough, in fact is average, but install vs cp + mkdir is always a suggestion that many people had in their applications, and it wasn't the point to be rejected. In my point of view, Jens should prepare a better application, explaining what are they goals, why he wants to become a TU, and how he will benefit AUR and community, that's all. For Jens: Better luck the next time, and don't feel dissapointed, try to focus on a better application next time, ;) Cheers! -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] TU appliance Jens Maucher (defcon)
My thoughts... I'd say that the install thing was considered to be a minor infraction -- but regardless of whether it's strictly necessary, I would say that conventions are good to follow. As someone who's been involved in an organization with a very strict entrance system based on votes, I have one thing to say that I have learned over the years: The number one thing improves chances of entrance success is knowing the people who are voting. If they know you and like you somewhat, they are greatly more likely to vote you in. Look at it this way: even if you're a mediocre packager, but everyone knows and likes you, then they're likely to think, Well, okay. He'll stumble a bit and we'll have to clean up some stuff, but he's a good, hard-working guy and he'll learn. As others here have said, this is just most crucial. To paraphrase above: Since we don't know the applicant, we have to rely on his PKGBUILDs. They aren't excellent, so there were a lot of negative votes. (Mind you, I'm not a TU.) So here is my recommendation: Now TUs know you somewhat, that's good. They've seen your name. Hang out with them on IRC/forums/newsgroups. Be helpful and humble, willing to learn. Then in three months (which, Iirc, is the time between TU apps), you can give it another shot. Chances are, if you've been active + nice + improving over that time, the TUs will know you and probably like you. They'll see that you've put three months of effort in after being rejected initially, and that shows dedication and hard-workingness. Chances are, at that point, if you re-apply, you'll get in without much trouble and be hailed as a good addition to the team who's overcome adversity and improved himself. Good luck, -Andrei Garoth Thorp On Sun, Apr 5, 2009 at 8:25 AM, Ali H. Caliskan ali.h.calis...@gmail.com wrote: Allan, you're right about your views, but unfortunately, zattoo seems to be installed that way, so much for several contributors effort in this inconsistency. However, I'll reconsider your critical approach when chaning zattoo PKGBUILD. One thing, mkdir is not something bad to use, I use it all the time, and install isn't also not required, since the developers of install command argue that a package manager should be used instead of install, so what's the big deal here? I mean as long as the code is working, why should it be that much trouble to maintain a package. Are we code fascists here? /ali On Sun, Apr 5, 2009 at 3:25 PM, Allan McRae al...@archlinux.org wrote: Ali H. Caliskan wrote: I don't think zatoo should be that much criticized, it looks somewhat clean. I am going to be fairly blunt here, but essentially you are wrong e.g. # Kerberos libs ln -s /usr/lib/libcrypto.so libk5crypto.so.3 ln -s /usr/lib/libkrb5.so libkrb5.so.3 ln -s /usr/lib/libkrb5.so libkrb5support.so.0 ln -s /usr/lib/libgssapi.so libgssapi_krb5.so.2 Symlinking libraries to different sonames is, in my opinion, the single worst thing you can do to your install. It can create bugs that are incredibly difficult to track down. The current libkrb5.so is .25! A lot has changed since .3... The correct way to deal with this is to find a version of the package that supplies these library versions and build it, either within the package or as a dep for the package. The former is probably cleaner in this case unless something else requires these versions. There is also the use of mkdir and cp instead of install to improve. As Jens pointed out, he no longer maintains this. But at this point, that is moot. He maintained it when he applied and the TUs did not know him very well in general so we needed to rely on his packaging skill to judge his application. The consensus opinion of the TUs was obviously that his package standards were not high enough and I have no doubt that this package was primarily to blame. So, for future reference, here is my subjectiveview of what should have happened after this package was pointed out as bad: 1) a reply to aur-general saying I will look into it. If it was fixable, good. If not then... 2) a reply saying, This is very difficult to fix. I am discussing this with my sponsor. Any suggestions on how to improve it?. 3) possibly delaying of voting until it is shown that the issue is fixed. I see the ability to know when you have a bad PKGBUILD or other problem and then asking for help to be far more important than the ability to produce perfect packages. Remember, once someone is a TU, they will be providing the community with binary packages. It is essential that the Trusted Users ensure any new applicant is up to standard. Any doubt is enough to say no. Allan
Re: [aur-general] TU appliance Jens Maucher (defcon)
Well there is a difference between TU and developer, I'm not saying that it's not required to be good at coding and consequent about organizing a PGBUILD, what I'm saying is that we should embrace the enthusiasm and dedication by people who want to contribute and serve the community the best way they can. So the requirements should be much tougher as developer than TU. Please reconsider Jens as a TU, not as what he *is*, but what he can *be *. Que bono? /ali 2009/4/5 Angel Velásquez an...@archlinux.com.ve On Mon, Apr 6, 2009 at 10:55 AM, Ali H. Caliskan ali.h.calis...@gmail.com wrote: One thing, mkdir is not something bad to use, I use it all the time, and install isn't also not required, since the developers of install command argue that a package manager should be used instead of install, so what's the big deal here? I mean as long as the code is working, why should it be that much trouble to maintain a package. Are we code fascists here? Isn't about code fascism is about to do our best effort, working code isn't enough, in fact is average, but install vs cp + mkdir is always a suggestion that many people had in their applications, and it wasn't the point to be rejected. In my point of view, Jens should prepare a better application, explaining what are they goals, why he wants to become a TU, and how he will benefit AUR and community, that's all. For Jens: Better luck the next time, and don't feel dissapointed, try to focus on a better application next time, ;) Cheers! -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] TU application: Biru Ionut
On Sun, Apr 05, 2009 at 12:10:27AM +0200, Biru Ionut wrote: Hi, My name is Biru Ionut Mircea and i'm addicted to archlinux. :) I'm a 23 year old student from Romania, studying at University Politehnica of Bucharest, Faculty of Automatic Control and Computer, Computer Science department. I'm using linux for more than 6 years, using different distributions before i discovered archlinux 3 years ago and in this time i can say that i know almost everything about archlinux. Mainly my contribution to archlinux community was on the forum, bug tracker and aur(username wonder), where i maintain 14 packages [1]. I helped on bug day on 21 march and for my work i got credit from allan and hdoria which i want to thank for that. I want to became a TU because i've noticed that important people in our community are resigning and my favorites packages aren't been updated because of lack of free time. I just want to do something so that our community to enjoy packages up to date. In the future I want to help more in archlinux projects and maybe i will start other projects that the archlinux community could use. Also i want to inform that i don't intend to move in community any of *-ubuntu package My sponsor is Hugo Doria. Thank you. [1] http://aur.archlinux.org/packages.php?SeB=mK=wonder -- Ionut Hi, I went through your packages and found out many of them have been previously created and mainained by someone else. I would like to see some of your own contributions, could you maybe point them out? I see in some of your packages the 1st line like: # $Id: PKGBUILD,... which comes in PKGBUILDs moved to AUR from the repos, but actually should not be there. You may remove this. I'm also not sure about the actual status of the #Maintainer/#Contributor lines. Maybe some other TU knows, if Maintainer is now allowed in AUR PKGBUILDs. I'm wondering if you are talking about any particular projects you want to help with or start, in your last paragraph? Cheers Jaroslav -- you've wrecked my year's first dream! cawing crow pgpUKon6QeQPa.pgp Description: PGP signature
Re: [aur-general] TU appliance Jens Maucher (defcon)
Hello, I think Jens and me got some thoughts about the reasons now, why the appliance failed. I would have expected this discussion in the discussion period, which was quite calm 8I now see that you guys expected some answers from Jens and me). But now I think it is time to calm down a bit and to answer some questions. Yes, the zattoo-software is bad, and the symlinking is dangerous. But on the on hand discussion was about TU appliance, not about moving zattoo to community. The latter will never happen, I think also the license forbids this. On the other hand, if we follow the arch way, we do what upstreamers want us to do, without much patching. And I really do not see a way to get zattoo working without much googling and searching libraries from third sources. And on i686 zattoo works surprisingly well with that bad symlinks (no known way for x86_64). install -d is preferable over mkdir -p, but also in extra are packages, that do not fullfil this point. As Angel said, I think this was a minor issue inthe rejection. So let us now stick moree to the other Appliance we have these days. again thank you for th discussion. Regards Stefan
Re: [aur-general] TU appliance Jens Maucher (defcon)
forgive me but, I believe there was a reaction going on before the TU discussion started, due to zattoo, which I strongly believe was the key element in Jens unfavourable situation. Again, in order to have a discussion, one should be encouraged, rather than terrified of being vulnerable. No offence, but I strongly suggest that you focus on Jens right now, and find a way to improve the guidelines for strict package policy. And of course, it's so much waste of time for nothing, and this is why I decline of becoming TU. Sorry guys, but the makepkg concept isn't really that much organized at all. I think both sides should improve themselves, which is a fair deal, and fair way of advancing Arch. Kind regards, Ali On Sun, Apr 5, 2009 at 6:19 PM, Stefan Husmann stefan-husm...@t-online.dewrote: Hello, I think Jens and me got some thoughts about the reasons now, why the appliance failed. I would have expected this discussion in the discussion period, which was quite calm 8I now see that you guys expected some answers from Jens and me). But now I think it is time to calm down a bit and to answer some questions. Yes, the zattoo-software is bad, and the symlinking is dangerous. But on the on hand discussion was about TU appliance, not about moving zattoo to community. The latter will never happen, I think also the license forbids this. On the other hand, if we follow the arch way, we do what upstreamers want us to do, without much patching. And I really do not see a way to get zattoo working without much googling and searching libraries from third sources. And on i686 zattoo works surprisingly well with that bad symlinks (no known way for x86_64). install -d is preferable over mkdir -p, but also in extra are packages, that do not fullfil this point. As Angel said, I think this was a minor issue inthe rejection. So let us now stick moree to the other Appliance we have these days. again thank you for th discussion. Regards Stefan
Re: [aur-general] TU application: Biru Ionut
Jaroslav Lichtblau schrieb:
On Sun, Apr 05, 2009 at 12:10:27AM +0200, Biru Ionut wrote:
Hi,
My name is Biru Ionut Mircea and i'm addicted to archlinux. :)
I'm a 23 year old student from Romania, studying at University
Politehnica of Bucharest, Faculty of Automatic Control and Computer,
Computer Science department.
I'm using linux for more than 6 years, using different distributions
before i discovered archlinux 3 years ago and in this time i can say
that i know almost everything about archlinux.
Mainly my contribution to archlinux community was on the forum, bug
tracker and aur(username wonder), where i maintain 14 packages [1]. I
helped on bug day on 21 march and for my work i got credit from allan
and hdoria which i want to thank for that.
I want to became a TU because i've noticed that important people in our
community are resigning and my favorites packages aren't been updated
because of lack of free time. I just want to do something so that our
community to enjoy packages up to date.
In the future I want to help more in archlinux projects and maybe i will
start other projects that the archlinux community could use. Also i want
to inform that i don't intend to move in community any of *-ubuntu package
My sponsor is Hugo Doria. Thank you.
[1] http://aur.archlinux.org/packages.php?SeB=mK=wonder
--
Ionut
Hi,
I went through your packages and found out many of them have been
previously created and mainained by someone else. I would like to
see some of your own contributions, could you maybe point them out?
I see in some of your packages the 1st line like: # $Id: PKGBUILD,...
which comes in PKGBUILDs moved to AUR from the repos, but actually
should not be there. You may remove this. I'm also not sure about
the actual status of the #Maintainer/#Contributor lines. Maybe some
other TU knows, if Maintainer is now allowed in AUR PKGBUILDs.
I'm wondering if you are talking about any particular projects you
want to help with or start, in your last paragraph?
Cheers
Jaroslav
Hello,
I think we some time ago came to the conclusion that the one who
actually takes care of the package _now_ is the Maintainer, and everyone
who formerly maintained the package is a contributor.
IMHO exactly this are the meanings of the words maintainer and
contributor. But I may be completely wrong.
Regarding your packages:
makedepends=('autoconf' 'automake' 'libtool' 'pkgconfig') is not needed
(cairo-ubuntu). All these tools are in base-devel.
Regards Stefan
Re: [aur-general] TU application: Biru Ionut
Am Sonntag, den 05.04.2009, 18:49 +0200 schrieb Stefan Husmann: Hello, I think we some time ago came to the conclusion that the one who actually takes care of the package _now_ is the Maintainer, and everyone who formerly maintained the package is a contributor. A Package Maintainer, in the context of Arch Linux, is either one of the following: *A core Arch Linux developer who maintains software packages in the official repositories (core, extra, or testing). *A Trusted User of the community who maintains software packages in the unsupported/unofficial community repository. A Contributor is a non-TU who maintain packages in AUR IMHO exactly this are the meanings of the words maintainer and contributor. But I may be completely wrong. Regards Stefan Cheers -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [aur-general] TU application: Biru Ionut
On Sun, Apr 5, 2009 at 13:03, Jens Maucher jensmauc...@online.de wrote: Am Sonntag, den 05.04.2009, 18:49 +0200 schrieb Stefan Husmann: Hello, I think we some time ago came to the conclusion that the one who actually takes care of the package _now_ is the Maintainer, and everyone who formerly maintained the package is a contributor. A Package Maintainer, in the context of Arch Linux, is either one of the following: *A core Arch Linux developer who maintains software packages in the official repositories (core, extra, or testing). *A Trusted User of the community who maintains software packages in the unsupported/unofficial community repository. A Contributor is a non-TU who maintain packages in AUR IMHO exactly this are the meanings of the words maintainer and contributor. But I may be completely wrong. Regards Stefan Cheers -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA That is no longer the case. I could dig up the ML thread in which it was discussed, but I'm rather lazy. Can you link to the page that has that wording so it can be updated? Maintainer is the person responsible for updating the package, contributors are as Stefan said, previous maintainers (or people who have submitted updates)
Re: [aur-general] TU application: Biru Ionut
Hi, 2009/4/5 Biru Ionut biru.io...@gmail.com: Hi, My name is Biru Ionut Mircea and i'm addicted to archlinux. :) I'm a 23 year old student from Romania, studying at University Politehnica of Bucharest, Faculty of Automatic Control and Computer, Computer Science department. I'm using linux for more than 6 years, using different distributions before i discovered archlinux 3 years ago and in this time i can say that i know almost everything about archlinux. Mainly my contribution to archlinux community was on the forum, bug tracker and aur(username wonder), where i maintain 14 packages [1]. I helped on bug day on 21 march and for my work i got credit from allan and hdoria which i want to thank for that. I want to became a TU because i've noticed that important people in our community are resigning and my favorites packages aren't been updated because of lack of free time. I just want to do something so that our community to enjoy packages up to date. In the future I want to help more in archlinux projects and maybe i will start other projects that the archlinux community could use. Also i want to inform that i don't intend to move in community any of *-ubuntu package My sponsor is Hugo Doria. Thank you. A suggestion: do run namcap on all your PKGBUILDs and package files; for example the gfxboot PKGBUILD installs files to /usr/man when it should be installing to /usr/share/man according to FHS guidelines. If you run namcap with the -i option then it prints out informational messages as well (like recommending $srcdir and $pkgdir). -- Abhishek
Re: [aur-general] TU application: Biru Ionut
Well, when my information was wrong.. please update the wiki! http://wiki.archlinux.org/index.php/Package_Maintainer Am Sonntag, den 05.04.2009, 13:09 -0400 schrieb Daenyth Blank: On Sun, Apr 5, 2009 at 13:03, Jens Maucher jensmauc...@online.de wrote: Am Sonntag, den 05.04.2009, 18:49 +0200 schrieb Stefan Husmann: Hello, I think we some time ago came to the conclusion that the one who actually takes care of the package _now_ is the Maintainer, and everyone who formerly maintained the package is a contributor. A Package Maintainer, in the context of Arch Linux, is either one of the following: *A core Arch Linux developer who maintains software packages in the official repositories (core, extra, or testing). *A Trusted User of the community who maintains software packages in the unsupported/unofficial community repository. A Contributor is a non-TU who maintain packages in AUR IMHO exactly this are the meanings of the words maintainer and contributor. But I may be completely wrong. Regards Stefan Cheers -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA That is no longer the case. I could dig up the ML thread in which it was discussed, but I'm rather lazy. Can you link to the page that has that wording so it can be updated? Maintainer is the person responsible for updating the package, contributors are as Stefan said, previous maintainers (or people who have submitted updates) -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 05, 2009 at 06:19:51PM +0200, Stefan Husmann wrote: install -d is preferable over mkdir -p, but also in extra are packages, that do not fullfil this point. I think using one or the other really depends on the situation. I don't think that's something that should be picked on at all, as long as it works correctly. So let us now stick moree to the other Appliance we have these days. again thank you for th discussion. s/Appliance/applicants/
Re: [aur-general] TU application: Biru Ionut
2009/4/5 Daenyth Blank daenyth+a...@gmail.com: That is no longer the case. I could dig up the ML thread in which it was discussed, but I'm rather lazy. Can you link to the page that has that wording so it can be updated? Maintainer is the person responsible for updating the package, contributors are as Stefan said, previous maintainers (or people who have submitted updates) I didn't know about this... namcap -i still shows 'Maintainer tags for TUs and devs only.' Could you provide a link to the ML thread where this was discussed? I've no preferences either way, but atleast if it was decided that the definition has changed, then it should be reflected in the wiki and namcap. -- Abhishek
Re: [aur-general] TU appliance Jens Maucher (defcon)
I have to agree with Allan's first message on this thread. My main reason for giving a negative vote, though, was the lack of response to the valid point raised by Allan regarding the quality of the zatoo package. That, and: - Applying without having found a sponsor first. - Poor use of English (I so hate seeing u instead of you). PS: Yes, I'm a bit grumpy.
Re: [aur-general] TU application: Biru Ionut
Jaroslav Lichtblau wrote: Hi, I went through your packages and found out many of them have been previously created and mainained by someone else. I would like to see some of your own contributions, could you maybe point them out? microblog-purple and linuxdcpp-plus-odc are my own contributions and the *-ubuntu package which i adopt them some time ago when somebody was deleteing orphan packages. Those are my primary contributions and i update them regulary. I see in some of your packages the 1st line like: # $Id: PKGBUILD,... which comes in PKGBUILDs moved to AUR from the repos, but actually should not be there. You may remove this. I'm also not sure about the actual status of the #Maintainer/#Contributor lines. Maybe some other TU knows, if Maintainer is now allowed in AUR PKGBUILDs. This is confusion for me, like is confusion from you also. I didn't know that Maintainer field is only for devs and TU or the Maintainer is the person who actually own it. I will wait a bit more to clarify this thing before doing any modification. That Maintainer field is there because i was using the build from extra as a starting point. I'm wondering if you are talking about any particular projects you want to help with or start, in your last paragraph? I was looking in pacman source tree and i've try to improve some behavior in pacman. For example when a group is in testing and extra/core also pacman asks you two times. This is my first contribution that i want to make into pacman. Also to answer in this mail for all the previous mails: Stefan and Abhishek i'll fix those issue right now. About namcap i forgot totally about that. Cheers Jaroslav -- Ionut
Re: [aur-general] TU application: Biru Ionut
Abhishek Dasgupta schrieb: 2009/4/5 Daenyth Blank daenyth+a...@gmail.com: That is no longer the case. I could dig up the ML thread in which it was discussed, but I'm rather lazy. Can you link to the page that has that wording so it can be updated? Maintainer is the person responsible for updating the package, contributors are as Stefan said, previous maintainers (or people who have submitted updates) I didn't know about this... namcap -i still shows 'Maintainer tags for TUs and devs only.' Could you provide a link to the ML thread where this was discussed? I've no preferences either way, but atleast if it was decided that the definition has changed, then it should be reflected in the wiki and namcap. I think it was discussed in October 2008 in concern with the applicance of foutrelis. The Thrread is named [aur-general] Where to put your name when you adopt an AUR package (was: TU Application) Regards Stefan
Re: [aur-general] kindergarten
We'll, although there are no real pro et contra discussion, I agree with your observation. We should study the art of argumentation and let the arguments speak for themselves. I hope we all change our minds regarding good ethics and code policy. On Sun, Apr 5, 2009 at 7:20 PM, Jens Maucher jensmauc...@online.de wrote: Im going to opt out. This discussion is like a kindergarten, and not what i expected from good trusted users! (really poor, but sadly the truth) Happy continue discussing -- Jens Maucher jensmauc...@online.de Gnupg: 44FF54EA Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA
Re: [aur-general] TU application: Biru Ionut
On Sun, 05 Apr 2009 19:12:03 +0200 Jens Maucher jensmauc...@online.de wrote: Well, when my information was wrong.. please update the wiki! http://wiki.archlinux.org/index.php/Package_Maintainer I've updated the page. The previous version seemed to refer only to the maintainers of binary packages present in the repos. Regards, Xyne
[aur-general] linux
Re: [aur-general] First Package
2009/4/5 Lucas Salies Brum lu...@archlinux.com.br: In line with that of the PKGBUILD: # $ Id: PKGBUILD, v 1.12 2003/11/06 08:26:13 Exp $ dorphell How to create it? cvs? It is mandatory? It's a cvs tag. You don't need to use that in AUR pkgbuild, when you find it simply remove it. To adopt an orphaned package, just download it to correct and re-send? ...after you adopted it on AUR, yes. I read various forums and wikis on the AUR, you have some additional tips for me? If you read these[1][2][3][4][5] you know all that you should know. Thank you very much. You are welcome, good contribute. P.S.: Sorry for bad english. Mine is worse. [1] http://wiki.archlinux.org/index.php/ArchLinux_User-community_Repository_(AUR) [2] http://wiki.archlinux.org/index.php/Building_Packages_in_Arch_Linux [3] http://wiki.archlinux.org/index.php/AUR_User_Guidelines [4] http://wiki.archlinux.org/index.php/AUR_Q_%26_A [5] http://wiki.archlinux.org/index.php/Arch_CVS_%26_SVN_PKGBUILD_guidelines -- Andrea `BaSh` Scarpino Arch Linux Developer
Re: [aur-general] First Package
On Sun, Apr 05, 2009 at 09:52:33PM +0200, Lucas Salies Brum wrote: Hello everyone, my name is Lucas Salies Brum, i live in Brazil and this is my first email to this list. Hi Lucas! Use the Arch for a while, but only now decided to help the community, before submitting my first package to the AUR would eliminate some doubts. In line with that of the PKGBUILD: # $ Id: PKGBUILD, v 1.12 2003/11/06 08:26:13 Exp $ dorphell How to create it? cvs? It is mandatory? This line is only present in PKGBUILDs which are in the repositories, tracked by some versioning system. Not needed for AUR at all. To adopt an orphaned package, just download it to correct and re-send? Yes, that is correct. I read various forums and wikis on the AUR, you have some additional tips for me? Did you read the AUR_User_Guidelines wiki page? There, you should find everything about submitting packages to AUR. Thank you very much. P.S.: Sorry for bad english. No problem, mine is not that much better :) Cheers Jaroslav -- Wenn wir bedenken, daß wir alle verrückt sind, ist das Leben erklärt. -- Mark Twain (eigl. Samuel Langhorne Clemens) pgpordpOBnc0z.pgp Description: PGP signature
[aur-general] Submitting a new package (sunjdk)
hi, i made a PKGBUILD that comprises both sun's jdk+jre (nothing weird), however, i'm not sure if that's OK with aur, so i thought i'd ask first.. tell me if you need more details.. regards M Rawash
Re: [aur-general] Submitting a new package (sunjdk)
On Sun, 05 Apr 2009 23:04:47 +0200 M Rawash mraw...@gmail.com wrote: hi, i made a PKGBUILD that comprises both sun's jdk+jre (nothing weird), however, i'm not sure if that's OK with aur, so i thought i'd ask first.. tell me if you need more details.. regards M Rawash Hi, Both of those packages (jdk and jre) are already in the community repo. In general you shouldn't upload packages to the AUR that already exist in core/extra/community (I think developmental versions and other variations are permitted as long as they're properly named). Could you explain why you've created such a package? If you're trying to achieve something specific then perhaps someone on the list can offer some suggestions of how to proceed. Regards, Xyne
Re: [aur-general] Submitting a new package (sunjdk)
On Sun, 2009-04-05 at 23:45 +0200, xyne wrote: Hi, Both of those packages (jdk and jre) are already in the community repo. In general you shouldn't upload packages to the AUR that already exist in core/extra/community (I think developmental versions and other variations are permitted as long as they're properly named). Could you explain why you've created such a package? If you're trying to achieve something specific then perhaps someone on the list can offer some suggestions of how to proceed. Regards, Xyne jdk and jre in [community] are not updated as often as they should be imo (currently out-of-date, again), and the only other option is jre/jdk_beta, which are, well, beta! also, my package installs both jdk and jre (in the same manner as openjdk) so users don't download the same binary package twice (a la jre/jdk_beta) if they are unaware.. regards..
Re: [aur-general] Submitting a new package (sunjdk)
jre/jdk_beta should not be beta at all, last time I checked it it was the stable release. On Mon, Apr 6, 2009 at 12:04 AM, M Rawash mraw...@gmail.com wrote: On Sun, 2009-04-05 at 23:45 +0200, xyne wrote: Hi, Both of those packages (jdk and jre) are already in the community repo. In general you shouldn't upload packages to the AUR that already exist in core/extra/community (I think developmental versions and other variations are permitted as long as they're properly named). Could you explain why you've created such a package? If you're trying to achieve something specific then perhaps someone on the list can offer some suggestions of how to proceed. Regards, Xyne jdk and jre in [community] are not updated as often as they should be imo (currently out-of-date, again), and the only other option is jre/jdk_beta, which are, well, beta! also, my package installs both jdk and jre (in the same manner as openjdk) so users don't download the same binary package twice (a la jre/jdk_beta) if they are unaware.. regards..
Re: [aur-general] Submitting a new package (sunjdk)
no, not at all, you seem to be right about jdk_beta 6u14 tough :) On Mon, Apr 6, 2009 at 12:15 AM, M Rawash mraw...@gmail.com wrote: On Mon, 2009-04-06 at 00:07 +0200, Ali H. Caliskan wrote: jre/jdk_beta should not be beta at all, last time I checked it it was the stable release. 6u13 is the stable release, as mentioned here: http://java.sun.com/javase/6/webnotes/ReleaseNotes.html current version of jre/jdk_beta is 6u14: http://aur.archlinux.org/packages.php?ID=22265 i could be wrong however. regards..
Re: [aur-general] TU appliance Jens Maucher (defcon)
Decent quality packages in Community please. - Just one member of the Arch user base On Sun, Apr 5, 2009 at 2:37 PM, xyne x...@archlinux.ca wrote: Ali H. Caliskan ali.h.calis...@gmail.com wrote: We'll as long as there is no human factor in stake, I believe making a package, especially a community package isn't that much a security risk. We are not talkling about core or extra packages, just the community repo, which is of course provided by the community users. I'm sure that the the Arch Linux user would understand that. ... I don't agree with that reasoning. Even though there are warnings and the user has to enable the community repo him-/herself, there is still a reasonable expectation of package quality which leads to a base level of trust for community packages. The same cannot be said for the AUR which, by your reasoning, should elicit the same level of confidence as the community repo or perhaps even more because the user builds the packages him-/herself. Even if the community repo is run by community users, the selection of those users strives to ensure certain minimal standards that warrant the trust of those who use the repo, even if it may not be as rigorous as the selection of those charged with the maintenance of the core and extra repos. For the record, I have no opinion of Jens' packaging abilities nor did I vote on his application (as I wasn't yet a TU). I am only responding to this particular point of your post and my response is only a statement of my own (possibly naïve) opinion. Regards, Xyne
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Mon, Apr 6, 2009 at 6:52 PM, Andrei Thorp gar...@gmail.com wrote: Decent quality packages in Community please. - Just one member of the Arch user base Excuse me? I hope that I missunderstood what you said, but in case you are complaining about the quality of packages in community, I just can say talk is easier than do anything (poor translation about an known advice in my language). Thanks. -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
i stopped using jre/jdk from [community] sometime ago, due to the lack of updates and unresponsiveness of the maintainer (jre/jdk_beta were introduced for this very reason) The fact is that you cannot duplicate packages on AUR even if these are more updated than existents.. If you think that the maintainer of jre/jdk is not doing a good job, then write him an e-mail, offering help. Cheers -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
On Mon, 2009-04-06 at 19:33 +1930, Angel Velásquez wrote: i stopped using jre/jdk from [community] sometime ago, due to the lack of updates and unresponsiveness of the maintainer (jre/jdk_beta were introduced for this very reason) The fact is that you cannot duplicate packages on AUR even if these are more updated than existents.. If you think that the maintainer of jre/jdk is not doing a good job, then write him an e-mail, offering help. Cheers it's *not* a duplicate, i just cited the lack of updates as one of the reasons i forked the package, you can review sunjdk here: http://aur.archlinux.org/packages.php?ID=25303 regards
Re: [aur-general] Submitting a new package (sunjdk)
it's *not* a duplicate, i just cited the lack of updates as one of the reasons i forked the package, you can review sunjdk here: http://aur.archlinux.org/packages.php?ID=25303 regards IMO this is a duplicate effort, because this package provided the same as existent packages (jre,jdk) in repos, and btw you can't use the Maintainer tag since this isn't a binary package and you aren't a TU/Dev Thanks for your effort, anyway -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
2009/4/5 Angel Velásquez an...@archlinux.com.ve: and btw you can't use the Maintainer tag since this isn't a binary package and you aren't a TU/Dev Didn't we just have this discussion on another thread? That's the correct usage of the maintainer comment.
Re: [aur-general] Submitting a new package (sunjdk)
On Mon, Apr 6, 2009 at 7:58 PM, Daenyth Blank daenyth+a...@gmail.com wrote: 2009/4/5 Angel Velásquez an...@archlinux.com.ve: and btw you can't use the Maintainer tag since this isn't a binary package and you aren't a TU/Dev Didn't we just have this discussion on another thread? That's the correct usage of the maintainer comment. Yes and I have to say that I disagree with this, and I will be pointing my reasons on the other thread. Regards -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
On Sun, 2009-04-05 at 20:25 -0400, Daenyth Blank wrote: 2009/4/5 Angel Velásquez an...@archlinux.com.ve: i stopped using jre/jdk from [community] sometime ago, due to the lack of updates and unresponsiveness of the maintainer (jre/jdk_beta were introduced for this very reason) The fact is that you cannot duplicate packages on AUR even if these are more updated than existents.. If you think that the maintainer of jre/jdk is not doing a good job, then write him an e-mail, offering help. Cheers -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909 While it technically is not a duplicate, it more or less is just two packages combined into one. I wouldn't add it and would instead coordinate with the jre/jdk maintainer so that those packages can be kept up to date. Alternately, apply to be a TU and keep the packages up to date yourself, if he's willing to orphan them for you. not really, unless you regard kde packages in [extra] as duplicates of those in [kde-mod]. jre and jdk is just sun's jdk split into two packages for the sole purpose of having smaller binary packages, but serve no purpose at all if you are building from a pkgbuild. however, if you still see it as problematic, you can well remove it, i'll continue to use it personally anyway.. cheers
[aur-general] Maintainer vs Contributor tag let's find a solution ; )
Hi, this thread were discussed in the history, so I think is time to clarify and put the correct information to the wiki. (Actually on the recent TU application and sunjdk package). IIRC: a) Maintainer tag in PKGBUILD is just use for people who maintain the binary package generated by this PKGBUILD on official repositories (core, extra, community*), and the people with abilities to do this are TU and Devs. b) Contributor tag is for people who upload the PKGBUILD for first time or is maintaining it at this time. But sometimes this is hard to apply, for example I adopted an orphan PKGBUILD on AUR and I decided to update it and maintain it, what I should have to do: 1.- Should I remove the past contributor and add myself as a Contributor? 2.- Should I keep all the contributor list even if they are more than 4 different people (4 lines more to the PKGBUILD) 3.- Add myself to the maintainer tag? IMO I will use the second option, to keep all the contributor list, maybe tomorrow I won't be able to contribute with this PKGBUILD but it will be nice, to the future owners of these PKGBUILD to know who maintained before them. But maybe we will have a long list of contributors, so, it would be nice to discuss an idea to have tags for maintainers of PKGBUILD with have a binary and contributors of PKGBUILDs, as I said, i would like to improve a method to apply the second idea. Please try to don't flame the ideas, try to propose new ones, or improve the exposed by me. Regards Note: * Many people should disagree with the idea about community and official repo, IMO if community it's enabled by default on pacman, community became official, no matter what the history was... -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
not really, unless you regard kde packages in [extra] as duplicates of those in [kde-mod]. jre and jdk is just sun's jdk split into two packages for the sole purpose of having smaller binary packages, but serve no purpose at all if you are building from a pkgbuild. First of all kde-mod is a good project, but their binaries are not official, and they can duplicate what they want on their repos. however, if you still see it as problematic, you can well remove it, i'll continue to use it personally anyway.. I can't remove it since I resigned on my TU position, but if I were tu I'd like to discuss about removal (like I am doing) before do it. And if you will be continue using your package then you got the idea about the Arch's way, and you realized that ABS rocks, and I am glad you got it. Cheers -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
On Mon, Apr 06, 2009 at 08:20:41PM +1930, Angel Velásquez wrote: Hi, this thread were discussed in the history, so I think is time to clarify and put the correct information to the wiki. (Actually on the recent TU application and sunjdk package). IIRC: a) Maintainer tag in PKGBUILD is just use for people who maintain the binary package generated by this PKGBUILD on official repositories (core, extra, community*), and the people with abilities to do this are TU and Devs. b) Contributor tag is for people who upload the PKGBUILD for first time or is maintaining it at this time. But sometimes this is hard to apply, for example I adopted an orphan PKGBUILD on AUR and I decided to update it and maintain it, what I should have to do: 1.- Should I remove the past contributor and add myself as a Contributor? 2.- Should I keep all the contributor list even if they are more than 4 different people (4 lines more to the PKGBUILD) 3.- Add myself to the maintainer tag? The accepted practice is to keep a contributor comment for all significant contributors of a PKGBUILD. I don't think it really matters if there's a maintainer comment or not. Maintainers for all packages are tracked by other means. That comment doesn't carry much weight. There's really no reason why maintainers of unsupported packages couldn't use it if they really wanted to.
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
On Sun, Apr 5, 2009 at 21:06, Loui Chang louipc@gmail.com wrote: The accepted practice is to keep a contributor comment for all significant contributors of a PKGBUILD. I don't think it really matters if there's a maintainer comment or not. Maintainers for all packages are tracked by other means. That comment doesn't carry much weight. There's really no reason why maintainers of unsupported packages couldn't use it if they really wanted to. I agree with this to a degree, but it is somewhat useful to have that information stored in the PKGBUILD, so that you don't have to go through the AUR interface, IMO
Re: [aur-general] Submitting a new package (sunjdk)
On Mon, Apr 06, 2009 at 03:01:46AM +0200, M Rawash wrote: On Mon, 2009-04-06 at 19:57 +1930, Angel Velásquez wrote: it's *not* a duplicate, i just cited the lack of updates as one of the reasons i forked the package, you can review sunjdk here: http://aur.archlinux.org/packages.php?ID=25303 regards IMO this is a duplicate effort, because this package provided the same as existent packages (jre,jdk) in repos, and btw you can't use the Maintainer tag since this isn't a binary package and you aren't a TU/Dev Thanks for your effort, anyway frankly, i'm not really sure if the Maintainer/Contributor tags signify anything other than 'current maintainer'/'former contributor', i didn't even know there was a debate about it.. It's an issue for some people because namcap has some odd quirks about it.
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
5. Change the previous maintainer tag to a contributor tag and add yourself as maintainer I don't quite follow... you say that you want to improve the method, but you insist that we don't change it and use the old one? Please correct me if I'm wrong This should be 4.- and it's more like than my 2nd point .. then that point about Maintainer is just because exist a binary package in official repos and it's maintained by will be lost, so the concept will change to Maintainer is the people who actually owns the PKGBUILD in any repo or AUR.. (just to clarify how to use the tags). Please try to don't flame the ideas, try to propose new ones, or improve the exposed by me. Uh.. what? Disregarding this... Don't know, sometimes I just generate flames, maybe is my bad english :D. So resuming: there is a new point on the list! by Daenyth, who will decide will be the valid point is the question that I have right now. Cheers! -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Submitting a new package (sunjdk)
Daenyth Blank daenyth+a...@gmail.com wrote: The analogy doesn't carry very well here.. The kdemod repos 1) are not officially supported or endorsed, and 2) contain patches that change functionality. That being said, I wouldn't go so far as to entirely delete the package, I just think it's a useless duplication of effort Considering that the combo-package does simplify both building and installation for those users who want both the development and the runtime environment and that it's already been created, it seems to be only beneficial to have it in the AUR. Perhaps it could be taken over by the jre/jkd maintainer (or vice versa) later on to consolidate the effort. Sorry if I'm missing something.
Re: [aur-general] Submitting a new package (sunjdk)
That being said, I wouldn't go so far as to entirely delete the package, I just think it's a useless duplication of effort That is my point, but according to this: [1] Quote: Check [core], [extra], and [community] for the package. If it is inside any of those repositories in ANY form, DO NOT submit the package (if the current package is broken or is lacking an included feature then please file a bug report in FlySpray). This should be deleted ... but thanks anyway for the effort as I said before. :) [1] http://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_Packages_to_UNSUPPORTED -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
2009/4/5 Angel Velásquez an...@archlinux.com.ve: This should be 4.- and it's more like than my 2nd point .. then that point about Maintainer is just because exist a binary package in official repos and it's maintained by will be lost, so the concept will change to Maintainer is the people who actually owns the PKGBUILD in any repo or AUR.. (just to clarify how to use the tags). I don't really have any comment to add here, but I'm not quite sure if I understand... you're saying that the intention of the maintainer tag is to store the data because the binary repos don't? Don't know, sometimes I just generate flames, maybe is my bad english :D. Ah, ok. I was confused :P So resuming: there is a new point on the list! by Daenyth, who will decide will be the valid point is the question that I have right now. As I said before, it seems like the general consensus was in favor of changing it. http://www.archlinux.org/pipermail/aur-general/2008-October/002502.html
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
I think it makes the most sense to designate the person currently maintaining the package/PKGBUILD as the maintainer irrespective of that person's status in the community or the destination of the package/PKGBUILD. It immediately indicates to anyone looking at the PKGBUILD whom they should contact about updating it. I think previous maintainers should be listed as contributors along with anyone who's contributed signficant changes to the package. Telling people that they can't claim to be a maintainer of a package because they're not a dev or TU comes across the wrong way too. Just because the binary isn't hosted in the AUR doesn't mean that the work of maintaining a package (updating, responding to comments, etc) is any different than if the binary were uploaded. Just my 2¢.
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
As I said before, it seems like the general consensus was in favor of changing it. http://www.archlinux.org/pipermail/aur-general/2008-October/002502.html But this was the last reply [1] by foutrelis, and confused me.. seems that even Aaron Griffin agree with having the maintainer tag for the actual maintainer and the past maintainers became contributors. P.S: I knew that this wasn't a Deja-vu and we discussed this before (for the record I didn't participated in the last discussion) [1] http://www.archlinux.org/pipermail/aur-general/2008-October/002514.html -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
Here goes an section from the the PKGBUILD man page: EXAMPLE The following is an example PKGBUILD for the patch package. For more examples, look through the build files of your distribution’s packages. For those using Arch Linux, consult the ABS tree. # Maintainer: Joe User joe.u...@example.com pkgname=patch pkgver=2.5.4 pkgrel=3 Note the use of Maintainer... In the end, it is a comment and nothing more so who really cares about this. Allan
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
I like option 1.- Should I remove the past contributor and add myself as a Contributor?. This is exactly like it is in /usr/share/pacman/PKGBUILD.proto example. -- José Valecillos
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
2009/4/6 José Valecillos valecillo...@gmail.com: I like option 1.- Should I remove the past contributor and add myself as a Contributor?. This is exactly like it is in /usr/share/pacman/PKGBUILD.proto example. -- José Valecillos The problem with this is that it's essentially claiming all the work in the package as your own, which it clearly isn't
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
Then you must add all the past Contributors, even if they are 10 or 100?. On the other hand, in the web interface or when you install the package it don't show anything about the contributor, this should be there I think, dont' you?. I mean, you only can know who is the contributor if you open the PKBUILD directly. However, there are things more importants to discuss. This is really irrelevant if you think about it.
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
2009/4/6 José Valecillos valecillo...@gmail.com: Then you must add all the past Contributors, even if they are 10 or 100?. On the other hand, in the web interface or when you install the package it don't show anything about the contributor, this should be there I think, dont' you?. I mean, you only can know who is the contributor if you open the PKBUILD directly. However, there are things more importants to discuss. This is really irrelevant if you think about it. Agreed. Let's stick to the one which was mostly agreed upon last time; that is any one who maintains the package anywhere can add a Maintainer tag and past contributors be listed in the PKGBUILD. I've filed a bug report to remove this info from namcap: http://bugs.archlinux.org/task/14114 -- Abhishek
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
2009/4/6 José Valecillos valecillo...@gmail.com: Then you must add all the past Contributors, even if they are 10 or 100?. On the other hand, in the web interface or when you install the package it don't show anything about the contributor, this should be there I think, dont' you?. I mean, you only can know who is the contributor if you open the PKBUILD directly. However, there are things more importants to discuss. This is really irrelevant if you think about it. Excuse me, And who are you to call the things irrelevant?, if is irrelevant for you, then don't reply and it's enough. The fact is that we will take the last discussion were several people agreed to use the Maintainer tag for the current maintainer of the PKGBUILD and past maintainers or the original contributors will be on the contributor tag (even if there are many contributors). So this thread at least was useful to remember the way to handle these tags. (at least for me, and to remember to several people who delete past maintainers). -- Angel Velásquez angvp @ irc.freenode.net Linux Counter: #359909
Re: [aur-general] TU appliance Jens Maucher (defcon)
2009/4/6 xyne x...@archlinux.ca: I don't agree with that reasoning. Even though there are warnings and the user has to enable the community repo him-/herself, there is still a reasonable expectation of package quality which leads to a base level of trust for community packages. The same cannot be said for the AUR which, by your reasoning, should elicit the same level of confidence as the community repo or perhaps even more because the user builds the packages him-/herself. Even if the community repo is run by community users, the selection of those users strives to ensure certain minimal standards that warrant the trust of those who use the repo, even if it may not be as rigorous as the selection of those charged with the maintenance of the core and extra repos. AFAIK, [community] is enabled by default on new Arch installs. -- Abhishek
Re: [aur-general] TU appliance Jens Maucher (defcon)
Agreed to Xyne and Dae, I certainly don't mean to say Community packages are bad at the moment. In fact, no trouble so far! :) As suggested translations to English sayings: Talk is cheap or perhaps Easier said than done. Cheers, -Andrei Garoth Thorp
Re: [aur-general] Maintainer vs Contributor tag let's find a solution ; )
I'm not sure if this has been mentioned before, but here's my take: - Maintainer: The person who currently maintains a package. - Contributor: The person who first submitted the package. If a package is so badly constructed that it needs to be rewritten from scratch, the contributor tag would only list the person who did the rewrite. I know we've agreed on multiple contributor tags, but I believe the method detailed above is cleaner, more maintainable and more straight-forward. I'll most likely adopt it for my own packages, but I'm not saying that anyone else should. I would say that we should hold a voting to make a final decision. However, it's not an important issue at all, so the current way of doing things (multiple contributor lines) is sufficient.
