Re: [aur-general] Some packages moved from extra/community to aur
On 7 December 2010 11:56, Michael Trunner mich...@trunner.de wrote: we use Archlinux on our university. The following packages where in extra/community the last time we reinstalled our student pool and now in AUR: * tcsh * autofs * python-numarray Is it possible to move it back to community? At least autofs? What must/can I do for that? Unfortunately they have been moved during the [extra] repo cleanup[1] and this means that nobody (DEVs and TUs) was interested on those. You have to build them yourself until some DEV/TU is interested on those packages. [1] http://mailman.archlinux.org/pipermail/arch-dev-public/2010-November/018341.html -- Andrea Scarpino Arch Linux Developer
Re: [aur-general] Some packages moved from extra/community to aur
On Tue, Dec 7, 2010 at 11:56 AM, Michael Trunner mich...@trunner.de wrote: Hi, we use Archlinux on our university. The following packages where in extra/community the last time we reinstalled our student pool and now in AUR: * tcsh * autofs * python-numarray Is it possible to move it back to community? At least autofs? What must/can I do for that? Tschö Michael Well, it's really simple. As autofs already have 10 votes, you just need to apply to become a TU and you will be able to move it to [community] and maintain it. More seriously, these packages have been move to AUR as no TU wants to maintain them. It will only change if one TU decides to adopt them. -- Cédric Girard
[aur-general] openttd package removal
openttd [1] is in community too. [1] http://aur.archlinux.org/packages.php?ID=9391 Thanks in advance Joao Cordeiro
Re: [aur-general] openttd package removal
Le mardi 7 décembre 2010 13:14:07, Joao Cordeiro a écrit : openttd [1] is in community too. [1] http://aur.archlinux.org/packages.php?ID=9391 Thanks in advance Joao Cordeiro Removed, thanks! ++
Re: [aur-general] Some packages moved from extra/community to aur
2010/12/7 Cédric Girard girard.ced...@gmail.com: On Tue, Dec 7, 2010 at 11:56 AM, Michael Trunner mich...@trunner.de wrote: Well, it's really simple. As autofs already have 10 votes, you just need to apply to become a TU and you will be able to move it to [community] and maintain it This is not so simple. If i wanna be a TU, this need a long time before to be enough famous in arch community to make an application. -- Sébastien Luttringer www.seblu.net
Re: [aur-general] Some packages moved from extra/community to aur
Is it possible to move it back to community? At least autofs? What must/can I do for that? Nice to see some use arch at uni :) Build them yourself and create a repo. https://wiki.archlinux.org/index.php/Custom_local_repository#Custom_local_repository
Re: [aur-general] Amendment
PyroPeter wrote: On 12/05/2010 07:55 PM, Xyne wrote: The voting period should remain 7 days regardless of the current votes. It is rude to others to exclude them from participation even if the outcome is assured. Once the voting period is over, the motion shall pass if either an absolute majority were reached, or if a simple majority were reached with quorum. This will allow all TUs to have their say if they so choose and it sidesteps the issue of determining inactivity due to shortened voting periods while preventing motions with absolute (i.e. insurmountable) majorities from failing, which is what the real issue is here. Overall I think this is the simplest solution. Maybe one could go one step further and only declare a motion as passed if there is an absolute majority after 7 days. (Meaning that more than one half of the active TUs voted YES) This would simplify the voting procedure a lot, but would higher the barrier for a motion to pass. e.g. results that express mainly indifference with a slight tendency to YES (like 5 yes, 4 no and 15 abstain votes) would no longer pass. I think that barrier might be a bit too high. At the same time, I think we should have some minimum barrier. As it currently stands, with Loui's and Pierre's interpretation of abstain*, it is fully possible for someone to become a TU with a single yes vote, e.g. 66% - 1 TUs abstain and only one votes yes. It basically means meh, I can't think of any reason *not* to give you access to [community] and the AUR, so have fun. A minimum threshold would mean ok, enough TUs are confident that you can be trusted with access. This makes more sense to me as a TU is a *Trusted* User, not a Not Distrusted User. Basically, access should be given for positive reasons, not for the absence of negative reasons. Perhaps a better system would be to simply require the following two conditions to pass the votes: $yes ($percent * $TUs) $yes $no In words, a set percentage of all active TUs must vote yes and there must be more yes votes than no notes. We could still require quorum. If quorum is not met, rather than reject the vote, it would be postponed until quorum can be met. There is no reason to reject an applicant simply because some TUs are unavailable or lazy (in which case we probably need some new TUs :P). Summarizing: * vote passes in EITHER of the following cases: - more than 50% of all active TUs vote yes (quorum doesn't matter in this case) - more than x% of all active TUs vote yes AND more vote yes than no AND quorum is established (yes + no + abstain y% of all TUs) (x% and y% to be determined by discussion, e.g. 33% and 66%, resp.) * voting period never gets shortened even if the outcome is assured (others would be prevented from voting) #!/usr/bin/env python2 from sys import argv from fractions import Fraction # Threshold percentage of yes votes to pass motion. # 33% used only as an example. threshold = Fraction(33, 100) # Quorum (66%) quorum = Fraction(66, 100) # Majority majority = Fraction(50, 100) # Total active TUs, yes votes, no votes, abstain votes. TUs, yes, no, abstain = [Fraction(x) for x in argv[1:]] # Total number of votes. votes = yes + no + abstain # If an absolute majority has voted yes, # or quorum has been established with a simple majority if (yes / TUs) majority \ or ( votes / TUs = quorumand \ yes / TUs threshold and \ yes no \ ): print The motion has passed. else: print The motion has failed.
[aur-general] deletion request: dbus-systemd
Good morning, dbus-systemd is now superfluous with the necessary compile flags being added to testing/dbus-core. Please delete dbus-systemd at your convenience: http://aur.archlinux.org/packages.php?ID=40399 thanks, dave
Re: [aur-general] deletion request: dbus-systemd
On Tue, Dec 7, 2010 at 3:22 PM, Dave Reisner d...@falconindy.com wrote: Good morning, dbus-systemd is now superfluous with the necessary compile flags being added to testing/dbus-core. Please delete dbus-systemd at your convenience: http://aur.archlinux.org/packages.php?ID=40399 Le package has been removed.
Re: [aur-general] Some packages moved from extra/community to aur
On Tuesday 07 December 2010 12:30:35 Seblu wrote: 2010/12/7 Cédric Girard girard.ced...@gmail.com: On Tue, Dec 7, 2010 at 11:56 AM, Michael Trunner mich...@trunner.de wrote: Well, it's really simple. As autofs already have 10 votes, you just need to apply to become a TU and you will be able to move it to [community] and maintain it This is not so simple. If i wanna be a TU, this need a long time before to be enough famous in arch community to make an application. I think Cédric's suggestion isn't daft at all. TUs really should be people who have a good experience of using Arch Linux and have the neccesary skills to build and maintain packages. It's not at all about being famous, IMO. (I hardly think I was, nor am I now!) Seriously, if you or anyone else is interested in there being certain packages in [community] (and they fulfill the requirements) and you have the skills, please do apply :-) We said a while back, I think, that we'd rather have more TUs maintaining reasonable numbers of packages, and packages that they use, than a small number of TUs with too much on their plates. Pete.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
Kaiting Chen wrote: Wow. I didn't think it was that bad. The wording could use some work. The biggest question I've been getting is how long is the discussion period between the first and second vote if the quorum fails?. The answer is of course zero, but apparently this is very unorthodox. Also it seems the people are confused by the difference between 'not accepted' and 'rejected', which to my understanding there is none. --Kaiting. I've rewritten that section with some changes (see below). I've tried to keep the wording unambiguous and relatively simple. Note the following functional changes: * If 50% or more of all active TUs vote NO then the vote is rejected even in the absence of quorum. This is logically coherent with accepting the vote when more than 50% vote YES in the absence of quorum. * Default durations for various items such as discussion periods and voting periods. I'm not sure about the wording of ... shall normally be ... but may be determined by the nature of the proposal as described elsewhere in the bylaws. and similar passages. The intention is to enable other sections of the bylaws and nothing else to supersede the defaults. For example the TU removal procedure allows for shorter discussion and voting periods. The section thus provides the standard template for voting that can be tweaked by other sections as necessary. The tricky bit is wording it in such a way that the person making the proposal can't arbitrarily change them. SVP SECTION: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall normally be 5 days but may be determined by the nature of the proposal as described elsewhere in the bylaws. All discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall normally be 7 days but may be determined by the nature of the proposal as described elsewhere in the bylaws. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall normally be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, but may be determined by the nature of the proposal as described elsewhere in the bylaws. The proposal is normally accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. The proposal is normally rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall normally be 3 months but may be determined by the nature of the proposal as described elsewhere in the bylaws. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
Re: [aur-general] Tarball Guidelines
keenerd wrote: On Mon, Dec 6, 2010 at 4:59 AM, Nicky726 nicky...@gmail.com wrote: been told by the bot, that selinux-flex has a binary (selinux-flex/flex- arch.patch.gz), which is a gziped patch. Guess I can ungzip it, though as this package is just a copy of a [core] package from some time ago, I guess the original maintainers new, what they were doing, if they included it this way. So should I do it to not include evil gziped patches? Evil is such a strong word. It is just without benefit. Disturbs the transparency of things. Technically against the rules. Zipped patches was an edge case. Here, I chose to take a strict interpritation of the edge cases. It is only a comment after all, very little of consequence. Besides, Arch tries hard to not patch things :-) But thank you for taking the time to read and respond. So many maintainers ignore comments. -Kyle http://kmkeen.com If the patch is large then what's the problem with compressing it?
Re: [aur-general] Some packages moved from extra/community to aur
On Tue, Dec 07, 2010 at 11:56:20AM +0100, Michael Trunner wrote: we use Archlinux on our university. The following packages where in extra/community the last time we reinstalled our student pool and now in AUR: * tcsh * autofs * python-numarray Is it possible to move it back to community? At least autofs? What must/can I do for that? As this actually the university I'm currently studying at, I'll move them back to [community] today or tomorrow :p I think that should be fine since all of the packages already have = 10 votes.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
Hey, On Tuesday 07 December 2010 15:37:41 Xyne wrote: I've rewritten that section with some changes (see below). I've tried to keep the wording unambiguous and relatively simple. Note the following functional changes: * If 50% or more of all active TUs vote NO then the vote is rejected even in the absence of quorum. This is logically coherent with accepting the vote when more than 50% vote YES in the absence of quorum. * Default durations for various items such as discussion periods and voting periods. I think this is really helpful. A few more thoughts interleaved below, including a suggestion on the normally point. I'm not sure about the wording of ... shall normally be ... but may be determined by the nature of the proposal as described elsewhere in the bylaws. and similar passages. The intention is to enable other sections of the bylaws and nothing else to supersede the defaults. For example the TU removal procedure allows for shorter discussion and voting periods. The section thus provides the standard template for voting that can be tweaked by other sections as necessary. The tricky bit is wording it in such a way that the person making the proposal can't arbitrarily change them. SVP SECTION: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). Do we require that a proposal has only yes and no as options, as well as abstain? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.) The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall normally be 5 days but may be I'd suggest 5 full days rather than just 5 days, for the removal of any potential ambiguity. determined by the nature of the proposal as described elsewhere in the bylaws. All discussion shall take place on aur-general. During the discussion period, votes shall not be cast. I'm not quite sure what all discussion shall... means. Does it mean that discussion outside of aur-general is forbidden, not allowed as evidence in a court, etc.? What's the purpose of this line? The voting period begins when the discussion period ends. The duration of the voting period shall normally be 7 days but may be determined by the nature of the proposal as described elsewhere in the bylaws. In answer to your normally point, perhaps: The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall normally be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, but may be determined by the nature of the proposal as described elsewhere in the bylaws. again, perhaps just make it a little tighter like above: Quorum shall be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws. The proposal is normally accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. Same thing, perhaps replace is normally accepted... ...but these conditions may be superseded with is accepted... ...unless these conditions are superseded. The proposal is normally rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes but these conditions may be superseded by other sections of the bylaws pertaining to the proposal. Same thing. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall normally be 3 months but may be determined by the nature of the proposal as described elsewhere in the bylaws. The waiting period begins at the end of the voting period. Same thing. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the
Re: [aur-general] Tarball Guidelines
Kaiting Chen wrote: On Mon, Dec 6, 2010 at 9:25 PM, Heiko Baums li...@baums-on-web.de wrote: Am Mon, 6 Dec 2010 21:02:00 -0500 schrieb Loui Chang louipc@gmail.com: I might be kind of crazy here, but maybe desktop files and icons are things that should be distributed from upstream. So maintainers should work to get those included like a patch or whatnot. I generally agree, but not every upstream does include desktop files and it's not possible for packages which aren't maintained by upstream anymore. We already had this discussion on the mailing lists. So this should be handled quite flexible in AUR as well as in the repos. You won't get the ideal in this point. In the official repositories we don't include these files generally. I think the AUR should be the place where maintainers can choose to include these files if they want. There are all kinds of PKGBUILD's in [unsupported] with all kinds of crazy patches. And including a *.desktop file that upstream doesn't include is essentially a patch. So if we're going to say that AUR PKGBUILD's should not include *.desktop files then we might as well say that AUR PKGBUILD's should not include patches. And if we're going to go with this level of communism then we might as well say that -svn, -git, etc. PKGBUILD's don't belong in [unsupported] because a development branch is basically a series of unofficially released patches. And if we do that we might as well scrap the whole AUR. On the other hand for [core], [extra], and [community] users expect a high level of standardization and QA. Therefore in my opinion things like *.desktop files and patches NEVER belong there except when critically necessary. Let me summarize: [unsupported] is not official so we should only suggest not enforce; [core], [extra], [community] are official and we should enforce our policy to the fullest extent. --Kaiting. I basically agree with previous comments to the effect that some extra files should be allowed in AUR packages provided that they are relatively small. The validity of inclusion should be determined case by case. I definitely don't think that mass-spamming the AUR with a bot is the right way to do it.
Re: [aur-general] Some packages moved from extra/community to aur
On Tue, Dec 7, 2010 at 4:58 PM, Michael Trunner mich...@trunner.de wrote: But back to topic: it isn't funny to use a not real officially autofs package on our university network. What was or is the problem, that no TU want's to maintain these package? Basically it is the package is not used by any TU or Dev. Thus testing is a little more complicated. -- Cédric Girard
Re: [aur-general] Amendment
* vote passes in EITHER of the following cases: - more than 50% of all active TUs vote yes (quorum doesn't matter in this case) - more than x% of all active TUs vote yes AND more vote yes than no AND quorum is established (yes + no + abstain y% of all TUs) (x% and y% to be determined by discussion, e.g. 33% and 66%, resp.) This is _very_ hard to understand. I proposed the use of an absolute majority mainly because of it's simplicity (as it works without the quorum stuff). $yes ($percent * $TUs) $yes $no I like that, as it combines the simplicity of an absolute majority with a barrier of variable height. It also works without defining a quorum. (as the number of required YES votes is relative to the number of active TUs, not the number of votes) -- freenode/pyropeter ETAOIN SHRDLU
Re: [aur-general] TU application - Kyle Keen
On Tue, Dec 7, 2010 at 11:16, Xyne x...@archlinux.ca wrote: keenerd wrote: Hello all. I am applying to become a TU. My sponsor is Xyne. My name is Kyle Keen, though my handle for irc/bbs/the-last-12-years has been Keenerd. I've been using Arch for a while now, from back when it was still known for refusing to package info files. Before that I did a wee bit of dev work for Puppy Linux. I actually got a bash gui app (yay xdialog) into the ISO but please don't look up the code, it was my first bash script and is rather terrifying. Lately I am a 24 year old freelance electrical engineer and spend my days writing C, my nights writing Python and during the twilight hours some Bash. Right now I host the bugbot in #archlinux-bugs and I've got a few AUR packages(1). Of them, ScrotWM and Slurm probably deserve to be in [community]. I've written several well-liked metatools for Arch including Pacgraph, Pacmatic, and Aurphan. Aurphan is the main reason for trying to apply. Pierre requested a feature to cross check official packages as well as the AUR(2). I was a little shocked to find 35 official orphans on my system. Clearly, we are understaffed. Arch has been nothing short of amazing and I want to do what I can to help keep it going. Other goals include improving the maintenance tools and porting Arch to old or cheap architectures. I also mirrored the AUR for a while and have a nearly complete copy of the old comments from before the Great Table Drop that should be re-inserted. Thanks for your consideration, Kyle http://kmkeen.com 1) http://aur.archlinux.org/packages.php?SeB=mK=keenerdSO=dSB=v 2) https://bbs.archlinux.org/viewtopic.php?id=108693 The discussion period is nearly over but I have something that I want to bring up after reading though the nearly 100 new messages on aur-general. keenerd wrote: If no one can think of a better way to deal with the nonconforming packages, I'll write a bot to post insulting comments. Personally, I really like this solution. The AUR has always had a wild west frontier / insane asylum feel to it. The less regulation, the better it works. But a few well placed suggestions could help make the two thousand maintainers do a better job. Heiko Baums wrote: Am Mon, 6 Dec 2010 16:53:08 -0500 schrieb keenerd keen...@gmail.com: find /var/abs -name *.png | wc -l == 60 Of +4800 packages, that is 1.2%. The AUR is more than twice that rate. But while we are running the numbers to determine best practices. This would be about 48+ e-mails to users if your bot continues writing those AUR comments. That's too many. As I said before, please, don't do this. You can, of course, let such a bot help you finding bad packages. But you have to verify its results personally, before you write such AUR comments. Such automations are usually pretty unreliable except they are written very thoughtfully and are tested a lot. And regarding the 1.2%... Don't trust any statistics you did not even fake. Heiko I'm a bit bothered by the way that you've handled this. You proceeded to write and launch the bot based on your personal interpretation of the rules without waiting for any definitive conclusion from the ongoing discussion about them. Comments aren't that big a deal, even if there will be many confused maintainers, but with TU status on the AUR you could do much more with disastrous consequences. Considering this and the still-ongoing discussion about the AUR guidelines, do you agree that it would be prudent to be more patient in the future and wait until we've come to a conclusion before going ahead with something like this again? Wow he actually launched that bot? I thought it was a joke. It seemed so stupid that I didn't think anyone would take it seriously. That definitely opens up some other perspectives on the application...
Re: [aur-general] Some packages moved from extra/community to aur
On 7 December 2010 17:30, Michael Trunner mich...@trunner.de wrote: Or more easy: I put the builded package on our repository and can use pacman as before. :-) Of curse, that's the right way. You could add and patch every tool your university needs in that way. -- Andrea Scarpino Arch Linux Developer
Re: [aur-general] TU application - Kyle Keen
On 12/07/2010 06:19 PM, Daenyth Blank wrote: Right now I host the bugbot in #archlinux-bugs and I've got a few AUR packages(1). Of them, ScrotWM and Slurm probably deserve to be in [community]. I've written several well-liked metatools for Arch including Pacgraph, Pacmatic, and Aurphan. Aurphan is the main reason for trying to apply. Pierre requested a feature to cross check official packages as well as the AUR(2). I was a little shocked to find 35 official orphans on my system. Clearly, we are understaffed. Arch has been nothing short of amazing and I want to do what I can to help keep it going. Other goals include improving the maintenance tools and porting Arch to old or cheap architectures. I also mirrored the AUR for a while and have a nearly complete copy of the old comments from before the Great Table Drop that should be re-inserted. Thanks for your consideration, Kyle http://kmkeen.com 1) http://aur.archlinux.org/packages.php?SeB=mK=keenerdSO=dSB=v 2) https://bbs.archlinux.org/viewtopic.php?id=108693 The discussion period is nearly over but I have something that I want to bring up after reading though the nearly 100 new messages on aur-general. keenerd wrote: If no one can think of a better way to deal with the nonconforming packages, I'll write a bot to post insulting comments. Personally, I really like this solution. The AUR has always had a wild west frontier / insane asylum feel to it. The less regulation, the better it works. But a few well placed suggestions could help make the two thousand maintainers do a better job. Heiko Baums wrote: Am Mon, 6 Dec 2010 16:53:08 -0500 schrieb keenerdkeen...@gmail.com: find /var/abs -name *.png | wc -l == 60 Of +4800 packages, that is 1.2%. The AUR is more than twice that rate. But while we are running the numbers to determine best practices. This would be about 48+ e-mails to users if your bot continues writing those AUR comments. That's too many. As I said before, please, don't do this. You can, of course, let such a bot help you finding bad packages. But you have to verify its results personally, before you write such AUR comments. Such automations are usually pretty unreliable except they are written very thoughtfully and are tested a lot. And regarding the 1.2%... Don't trust any statistics you did not even fake. Heiko I'm a bit bothered by the way that you've handled this. You proceeded to write and launch the bot based on your personal interpretation of the rules without waiting for any definitive conclusion from the ongoing discussion about them. Comments aren't that big a deal, even if there will be many confused maintainers, but with TU status on the AUR you could do much more with disastrous consequences. Considering this and the still-ongoing discussion about the AUR guidelines, do you agree that it would be prudent to be more patient in the future and wait until we've come to a conclusion before going ahead with something like this again? Wow he actually launched that bot? I thought it was a joke. It seemed so stupid that I didn't think anyone would take it seriously. That definitely opens up some other perspectives on the application... dude, he said it will write a bot for aur. RIGHT NOW he has a bot for bugtracker and it doesn't send any emails, just write some text in the channel. nothing more, nothing less -- Ionuț
Re: [aur-general] Some packages moved from extra/community to aur
On 12/07/2010 06:34 PM, Michael Trunner wrote: On Tue, Dec 7, 2010 at 4:58 PM, Michael Trunnermich...@trunner.de wrote: But back to topic: it isn't funny to use a not real officially autofs package on our university network. What was or is the problem, that no TU want's to maintain these package? Basically it is the package is not used by any TU or Dev. Thus testing is a little more complicated. Why you can use it for crypted folders, too. You need nor network ;-). But yes if nobody use it, ... If Lukas put it into community I think I can test it easily. this subject is settled. Lukas agreed to adopt them. move along, nothing to see here :D -- Ionuț
Re: [aur-general] TU application - Kyle Keen
On Tue, Dec 7, 2010 at 11:36, Ionuț Bîru ib...@archlinux.org wrote: dude, he said it will write a bot for aur. RIGHT NOW he has a bot for bugtracker and it doesn't send any emails, just write some text in the channel. nothing more, nothing less -- Ionuț Ah, I must have misread something.
Re: [aur-general] TU application - Kyle Keen
On 12/07/2010 05:36 PM, Ionuț Bîru wrote: On 12/07/2010 06:19 PM, Daenyth Blank wrote: Wow he actually launched that bot? I thought it was a joke. It seemed so stupid that I didn't think anyone would take it seriously. That definitely opens up some other perspectives on the application... dude, he said it will write a bot for aur. RIGHT NOW he has a bot for bugtracker and it doesn't send any emails, just write some text in the channel. nothing more, nothing less I think he actually launched the AUR-bot: http://aur.archlinux.org/packages.php?ID=8388 (first comment) -- freenode/pyropeter ETAOIN SHRDLU
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
Peter Lewis wrote: Do we require that a proposal has only yes and no as options, as well as abstain? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.) For now those are the only options available on the interface, so we don't need to consider anything else. Eventually Standard Voting Procedure could be changed to Simple Voting Procedure and another procedure could be introduced for anything beyond an accept/reject motion. I'm not quite sure what all discussion shall... means. Does it mean that discussion outside of aur-general is forbidden, not allowed as evidence in a court, etc.? What's the purpose of this line? I've changed that to Official discussion shall I'd suggest 5 full days rather than just 5 days, for the removal of any potential ambiguity. I agree and will include that. In practice though, nobody counts the hours. In answer to your normally point, perhaps: The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws. I tried to find a natural-sounding formulation using unless too but couldn't. I think it's because I already had ... nature of the proposal... in my head. I agree with the use of unless but not the proposed statement. I've used UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. in the updated version below. But yes, I think these are very clear. Well done! Thanks. Second version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs, with participation measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER the number of YES votes is greater than half the number of active TUs OR quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER more than half of all active TUs have voted NO OR quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
I've tried to remove further ambiguity from the sections about quorum, acceptance and rejection. I've also reformulated the first case in the rejection section to use similar wording to the acceptance section. Third version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
On Tuesday 07 December 2010 16:44:36 Xyne wrote: Peter Lewis wrote: Do we require that a proposal has only yes and no as options, as well as abstain? Could a proposal present a list of options? How would this affect the voting, or should it not be allowed? (If not, I think we should state explicitly what is [only] allowed.) For now those are the only options available on the interface, so we don't need to consider anything else. I agree. Let's say so then in the byelaws. Eventually Standard Voting Procedure could be changed to Simple Voting Procedure and another procedure could be introduced for anything beyond an accept/reject motion. Indeed :-) In answer to your normally point, perhaps: The duration of the voting period shall be 7 days unless determined otherwise according to the nature of the proposal and as described elsewhere in the bylaws. I tried to find a natural-sounding formulation using unless too but couldn't. I think it's because I already had ... nature of the proposal... in my head. I agree with the use of unless but not the proposed statement. I've used UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. in the updated version below. Good stuff. Oops, I just saw you replied again... will reply to that...
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
On Tuesday 07 December 2010 16:58:49 Xyne wrote: Third version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). So I'd just suggest also adding: The proposal must also be worded unambiguously, and such that a YES / NO answer may be given. Looks good to me though :-) Pete.
Re: [aur-general] TU application - Kyle Keen
PyroPeter wrote: On 12/07/2010 05:36 PM, Ionuț Bîru wrote: On 12/07/2010 06:19 PM, Daenyth Blank wrote: Wow he actually launched that bot? I thought it was a joke. It seemed so stupid that I didn't think anyone would take it seriously. That definitely opens up some other perspectives on the application... dude, he said it will write a bot for aur. RIGHT NOW he has a bot for bugtracker and it doesn't send any emails, just write some text in the channel. nothing more, nothing less I think he actually launched the AUR-bot: http://aur.archlinux.org/packages.php?ID=8388 (first comment) Some AUR users have posted on the list in response to the bot. I can't find the others right now but here's one: http://mailman.archlinux.org/pipermail/aur-general/2010-December/012330.html Just to be clear, the bot does not insult anyone and it does state the reason for the comment rather than some ambiguous ur pkg is full of fail, lol comment. My issue is that I consider the launch premature and overzealous and I'm seeking reassurance that in the future ongoing discussions will be considered before action is taken.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
Hang on, I just went through this again: On Tuesday 07 December 2010 16:58:49 Xyne wrote: Third version: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about: The proposal is accepted if EITHER: A) the number of YES votes is greater than half the number of active TUs, OR B) quorum has been established and the number of YES votes is greater than the number of NO votes; UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. or something similar? The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Same here. Just more thoughts, trying to spot loopholes, etc... :-)
Re: [aur-general] Tarball Guidelines
On 7 December 2010 10:02, Loui Chang louipc@gmail.com wrote: On Tue 07 Dec 2010 03:58 +0800, Ray Rashif wrote: On 6 December 2010 22:47, Dave Reisner d...@falconindy.com wrote: On Mon, Dec 06, 2010 at 03:20:06PM +0100, Heiko Baums wrote: In most cases there's a reason for having binaries, icons and the like in a package. And whether such a package actually has a bad quality or its contents are necessary can't be decided by a bot. In _all_ cases, binaries are not permissable as stated by the AUR guidelines [1]. Your opinion doesn't change this. A proposal to amend the guidelines can. There is no need to ammend the guidelines. We have been including desktop files, images (needed by the desktop files most of the time) and init scripts all along, because it should be a common understanding. find /var/abs -name *.png | wc -l == 60 I might be kind of crazy here, but maybe desktop files and icons are things that should be distributed from upstream. So maintainers should work to get those included like a patch or whatnot. Definitely. Another interesting observation I've made in packages from both our repos and AUR: * Upstream tarball includes icons but they are not provided by the install method This gives a false impression that upstream does not provide the icon, so the maintainer includes it in the package. As for desktop files, aside from the above, sometimes they violate specs, so maintainers replace them with compatible ones, including an icon image along as well (forgetting that they can get it from the tarball instead).
Re: [aur-general] Tarball Guidelines
On 7 December 2010 12:23, Kaiting Chen kaitocr...@gmail.com wrote: In the official repositories we don't include these files generally. We do, when needed. So if we're going to say that AUR PKGBUILD's should not include *.desktop files then we might as well say that AUR PKGBUILD's should not include patches. Nobody said that! :O And if we're going to go with this level of communism then we might as well say that -svn, -git, etc. PKGBUILD's don't belong in [unsupported] because a development branch is basically a series of unofficially released patches. And if we do that we might as well scrap the whole AUR. Yes, such nonsense! On the other hand for [core], [extra], and [community] users expect a high level of standardization and QA. Therefore in my opinion things like *.desktop files and patches NEVER belong there except when critically necessary. Let me summarize: [unsupported] is not official so we should only suggest not enforce; [core], [extra], [community] are official and we should enforce our policy to the fullest extent. --Kaiting. I don't think there's a need to enforce anything here. Likewise.. On 7 December 2010 05:53, keenerd keen...@gmail.com wrote: But while we are running the numbers to determine best practices. grep -r '|| return 1' /var/abs/ | wc -l == 6165 This is something like Hey, pacman has this cool feature for some time now to detect any kind of error. So the next time you update your builds, remember that you no longer need to return 1. It's not something to enforce, you update as and when you can. KISS. All we really need right now is a reminder to check if included files are really necessary.
Re: [aur-general] TU application - Kyle Keen
On Tue, 7 Dec 2010 18:14:01 +0100 Xyne x...@archlinux.ca wrote: PyroPeter wrote: On 12/07/2010 05:36 PM, Ionuț Bîru wrote: On 12/07/2010 06:19 PM, Daenyth Blank wrote: Wow he actually launched that bot? I thought it was a joke. It seemed so stupid that I didn't think anyone would take it seriously. That definitely opens up some other perspectives on the application... dude, he said it will write a bot for aur. RIGHT NOW he has a bot for bugtracker and it doesn't send any emails, just write some text in the channel. nothing more, nothing less I think he actually launched the AUR-bot: http://aur.archlinux.org/packages.php?ID=8388 (first comment) Some AUR users have posted on the list in response to the bot. I can't find the others right now but here's one: http://mailman.archlinux.org/pipermail/aur-general/2010-December/012330.html Just to be clear, the bot does not insult anyone and it does state the reason for the comment rather than some ambiguous ur pkg is full of fail, lol comment. My issue is that I consider the launch premature and overzealous and I'm seeking reassurance that in the future ongoing discussions will be considered before action is taken. Still because of that quickshot I'll change my previous expectation to vote. Even a reassurance won't change that for this vote, probably for a future one but not for this. Sorry but once a application is passed the applicant has directly to show a responsible behaviour, TU stands for Trusted User not Trolling User. This is not meant as a direct insult, don't misinterprete it. Atsutane -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] TU application - Kyle Keen
Thorsten Töpper wrote: Some AUR users have posted on the list in response to the bot. I can't find the others right now but here's one: http://mailman.archlinux.org/pipermail/aur-general/2010-December/012330.html Just to be clear, the bot does not insult anyone and it does state the reason for the comment rather than some ambiguous ur pkg is full of fail, lol comment. My issue is that I consider the launch premature and overzealous and I'm seeking reassurance that in the future ongoing discussions will be considered before action is taken. Still because of that quickshot I'll change my previous expectation to vote. Even a reassurance won't change that for this vote, probably for a future one but not for this. Sorry but once a application is passed the applicant has directly to show a responsible behaviour, TU stands for Trusted User not Trolling User. This is not meant as a direct insult, don't misinterprete it. Regardless of how it was meant, Trolling User was inappropriate imo. The intentions were good. It's the rashness that's the problem as far as I'm concerned. Realizing that it was a bad idea and that there are better ways to do things is enough.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
Peter Lewis wrote: This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about: /snip Just more thoughts, trying to spot loopholes, etc... :-) The formatting got mangled. The format was The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to insert parentheses then let me know. Here's version 3 again without wrapping, hopefully: Standard Voting Procedure (SVP) describes the formal procedure used by TUs to accept or reject proposals regarding TU affairs. SVP begins with a proposal, for example the addition of a TU or an amendment to the bylaws. The proposal should be clear and concise and it must be posted on the aur-general mailing list (aur-general). The discussion period begins when the proposal is posted on aur-general. The duration of the discussion period shall be 5 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. Official discussion shall take place on aur-general. During the discussion period, votes shall not be cast. The voting period begins when the discussion period ends. The duration of the voting period shall be 7 full days UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. During the voting period, TUs may vote YES, NO or ABSTAIN. Votes shall be cast under the Trusted User section of the AUR homepage. At the end of the voting period, all votes shall be tallied. In the context of SVP, TUs are considered active if they are marked as active when the voting period ends. Quorum shall be 66% of all active TUs and participation shall be measured by the sum of YES, NO and ABSTAIN votes, UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is accepted if EITHER A) the number of YES votes is greater than half the number of active TUs OR B) quorum has been established and the number of YES votes is greater than the number of NO votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The proposal is rejected if EITHER A) the number of NO votes is greater than or equal to the number of active TUs have voted NO OR B) quorum was established and the number of NO votes is greater than or equal to the number of YES votes UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. A rejected proposal may not be presented again before a waiting period has passed. The duration of the waiting period shall be 3 full months UNLESS otherwise stated in a section of the bylaws pertaining to the proposal. The waiting period begins at the end of the voting period. If quorum is not established by the end of the voting period then the proposal is neither accepted nor rejected. A second SVP shall begin to establish the status of the proposal. If the proposal is not accepted at the end of the second SVP then it shall be rejected.
Re: [aur-general] Amendment
On Tue, Dec 7, 2010 at 8:16 AM, Xyne x...@archlinux.ca wrote: I think that barrier might be a bit too high. At the same time, I think we should have some minimum barrier. As it currently stands, with Loui's and Pierre's interpretation of abstain*, it is fully possible for someone to become a TU with a single yes vote, e.g. 66% - 1 TUs abstain and only one votes yes. Democracy dies in apathy. The abstain vote should be used sparingly in the case where a TU has not had time determine the full state of the application. I think in all other cases having an opinion is an important responsibility for a Trusted User. In the end I think the current system is complicated enough as it is. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] TU application - Kyle Keen
On Tue, 7 Dec 2010 19:56:12 +0100 Xyne x...@archlinux.ca wrote: Thorsten Töpper wrote: Still because of that quickshot I'll change my previous expectation to vote. Even a reassurance won't change that for this vote, probably for a future one but not for this. Sorry but once a application is passed the applicant has directly to show a responsible behaviour, TU stands for Trusted User not Trolling User. This is not meant as a direct insult, don't misinterprete it. Regardless of how it was meant, Trolling User was inappropriate imo. The intentions were good. It's the rashness that's the problem as far as I'm concerned. Realizing that it was a bad idea and that there are better ways to do things is enough. You're right, that was far too harsh, pardon me for this formulation. @Kyle: Starting a discussion about the tarballs was a good idea, what followed was wrong, so I'm stuck between an Abstain and a No and I guess some other TUs are also thinking about how they should handle this. The discussion is nearly finished, still a statement from your side might help to decide, which of these two options seems right, even after the end of this phase. -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] TU application - Kyle Keen
On Tue, Dec 7, 2010 at 11:16 AM, Xyne x...@archlinux.ca wrote: I'm a bit bothered by the way that you've handled this. You proceeded to write and launch the bot based on your personal interpretation of the rules without waiting for any definitive conclusion from the ongoing discussion about them. Kyle I'm really hoping that what I said last night on IRC did not make you think it would be a good idea to do this. I did not make a clear distinction between execution of established policy which you may go ahead and do whenever and in just about whatever way you want; and a decision of policy which should come from the group as a whole and may or may not involve a vote. Regardless I think the mistake is minor in this instance; I'm going to chalk it up to enthusiasm. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] Tarball Guidelines
Here are some of my favorites. And some stats about what is in the AUR. -Kyle http://kmkeen.com worst_offenders Description: Binary data
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
On Tuesday 07 December 2010 19:02:59 Xyne wrote: Peter Lewis wrote: This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about: /snip Just more thoughts, trying to spot loopholes, etc... :-) The formatting got mangled. The format was The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to insert parentheses then let me know. Ah, thought so :-) Here's version 3 again without wrapping, hopefully: Nice. Yeah, I don't have any better suggestion really, and apart from my general dislike for using whitespace to provide meaning (a la python) it's pretty clear to me. Actually... how about switching the sentence around somewhat: UNLESS some other condition, the proposal is foo if EITHER A) condition 1 OR B) condition 2 is that clearer? So my only other suggestion would be that in my other post, about proposals having to have yes/no answers. Also - and this is a wider point - who should be allowed to make proposals? Only TUs, I presume... (maybe technical details just make this a moot point anyway). Pete.
Re: [aur-general] TU application - Kyle Keen
On 7 December 2010 19:10, Thorsten Töpper atsut...@freethoughts.de wrote: On Tue, 7 Dec 2010 18:14:01 +0100 Xyne x...@archlinux.ca wrote: Still because of that quickshot I'll change my previous expectation to vote. Even a reassurance won't change that for this vote, probably for a future one but not for this. Sorry but once a application is passed the applicant has directly to show a responsible behaviour, TU stands for Trusted User not Trolling User. This is not meant as a direct insult, don't misinterprete it. Atsutane -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 I have the same feelings. When I first read Kyle's application I thought it's great to have someone like him on board and he would get my Yes for a 100%. Kyle is certainly doing a lot of good for Arch Linux and I'm sure he wrote the bot with good intentions. But launching the bot without discussion wasn't very responsible. Now I'm somewhere in between. On one hand I think Kyle would be a great addition to the team, especially given his enthusiasm. On the other hand I'm a bit scared about such impulsive behavior as the launching of the bot was.
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
As soon as I get back from lab I'm going to put the text up on a wiki page so we can stop doing massive amounts of scrolling... --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] TU application - Kyle Keen
On Tue, Dec 7, 2010 at 2:36 PM, Thorsten Töpper atsut...@freethoughts.dewrote: ... I'm stuck between an Abstain and a No and I guess some other TUs are also thinking about how they should handle this... You can stop being stuck; with the current bylaws Abstain and No are functionally identical. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] Some packages moved from extra/community to aur
On Tue, Dec 07, 2010 at 11:56:20AM +0100, Michael Trunner wrote: * tcsh * autofs * python-numarray Moved to [community-testing] as I didn't have the chance to do any testing yet. If everything works as expected, I'll move them to [community] soon. Cheers!
Re: [aur-general] Tarball Guidelines
Just wanted to say I appreciated the one email I got from the bot that told me there was a .PKGINFO file in my source package. I adopted this package so I'm not sure how the original packager pulled that off. I like the idea. Yes, obviously it should be built into the AUR website itself. The problem is that it is a lot quicker and easier to make a bot. There's also the whole weird maintenance mode thing. The cool part is we've already beta tested this thing without modifying the AUR at all. I would not mess with binary files. I always assumed the packaging guidelines meant executable files instead of binaries. Yes executable (ELF) files are bad. I think this has been established earlier. One suggestion is that the comment adds Keenerd's email or some way to know where in the world it came from or who owns it. An anonymous bot! Fear! Another idea: instead of commenting en mass you could send an e-mail to the maintainer with a list of packages and their problems. If they have their e-mail available of course. -- -Justin
Re: [aur-general] meaning of abstain
On Tuesday 07 December 2010 20:53:40 Kaiting Chen wrote: On Tue, Dec 7, 2010 at 2:36 PM, Thorsten Töpper atsut...@freethoughts.dewrote: ... I'm stuck between an Abstain and a No and I guess some other TUs are also thinking about how they should handle this... You can stop being stuck; with the current bylaws Abstain and No are functionally identical. Just out of interest - has a circumstance occured as yet where a difference in understanding of the concept of abstain would have affected the outcome? If so, what happened?
Re: [aur-general] TU application - Kyle Keen
After much heavy thought, I withdraw my application. My apologies for the trouble. -Kyle
Re: [aur-general] Tarball Guidelines
On 8 December 2010 03:47, keenerd keen...@gmail.com wrote: Here are some of my favorites. And some stats about what is in the AUR. -Kyle http://kmkeen.com You could also try the following: * PKGBUILDs with executable bit set * Install scriptlets with executable bit set * One or more included files from source array if it's a URL Anyway, we could implement things like these in AUR itself, and the maintainer would be informed upon upload (first submission or subsequent updates) without having to resort to posting comments, and depending on the severity of non-compliance either allow or reject the upload. Also, while you're on this, you can actually send the maintainer an e-mail, rather than posting a comment. That would be pretty slick, actually. But of course, first we need to decide what and what not to warn/inform about.
Re: [aur-general] TU application - Kyle Keen
On 8 December 2010 05:44, keenerd keen...@gmail.com wrote: After much heavy thought, I withdraw my application. My apologies for the trouble. You shouldn't let other issues hinder your application. Reconsider withdrawing, because it would disappoint your sponsor. You were asked a very simple question: Considering this and the still-ongoing discussion about the AUR guidelines, do you agree that it would be prudent to be more patient in the future and wait until we've come to a conclusion before going ahead with something like this again? And that's about it. Maybe some took the bot issue a little too seriously, but we would still vote. Personally, I believe you will be of help to the team :)
Re: [aur-general] Some packages moved from extra/community to aur
Am 07.12.2010 22:13, schrieb Lukas Fleischer: On Tue, Dec 07, 2010 at 11:56:20AM +0100, Michael Trunner wrote: * tcsh * autofs * python-numarray Moved to [community-testing] as I didn't have the chance to do any testing yet. If everything works as expected, I'll move them to [community] soon. Cheers! Did you build against [testing] and [community-testing]? If so, it is not said that the packages will work in an extra-and-community-only environment. If you build the packages against [extra], you should use [community-staging] for testing purposes. Regards Stefan
Re: [aur-general] Some packages moved from extra/community to aur
On 08/12/10 09:28, Stefan Husmann wrote:
Am 07.12.2010 22:13, schrieb Lukas Fleischer:
On Tue, Dec 07, 2010 at 11:56:20AM +0100, Michael Trunner wrote:
* tcsh
* autofs
* python-numarray
Moved to [community-testing] as I didn't have the chance to do any
testing yet. If everything works as expected, I'll move them to
[community] soon.
Cheers!
Did you build against [testing] and [community-testing]? If so, it is
not said that the packages will work in an extra-and-community-only
environment. If you build the packages against [extra], you should
use [community-staging] for testing purposes.
Umm... anything in [{community-,}staging] is usually built on top of
[{community-,}testing] too. Also, [community-staging] should only be
used for in progress rebuilds.
Given these packages do not rely on any of the soname bumps in [testing]
(as far as I can tell), it should be fine to test them in a non-testing
environment.
Allan
[aur-general] How were those packages created? [WAS: Tarball Guidelines]
On Tue, 2010-12-07 at 14:47 -0500, keenerd wrote: Here are some of my favorites. And some stats about what is in the AUR. -Kyle http://kmkeen.com Point of curiosity, how were the listed packages created? Some things (like including icons) I can see, but things like .swp etc... doesn't everybody use makepkg --source?
Re: [aur-general] How were those packages created? [WAS: Tarball Guidelines]
On Wed, Dec 08, 2010 at 08:42:35AM +0800, Ng Oon-Ee wrote: On Tue, 2010-12-07 at 14:47 -0500, keenerd wrote: Here are some of my favorites. And some stats about what is in the AUR. -Kyle http://kmkeen.com Point of curiosity, how were the listed packages created? Some things (like including icons) I can see, but things like .swp etc... doesn't everybody use makepkg --source? That was part of the point of the exercise. It'd be nice if everyone did, but it's clearly not the case. d
Re: [aur-general] TU application - Kyle Keen
On Tue 07 Dec 2010 16:44 -0500, keenerd wrote: After much heavy thought, I withdraw my application. My apologies for the trouble. N. I was interested in your analysis of the AUR and I think we could make good use of it. I kind of wish I could spam users about their bad packages. I have sent a few emails manually. I guess the real issue is that if there is any action that has a widespread effect on the AUR we should always decide what should be done as a group of TUs. That's one reason that I made Jakob create a proposal for the last mass AUR cleanup. I could have easily applied the changes behind the scenes otherwise.
Re: [aur-general] TU Application
On Sun 05 Dec 2010 22:50 +0100, Jelle van der Waa wrote: Hello all. I would like apply to become a TU! Daenyth has decided to sponsor me for my TU application I'm 21 years old and a Bachelor student Computer Science. I have experience with C++, C, x86 ASM, Java, Python, PHP, SQL and javascript. I use archlinux on daily basis as a server and as desktop on my laptop. My current packaging interests are haskell, LaTeX, cli apps, virtualization. In the future i am looking into improving tools such as namcap. Feel free ask any questions here or on irc. Nice. Are there any specific packages that you plan to adopt or add to community? Do you see any relationship between community and arch-games? I know that recently some people have been concerned that disk space on the community server is getting tight, so it might not be a great idea to bring more games. Usually those use a lot of disk.
Re: [aur-general] TU Application
On Tue, Dec 7, 2010 at 11:10 PM, Loui Chang louipc@gmail.com wrote: Nice. Are there any specific packages that you plan to adopt or add to community? Do you see any relationship between community and arch-games? I know that recently some people have been concerned that disk space on the community server is getting tight, so it might not be a great idea to bring more games. Usually those use a lot of disk. Aren't we getting a new server? --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
Re: [aur-general] [PATCH] tu-bylaws: Amend Standard Voting Procedure
On Tue 07 Dec 2010 20:27 +, Peter Lewis wrote: On Tuesday 07 December 2010 19:02:59 Xyne wrote: Peter Lewis wrote: This means that we cannot override (A) in the rest of the byelaws. I can imagine that we might want to create something requiring (say) a 2/3rds majority for some type of serious proposal at some point... How about: /snip Just more thoughts, trying to spot loopholes, etc... :-) The formatting got mangled. The format was The proposal is foo if EITHER A) condition 1 OR B) condition 2 UNLESS some other condition The indentation should make it clear that the EITHER and UNLESS wrap the two choices. If you have a better idea of how to insert parentheses then let me know. Ah, thought so :-) Here's version 3 again without wrapping, hopefully: Nice. Yeah, I don't have any better suggestion really, and apart from my general dislike for using whitespace to provide meaning (a la python) it's pretty clear to me. I do like to separate words by a space and paragraphs by a blank line. It makes text easier to read and understand. ;) It's nice to see this getting some development now, but I think we should make a final revision soon, so this doesn't end up in endless discussion. It doesn't need to be perfect. Making it better than it was is good too.
Re: [aur-general] meaning of abstain
On Tue, 7 Dec 2010 21:44:19 + Peter Lewis ple...@aur.archlinux.org wrote: On Tuesday 07 December 2010 20:53:40 Kaiting Chen wrote: On Tue, Dec 7, 2010 at 2:36 PM, Thorsten Töpper atsut...@freethoughts.dewrote: ... I'm stuck between an Abstain and a No and I guess some other TUs are also thinking about how they should handle this... You can stop being stuck; with the current bylaws Abstain and No are functionally identical. Just out of interest - has a circumstance occured as yet where a difference in understanding of the concept of abstain would have affected the outcome? If so, what happened? Well as Kaiting said in the amendment thread, he thinks as a machine, so with this binary thinking I'll just ignore this everywhere where it's not topic of the thread, in other words for the current state: everywhere except for the amendment one. -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
Re: [aur-general] TU application - Kyle Keen
On Wed, 8 Dec 2010 05:57:34 +0800 Ray Rashif sc...@archlinux.org wrote: On 8 December 2010 05:44, keenerd keen...@gmail.com wrote: After much heavy thought, I withdraw my application. My apologies for the trouble. You shouldn't let other issues hinder your application. Reconsider withdrawing, because it would disappoint your sponsor. You were asked a very simple question: Considering this and the still-ongoing discussion about the AUR guidelines, do you agree that it would be prudent to be more patient in the future and wait until we've come to a conclusion before going ahead with something like this again? And that's about it. Maybe some took the bot issue a little too seriously, but we would still vote. Personally, I believe you will be of help to the team :) Don't withdraw, you made a good impression and as long as you answer this question of Xyne I don't think there are people that vote against you as long as you assure to keep waiting till something is decided in the future. An Abstain is not a No, it is to reach quorum and I'm still mostly tending to that, as Lukas said you made a very good impression and I think if we two had real contact in the past, I still would vote clearly for you. I think this application will pass, I guess there are enough of us who really know you and vote for a Yes as they really know your person and don't just read some forum posts as I did. So don't withdraw, just make a clear assurance to keep low till something is really discussed and you'll pass, as long as there are more Yes votes than No votes and like I said there won't be many of the latter as you really left a good impression. An Abstain is to reach Quorum it currently has no influence on wether a vote passes or not. -- Jabber: atsut...@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 signature.asc Description: PGP signature
