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] TU appliance Jens Maucher (defcon)
2009/4/6 xyne : > 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)
On Sun, Apr 5, 2009 at 19:53, Xyne wrote: > Angel Velásquez wrote: > >> On Mon, Apr 6, 2009 at 6:52 PM, Andrei Thorp 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 > > I don't think he meant it that way. I think he was replying to Ali's > statement that implied that the quality of packages in community was not as > important as the quality of packages in core/extra. I think he means that the > quality of community packages is good and that it should stay that way. > > I could be wrong. > > This is how I read it also
Re: [aur-general] TU appliance Jens Maucher (defcon)
Angel Velásquez wrote: > On Mon, Apr 6, 2009 at 6:52 PM, Andrei Thorp 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 I don't think he meant it that way. I think he was replying to Ali's statement that implied that the quality of packages in community was not as important as the quality of packages in core/extra. I think he means that the quality of community packages is good and that it should stay that way. I could be wrong.
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Mon, Apr 6, 2009 at 6:52 PM, Andrei Thorp 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] 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 wrote: > "Ali H. Caliskan" 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)
"Ali H. Caliskan" 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)
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. Also, one will eventually grow into such responsibility and organization. So the filter process should be efficient and smart, not inconsistent. This is my point of view, so good luck guys with your hard work :) On Sun, Apr 5, 2009 at 10:24 PM, Jaroslav Lichtblau wrote: > On Sun, Apr 05, 2009 at 10:13:03PM +0200, Baho Utot wrote: > > Ali H. Caliskan wrote: > >> 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 > >> > >> > > Yes, I think anyone could be an asset. > > > > Why is the TU all about making packages/being a good packager? > > It is not just about to be a good packager. But as said before, you > have the power to create binary packages and access the [community] > repository, and we need to be sure that TU's know what they do. > This is my point of view. > > > > > For me I am good at making bugs, so I could never be a TU but I could be > > a TBM (trusted bug maker) :) > > > > > > [putloin] > > > > -- > - No manual is ever necessary. > May I politely interject here: BULLSHIT. That's the biggest Apple lie of > all! >-- Discussion in comp.os.linux.misc on the intuitiveness of > interfaces >
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sun, Apr 05, 2009 at 10:13:03PM +0200, Baho Utot wrote: > Ali H. Caliskan wrote: >> 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 >> >> > Yes, I think anyone could be an asset. > > Why is the TU all about making packages/being a good packager? It is not just about to be a good packager. But as said before, you have the power to create binary packages and access the [community] repository, and we need to be sure that TU's know what they do. This is my point of view. > > For me I am good at making bugs, so I could never be a TU but I could be > a TBM (trusted bug maker) :) > > > [putloin] > -- - No manual is ever necessary. May I politely interject here: BULLSHIT. That's the biggest Apple lie of all! -- Discussion in comp.os.linux.misc on the intuitiveness of interfaces pgpDjBKeinDNR.pgp Description: PGP signature
Re: [aur-general] TU appliance Jens Maucher (defcon)
Ali H. Caliskan wrote: 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 Yes, I think anyone could be an asset. Why is the TU all about making packages/being a good packager? For me I am good at making bugs, so I could never be a TU but I could be a TBM (trusted bug maker) :) [putloin]
Re: [aur-general] TU appliance Jens Maucher (defcon)
Anyway, it seems the applicant has lost interest, so I guess discussion can end. (See Kindergarten post.) -AT On Sun, Apr 5, 2009 at 10:33 AM, Evangelos Foutras wrote: > 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 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 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 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 wrote: > 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)
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)
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 > On Mon, Apr 6, 2009 at 10:55 AM, Ali H. Caliskan > 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 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 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)
On Mon, Apr 6, 2009 at 10:55 AM, Ali H. Caliskan 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)
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 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)
On Sun, Apr 5, 2009 at 09:53, Jens Maucher 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 > 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)
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 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:19, Chris Brannon 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 wrote: > > I am going to be fairly blunt here, but essentially you are wrong > > > > 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)
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)
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] 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 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: > > > > > > > And I also didn't see any response to Allan's suggestion adn that > > > > surprised me a bit. > > > > > > > > > -- > > > Jens Maucher > > > 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 > Gnupg: 44FF54EA > Fingerprint: 0E54 F345 E7C9 0295 90F8 2B56 CD9A EE71 44FF 54EA >
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: > > > > > And I also didn't see any response to Allan's suggestion adn that > > > surprised me a bit. > > > > > > -- > > Jens Maucher > > 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 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: > > > And I also didn't see any response to Allan's suggestion adn that > > surprised me a bit. > > > -- > Jens Maucher > 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)
Which suggestion? Am Sonntag, den 05.04.2009, 11:22 +0200 schrieb Jaroslav Lichtblau: > And I also didn't see any response to Allan's suggestion adn that > surprised me a bit. -- Jens Maucher 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 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)
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.
Re: [aur-general] TU appliance Jens Maucher (defcon)
Daenyth Blank wrote: On Sat, Apr 4, 2009 at 19:40, Loui Chang wrote: On Sat, Apr 04, 2009 at 10:08:50PM +0200, 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 suspect that the Trusted Users in general don't really know defcon that well, so they were reluctant to appoint him. 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.
Re: [aur-general] TU appliance Jens Maucher (defcon)
Daniel J Griffiths wrote: Daenyth Blank wrote: On Sat, Apr 4, 2009 at 19:40, Loui Chang wrote: On Sat, Apr 04, 2009 at 10:08:50PM +0200, 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 suspect that the Trusted Users in general don't really know defcon that well, so they were reluctant to appoint him. 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'd say this is almost entirely due to the zatoo package. It had sim-links to libraries due to soname differences making the binary blob fail. That is really bad... Given Jens was not well known to the TUs, I think this one bad package was enough for no votes. Allan
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sat, Apr 4, 2009 at 19:40, Loui Chang wrote: > On Sat, Apr 04, 2009 at 10:08:50PM +0200, 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 suspect that the Trusted Users in general don't really know defcon > that well, so they were reluctant to appoint him. > > In addition to this, the PKGBUILDs he maintained were generally of pretty low quality, at least from my perspective.
Re: [aur-general] TU appliance Jens Maucher (defcon)
On Sat, Apr 04, 2009 at 10:08:50PM +0200, 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 suspect that the Trusted Users in general don't really know defcon that well, so they were reluctant to appoint him.
Re: [aur-general] TU appliance Jens Maucher (defcon)
I agree, perhaps it's a good idea to guide him to some level of required improvement. ali On Sat, Apr 4, 2009 at 10:08 PM, Stefan Husmann wrote: > Hello, > > 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. > > Regards Stefan >
[aur-general] TU appliance Jens Maucher (defcon)
Hello, 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. Regards Stefan
