https://wiki.archlinux.org/api.php?action=feedcontributions&user=SpepS&feedformat=atomArchWiki - User contributions [en]2024-03-28T20:09:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=DeveloperWiki:Roll_Call&diff=411170DeveloperWiki:Roll Call2015-12-07T11:59:51Z<p>SpepS: /* Trusted Users */ added speps details</p>
<hr />
<div>[[Category:DeveloperWiki]]<br />
==Developers==<br />
* Aaron Griffin<br />
<br />
* Allan McRae<br />
** Packaging (toolchain)<br />
** Pacman development<br />
<br />
* Anatol Pomozov<br />
* Andreas Radke<br />
** Packaging (Bluetooth, Printing, Xorg, LibreOffice, LTS kernel)<br />
* Andrew Gregory<br />
** Pacman development<br />
* Ángel Velásquez<br />
* Antonio Rojas<br />
** Packaging (KDE, math stuff, orphans)<br />
* Bartłomiej Piotrowski<br />
** Packaging (mostly core and extra)<br />
** Bug tracker admin<br />
** Planet admin<br />
** Helping with rebuilds<br />
* Dan McGee<br />
* Daniel Isenmann<br />
* Dave Reisner<br />
* Eric Bélanger<br />
* Evangelos Foutras<br />
** Packaging (Xfce, LLVM/Clang)<br />
** Rebuild automation (arch-rebuilds)<br />
** Might be inactive for some period in 2016 and/or 2017<br />
* Felix Yan<br />
** Packaging (Python, Perl, Haskell, Nodejs, KDE/Qt, Deepin, Chinese/Japanese l10n, and more)<br />
* Florian Pritz<br />
** Packaging<br />
** Serveradmin<br />
** Mirrors<br />
** Mailinglists<br />
* Gaetan Bisson<br />
** Packaging<br />
* Gerardo Pozzi<br />
* Giovanni Scafora<br />
* Guillaume Alaux<br />
** Packaging ([extra] and [Community] – mainly Java related packages)<br />
* Ionuț Mircea Bîru<br />
** Currently I'm in charge of paying all our servers and signing.<br />
** I don't do any packaging this days, unless there is a bug in a package that affects or annoys me.<br />
** Group contact for archlinux on freenode.<br />
* Jan de Groot<br />
* Jan Steffens<br />
** Packaging (GNOME, misc other stuff)<br />
* Jürgen Hötzel<br />
* Laurent Carlier<br />
** Packaging (mesa, xorg)<br />
* Lukas Fleischer<br />
** Packaging<br />
** aurweb development<br />
** projects.archlinux.org maintenance<br />
* Maxime Gauduin<br />
* Pierre Schmitz<br />
** Packaging<br />
*** PHP<br />
*** See https://www.archlinux.org/packages/?maintainer=pierre<br />
** Maintaining<br />
*** install ISO and bootstrap packages<br />
*** Keyring<br />
*** wiki and bbs software (MediaWiki, FluxBB, custom themes and extensions)<br />
* Ray Rashif<br />
** Packaging (Audio, misc productivity and creativity, others)<br />
** Sporadic inactivity (mostly due to hardware issues needing to work in Windowz with pain)<br />
* Rémy Oudompheng<br />
* Ronald van Haren<br />
* Sébastien Luttringer<br />
* Sven-Hendrik Haase<br />
** Packaging (NVIDIA stuff, multimedia stuff)<br />
* Thomas Bächler<br />
* Thomas Dziedzic<br />
* Tobias Powalowski<br />
* Tom Gundersen<br />
<br />
==Trusted Users==<br />
* Alexander Rødseth<br />
* Alexandre Filgueira<br />
* Anatol Pomozov<br />
* Andrzej Giniewicz<br />
* Antonio Rojas<br />
* Balló György<br />
** Packaging (Cinnamon, GNOME Flashback, LXDE)<br />
* Christian Hesse<br />
* Connor Behan<br />
** Packaging<br />
* Daniel Micay<br />
* Daniel Wallace<br />
** Packaging<br />
* Evgeniy Alekseev<br />
* Fabio Castelli<br />
** Packaging<br />
* Ike Devolder<br />
** Packaging<br />
* Jakob Gruber<br />
** Packaging<br />
* Jaroslav Lichtblau<br />
* Jelle van der Waa<br />
* Jerome Leclanche<br />
** Packaging (LXQt)<br />
* Jiachen Yang<br />
* Johannes Löthberg<br />
* Jonathan Steel<br />
** Packaging<br />
* Kyle Keen<br />
* Laurent Carlier<br />
** Packaging<br />
* Levente Polyak<br />
** Packaging<br />
** Security team<br />
** Reproducible builds<br />
* Lukas Fleischer<br />
** Packaging<br />
** aurweb development<br />
** projects.archlinux.org maintenance<br />
* Lukas Jirkovsky<br />
** Packaging<br />
* Martin Wimpress<br />
* Massimiliano Torromeo<br />
** Packaging<br />
* Maxime Gauduin<br />
* Pierre Neidhardt<br />
* Sébastien Luttringer<br />
* Sergej Pupykin<br />
* speps<br />
** Packaging (mostly Audio stuff)<br />
* Thomas Dziedzic<br />
* Thorsten Töpper<br />
* Timothy Redaelli<br />
* Xyne<br />
* Михаил Страшун<br />
<br />
==Support Staff==<br />
* Alad Wenter<br />
** Wiki administration<br />
* Christian Rebischke<br />
** arch-security mailinglist, searching CVE's in arch packages, writing bug reports<br />
* Dario Giovannetti<br />
** Wiki administration<br />
* Doug Newgard<br />
** Bug tracker basic triage, sorting, correction, and assigning<br />
* Eric Waller<br />
* Jakob Wadsager<br />
* Jason Ryan<br />
** Forum Administration and Moderation<br />
** Wiki Administration<br />
* Johannes Löthberg<br />
* Levente Polyak<br />
** See above (TU)<br />
* Remi Gacogne<br />
** Security team<br />
** Reproducible builds<br />
* tigrmesh<br />
* WorMzy Tykashi<br />
** Forum moderation<br />
* Xyne</div>SpepShttps://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=203130Package Maintainer guidelines2012-05-28T23:35:45Z<p>SpepS: rule 12 grammar fixes</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:About Arch]]<br />
[[Category:Arch User Repository]]<br />
{{i18n|AUR Trusted User Guidelines}}<br />
{{Article summary start}}<br />
{{Article summary text|Explains guidelines for the Arch User Repository's Trusted Users.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary end}}<br />
<br />
The '''Trusted User (TU)''' is a member of the community charged with keeping the AUR in working order. He/she maintains popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), and votes in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]<br />
<br />
==TODO list for new Trusted Users==<br />
# Read this entire wiki article.<br />
# Read the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].<br />
# Make sure your account details on the [[Arch User Repository|AUR]] are up-to-date and that your sponsor has given you TU status.<br />
# Add yourself to the [[Trusted Users]] page.<br />
# Remind Allan/Andrea to change your account on forums.<br />
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.<br />
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to Andrea Scarpino (andrea@archlinux.org).<br />
# Send Ionuț Bîru (ibiru@archlinux.org) all the information based on this [https://www.archlinux.org/trustedusers/ template] to have access on dev interface.<br />
# Install the {{pkg|devtools}} package.<br />
# Send an email to Lukas Fleischer with one SSH public key attached. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.<br />
# Create a PGP key for [[package signing]].<br />
# Send a signed email to all [http://www.archlinux.org/master-keys/ Master Keys owners] including your PGP key and the relative full key fingerprint. Your key needs to be signed at least by three of five master key holders.<br />
# Make the directories {{ic|~/staging/community}} and {{ic|~/staging/community-testing}} (and {{ic|~/staging/multilib}} if you are interested in maintaining multilib packages) on aur.archlinux.org. This step is '''important''' as the devtools scripts use this directory to process incoming packages.<br />
# Start contributing!<br />
<br />
==The TU and [unsupported]==<br />
<br />
The TUs should also make an effort to check package submissions in UNSUPPORTED for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.<br />
<br />
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all pkgs follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distro.<br />
<br />
TUs are also in an excellent position to document recommended practices.<br />
<br />
==The TU and [community], Guidelines for Package Maintenance==<br />
<br />
=== Rules for Packages Entering the [community] Repo ===<br />
<br />
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://www.archlinux.de/?page=PackageStatistics pkgstats] or 10 votes on the AUR.<br />
<br />
* Automatic exceptions to this rule are:<br />
** i18n packages<br />
** accessibility packages<br />
** drivers<br />
** dependencies of packages who satisfy the definition of popular, including makedeps and optdeps<br />
** packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular<br />
<br />
* Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.<br />
<br />
* TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.<br />
<br />
=== Accessing and Updating the Repository ===<br />
<br />
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra], except that it uses another server https://aur.archlinux.org instead of http://archlinux.org. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here.<br />
<br />
Initially you should do a '''non-recursive checkout''' of the [community] repository:<br />
svn checkout -N svn+ssh://aur.archlinux.org/srv/svn-packages<br />
<br />
This creates a directory named "svn-packages" which contains nothing. It does, however, know that it is an svn checkout. <br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].<br />
<br />
To '''remove''' a package:<br />
ssh aur.archlinux.org /arch/db-remove pkgname community arch<br />
<br />
Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux. (What about "any"?)<br />
<br />
When you are done with editing the PKGBUILD, etc, you should '''commit''' the changes ({{ic|svn commit}}).<br />
<br />
When you want to '''release''' a package, first copy the package to the ''staging/community'' directory on aur.archlinux.org using scp and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-i686'' or ''community-x86_64'' indicating that this package is in the community repository for that architecture.<br />
<br />
'''''Note:''' In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1 (and not +1). This indicates that the change to the PKGBUILD is x86_64 specific and i686 maintainers '''should not''' rebuild the package for i686. When the TU decides to bump the pkgrel, it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.) releases exclusive to the x86_64 TU's to avoid confusion.''<br />
<br />
Thus the '''process''' of updating a package can be summarised as:<br />
<br />
* '''Update''' the package directory ({{ic|svn update some-package}})<br />
* '''Change''' to the package trunk directory ({{ic|cd some-package/trunk}})<br />
* '''Edit''' the PKGBUILD, make necessary changes and {{ic|makepkg}}. It is recommended to build in a [[DeveloperWiki:Building in a Clean Chroot|clean chroot]].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary pkg.tar.gz.<br />
* '''Commit''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:<br />
** '''Commit''' the changes to trunk ({{ic|svn commit}})<br />
** '''Copy''' the package to aur.archlinux.org ({{ic|scp pkgname-ver-rel-arch.pkg.tar.xz* aur.archlinux.org:staging/community/}})<br />
** '''Tag''' the package ({{ic|archrelease community-{i686,x86_64}}})<br />
* '''Update''' the repository ({{ic|ssh aur.archlinux.org /arch/db-update}})<br />
<br />
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]]. For the section ''Avoid having to enter your password all the time'' use aur.archlinux.org instead of archlinux.org and svn.archlinux.org.<br />
<br />
=== Disowning packages ===<br />
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can<br />
maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.<br />
<br />
=== Moving packages from unsupported to [community] ===<br />
<br />
Follow the normal procedures for adding a package community, but remember to delete the corresponding package from unsupported!<br />
<br />
=== Moving packages from [community] to unsupported ===<br />
<br />
Remove the package using the instructions above and upload your source tarball to the AUR.<br />
<br />
=== Moving packages from [community-testing] to [community] ===<br />
ssh aur.archlinux.org /arch/db-move community-testing community package<br />
<br />
=== Deleting packages from unsupported ===<br />
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a<br />
real package then all dependents will point to the correct place.<br />
<br />
=== See also ===<br />
* [[DeveloperWiki#Packaging_Guidelines]]</div>SpepShttps://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=203129Package Maintainer guidelines2012-05-28T23:16:15Z<p>SpepS: Adding a point to the TU TODO list for requesting key signature by the master key holders</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:About Arch]]<br />
[[Category:Arch User Repository]]<br />
{{i18n|AUR Trusted User Guidelines}}<br />
{{Article summary start}}<br />
{{Article summary text|Explains guidelines for the Arch User Repository's Trusted Users.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary end}}<br />
<br />
The '''Trusted User (TU)''' is a member of the community charged with keeping the AUR in working order. He/she maintains popular packages ([https://mailman.archlinux.org/pipermail/aur-general/2010-September/010649.html communicating with and sending patches upstream as needed]), and votes in administrative matters. A TU is elected from active community members by current TUs in a democratic process. TUs are the only members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]<br />
<br />
==TODO list for new Trusted Users==<br />
# Read this entire wiki article.<br />
# Read the [https://aur.archlinux.org/trusted-user/TUbylaws.html TU Bylaws].<br />
# Make sure your account details on the [[Arch User Repository|AUR]] are up-to-date and that your sponsor has given you TU status.<br />
# Add yourself to the [[Trusted Users]] page.<br />
# Remind Allan/Andrea to change your account on forums.<br />
# Ask some TU for the #archlinux-tu@freenode key and hang out with us in the channel. You do not have to do this, but it would be neat since this is where most dark secrets are spilled and where many new ideas are conceived.<br />
# If you are not upgraded to a Trusted User group on bug tracker in two days, report this as a bug to Andrea Scarpino (andrea@archlinux.org).<br />
# Send Ionuț Bîru (ibiru@archlinux.org) all the information based on this [https://www.archlinux.org/trustedusers/ template] to have access on dev interface.<br />
# Install the {{pkg|devtools}} package.<br />
# Send an email to Lukas Fleischer with one SSH public key attached. If you do not have one, use {{ic|ssh-keygen}} to generate one. Check the [[Using SSH Keys]] wiki page for more information about SSH keys.<br />
# Create a PGP key for [[package signing]].<br />
# Send a signed email to all [http://www.archlinux.org/master-keys/ Master Keys owner's] including your PGP key and the relative full key fingerprint. Your key needs to be signed at least by three on five master key holders.<br />
# Make the directories {{ic|~/staging/community}} and {{ic|~/staging/community-testing}} (and {{ic|~/staging/multilib}} if you are interested in maintaining multilib packages) on aur.archlinux.org. This step is '''important''' as the devtools scripts use this directory to process incoming packages.<br />
# Start contributing!<br />
<br />
==The TU and [unsupported]==<br />
<br />
The TUs should also make an effort to check package submissions in UNSUPPORTED for malicious code and good PKGBUILDing standards. In around 80% of cases the PKGBUILDs in the UNSUPPORTED are very simple and can be quickly checked for sanity and malicious code by the TU team.<br />
<br />
TUs should also check PKGBUILDs for minor mistakes, suggest corrections and improvements. The TU should endeavor to confirm that all pkgs follow the Arch Packaging Guidelines/Standards and in doing so share their skills with other package builders in an effort to raise the standard of package building across the distro.<br />
<br />
TUs are also in an excellent position to document recommended practices.<br />
<br />
==The TU and [community], Guidelines for Package Maintenance==<br />
<br />
=== Rules for Packages Entering the [community] Repo ===<br />
<br />
* Only "popular" packages may enter the repo, as defined by 1% usage from [https://www.archlinux.de/?page=PackageStatistics pkgstats] or 10 votes on the AUR.<br />
<br />
* Automatic exceptions to this rule are:<br />
** i18n packages<br />
** accessibility packages<br />
** drivers<br />
** dependencies of packages who satisfy the definition of popular, including makedeps and optdeps<br />
** packages that are part of a collection and are intended to be distributed together, provided a part of this collection satisfies the definition of popular<br />
<br />
* Any additions not covered by the above criteria must first be proposed on the aur-general mailing list, explaining the reason for the exemption (e.g. renamed package, new package). The agreement of three other TUs is required for the package to be accepted into [community]. Proposed additions from TUs with large numbers of "non-popular" packages are more likely to be rejected.<br />
<br />
* TUs are strongly encouraged to move packages they currently maintain from [community] if they have low usage. No enforcement will be made, although resigning TUs packages may be filtered before adoption can occur.<br />
<br />
=== Accessing and Updating the Repository ===<br />
<br />
The [community] repository now uses '''devtools''' which is the same system used for uploading packages to [core] and [extra], except that it uses another server https://aur.archlinux.org instead of http://archlinux.org. Thus most of the instructions in [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]] work without any change. Information which is specific for the [community] repository (like changed URLs) have been put here.<br />
<br />
Initially you should do a '''non-recursive checkout''' of the [community] repository:<br />
svn checkout -N svn+ssh://aur.archlinux.org/srv/svn-packages<br />
<br />
This creates a directory named "svn-packages" which contains nothing. It does, however, know that it is an svn checkout. <br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]].<br />
<br />
To '''remove''' a package:<br />
ssh aur.archlinux.org /arch/db-remove pkgname community arch<br />
<br />
Here and in the following text, arch can be one of i686 or x86_64 which are the two architectures supported by Arch Linux. (What about "any"?)<br />
<br />
When you are done with editing the PKGBUILD, etc, you should '''commit''' the changes ({{ic|svn commit}}).<br />
<br />
When you want to '''release''' a package, first copy the package to the ''staging/community'' directory on aur.archlinux.org using scp and then '''tag''' the package by going to the ''pkgname/trunk'' directory and issuing {{ic|archrelease community-arch}}. This makes an svn copy of the trunk entries in a directory named ''community-i686'' or ''community-x86_64'' indicating that this package is in the community repository for that architecture.<br />
<br />
'''''Note:''' In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1 (and not +1). This indicates that the change to the PKGBUILD is x86_64 specific and i686 maintainers '''should not''' rebuild the package for i686. When the TU decides to bump the pkgrel, it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.) releases exclusive to the x86_64 TU's to avoid confusion.''<br />
<br />
Thus the '''process''' of updating a package can be summarised as:<br />
<br />
* '''Update''' the package directory ({{ic|svn update some-package}})<br />
* '''Change''' to the package trunk directory ({{ic|cd some-package/trunk}})<br />
* '''Edit''' the PKGBUILD, make necessary changes and {{ic|makepkg}}. It is recommended to build in a [[DeveloperWiki:Building in a Clean Chroot|clean chroot]].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary pkg.tar.gz.<br />
* '''Commit''', '''Copy''' and '''Tag''' the package using {{ic|communitypkg "commit message"}}. This automates the following:<br />
** '''Commit''' the changes to trunk ({{ic|svn commit}})<br />
** '''Copy''' the package to aur.archlinux.org ({{ic|scp pkgname-ver-rel-arch.pkg.tar.xz* aur.archlinux.org:staging/community/}})<br />
** '''Tag''' the package ({{ic|archrelease community-{i686,x86_64}}})<br />
* '''Update''' the repository ({{ic|ssh aur.archlinux.org /arch/db-update}})<br />
<br />
Also see the ''Miscellaneous'' section in the [[DeveloperWiki:HOWTO Be A Packager|Packager Guide]]. For the section ''Avoid having to enter your password all the time'' use aur.archlinux.org instead of archlinux.org and svn.archlinux.org.<br />
<br />
=== Disowning packages ===<br />
If a TU cannot or does not want to maintain a package any longer, a notice should be posted to the AUR Mailing List, so another TU can<br />
maintain it. A package can still be disowned even if no other TU wants to maintain it, but the TUs should try not to drop many packages (they should not take on more than they have time for). If a package has become obsolete or is not used any longer, it can be removed completely as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again (fresh) to UNSUPPORTED, where a regular user can maintain the package instead of the TU.<br />
<br />
=== Moving packages from unsupported to [community] ===<br />
<br />
Follow the normal procedures for adding a package community, but remember to delete the corresponding package from unsupported!<br />
<br />
=== Moving packages from [community] to unsupported ===<br />
<br />
Remove the package using the instructions above and upload your source tarball to the AUR.<br />
<br />
=== Moving packages from [community-testing] to [community] ===<br />
ssh aur.archlinux.org /arch/db-move community-testing community package<br />
<br />
=== Deleting packages from unsupported ===<br />
There is no point in removing dummy packages, because they will be re-created in an attempt to track dependencies. If someone uploads a<br />
real package then all dependents will point to the correct place.<br />
<br />
=== See also ===<br />
* [[DeveloperWiki#Packaging_Guidelines]]</div>SpepShttps://wiki.archlinux.org/index.php?title=PKGBUILD&diff=201204PKGBUILD2012-05-13T00:02:50Z<p>SpepS: update pkgname rules according to latest changes http://projects.archlinux.org/pacman.git/commit/?id=5f71570ec</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
{{i18n|PKGBUILD}}<br />
[[fr:PKGBUILD]]<br />
[[fa:PKGBUILD]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article provides an explanation of PKGBUILD variables used when [[Creating Packages|creating packages]]. A PKGBUILD is a script that describes how software is to be compiled and packaged. Writing installation functions and general packaging information is covered in [[Creating Packages]] and other [[:Category:Package development|package development]] articles}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Packaging Standards}}<br />
{{Article summary wiki|Creating Packages}}<br />
{{Article summary wiki|Custom local repository}}<br />
{{Article summary wiki|pacman Tips}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|PKGBUILD(5) Manual Page|https://www.archlinux.org/pacman/PKGBUILD.5.html}}<br />
{{Article summary end}}<br />
<br />
A '''PKGBUILD''' is an [[Arch Linux]] package build description file used when [[Creating Packages|creating packages]].<br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and information stored in PKGBUILDs. When '''makepkg''' is run, it searches for a {{Ic|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the files to build a package file ({{ic|''pkgname''.pkg.tar.xz}}). The resulting package contains binary files and installation instructions, readily installed with [[pacman]].<br />
<br />
== Variables ==<br />
The following are variables that can be filled out in the PKGBUILD file.<br />
<br />
It is common practice to define the variables in the PKGBUILD in same order as given here. However, this is not mandatory, as long as correct [[Bash]] syntax is used.<br />
<br />
=== pkgname ===<br />
The name of the package. It should consist of ''alphanumeric and any of the following characters @ . _ + - (at symbol, dot, underscore, plus, hyphen)''. All letters should be ''lowercase'' and ''names are not allowed to start with hyphens''. For the sake of consistency, {{ic|pkgname}} should match the name of the source tarball of the software you are packaging. For instance, if the software is in {{ic|foobar-2.5.tar.gz}}, the {{ic|pkgname}} value should be {{Ic|foobar}}. The present working directory the PKGBUILD file is in should also match the {{ic|pkgname}}.<br />
<br />
=== pkgver ===<br />
The version of the package. The value should be the same as the version released by the author of the package. It can contain letters, numbers and periods but CANNOT contain a hyphen. If the author of the package uses a hyphen in their version numbering scheme, replace it with an underscore. For instance, if the version is ''0.99-10'', it should be changed to ''0.99_10''. If the {{ic|pkgver}} variable is used later in the PKGBUILD then the underscore can easily be substituted for a dash on usage e.g.:<br />
source=($pkgname-${pkgver//_/-}.tar.gz)<br />
<br />
=== pkgrel ===<br />
The release number of the package specific to Arch Linux. This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the '''release number starts at 1'''. As fixes and optimizations are made to the {{ic|PKGBUILD}} file, the package will be '''re-released''' and the '''release number''' will increment by 1. When a new version of the package comes out, the release number resets to 1.<br />
<br />
=== epoch ===<br />
An integer value, specific to Arch Linux, representing what 'lifetime' to compare version numbers against. This value allows overrides of the normal version comparison rules for packages that have inconsistent version numbering, require a downgrade, change numbering schemes, etc. By default, packages are assumed to have an epoch value of ''0''. Do not use this unless you know what you are doing.<br />
<br />
=== pkgdesc ===<br />
The description of the package. The description should be about 80 characters or less and should not include the package name in a self-referencing way. For instance, "Nedit is a text editor for X11" should be written as "A text editor for X11."<br />
<br />
{{Note|Do not follow this rule thoughtlessly when submitting packages to [[AUR]]. If package name differs from application name for some reason, inclusion of full name into description can be the only way to ensure that package can be found during search.}}<br />
<br />
=== arch ===<br />
An array of architectures that the {{ic|PKGBUILD}} file is known to build and work on. Currently, it should contain {{ic|i686}} and/or {{ic|x86_64}}, {{ic|1=arch=('i686' 'x86_64')}}. The value {{ic|any}} can also be used for architecture-independent packages.<br />
<br />
You can access the target architecture with the variable {{ic|$CARCH}} during a build, and even when defining variables. See also {{bug|16352}}. Example:<br />
<br />
depends=(foobar)<br />
if test "$CARCH" == x86_64; then<br />
depends+=(lib32-glibc)<br />
fi<br />
<br />
=== url ===<br />
The URL of the official site of the software being packaged.<br />
<br />
=== license ===<br />
The license under which the software is distributed. A {{pkg|licenses}} package has been created in {{ic|[core]}} that stores common licenses in {{ic|/usr/share/licenses/common}}, e.g. {{ic|/usr/share/licenses/common/GPL}}. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. {{ic|1=license=('GPL')}}. If the appropriate license is not included in the official {{Pkg|licenses}} package, several things must be done:<br />
<br />
# The license file(s) should be included in: {{ic|/usr/share/licenses/''pkgname''/}}, e.g. {{ic|/usr/share/licenses/foobar/LICENSE}}.<br />
# If the source tarball does NOT contain the license details and the license is only displayed elsewhere, e.g. a website, then you need to copy the license to a file and include it.<br />
# Add {{ic|custom}} to the {{ic|license}} array. Optionally, you can replace {{ic|custom}} with {{ic|custom:name of license}}. Once a license is used in two or more packages in an official repository (including {{ic|[community]}}), it becomes a part of the {{Pkg|licenses}} package.<br />
* The [[Wikipedia:BSD License|BSD]], [[Wikipedia:MIT License|MIT]], [[Wikipedia:ZLIB license|zlib/png]] and [[Wikipedia:Python License|Python]] licenses are special cases and could not be included in the {{pkg|licenses}} package. For the sake of the {{ic|license}} array, it is treated as a common license ({{ic|1=license=('BSD')}}, {{ic|1=license=('MIT')}}, {{ic|1=license=('ZLIB')}} and {{ic|1=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 {{ic|/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. {{ic|1=license=('GPL' 'custom:name of license')}}.<br />
* Additionally, the (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:<br />
** (L)GPL - (L)GPLv2 or any later version<br />
** (L)GPL2 - (L)GPL2 only<br />
** (L)GPL3 - (L)GPL3 or any later version<br />
* If after researching the issue no license can be determined, {{ic|PKGBUILD.proto}} suggests using {{ic|unknown}}. However, upstream should be contacted about the conditions under which the software is (and is not) available.<br />
<br />
{{Tip|Some software authors do not provide separate license file and describe distribution rules in section of common ReadMe.txt. This information can be extracted in separate file during {{Ic|build}} phase with something like this: {{Ic|sed -n '/'''This software'''/,/''' thereof.'''/p' ReadMe.txt > LICENSE}}.}}<br />
<br />
=== groups ===<br />
The group the package belongs in. For instance, when you install the {{Pkg|kdebase}} package, it installs all packages that belong in the {{Grp|kde}} group.<br />
<br />
=== depends ===<br />
An array of package names that must be installed before this software can be run. If a software requires a minimum version of a dependency, the {{ic|1=>=}} operator should be used to point this out, e.g. {{ic|1=depends=('foobar>=1.8.0')}}. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency. For instance, {{pkg|gtk2}} depends on {{pkg|glib2}} and {{pkg|glibc}}. However, {{pkg|glibc}} does not need to be listed as a dependency for {{pkg|gtk2}} because it is a dependency for {{pkg|glib2}}.<br />
<br />
===makedepends===<br />
An array of package names that must be installed to build the software but unnecessary for using the software after installation. You can specify the minimum version dependency of the packages in the same format as the {{ic|depends}} array.<br />
<br />
{{Warning|The group {{Grp|base-devel}} is assumed already installed when building with makepkg . Members of "base-devel" '''should not''' be included in {{ic|makedepends}} arrays.}}<br />
<br />
=== checkdepends ===<br />
An array of packages this package depends on to run its test suite but are not needed at runtime. Packages in this list follow the same format as depends. These dependencies are only considered when the [[Creating Packages#The check() function|check()]] function is present and is to be run by makepkg.<br />
<br />
=== optdepends ===<br />
An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted. An {{ic|optdepends}} may look like this:<br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
<br />
=== provides ===<br />
An array of package names that this package provides the features of (or a virtual package such as {{Ic|cron}} or {{Ic|sh}}). Packages that provide the same things can be installed at the same time unless conflict with each other (see below). If you use this variable, you should add the version ({{ic|pkgver}} and perhaps the {{ic|pkgrel}}) that this package will provide if dependencies may be affected by it. For instance, if you are providing a modified ''qt'' package named ''qt-foobar'' version 3.3.8 which provides ''qt'' then the {{ic|provides}} array should look like {{ic|1=provides=('qt=3.3.8')}}. Putting {{ic|1=provides=('qt')}} will cause to fail those dependencies that require a specific version of ''qt''. Do not add {{ic|pkgname}} to your provides array, this is done automatically.<br />
<br />
=== conflicts ===<br />
An array of package names that may cause problems with this package if installed. Package with this name and all packages which {{Ic|provides}} virtual packages with this name will be removed. You can also specify the version properties of the conflicting packages in the same format as the {{ic|depends}} array.<br />
<br />
=== replaces ===<br />
An array of obsolete package names that are replaced by this package, e.g. {{ic|1=replaces=('ethereal')}} for the {{pkg|wireshark}} package. After syncing with {{ic|pacman -Sy}}, it will immediately replace an installed package upon encountering another package with the matching {{ic|replaces}} in the repositories. If you are providing an alternate version of an already existing package, use the {{ic|conflicts}} variable which is only evaluated when actually installing the conflicting package.<br />
<br />
=== backup ===<br />
An array of files that can contain user-made changes and should be preserved during upgrade or removal of a package, primarily intended for configuration files in {{ic|/etc}}.<br />
<br />
When updating, new version may be saved as {{ic|file.pacnew}} to avoid overwriting a file which already exists and was previously modified by the user. Similarly, when the package is removed, user-modified file will be preserved as {{ic|file.pacsave}} unless the package was removed with {{ic|pacman -Rn}} command. <br />
<br />
The file paths in this array should be relative paths (e.g. {{ic|etc/pacman.conf}}) not absolute paths (e.g. {{ic|/etc/pacman.conf}}). See also [[Pacnew and Pacsave Files]].<br />
<br />
=== options ===<br />
This array allows you to override some of the default behavior of {{ic|makepkg}}, defined in {{Ic|/etc/makepkg.conf}}. To set an option, include the option name in the array. To reverse the default behavior, place an '''{{ic|!}}''' at the front of the option. The following options may be placed in the array:<br />
<br />
* '''''strip''''' - Strips symbols from binaries and libraries. If you frequently use a debugger on programs or libraries, it may be helpful to disable this option.<br />
* '''''docs''''' - Save {{ic|/doc}} directories.<br />
* '''''libtool''''' - Leave ''libtool'' ({{ic|.la}}) files in packages.<br />
* '''''emptydirs''''' - Leave empty directories in packages.<br />
* '''''zipman''''' - Compress ''man'' and ''info'' pages with ''gzip''.<br />
* '''''ccache''''' - Allow the use of {{ic|ccache}} during build. More useful in its negative form {{ic|!ccache}} with select packages that have problems building with {{ic|ccache}}.<br />
* '''''distcc''''' - Allow the use of {{ic|distcc}} during build. More useful in its negative form {{ic|!distcc}} with select packages that have problems building with {{ic|distcc}}.<br />
* '''''buildflags''''' - Allow the use of user-specific {{ic|buildflags}} (CFLAGS, CXXFLAGS, LDFLAGS) during build. More useful in its negative form {{ic|!buildflags}} with select packages that have problems building with custom {{ic|buildflags}}.<br />
* '''''makeflags''''' - Allow the use of user-specific {{ic|makeflags}} during build. More useful in its negative form {{ic|!makeflags}} with select packages that have problems building with custom {{ic|makeflags}}.<br />
<br />
=== install ===<br />
The name of the {{ic|.install}} script to be included in the package. pacman has the ability to store and execute a package-specific script when it installs, removes or upgrades a package. The script contains the following functions which run at different times:<br />
<br />
* '''''pre_install''''' - The script is run right before files are extracted. One argument is passed: new package version.<br />
* '''''post_install''''' - The script is run right after files are extracted. One argument is passed: new package version.<br />
* '''''pre_upgrade''''' - The script is run right before files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''post_upgrade''''' - The script is run after files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''pre_remove''''' - The script is run right before files are removed. One argument is passed: old package version.<br />
* '''''post_remove''''' - The script is run right after files are removed. One argument is passed: old package version.<br />
<br />
Each function is run chrooted inside the pacman install directory. See [https://bbs.archlinux.org/viewtopic.php?pid=913891 this thread].<br />
<br />
{{Tip|A prototype {{ic|.install}} is provided at {{ic|/usr/share/pacman/proto.install}}.}}<br />
<br />
=== changelog ===<br />
The name of the package changelog. To view changelogs for installed packages (that have this file):<br />
pacman -Qc ''pkgname''<br />
<br />
{{Tip|A prototype changelog file is provided at {{ic|/usr/share/pacman/ChangeLog.proto}}.}}<br />
<br />
=== source ===<br />
An array of files which are needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables {{ic|pkgname}} and {{ic|pkgver}} can be used effectively here (e.g. {{ic|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})<br />
<br />
{{Note|If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your {{ic|PKGBUILD}} file is in and add the filename to this array. Any paths you add here are resolved relative to the directory where the {{ic|PKGBUILD}} lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and {{ic|makepkg}} will not proceed if any are missing.}}<br />
<br />
{{Tip|You can specify a different name for the downloaded file - if the downloaded file has a different name for some reason like the URL had a GET parameter - using the following syntax: {{Ic|''filename''::''fileuri''}}, for example {{Ic|$pkgname-$pkgver.zip::<nowiki>http://199.91.152.193/7pd0l2tpkidg/jg2e1cynwii/Warez_collection_16.4.exe</nowiki>}}}}<br />
<br />
=== noextract ===<br />
An array of files listed under the {{ic|source}} array which should not be extracted from their archive format by {{ic|makepkg}}. This most commonly applies to certain zip files which cannot be handled by {{ic|/usr/bin/bsdtar}} because {{Pkg|libarchive}} processes all files as streams rather than random access as {{Pkg|unzip}} does. In these situations {{ic|unzip}} should be added in the {{ic|makedepends}} array and the first line of the [[Creating Packages#The build() function|build()]] function should contain:<br />
<br />
cd "$srcdir/$pkgname-$pkgver"<br />
unzip [source].zip<br />
<br />
Note that while the {{ic|source}} array accepts URLs, {{ic|noextract}} is '''just''' the file name portion. So, for example, you would do something like this (simplified from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/grub2&id=f054e33a0b5cbdfe7d81e91a8c4c807a9bfaa124 grub2's PKGBUILD]):<br />
<br />
source=(<nowiki>"http://ftp.archlinux.org/other/grub2/grub2_extras_lua_r20.tar.xz"</nowiki>)<br />
noextract=("grub2_extras_lua_r20.tar.xz")<br />
<br />
To extract ''nothing'', you can do something fancy like this (taken from [https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/firefox-i18n&id=cb10a40aeda9b444285d1ae6959c344110b4c936 firefox-i18n]):<br />
<br />
noextract=(${source[@]##*/})<br />
<br />
{{Note|More conservative Bash substitution would include quotes, or possibly even a loop that calls {{ic|basename}}. If you have read this far, you should get the idea.}}<br />
<br />
=== md5sums ===<br />
An array of MD5 checksums of the files listed in the {{ic|source}} array. Once all files in the {{ic|source}} array are available, an MD5 hash of each file will be automatically generated and compared with the values of this array in the same order they appear in the {{ic|source}} array. While the order of the source files itself does not matter, it is important that it matches the order of this array since {{ic|makepkg}} cannot guess which checksum belongs to what source file. You can generate this array quickly and easily using the command {{ic|makepkg -g}} in the directory that contains the {{ic|PKGBUILD}} file. Note that the MD5 algorithm is known to have weaknesses, so you should consider using a stronger alternative.<br />
<br />
=== sha1sums ===<br />
An array of SHA-1 160-bit checksums. This is an alternative to {{ic|md5sums}} described above, but it is also known to have weaknesses, so you should consider using a stronger alternative. To enable use and generation of these checksums, be sure to set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
<br />
=== sha256sums, sha384sums, sha512sums ===<br />
An array of SHA-2 checksums with digest sizes 256, 384 and 512 bits respectively. These are alternatives to {{ic|md5sums}} described above and are generally believed to be stronger. To enable use and generation of these checksums, be sure to set up the {{ic|INTEGRITY_CHECK}} option in {{ic|/etc/makepkg.conf}}. See {{ic|man makepkg.conf}}.<br />
<br />
== See also ==<br />
*[http://pastebin.com/MeXiLDV9 Example PKGBUILD file]<br />
*[http://seberm.pastebin.com/gP0tBqvs Example .install file]</div>SpepShttps://wiki.archlinux.org/index.php?title=Package_Maintainers&diff=200797Package Maintainers2012-05-08T22:50:05Z<p>SpepS: Adding myself to the TU list</p>
<hr />
<div>[[Category:Arch development]]<br />
{{i18n|Trusted Users}}<br />
[[fr:TU]]<br />
The '''Trusted Users''' serve the following purposes:<br />
# Maintain {{Ic|[community]}} as an intermediary between Arch Linux's [[Official Repositories]] and the unsupported package collection in the [[AUR]].<br />
# Maintain, manage, and watch over the operation of the [[AUR]].<br />
<br />
== How to become TU? ==<br />
The ''minimum'' requirements to becoming a TU are as follows:<br />
* know basic shell scripting<br />
* maintain a few packages in AUR with clean, high-quality PKGBUILDs<br />
* basic community involvement (mailing list, forums, IRC)<br />
* know Google-Fu<br />
* a general idea of the kind of packages you want to maintain (basically, why do you want to become TU?)<br />
<br />
<br />
Even though you could become a TU by merely fulfilling those minimum requirements, the people judging you [https://aur.archlinux.org/trusted-user/TUbylaws.html#SVP during voting] might expect more of you. Such as:<br />
* involvement in the bug tracker (reporting, research, info)<br />
* patches for Arch projects<br />
* involvement in a few open-source projects (even if they are your own)<br />
<br />
<br />
In case you still feel up to becoming TU after reading these lists, you should find another TU to sponsor you and write a witty application signed with your GPG key to the aur-general mailing list.<br />
<br />
For more information, please see [https://aur.archlinux.org/trusted-user/TUbylaws.html Trusted User Bylaws] and [[AUR Trusted User Guidelines]].<br />
<br />
== Active Trusted Users ==<br />
{|<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?SeB=m&K=Atsutane Atsutane] ||Thorsten Töpper||atsutane {0x40} freethoughts {0x2E} de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Barthalion&SeB=m Barthalion] ||Bartłomiej Piotrowski||barthalion@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?SeB=m&K=BlackIkeEagle BlackIkeEagle]||[[User:BlackEagle|Ike Devolder]]||ike DOT devolder AT gmail DOT com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=bluewind&SeB=m Bluewind]||Florian Pritz || bluewind@xinu.at<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=cmb&SeB=m cmb]||Chris Brannon||cmbrannon79 at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=City-busz&SeB=m City-busz]||György Balló||ballogyor+arch at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?SeB=m&K=ConnorBehan ConnorBehan]||Connor Behan||connor.behan@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=cryptocrack&SeB=m cryptocrack]||Lukas Fleischer||archlinux at cryptocrack dot de<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Daenyth&SeB=m Daenyth]||Daenyth Blank||Daenyth+Arch gmail com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Dragonlord&SeB=m Dragonlord]||[[User:Dragonlord|Jaroslav Lichtblau]]||tu dragonlord cz<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=falconindy&SeB=m falconindy]||Dave Reisner||d[at]falconindy[dot]com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=foutrelis&SeB=m foutrelis]||Evangelos Foutras||evangelos@foutrelis.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=heftig&SeB=m heftig]||Jan Steffens||jan.steffens@student.kit.edu<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=jelly&SeB=m jelly]||Jelle van der Waa || jelle vdwaa nl<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=kaitocracy&SeB=m kaitocracy]||[[User:kaitocracy|Kaiting Chen]]||kaitocracy@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=lordheavy&SeB=m Lordheavy]||[[User:Lordheavy|Laurent Carlier]]||lordheavym at gmail com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=mtorromeo&SeB=m mtorromeo]||Massimiliano Torromeo||massimiliano.torromeo@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=ornitorrincos&SeB=m ornitorrincos]||Imanol Celaya||ilcra1989@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=Partition&SeB=m Partition]||Mateusz Herych||heniekk at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=petelewis&SeB=m petelewis]||Peter Lewis||plewis at aur dot archlinux dot org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=PirateJonno&SeB=m PirateJonno]||Jonathan Conder||jonno dot conder at gmail dot com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=pressh&SeB=m pressh]||Ronald van Haren||ronald.archlinux.org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schivmeister&SeB=m schivmeister]||[[User:Schivmeister|Ray Rashif]]||schiv archlinux org<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=schuay&SeB=m schuay]||Jakob Gruber||jakob.gruber@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=seblu&SeB=m seblu]||Sébastien Luttringer||s e b l u '''+''' a r c h # s e b lu ''dot'' n e t<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=sergej&SeB=m sergej]||Sergej Pupykin||pupykins@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=speps&SeB=m speps]||SpepS||dreamspepser at yahoo dot it<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=stativ&SeB=m stativ]||Lukas Jirkovsky||l.jirkovsky strange_curved_character gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=svenstaro&SeB=m svenstaro]||[[User:svenstaro|Sven-Hendrik Haase]]||sh@lutzhaase.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=td123&SeB=m td123]||Thomas Dziedzic||gostrc at gmail<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=tredaelli&SeB=m tredaelli]||Timothy Redaelli||timothy.redaelli@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=vegai&SeB=m vegai]||Vesa Kaihlavirta||vpkaihla@gmail.com<br />
|-<br />
|[https://aur.archlinux.org/packages.php?SeB=m&K=Xyne Xyne]||<--||ca . archlinux @ xyne, in reverse order<br />
|-<br />
|[https://aur.archlinux.org/packages.php?SeB=m&K=trontonic&O=0&PP=100&SB=v&SO=d xyproto]||Alexander Rødseth||rodseth@gmail.com<br />
|}<br />
<br />
== Inactive Trusted Users ==<br />
{|<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|style="font-weight: bold;"|E-Mail<br />
|style="font-weight: bold;"|Comments/Reference<br />
|-<br />
|<br />
|-<br />
|}<br />
<br />
== Some Past Trusted Users ==<br />
{|<br />
|- style="border-bottom:solid 2px"<br />
|style="font-weight: bold;padding-right:120px"|Nick<br />
|style="font-weight: bold;padding-right:200px"|Name<br />
|-<br />
|abhidg||Abhishek Dasgupta<br />
|-<br />
|Allan||Allan McRae<br />
|-<br />
|anders||Anders Bergh<br />
|-<br />
|angvp||[[User:Angvp|Angel Velásquez]]<br />
|-<br />
|bardo||Corrado Primier<br />
|-<br />
|bash||Andrea Scarpino<br />
|-<br />
|bfinch||Bob Finch<br />
|-<br />
|brain0||Thomas Bächler<br />
|-<br />
|bjorn||[[User:Bjørn|Bjørn Lindeijer]]<br />
|-<br />
|codemac||Jeff Mickey<br />
|-<br />
|DaNiMoTh||JJ. DaNiMoTh<br />
|-<br />
|dejari||Leslie P. Polzer<br />
|-<br />
|dsa||Douglas Soares de Andrade<br />
|-<br />
|dtw||Phil Dillon-Thiselton<br />
|-<br />
|elasticdog||Aaron Bull Schaefer<br />
|-<br />
|encelo||Angelo Theodorou<br />
|-<br />
|even ||Kessia Pinheiro<br />
|-<br />
|filoktetes||Robert Emil Berge<br />
|-<br />
|firmicus||François Charette<br />
|-<br />
|ganja_guru||Varun Acharya<br />
|-<br />
|gcarrier||Geoffroy Carrier<br />
|-<br />
|Ghost1227||Dan Griffiths<br />
|-<br />
|gummibaerchen||Timm Preetz<br />
|-<br />
|hdoria||Hugo Doria<br />
|-<br />
|iphitus||James Rayner<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=itsbrad212&SeB=m itsbrad212]||Brad Fanella<br />
|-<br />
|louipc||Loui Chang<br />
|-<br />
|mOLOk||Alessio Bolognino<br />
|-<br />
|nesl247||Alex Heck<br />
|-<br />
|Neverth||Mikko Seppälä<br />
|-<br />
|phrakture||Aaron Griffin<br />
|-<br />
|Pierre||Pierre Schmitz<br />
|-<br />
|pizzapunk||Alexander Fehr<br />
|-<br />
|pjmattal||Paul Mattal<br />
|-<br />
|Ranguvar||Devin Cofer<br />
|-<br />
|Romashka||Roman Kyrylych<br />
|-<br />
|shastry||Vinay S Shastry<br />
|-<br />
|Snowman||Eric Bélanger<br />
|-<br />
|shinlun||Shinlun Hsieh<br />
|-<br />
|[https://aur.archlinux.org/packages.php?K=StefanHusmann&SeB=m StefanHusmann]||Stefan Husmann<br />
|-<br />
|STiAT||Georg Grabler<br />
|-<br />
|swiergot||Jaroslaw Swierczynski<br />
|-<br />
|tardo||Shehzad Qureshi<br />
|-<br />
|thotypous||Paulo Matias<br />
|-<br />
|voidnull||Giovanni Scafora<br />
|-<br />
|wizzomafizzo||Callan Barrett<br />
|-<br />
|wonder || Ionut Biru<br />
|-<br />
|Xilon||Sebastian Nowicki<br />
|-<br />
|xterminus||Charles Mauch<br />
|-<br />
|zeus||Zhukov Pavel<br />
|}<br />
<br />
==See also==<br />
*[http://www.archlinux.org/trustedusers/ Trusted Users profiles]</div>SpepS