[aur-general] Trusted User Application
Hello Trusted Users! I'd like to formally express my interest in becoming a Trusted User. My name is Loui Chang and I've been using Arch Linux for about a year and a half. My alias is louipc in aur/wiki/bugs/bbs/freenode. I'm the current developer of aurbuild and I've also submitted many patches to help improve AUR. I'm generally interested in improving the ways that we build, distribute and manage packages. To be honest, I maintain few packages in unsupported. Most packages I need already seem to be taken care of, so I don't plan on bringing many new packages to community. Here's what I have submitted to AUR: http://aur.archlinux.org/packages.php?K=louipc&SeB=s Mostly what I offer is this: - Helping to clean up and administer AUR and community. - Help squashing bugs. - Continue developing AUR with the added perspective of a Trusted User. - Take on some packages that are already in community or packages that get dropped from the official repos. Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed. I greatly appreciate if you can see a benefit in appointing me as a Trusted User. You guys already seem to do a very good job though. If anyone has packages that they don't really use, please let me know and maybe I can take care of them. :D Cheers!
On Mon, Jun 2, 2008 at 12:40 PM, Loui <louipc.ist@gmail.com> wrote:
Hello Trusted Users!
I'd like to formally express my interest in becoming a Trusted User. My name is Loui Chang and I've been using Arch Linux for about a year and a half. My alias is louipc in aur/wiki/bugs/bbs/freenode. I'm the current developer of aurbuild and I've also submitted many patches to help improve AUR. I'm generally interested in improving the ways that we build, distribute and manage packages. To be honest, I maintain few packages in unsupported. Most packages I need already seem to be taken care of, so I don't plan on bringing many new packages to community.
Here's what I have submitted to AUR: http://aur.archlinux.org/packages.php?K=louipc&SeB=s
Mostly what I offer is this: - Helping to clean up and administer AUR and community. - Help squashing bugs. - Continue developing AUR with the added perspective of a Trusted User. - Take on some packages that are already in community or packages that get dropped from the official repos.
Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed.
I greatly appreciate if you can see a benefit in appointing me as a Trusted User. You guys already seem to do a very good job though. If anyone has packages that they don't really use, please let me know and maybe I can take care of them. :D
Cheers!
I think Loui would be a great asset to the Trusted Users if only for the added perspective of being a TU to help better develop the AUR. I would suggest someone definitely sponsor him right away. ;) -- Callan Barrett
Loui wrote:
Hello Trusted Users!
I'd like to formally express my interest in becoming a Trusted User. <snip>
And I said I would sponsor him. Loui is not a traditional TU candidate. As he said, he does not maintain many packages in the AUR and will not be bringing many packages into the [community] repo. However, he is interested in the development of the AUR and I have seen many patches he has submitted to the AUR codebase (see http://projects.archlinux.org/?p=aur.git;a=shortlog). From the trusted user guidelines: "The Trusted User (TU) is a member of the community charged with keeping the AUR in working order." I feel maintaining the AUR extends to developing and improving its codebase so it is a perfectly good reason to make him a TU. Also, the few PKGBUILDs he does maintain look good (maybe a few cosmetic changes needed at most), so I am not worried about anything he would bring into the community repos. Overall, I think Loui would be a good addition to the team. This starts the usual discussion period. Allan
Hi! Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.
Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed.
Can you elaborate on these three points (like what kind of system do you have in mind, by bugs you mean AUR bugs or any kind of bugs, etc) ?
I greatly appreciate if you can see a benefit in appointing me as a Trusted User. You guys already seem to do a very good job though. If anyone has packages that they don't really use, please let me know and maybe I can take care of them. :D
I got lots of these packages, and so do many other TUs I think. Do you want to take them all? :p Ronald
On Mon, 2 Jun 2008 07:19:40 +0200 "Ronald van Haren" <pressh@gmail.com> wrote:
Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.
I'll have a look at those three I still maintain, but I'd be glad to receive pointers as well.
Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed.
Can you elaborate on these three points (like what kind of system do you have in mind, by bugs you mean AUR bugs or any kind of bugs, etc) ?
- Develop a new system for sharing PKGBUILDs. If you look through the AUR source code it'll become obvious that the design hadn't quite been thought through and the implementation is pretty dodgy. I'm interested in designing a completely new system based on a client-server model. It's a big goal for me that won't be immediatly realised, but I'm just putting the idea out there. I'm kind of working out the client side via aurbuild. aurbuild won't be the client, but I might be able to work out some ideas with it and reuse parts of it. - Give TUs more direct access and control of that system. That's something I'll have to think about more when the time comes. It's related to something that's mostly in my imagination. Some things might include mechanisms to fix problems in the server on the fly, to set up new repos, or migrate repos to new systems. - Get every single darn bug closed. AUR bugs, community packages bugs, and Arch Linux bugs in general. I'm trying to think big here. :D
I greatly appreciate if you can see a benefit in appointing me as a Trusted User. You guys already seem to do a very good job though. If anyone has packages that they don't really use, please let me know and maybe I can take care of them. :D
I got lots of these packages, and so do many other TUs I think. Do you want to take them all? :p
Haha. Well I can take some. I don't want to overwhelm myself. Post what you don't want and I'll let you know what I can take.
On 6/2/08, Loui <louipc.ist@gmail.com> wrote:
On Mon, 2 Jun 2008 07:19:40 +0200 "Ronald van Haren" <pressh@gmail.com> wrote:
Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.
I'll have a look at those three I still maintain, but I'd be glad to receive pointers as well.
from a quick look: tomatoes: - try to avoid custom variables (_pkgdata). It is not needed and it only appears once. - license is an array - you can use install -Dm755 to install the executable instead of mkdir -p and install (not that what you did is wrong, it's just easier) brlcad: - You can use 'install -Dm' as above for future reference, you can use $srcdir and $pkgdir instead of $startdir/src and $startdir/pkg (of course both work equally well so you can use whatever you like)
On Mon, 2 Jun 2008 11:45:06 +0200 "Ronald van Haren" <pressh@gmail.com> wrote:
- you can use install -Dm755 to install the executable instead of mkdir -p and install (not that what you did is wrong, it's just easier)
I did originally use `install -Dm` but then I was shown some instances of install on other systems where -D wasn't available so I decided to use `mkdir -p` to make it more compatible to other systems.
for future reference, you can use $srcdir and $pkgdir instead of $startdir/src and $startdir/pkg (of course both work equally well so you can use whatever you like)
Cool. Thanks for your help.
On 02/06/2008, at 3:43 PM, Loui wrote:
On Mon, 2 Jun 2008 07:19:40 +0200 "Ronald van Haren" <pressh@gmail.com> wrote:
Although as you stated contributing packages is not your primary goal, I suggest you still take another look at your PKGBUILDs and correct the small mistakes that are still in there. If you need help finding them please let me know and I'm happy to point them out.
I'll have a look at those three I still maintain, but I'd be glad to receive pointers as well.
Some of my big goals are: - Develop a new system for sharing PKGBUILDs. - Give TUs more direct access and control of that system. - Get every single darn bug closed.
Can you elaborate on these three points (like what kind of system do you have in mind, by bugs you mean AUR bugs or any kind of bugs, etc) ?
- Develop a new system for sharing PKGBUILDs. If you look through the AUR source code it'll become obvious that the design hadn't quite been thought through and the implementation is pretty dodgy. I'm interested in designing a completely new system based on a client-server model. It's a big goal for me that won't be immediatly realised, but I'm just putting the idea out there. I'm kind of working out the client side via aurbuild. aurbuild won't be the client, but I might be able to work out some ideas with it and reuse parts of it.
Are you planning on creating a new web interface and using aurbuild to ease the building of AUR packages, or do you mean something new completely? I'm just wondering if AUR2 would be of any use to you. I most likely going to start up a similar project to AUR, and I'm going to either be using the Archlinux web site code base and extend that or work on making AUR2 more flexible (currently the community/aur repositories are kind of hard coded). I'd like to hear some of your ideas :). Anyway that's a bit off topic. You indeed have few packages, but fortunately that's not all TUs do, and I know that you have an interest in improving AUR and related projects. I agree with Callan and Allan.
- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.
Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.
On Tue 2008-06-03 01:08, Sebastian Nowicki wrote:
On 02/06/2008, at 3:43 PM, Loui wrote:
- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.
Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.
What's the point of using a variable if it never changes and it is used only once? -- Alessio (molok) Bolognino Please send personal email to themolok@gmail.com Public Key http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xFE0270FB GPG Key ID = 1024D / FE0270FB 2007-04-11 Key Fingerprint = 9AF8 9011 F271 450D 59CF 2D7D 96C9 8F2A FE02 70FB
On 03/06/2008, at 1:18 AM, Alessio Bolognino wrote:
On Tue 2008-06-03 01:08, Sebastian Nowicki wrote:
On 02/06/2008, at 3:43 PM, Loui wrote:
- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.
Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.
What's the point of using a variable if it never changes and it is used only once?
In this case it's not really necessary, I agree, but I was asking about the general use of "private" variables.
On Tue, Jun 3, 2008 at 5:13 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
On 03/06/2008, at 1:18 AM, Alessio Bolognino wrote:
On Tue 2008-06-03 01:08, Sebastian Nowicki wrote:
On 02/06/2008, at 3:43 PM, Loui wrote:
- try to avoid custom variables (_pkgdata). It is not needed and it only appears once.
Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.
What's the point of using a variable if it never changes and it is used only once?
In this case it's not really necessary, I agree, but I was asking about the general use of "private" variables.
On Mon, Jun 2, 2008 at 7:08 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
Is that really such a bad thing? I just want to make it clear, since I've been a bit confused about it for a while now. As far as I can tell the only reason not to use custom variables is that the current AUR code base doesn't support them (or maybe it does now?), so URLs and such have unparsed variables in them. Apart from that I don't see any problems with them, as long as it is made sure that they won't conflict with existing package, and using an underscore will do that.
From the AUR Packaging guidelines (http://wiki.archlinux.org/index.php/Arch_Packaging_Standards):
Do not introduce new variables into your PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore As we want others to follow these guidelines I think we as TUs should also do so as people can use our PKGBUILDs as a guideline. The main reason not to like custom variables is that it is not easy to read when checking if a PKGBUILD is safe when you get it from AUR. You see a custom variable in the build{} part and you have to search in the PKGBUILD what this variable means. (clearly our custom variables can be trusted (hence truster users) but for other users one can easily slip a 'rm -rf /' or something in it (no it has never happened but still). I would say be a good example for other users unless there is really an advantage on both sides of the chain). When a custom variable appears a number of times in the build{} field I think it is not bad to use a custom variable so you only have to change it ones (if it is a number for example), but if it appears only one time there is just no point in using one.
Again, that is where the simplicity/Arch principle comes in. Things happen when and where approriate; making sense of it all. There are 2 primary cases: 1) Traditional reason for variables - shorter alternatives to longer strings 2) Portability/flexibility - other programmers are able to manipulate your code easily (for PKGBUILDS; those editing it) So if the script doesn't have any content relating to (1) or (2) then yet another variable is indeed pointless. We should avoid them unless the benefit is practically significant. Say, for instance, a short PKGBUILD where the source archive's $pkgver != real $pkgver. You are going to submit it to [unsupported] where the AUR web interface cannot resolve custom variables, and the source archive's name has an underscore. You create _pkgver as the new one, and you use it in the source array as ${pkgname}_${_pkgver}, which could do with some cosmetic surgery. Then it'd be up to you to decide whether this new variable, or having a clean look on the web interface, is more beneficial/"important". Since bumping pkgver will not change the source, introducing _pkgver makes it easy to update. At the same time, though, if one is editing the PKGBUILD the source array isn't that many lines down and thus, is as easy as changing the value of a variable. It's a matter of weighing priorities; takes a few seconds before clicking on "submit". In [community] (ABS), this isn't a problem but then - as a TU - you should be able to do the weighing just fine. I don't know if I'm guilty as an [unsupported] user but I sure hope not =P
On Wed, 4 Jun 2008 01:06:57 +0800 "Ray Rashif" <schivmeister@gmail.com> wrote:
Again, that is where the simplicity/Arch principle comes in. Things happen when and where approriate; making sense of it all. There are 2 primary cases: [...]
Hey you guys hijacked my TU application thread! :P
On Tue, 3 Jun 2008 01:08:43 +0800 Sebastian Nowicki <sebnow@gmail.com> wrote:
On 02/06/2008, at 3:43 PM, Loui wrote:
- Develop a new system for sharing PKGBUILDs. If you look through the AUR source code it'll become obvious that the design hadn't quite been thought through and the implementation is pretty dodgy. I'm interested in designing a completely new system based on a client-server model. It's a big goal for me that won't be immediatly realised, but I'm just putting the idea out there. I'm kind of working out the client side via aurbuild. aurbuild won't be the client, but I might be able to work out some ideas with it and reuse parts of it.
Are you planning on creating a new web interface and using aurbuild to ease the building of AUR packages, or do you mean something new completely? I'm just wondering if AUR2 would be of any use to you. I most likely going to start up a similar project to AUR, and I'm going to either be using the Archlinux web site code base and extend that or work on making AUR2 more flexible (currently the community/aur repositories are kind of hard coded). I'd like to hear some of your ideas :).
I'm planning on creating something completely new that doesn't require any web interface, but can use one for convenience. It'll come with command line tools that will be used for full functionality. There are many crazy features that you can add on to it, but that's the basic idea. Something where any hacker can fix bugs, distribute the code and he doesn't have to rely on a central server for everyone to reap the benefits. Where sharing PKGBUILDs can become distributed if desired.
participants (7)
-
Alessio Bolognino
-
Allan McRae
-
Callan Barrett
-
Loui
-
Ray Rashif
-
Ronald van Haren
-
Sebastian Nowicki