[aur-general] Application as a Trusted User
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 Hello, I've been playing for a while with the thought to apply as a Trusted User, but I never really had the courage to do so, well now I try it. About my person: I'm a 1990 born student from the south of Germany, I study Computer Science(first semester) and use Arch as my main system now since two years and 4 days. I'm mainly active in the german part of the community as the international forums and IRC are too lively for me to actively participate a lot, so I mostly only read the topics, but don't post in the threads. However I read nearly every mail at the mailing lists (except for the ones concerning problems of Users with software I haven't used in years e.g. KDE), but as my opinion was often already stated I don't feel that I have to repeat what's already been said, so I mail rarely to the lists too. About my skills: I'm programming in C since a few years, though I mostly review code in order to learn more, I'm also capable of the basics with python 2.5, several BASIC dialects, C++, Objective C, Java and of course shell scripting. Whereas the focus for the next years lies upon C and Java as they're both needed by my study. About my packages: I maintain 10 packages in AUR[1], whereby I also participate in the development of the i3 window manager to whom's project family 6 of these packages belong(3 projects, each as stable and git package), the other four are the git package of the newsbeuter feedreader and the cococpp package which is a build dependency for the previously named, structorizer which is a Java program to design structograms (or Nassi- Schneiderman diagrams) and a mecurial package for objfw which is a portable framework for the Objective C language, not one of them was adopted. If you want to see their history, I also keep them in a git repository at github.com[2]. About my Application: I asked Stefan Husmann if he would like to sponsor me and he agreed to do so. I have two Arch systems, my laptop running an i686 installation and my desktop machine running a x86_64 installation, both run without the testing repository. As I have to use Java and corresponding util- ities for my study I'd take care of orphanages of the Java development segment, but also orphans in the topics I'm mainly interested in(window managers, development and networks). And as I check my mail whenever it's possible I'd also help with the request of users regarding the administration of the AUR. If you want to search for me, my nick at Arch related sites is Atsutane. Regards Thorsten [1] http://aur.archlinux.org/packages.php?SeB=m&K=Atsutane [2] http://github.com/Atsutane/packages - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iFYEARELAAYFAksIGCkACgkQOeTxfyla+/QIXgDgq6vF0HVT5ab9E2eMNjcRvxzw MLDlK0b2ILDHugDeLTJMdLx609Qhnh5Z87jPEDohZiLX0i4Cd/0HZQ== =uTIK -----END PGP SIGNATURE-----
Thorsten Töpper schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hello,
I've been playing for a while with the thought to apply as a Trusted User, but I never really had the courage to do so, well now I try it.
About my person: I'm a 1990 born student from the south of Germany, I study Computer Science(first semester) and use Arch as my main system now since two years and 4 days. I'm mainly active in the german part of the community as the international forums and IRC are too lively for me to actively participate a lot, so I mostly only read the topics, but don't post in the threads. However I read nearly every mail at the mailing lists (except for the ones concerning problems of Users with software I haven't used in years e.g. KDE), but as my opinion was often already stated I don't feel that I have to repeat what's already been said, so I mail rarely to the lists too.
About my skills: I'm programming in C since a few years, though I mostly review code in order to learn more, I'm also capable of the basics with python 2.5, several BASIC dialects, C++, Objective C, Java and of course shell scripting. Whereas the focus for the next years lies upon C and Java as they're both needed by my study.
About my packages: I maintain 10 packages in AUR[1], whereby I also participate in the development of the i3 window manager to whom's project family 6 of these packages belong(3 projects, each as stable and git package), the other four are the git package of the newsbeuter feedreader and the cococpp package which is a build dependency for the previously named, structorizer which is a Java program to design structograms (or Nassi- Schneiderman diagrams) and a mecurial package for objfw which is a portable framework for the Objective C language, not one of them was adopted. If you want to see their history, I also keep them in a git repository at github.com[2].
About my Application: I asked Stefan Husmann if he would like to sponsor me and he agreed to do so. I have two Arch systems, my laptop running an i686 installation and my desktop machine running a x86_64 installation, both run without the testing repository. As I have to use Java and corresponding util- ities for my study I'd take care of orphanages of the Java development segment, but also orphans in the topics I'm mainly interested in(window managers, development and networks). And as I check my mail whenever it's possible I'd also help with the request of users regarding the administration of the AUR.
If you want to search for me, my nick at Arch related sites is Atsutane.
Regards Thorsten
[1] http://aur.archlinux.org/packages.php?SeB=m&K=Atsutane [2] http://github.com/Atsutane/packages - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iFYEARELAAYFAksIGCkACgkQOeTxfyla+/QIXgDgq6vF0HVT5ab9E2eMNjcRvxzw MLDlK0b2ILDHugDeLTJMdLx609Qhnh5Z87jPEDohZiLX0i4Cd/0HZQ== =uTIK -----END PGP SIGNATURE-----
Hello, as Thorsten already said, I want want to sponsor his application as a TU. He is very wellknown in german forums I believe he is a responsible person and will be a good addition to our team. So let us start the five days deiscussion period. Regards Stefan
About my packages: I maintain 10 packages in AUR[1], whereby I also participate in the development of the i3 window manager to whom's project family 6 of these packages belong(3 projects, each as stable and git package), the other four are the git package of the newsbeuter feedreader and the cococpp package which is a build dependency for the previously named, structorizer which is a Java program to design structograms (or Nassi- Schneiderman diagrams) and a mecurial package for objfw which is a portable framework for the Objective C language, not one of them was adopted. If you want to see their history, I also keep them in a git repository at github.com[2]. Hi Thorsten, you don't need to include LICENSE file for packages that use GPL or common licenses (e.g. cococp), and you can omit 'custom:' when a
On 21/11/2009, Thorsten Töpper <atsutane@freethoughts.de> wrote: package is licensed under BSD or MIT. Why do you use package() function when the package isn't a splitted package? Also, you don't need to put Contributor/Maintainer tag twice (e.g. objfw-hg) and you can omit empty arrays from PKGBUILD (e.g. newsbeuter-git). Ah, another little thing: don't include $pkgname in description (e.g. structorizer). Regards -- Andrea `bash` Scarpino Arch Linux Developer
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :) Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages. Good luck! -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On 21/11/2009, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages. Nice, I didn't know that. Thanks Gerardo :)
-- Andrea `bash` Scarpino Arch Linux Developer
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
hollunder@gmx.at schrieb:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
The build process normally does not need root permissions at all. So it is save to build als normal user and nessasary to install as "faked" root. Regards Stefan
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed. If you have an example that breaks this, please let me know ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot. Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package. best, Lukas
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot.
Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;) Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot.
Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
Ray Rashif wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
Andrea Scarpino wrote:
> Why do you use package() function when the package isn't a splitted > package? > > > > Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
Good luck!
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot. Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp". Allan
On Sun, Nov 22, 2009 at 1:17 AM, Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
The minor problem with using 'install' is that you must specify the permissions right there, and you cannotsimply use whatever permission was set by make install. Of course, that's what makes it not have tainted permissions from the building user in the first place... -- Ranguvar
Ranguvar wrote:
On Sun, Nov 22, 2009 at 1:17 AM, Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
The minor problem with using 'install' is that you must specify the permissions right there, and you cannotsimply use whatever permission was set by make install.
Sure if you are using "make install" then you do not have to manually install that files anyway...
On Sun, Nov 22, 2009 at 1:34 AM, Allan McRae <allan@archlinux.org> wrote:
With a package() function, you can actually change the contents of the package.
Splitting of the build and package steps is one of the most under-appreciated features in the last pacman release. It is really good to see someone actually using it. (I do not and I implemented it!)
Allan
May I ask what's the policy in case of earlier submitted, but working packages ? Is it needed to modify according to this new feature immediately if otherwise the packages work well and no requirement until now from the users for splitting Is it enough to modify according to this feature only that time if I need to change the PKGBUILDs because of other reason(s) too ? Best Regards, Laszlo Papp
Laszlo Papp wrote:
On Sun, Nov 22, 2009 at 1:34 AM, Allan McRae <allan@archlinux.org> wrote:
With a package() function, you can actually change the contents of the package.
Splitting of the build and package steps is one of the most under-appreciated features in the last pacman release. It is really good to see someone actually using it. (I do not and I implemented it!)
Allan
May I ask what's the policy in case of earlier submitted, but working packages ? Is it needed to modify according to this new feature immediately if otherwise the packages work well and no requirement until now from the users for splitting Is it enough to modify according to this feature only that time if I need to change the PKGBUILDs because of other reason(s) too ?
It is fully backwards compatible (otherwise you would have noticed by now...), so do whatever you want. Allan
On Sun, Nov 22, 2009 at 11:13 AM, Allan McRae <allan@archlinux.org> wrote:
Laszlo Papp wrote:
On Sun, Nov 22, 2009 at 1:34 AM, Allan McRae <allan@archlinux.org> wrote:
With a package() function, you can actually change the contents of the package.
Splitting of the build and package steps is one of the most under-appreciated features in the last pacman release. It is really good to see someone actually using it. (I do not and I implemented it!)
Allan
May I ask what's the policy in case of earlier submitted, but working packages ? Is it needed to modify according to this new feature immediately if otherwise the packages work well and no requirement until now from the users for splitting Is it enough to modify according to this feature only that time if I need to change the PKGBUILDs because of other reason(s) too ?
It is fully backwards compatible (otherwise you would have noticed by now...), so do whatever you want.
Allan
Okay, thanks Allan! Best Regards, Laszlo Papp
On Sun, 22 Nov 2009 16:17:36 +1000 Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
On Sat, 21 Nov 2009 14:24:58 -0300 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
> Andrea Scarpino wrote: > > >> Why do you use package() function when the package isn't a >> splitted package? >> >> >> >> > Hello :) > > Using both build() and package() is not necessary condition > for use only with splitted packages, its avoid to use the > fakeroot on building process that is not needed in 99% of > packages. > > Good luck! > > > Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot. Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
I've often seen cp used in makefiles, would this cause problems? Would you need to patch those makefiles?
hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 16:17:36 +1000 Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
hollunder@gmx.at wrote:
> On Sat, 21 Nov 2009 14:24:58 -0300 > Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: > > > >> Andrea Scarpino wrote: >> >> >>> Why do you use package() function when the package isn't a >>> splitted package? >>> >>> >>> >>> >> Hello :) >> >> Using both build() and package() is not necessary condition >> for use only with splitted packages, its avoid to use the >> fakeroot on building process that is not needed in 99% of >> packages. >> >> Good luck! >> >> >> > Sorry, but I consider the use of fakeroot a good thing, it helps > to reveal errors while packaging/creating the PKGBUILD at > least. Don't know why it should be avoided. > > > fakeroot make a table of function pointers for many file manipulation calls, like open(), close(), chmod() and etc -> overhead, slowdowns (small of course) During the build process file perms are not necessary to be "tracked", or at least in 99% of packages. Only during the install process is only needed.
If you have an example that breaks this, please let me know ;)
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Nice feature! I didn't know that using package() avoids using of fakeroot. Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
I've often seen cp used in makefiles, would this cause problems? Would you need to patch those makefiles?
If it breaks stuff, then you should tell upstream that they makefile is crap.
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 16:17:36 +1000 Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote:
2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
> hollunder@gmx.at wrote: > >> On Sat, 21 Nov 2009 14:24:58 -0300 >> Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: >> >> >> >>> Andrea Scarpino wrote: >>> >>> >>>> Why do you use package() function when the package isn't a >>>> splitted package? >>>> >>>> >>>> >>>> >>> Hello :) >>> >>> Using both build() and package() is not necessary condition >>> for use only with splitted packages, its avoid to use the >>> fakeroot on building process that is not needed in 99% of >>> packages. >>> >>> Good luck! >>> >>> >>> >> Sorry, but I consider the use of fakeroot a good thing, it >> helps to reveal errors while packaging/creating the PKGBUILD >> at least. Don't know why it should be avoided. >> >> >> > fakeroot make a table of function pointers for many file > manipulation calls, like open(), close(), chmod() and etc -> > overhead, slowdowns (small of course) > During the build process file perms are not necessary to be > "tracked", or at least in 99% of packages. Only during the > install process is only needed. > > If you have an example that breaks this, please let me know ;) > > -- > Gerardo Exequiel Pozzi ( djgera ) > http://www.djgera.com.ar > KeyID: 0x1B8C330D > Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C > 330D > > > > Nice feature! I didn't know that using package() avoids using of fakeroot. Back to my point. There used to be a problem with compilation of amarok1 package from AUR only because of fakeroot and I guess that it would also help with building of mplayer (configure crashes under fakeroot environment and needs to be patched but maybe it was fixed meanwile alongside with amarok1 problem). So in some specific cases I can see the point of using separate package() even when the PKGBUILD builds only one package.
best, Lukas
;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
I've often seen cp used in makefiles, would this cause problems? Would you need to patch those makefiles?
If it breaks stuff, then you should tell upstream that they makefile is crap.
So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 16:17:36 +1000 Allan McRae <allan@archlinux.org> wrote:
Ray Rashif wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Lukáš Jirkovský wrote: > 2009/11/21 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>: > >> hollunder@gmx.at wrote: >> >>> On Sat, 21 Nov 2009 14:24:58 -0300 >>> Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: >>> >>> >>> >>>> Andrea Scarpino wrote: >>>> >>>> >>>>> Why do you use package() function when the package isn't a >>>>> splitted package? >>>>> >>>>> >>>>> >>>>> >>>> Hello :) >>>> >>>> Using both build() and package() is not necessary condition >>>> for use only with splitted packages, its avoid to use the >>>> fakeroot on building process that is not needed in 99% of >>>> packages. >>>> >>>> Good luck! >>>> >>>> >>>> >>> Sorry, but I consider the use of fakeroot a good thing, it >>> helps to reveal errors while packaging/creating the PKGBUILD >>> at least. Don't know why it should be avoided. >>> >>> >>> >> fakeroot make a table of function pointers for many file >> manipulation calls, like open(), close(), chmod() and etc -> >> overhead, slowdowns (small of course) >> During the build process file perms are not necessary to be >> "tracked", or at least in 99% of packages. Only during the >> install process is only needed. >> >> If you have an example that breaks this, please let me know ;) >> >> -- >> Gerardo Exequiel Pozzi ( djgera ) >> http://www.djgera.com.ar >> KeyID: 0x1B8C330D >> Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C >> 330D >> >> >> >> > Nice feature! I didn't know that using package() avoids using of fakeroot. > Back to my point. There used to be a problem with compilation of > amarok1 package from AUR only because of fakeroot and I guess > that it would also help with building of mplayer (configure > crashes under fakeroot environment and needs to be patched but > maybe it was fixed meanwile alongside with amarok1 problem). So > in some specific cases I can see the point of using separate > package() even when the PKGBUILD builds only one package. > > best, > Lukas > > ;)
Most reported crashes on bugtracker are because nvidia libgl, that conflics with libfakeroot, both uses dlsym() (nvidia i don't know why does this, fakeroot do this to fill a table of pointer to functions), the result is a jump to NULL :P http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024#75
-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
Hi Gerardo can you confirm that there are no (owner) permission issues when building without fakeroot (i.e all owned by user)? I don't see chown anywhere other than extract_sources().
If your packaging is done properly, then there is no issues. Always use "install" and not "cp".
Allan
I've often seen cp used in makefiles, would this cause problems? Would you need to patch those makefiles? If it breaks stuff, then you should tell upstream that they makefile is crap.
So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
Probably not... makepkg sets a "sane" umask and the install is done as (fake)root. So you should be fine unless something is really screwed in the makefile.
Hi all, On Sun, Nov 22, 2009 at 11:14:52AM +0100, hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
If it breaks stuff, then you should tell upstream that they makefile is crap.
So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
However, "install" is quite inconvenient when copying directories with many files inside. Simply running "cp" and then changing permissions with " find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \; " is a reasonable workaround, at least for me. Vlad --
vlad wrote:
Hi all,
On Sun, Nov 22, 2009 at 11:14:52AM +0100, hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
If it breaks stuff, then you should tell upstream that they makefile is crap. So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
However, "install" is quite inconvenient when copying directories with many files inside. Simply running "cp" and then changing permissions with " find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \; " is a reasonable workaround, at least for me. Vlad
read "man install": e.g. install -t $pkgdir/target src/dir/*
Hi Allen, On Sun, Nov 22, 2009 at 09:30:39PM +1000, Allan McRae wrote:
vlad wrote:
Hi all,
On Sun, Nov 22, 2009 at 11:14:52AM +0100, hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
If it breaks stuff, then you should tell upstream that they makefile is crap. So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
However, "install" is quite inconvenient when copying directories with many files inside. Simply running "cp" and then changing permissions with " find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \; " is a reasonable workaround, at least for me. Vlad
read "man install": e.g. install -t $pkgdir/target src/dir/*
This works only if there are only files in that directory. Subfolders are not copied. So one has to run "install" for each folder. "cp" copies everything - files and folders. --
On Sun, Nov 22, 2009 at 12:37 PM, vlad <vla@uni-bonn.de> wrote:
Hi Allen,
On Sun, Nov 22, 2009 at 09:30:39PM +1000, Allan McRae wrote:
vlad wrote:
Hi all,
On Sun, Nov 22, 2009 at 11:14:52AM +0100, hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
If it breaks stuff, then you should tell upstream that they makefile is crap. So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
However, "install" is quite inconvenient when copying directories with many files inside. Simply running "cp" and then changing permissions with " find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \; " is a reasonable workaround, at least for me. Vlad
read "man install": e.g. install -t $pkgdir/target src/dir/*
This works only if there are only files in that directory. Subfolders are not copied. So one has to run "install" for each folder. "cp" copies everything - files and folders.
--
If the copying is not so multiple, I use for;do;done cycle to solve it. There are some 'cp' In core/extra/community too: grep -R " cp " /var/abs/core/*/PKGBUILD | wc -l 82 grep -R " cp " /var/abs/extra/*/PKGBUILD | wc -l 341 grep -R " cp " /var/abs/community/*/PKGBUILD | wc -l 430 Best Regards, Laszlo Papp
On Sun, Nov 22, 2009 at 12:44:22PM +0100, Laszlo Papp wrote:
On Sun, Nov 22, 2009 at 12:37 PM, vlad <vla@uni-bonn.de> wrote:
Hi Allen,
On Sun, Nov 22, 2009 at 09:30:39PM +1000, Allan McRae wrote:
vlad wrote:
Hi all,
On Sun, Nov 22, 2009 at 11:14:52AM +0100, hollunder@gmx.at wrote:
On Sun, 22 Nov 2009 20:12:24 +1000 Allan McRae <allan@archlinux.org> wrote:
If it breaks stuff, then you should tell upstream that they makefile is crap. So I guess this means it breaks? I usually do. You'd be surprised how many don't know about DESTDIR and use cp.
However, "install" is quite inconvenient when copying directories with many files inside. Simply running "cp" and then changing permissions with " find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \; " is a reasonable workaround, at least for me. Vlad
read "man install": e.g. install -t $pkgdir/target src/dir/*
This works only if there are only files in that directory. Subfolders are not copied. So one has to run "install" for each folder. "cp" copies everything - files and folders.
--
If the copying is not so multiple, I use for;do;done cycle to solve it. Sure. But why use a loop for a simple task "cp" and "find" does with same result? Just to use "install"? Or are the results not the same?
--
This works only if there are only files in that directory. Subfolders are not copied. So one has to run "install" for each folder. "cp" copies everything - files and folders.
--
I wrote a function to handle that at some point which I include in PKGBUILDs on very rare occasions: function _install_dir { _src_dir=$1 _dest_dir=$2 _n=${#_src_dir} for _file in $(find $_src_dir -type f) do _dest_file=${_dest_dir}${_file:$_n} install -Dm644 $_file $_dest_file done } Obviously it could be modified to accept a permissions argument as well. Xyne
find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \;
chmod -R u=rwX,go=rX $pkgdir The capital X will only set the execute bit on directories, and leave it untouched on files if it is already set :)
On 11/22/2009 03:35 PM, Phillip Smith wrote:
find ${pkgdir}/.../ -type d -exec chmod 755 {} \; find ${pkgdir}/.../ -type f -exec chmod 644 {} \;
chmod -R u=rwX,go=rX $pkgdir
The capital X will only set the execute bit on directories, and leave it untouched on files if it is already set :)
That assumes that all executable files actually need to be executable, which is often not the case with pre-packaged binary tarballs.. you just get random png/desktop/jar/etc files (or even all files sometimes) that are 755. Of course, there probably isn't any tangible harm in it, but it's at least annoying for the detail-oriented ;)
On Sat, Nov 21, 2009 at 6:29 PM, <hollunder@gmx.at> wrote:
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
Sorry, but you are wrong. Since when using fakeroot when not needed is a good thing ? How can it reveal errors ? Care to elaborate ? We are all very curious :)
On Sat, 21 Nov 2009 19:13:17 +0100 Xavier <shiningxc@gmail.com> wrote:
On Sat, Nov 21, 2009 at 6:29 PM, <hollunder@gmx.at> wrote:
Sorry, but I consider the use of fakeroot a good thing, it helps to reveal errors while packaging/creating the PKGBUILD at least. Don't know why it should be avoided.
Sorry, but you are wrong. Since when using fakeroot when not needed is a good thing ? How can it reveal errors ? Care to elaborate ? We are all very curious :)
You know about DESTDIR and all that? Some apps don't support it, some semm to support it and don't really. In those cases you get notified, can patch makefiles or work around it some other way. I had a number of these cases in my 50+ PKGBUILDs. Might be that building as user would reveal these as well, I'm not sure. I'm not sure about all possible consequences and everything that could go wrong, but I doubt that a small compile speed gain, according to another mail, is worth it.
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
It's also good to be able to use the -R flag to makepkg which you can't do without the separate functions :)
On Sun 22 Nov 2009 07:34 +1100, Phillip Smith wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages.
It's also good to be able to use the -R flag to makepkg which you can't do without the separate functions :)
Actually you can repackage without a package function. Whatever is contained in $pkgdir will be made into a package.
Loui Chang wrote:
On Sun 22 Nov 2009 07:34 +1100, Phillip Smith wrote:
2009/11/22 Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>:
Andrea Scarpino wrote:
Why do you use package() function when the package isn't a splitted package?
Hello :)
Using both build() and package() is not necessary condition for use only with splitted packages, its avoid to use the fakeroot on building process that is not needed in 99% of packages. It's also good to be able to use the -R flag to makepkg which you can't do without the separate functions :)
Actually you can repackage without a package function. Whatever is contained in $pkgdir will be made into a package.
Yes, but it is rather crap... without the package() function using -R is only useful if you want to change a variable in the PKGBUILD (pkgdesc, depends,...). With a package() function, you can actually change the contents of the package. Splitting of the build and package steps is one of the most under-appreciated features in the last pacman release. It is really good to see someone actually using it. (I do not and I implemented it!) Allan
Andrea Scarpino wrote (omissions by me)
you don't need to include LICENSE file for packages that use GPL or common licenses (e.g. cococp), and you can omit 'custom:' when a package is licensed under BSD or MIT.
It was my advise to include "custom" for BSD and MIT licenses, so if this is an error, it is mine. But I think having a "custom" in the license array makes it more clear where to look for the license file. Regards Stefan
It was my advise to include "custom" for BSD and MIT licenses, so if this is an error, it is mine.
But I think having a "custom" in the license array makes it more clear where to look for the license file. from[1]: "The BSD, MIT, zlib/png and Python licenses are special cases and could not be included in the licenses package. For the sake of the
On 21/11/2009, Stefan Husmann <stefan-husmann@t-online.de> wrote: license array, it is treated as a common license (license=('BSD'), license=('MIT'), license=('ZLIB') and license=('Python')) but technically each one is a custom license because each one has its own copyright line. Any packages licensed under these four should have its own unique license stored in /usr/share/licenses/pkgname. Some packages may not be covered by a single license. In these cases, multiple entries may be made in the license array, e.g. license=('GPL' 'custom:name of license')." [1] - http://wiki.archlinux.org/index.php/Building_Packages_in_Arch_Linux -- Andrea `bash` Scarpino Arch Linux Developer
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 On Sat, 21 Nov 2009 18:09:27 +0100 Andrea Scarpino <andrea@archlinux.org> wrote:
Hi Thorsten, you don't need to include LICENSE file for packages that use GPL or common licenses (e.g. cococp), and you can omit 'custom:' when a package is licensed under BSD or MIT. Why do you use package() function when the package isn't a splitted package? Also, you don't need to put Contributor/Maintainer tag twice (e.g. objfw-hg) and you can omit empty arrays from PKGBUILD (e.g. newsbeuter-git). Ah, another little thing: don't include $pkgname in description (e.g. structorizer).
Regards
As an exception, it is allowed to write an extension of Coco/R that is used as a plugin in non-free software. which I had not read in another GPL license file I read so far, so I decided to include it to the package in order to avoid any legal
Hello Andrea, when I packaged cococpp I stumbled upon this paragraph in the text: problems. As namcap always throwed a unnecessary warning if only the Maintainer tag was set, I decided to simply set both because I thought it wouldn't disturb anyone and I had a warning less when I was proving my packages. As Stefan already said, he told me to set a custom in front of the license I will change that when it is clarified how it should be. I'll upload a new structorizer package with a fixed description in the next few minutes. For the usage of both methods(build and package), I thought it's much nicer to read for people who are new to Arch and read their first PKGBUILDs and as the packages didn't need fakeroot to build I used it. Regards - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iFUEARELAAYFAksIKKUACgkQOeTxfyla+/SfOgDYh+41Vi97OFPPTO5VnxtVvpyl A9psMOmq66wUAN4+2Aew9cW0c1foq6eWcbWo6BaJCrLtBrEcuUXi =JkFe -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224 Hello, I just uploaded a new version of every of my PKGBUILDs, now only the Maintainer flag is set and I reverted the change to the license array in the MIT/BSD licensed PKGBUILDs, so that they're now again listed without the "custom:" in front of the license. As none of my packages requires a fakeroot for build and the discussion showed that the usage of both methods has some bonuses, I will use them as long as no problem with that occurs or is being reported to me. Regards Thorsten - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iFYEARELAAYFAksMR+sACgkQOeTxfyla+/R2CwDg2RcLQdJMBHcXXTixTkrC0Fvj grr2KjAVJ9iwcADgqWuueO2aw/CBZcMhSEyNhHNtbNOk+nIb2/khJg== =uJlj -----END PGP SIGNATURE-----
Thorsten Töpper schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hello,
I've been playing for a while with the thought to apply as a Trusted User, but I never really had the courage to do so, well now I try it.
About my person: I'm a 1990 born student from the south of Germany, I study Computer Science(first semester) and use Arch as my main system now since two years and 4 days. I'm mainly active in the german part of the community as the international forums and IRC are too lively for me to actively participate a lot, so I mostly only read the topics, but don't post in the threads. However I read nearly every mail at the mailing lists (except for the ones concerning problems of Users with software I haven't used in years e.g. KDE), but as my opinion was often already stated I don't feel that I have to repeat what's already been said, so I mail rarely to the lists too.
About my skills: I'm programming in C since a few years, though I mostly review code in order to learn more, I'm also capable of the basics with python 2.5, several BASIC dialects, C++, Objective C, Java and of course shell scripting. Whereas the focus for the next years lies upon C and Java as they're both needed by my study.
About my packages: I maintain 10 packages in AUR[1], whereby I also participate in the development of the i3 window manager to whom's project family 6 of these packages belong(3 projects, each as stable and git package), the other four are the git package of the newsbeuter feedreader and the cococpp package which is a build dependency for the previously named, structorizer which is a Java program to design structograms (or Nassi- Schneiderman diagrams) and a mecurial package for objfw which is a portable framework for the Objective C language, not one of them was adopted. If you want to see their history, I also keep them in a git repository at github.com[2].
About my Application: I asked Stefan Husmann if he would like to sponsor me and he agreed to do so. I have two Arch systems, my laptop running an i686 installation and my desktop machine running a x86_64 installation, both run without the testing repository. As I have to use Java and corresponding util- ities for my study I'd take care of orphanages of the Java development segment, but also orphans in the topics I'm mainly interested in(window managers, development and networks). And as I check my mail whenever it's possible I'd also help with the request of users regarding the administration of the AUR.
If you want to search for me, my nick at Arch related sites is Atsutane.
Regards Thorsten
[1] http://aur.archlinux.org/packages.php?SeB=m&K=Atsutane [2] http://github.com/Atsutane/packages - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iFYEARELAAYFAksIGCkACgkQOeTxfyla+/QIXgDgq6vF0HVT5ab9E2eMNjcRvxzw MLDlK0b2ILDHugDeLTJMdLx609Qhnh5Z87jPEDohZiLX0i4Cd/0HZQ== =uTIK -----END PGP SIGNATURE-----
Hello TUs, the discussion period for Thorstens application is over, let us start the 7-day voting period now. Good luck, Thorsten! Best Regards Stefan
Stefan Husmann schrieb:
Thorsten Töpper schrieb:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
Hello,
I've been playing for a while with the thought to apply as a Trusted User, but I never really had the courage to do so, well now I try it.
About my person: I'm a 1990 born student from the south of Germany, I study Computer Science(first semester) and use Arch as my main system now since two years and 4 days. I'm mainly active in the german part of the community as the international forums and IRC are too lively for me to actively participate a lot, so I mostly only read the topics, but don't post in the threads. However I read nearly every mail at the mailing lists (except for the ones concerning problems of Users with software I haven't used in years e.g. KDE), but as my opinion was often already stated I don't feel that I have to repeat what's already been said, so I mail rarely to the lists too.
About my skills: I'm programming in C since a few years, though I mostly review code in order to learn more, I'm also capable of the basics with python 2.5, several BASIC dialects, C++, Objective C, Java and of course shell scripting. Whereas the focus for the next years lies upon C and Java as they're both needed by my study.
About my packages: I maintain 10 packages in AUR[1], whereby I also participate in the development of the i3 window manager to whom's project family 6 of these packages belong(3 projects, each as stable and git package), the other four are the git package of the newsbeuter feedreader and the cococpp package which is a build dependency for the previously named, structorizer which is a Java program to design structograms (or Nassi- Schneiderman diagrams) and a mecurial package for objfw which is a portable framework for the Objective C language, not one of them was adopted. If you want to see their history, I also keep them in a git repository at github.com[2].
About my Application: I asked Stefan Husmann if he would like to sponsor me and he agreed to do so. I have two Arch systems, my laptop running an i686 installation and my desktop machine running a x86_64 installation, both run without the testing repository. As I have to use Java and corresponding util- ities for my study I'd take care of orphanages of the Java development segment, but also orphans in the topics I'm mainly interested in(window managers, development and networks). And as I check my mail whenever it's possible I'd also help with the request of users regarding the administration of the AUR.
If you want to search for me, my nick at Arch related sites is Atsutane.
Regards Thorsten
[1] http://aur.archlinux.org/packages.php?SeB=m&K=Atsutane [2] http://github.com/Atsutane/packages - -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iFYEARELAAYFAksIGCkACgkQOeTxfyla+/QIXgDgq6vF0HVT5ab9E2eMNjcRvxzw MLDlK0b2ILDHugDeLTJMdLx609Qhnh5Z87jPEDohZiLX0i4Cd/0HZQ== =uTIK -----END PGP SIGNATURE-----
Hello TUs,
the discussion period for Thorstens application is over, let us start the 7-day voting period now.
Good luck, Thorsten!
Best Regards Stefan
Hello, only two days are left in the voting period. and not all TUs have voted. Please vote and try to reach a quorum. Thanks and regards Stefan
participants (16)
-
Allan McRae
-
Andrea Scarpino
-
Gerardo Exequiel Pozzi
-
hollunder＠gmx.at
-
Laszlo Papp
-
Loui Chang
-
Lukáš Jirkovský
-
Phillip Smith
-
Ranguvar
-
Ray Rashif
-
Stefan Husmann
-
TDY
-
Thorsten Töpper
-
vlad
-
Xavier
-
Xyne