https://wiki.archlinux.org/api.php?action=feedcontributions&user=Phrakture&feedformat=atom
ArchWiki - User contributions [en]
2024-03-19T05:57:56Z
User contributions
MediaWiki 1.41.0
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Roll_Call&diff=95944
DeveloperWiki:Roll Call
2010-02-10T19:41:33Z
<p>Phrakture: </p>
<hr />
<div>This is a list of developers and what they work on:<br />
<br />
<br />
'''Allan McRae'''<br />
* toolchain + related packages<br />
* a lot more from core<br />
* python<br />
* SDL<br />
* a bunch of other crap<br />
* makepkg<br />
<br />
'''Jan de Groot'''<br />
* Xorg + official drivers + mesa<br />
* GNOME<br />
* GStreamer<br />
* Xulrunner + Firefox<br />
<br />
'''Daniel Isenmann'''<br />
* complete MONO stack<br />
* monodevelop<br />
* windowmaker<br />
* 3 or 4 more smaller packages<br />
<br />
'''Vesa Kaihlavirta'''<br />
* Haskell <br />
* Erlang<br />
* 5ish small packages<br />
* Willing to take openjdk amongst other things. <br />
<br />
'''Giovanni Scafora'''<br />
* abiword + related packages<br />
* mythtv + related packages<br />
* VLC + related packages<br />
* k9copy/dvdrip/dvdauthor<br />
* some packages that cannot be grouped<br />
* pacman translations<br />
* AUR Italian translation<br />
<br />
'''François Charette'''<br />
* TeX Live<br />
* Perl<br />
<br />
'''Ionuț MirceaB'''<br />
* Telepathy framework + related packages<br />
* Empathy/gajim/pidgin(+some plugins)<br />
* x264/ffmpeg/mplayer/smpalyer<br />
* networkmanager plugins<br />
* deluge + related packages<br />
* lib32 packages<br />
* some packages that cannot be grouped<br />
<br />
'''Ronald van Haren'''<br />
* Scientific related packages<br />
* koffice and other kde related packages<br />
* quite a few packages that can't be grouped<br />
* networkmanager plugins<br />
* some backend coding for a build service but seems D.Griffith is now ahead for me<br />
<br />
'''Andrea Scarpino'''<br />
* KDE core<br />
* KDE applications<br />
* MySQL<br />
* Bluetooth stuff<br />
* BBS maintainer<br />
* AUR development<br />
<br />
'''Paul Mattal'''<br />
* postgres, postfix, spamassassin, cron, etc.<br />
* bug fixing / un-sticking<br />
* archweb (if I manage to find more time after the first two to help Dan)<br />
<br />
'''Dale Blount'''<br />
* Physical server maintenance<br />
* Would like to help with the "tiered mirroring" design and setup.<br />
* Not much else lately, haven't had a bunch of time.<br />
<br />
'''Daniel J Griffiths'''<br />
* Openbox<br />
* Chromium<br />
* General cleanup of repos/bugtrackers<br />
* I will continue patching away at dbscripts and the such as needed.<br />
* I will also take on other packages that need a home as the are made available.<br />
<br />
'''Aaron Griffin'''<br />
(Take this all with a grain of salt, as my freetime is rare as hell right now)<br />
* dbscripts/devtools<br />
* bash and related (though Allan has been doing most of it)<br />
* releases and archiso<br />
* external contact (press, legal, etc)<br />
* donations<br />
<br />
People on the [http://www.archlinux.org/developers/ developers] page that have not filled this out yet:<br />
*AndreasR<br />
*DanM<br />
*DieterP<br />
*EricB<br />
*GeoffroyC<br />
*HugoD<br />
*JamesR<br />
*JürgenH<br />
*KevinP<br />
*PierreS<br />
*RomanK<br />
*ThayerW<br />
*ThomasB<br />
*TobiasK<br />
*TobiasP</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Roll_Call&diff=95943
DeveloperWiki:Roll Call
2010-02-10T19:40:57Z
<p>Phrakture: </p>
<hr />
<div>This is a list of developers and what they work on:<br />
<br />
<br />
'''Allan McRae'''<br />
* toolchain + related packages<br />
* a lot more from core<br />
* python<br />
* SDL<br />
* a bunch of other crap<br />
* makepkg<br />
<br />
'''Jan de Groot'''<br />
* Xorg + official drivers + mesa<br />
* GNOME<br />
* GStreamer<br />
* Xulrunner + Firefox<br />
<br />
'''Daniel Isenmann'''<br />
* complete MONO stack<br />
* monodevelop<br />
* windowmaker<br />
* 3 or 4 more smaller packages<br />
<br />
'''Vesa Kaihlavirta'''<br />
* Haskell <br />
* Erlang<br />
* 5ish small packages<br />
* Willing to take openjdk amongst other things. <br />
<br />
'''Giovanni Scafora'''<br />
* abiword + related packages<br />
* mythtv + related packages<br />
* VLC + related packages<br />
* k9copy/dvdrip/dvdauthor<br />
* some packages that cannot be grouped<br />
* pacman translations<br />
* AUR Italian translation<br />
<br />
'''François Charette'''<br />
* TeX Live<br />
* Perl<br />
<br />
'''Ionuț MirceaB'''<br />
* Telepathy framework + related packages<br />
* Empathy/gajim/pidgin(+some plugins)<br />
* x264/ffmpeg/mplayer/smpalyer<br />
* networkmanager plugins<br />
* deluge + related packages<br />
* lib32 packages<br />
* some packages that cannot be grouped<br />
<br />
'''Ronald van Haren'''<br />
* Scientific related packages<br />
* koffice and other kde related packages<br />
* quite a few packages that can't be grouped<br />
* networkmanager plugins<br />
* some backend coding for a build service but seems D.Griffith is now ahead for me<br />
<br />
'''Andrea Scarpino'''<br />
* KDE core<br />
* KDE applications<br />
* MySQL<br />
* Bluetooth stuff<br />
* BBS maintainer<br />
* AUR development<br />
<br />
'''Paul Mattal'''<br />
* postgres, postfix, spamassassin, cron, etc.<br />
* bug fixing / un-sticking<br />
* archweb (if I manage to find more time after the first two to help Dan)<br />
<br />
'''Dale Blount'''<br />
* Physical server maintenance<br />
* Would like to help with the "tiered mirroring" design and setup.<br />
* Not much else lately, haven't had a bunch of time.<br />
<br />
'''Daniel J Griffiths'''<br />
* Openbox<br />
* Chromium<br />
* General cleanup of repos/bugtrackers<br />
* I will continue patching away at dbscripts and the such as needed.<br />
* I will also take on other packages that need a home as the are made available.<br />
<br />
'''Aaron Griffin'''<br />
(Take this all with a grain of salt, as my freetime is rare as hell right now)<br />
* dbscripts/devtools<br />
* releases and archiso<br />
* external contact (press, legal, etc)<br />
* donations<br />
<br />
People on the [http://www.archlinux.org/developers/ developers] page that have not filled this out yet:<br />
*AndreasR<br />
*DanM<br />
*DieterP<br />
*EricB<br />
*GeoffroyC<br />
*HugoD<br />
*JamesR<br />
*JürgenH<br />
*KevinP<br />
*PierreS<br />
*RomanK<br />
*ThayerW<br />
*ThomasB<br />
*TobiasK<br />
*TobiasP</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=95715
DeveloperWiki:Developer Checklist
2010-02-09T18:28:33Z
<p>Phrakture: /* For the new developer */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
** Delete the user's password (passwd -d)<br />
** Upload the user's public ssh key<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums <br />
* upgrade to a "Administrator" on the wiki: [[Special:Userrights]]<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group<br />
* The core repo is typically disabled for newer developers. This is just a safeguard. If you feel, at some point in the future, that you'd make a good maintainer of a given core package, send an email to the arch-dev mailing list requesting access</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=95714
DeveloperWiki:Developer Checklist
2010-02-09T18:21:05Z
<p>Phrakture: </p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
** Delete the user's password (passwd -d)<br />
** Upload the user's public ssh key<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums <br />
* upgrade to a "Administrator" on the wiki: [[Special:Userrights]]<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Server_configuration&diff=81595
DeveloperWiki:Server configuration
2009-11-02T20:06:15Z
<p>Phrakture: /* gudrun.archlinux.org */</p>
<hr />
<div>This page provides an overview of the Arch servers and their functions. Details can be found in the respective links for each server. We currently have two phyical server machines:<br />
<br />
== Main development server (formerly gerolde) ==<br />
<br />
This is a Dual-Xeon 2.8GHz server with 16GB of memory and a 2x300GB software RAID 1 array. It has been bought with Arch donation money and is currently located at velocity, who also donate the power and bandwidth. It runs a Xen hypervisor with the following hosts:<br />
<br />
=== [[DeveloperWiki:Dom0|dom0.archlinux.org]] ===<br />
<br />
This is the Xen dom0 for the development server. It runs a Debian system with the Debian Xen kernel, as Arch does not maintain a stable Xen kernel. It has no public services. ssh access is limited to a small number of IP addresses and only Thomas, Aaron, Jan and Dale have access to it.<br />
<br />
It bridges the physical ethernet interface with the virtual interfaces of the Xen domU instances and runs an IP-based [[DeveloperWiki:Dom0#firewall|firewall]].<br />
<br />
=== [[DeveloperWiki:Gerolde (dev)|gerolde.archlinux.org]] ===<br />
<br />
This is the main development server. It runs Arch Linux with a modified kernel26 package with pv_ops/Xen support added.<br />
<br />
DNS aliases: rsync.archlinux.org, archlinux.org, mail.archlinux.org<br />
<br />
It offers the following public services:<br />
* ''ssh''(openssh): All developers have ssh access to this machine.<br />
* ''rsync''(rsyncd): Public mirrors (whitelisted by IP address) can synchronize the FTP directory. Anyone can synchronize the ABS tree.<br />
* ''smtp''(postfix): SMTP server for the @archlinux.org and @aur.archlinux.org domains<br />
* ''http''(lighttpd): All developers have direct access to the FTP directory via HTTP (static content only) - this is password-protected, users must use the mirrors.<br />
<br />
Developers use this server to maintain the package repositories, the corresponding ''packages'' subversion repository and access the git repositories for their various arch-related projects.<br />
<br />
=== [[DeveloperWiki:Gudrun (web)|gudrun.archlinux.org]] ===<br />
<br />
This is the main web server. It runs Arch Linux with a modified kernel26 package with pv_ops/Xen support added. Only developers who maintain web applications have ssh access. The ssh port is only open to gerolde.<br />
<br />
DNS aliases: bbs.archlinux.org, dev.archlinux.org, mailman.archlinux.org, planet.archlinux.org, projects.archlinux.org, repos.archlinux.org, svn.archlinux.org, wiki.archlinux.org, bugs.archlinux.org<br />
<br />
It offers the following public services:<br />
* ''http''(apache): Hosts the following websites:<br />
** www.archlinux.org: Main Arch website - uses python/django and a few static html pages<br />
** dev.archlinux.org: Developer and Trusted User access to the main website - uses python/django, as well as developer public html directories<br />
** mailman.archlinux.org: Mailing list configuration, subscription and archives - uses mailman<br />
** bbs.archlinux.org: Forums - uses fluxbb(php)<br />
** wiki.archlinux.org: Arch Wiki - uses mediawiki(php)<br />
** projects.archlinux.org: Access to the git repositories - uses cgit<br />
** planet.archlinux.org: Feeds from Arch-related blogs - uses static html pages<br />
** repos.archlinux.org: Access to the ''packages'' and ''community'' subversion repositories - uses websvn<br />
** bugs.archlinux.org: Bugtracker - uses flyspray(php)<br />
* ''svn''(xinetd/svnserve): Public subversion access<br />
* ''git''(xinetd/git-daemon): Public git access<br />
<br />
=== Resource Allocation ===<br />
Because this box is servicing multiple VMs, the resources allocated to each are not static. Here is how the box is currently divided up:<br />
<br />
* dom0: 512 MB RAM, 4 CPUs, 4GB disk<br />
* gerolde: 9493 MB RAM, 4 CPUs, 193 GB disk<br />
* gudrun: 6145 MB RAM, 4 CPUs, 30 GB disk<br />
<br />
== Trusted User server (sigurd) ==<br />
<br />
This is a Pentium D dual core 3.40GHz server with 4GB of memory and a 2x160GB software RAID 1 array. The machine is being donated by SevenL networks. It runs Arch Linux.<br />
<br />
=== [[DeveloperWiki:Sigurd (TU)|sigurd.archlinux.org]] ===<br />
<br />
This is the trusted user development server. All trusted users have access.<br />
<br />
DNS aliases: aur.archlinux.org, build.archlinux.org, community.archlinux.org, tracker.archlinux.org<br />
<br />
It offers the following public services:<br />
* ''ssh''(openssh): All trusted users have ssh access to this machine.<br />
* ''http''(lighttpd): Hosts the following websites:<br />
** aur.archlinux.org: The AUR - uses php<br />
** build.archlinux.org: test ISOs and aif packages, only static content<br />
** community.archlinux.org: apparently nothing<br />
* ''bit torrent''(opentracker): Bit Torrent tracker for the Arch Linux ISO images<br />
<br />
== Other servers ==<br />
<br />
We can always use more of course for our world domination plans! Right now our infrastructure is mostly contained to the above-mentioned servers, but there are a few specialty things running elsewhere.<br />
<br />
=== stats.archlinux.org ===<br />
<br />
This server is hosted on [[User:Toofishes|Dan's]] slice. It runs an instance of munin, which collects various stats from the three main servers (gerolde, gudrun. sigurd) in the archlinux.org domain. If you need access to any of this information and are a developer, get in contact with someone that does [[DeveloperWiki:Internal Projects#Server Administration|server administration]].</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Adopting_Packages&diff=80879
DeveloperWiki:Adopting Packages
2009-10-28T18:47:34Z
<p>Phrakture: </p>
<hr />
<div>= Introduction =<br />
This document outlines the process for Arch Linux package maintainers to add new packages to the official repositories. This article is part of the [[DeveloperWiki]].<br />
<br />
= Quick Instructions =<br />
<br />
'''TODO:''' Rewrite this section with steps for adding new packages to svn<br />
<br />
= The BIG Picture =<br />
<br />
Generally speaking, new packages are submitted by Archlinux end users to the AUR's [unsupported] collection on http://aur.archlinux.org/. From there, one of the [[Trusted Users]] will take the package, test the PKGBUILD locally, fix any errors and make sure it conforms to AL package guidelines. When the TU has finished testing it, they will place the package in the [community] repo at ftp://ftp.archlinux.org/community/<br />
<br />
When the package has been placed in the [community] repo, AL users have access to the package via [[pacman]] (assuming the user hasn't disabled the [community] repo in '''/etc/pacman.conf'''). Once the package has lived bug-free in the [community] repo for a while, an AL package maintainer can elect to adopt the package and follow the procedure outlined above.<br />
<br />
Trusted Users are selected users within the AL user community that show sound Linux knowledge and the ability to produce solid PKGBUILDs. The [community] repo is not officially supported by AL developers or package maintainers. The TUs are fully responsible for the packages found within it. It is not until a package is adopted into the official AL repos that the AL team becomes responsible for the package.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Python_package_guidelines&diff=79511
Python package guidelines
2009-10-19T20:10:06Z
<p>Phrakture: </p>
<hr />
<div>{{stub}}<br />
[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
<br />
==Package Naming==<br />
For libraries, use ''python-modulename''. For applications, use the program name. In either case, the pkgname should be entirely lowercase.<br />
<br />
==Examples==<br />
Most python packages are installed using the ''distutils'' system using ''setup.py''. An example PKGBUILD is shown below<br />
<br />
<pre><br />
# Contributor: Your Name <youremail@domain.com><br />
<br />
pkgname=python-foo<br />
pkgver=VERSION<br />
pkgrel=1<br />
pkgdesc=""<br />
arch=(any)<br />
url=""<br />
license=()<br />
depends=('python')<br />
makedepends=()<br />
provides=()<br />
conflicts=()<br />
replaces=()<br />
backup=()<br />
options=(!emptydirs)<br />
install=<br />
<br />
build() {<br />
cd $srcdir/$pkgname-$pkgver<br />
python setup.py install --root=$pkgdir/ --optimize=1 || return 1<br />
<br />
# Remember to install licenses if the license is not a common license!<br />
# install -D -m644 $srcdir/LICENSE $pkgdir/usr/share/licenses/$pkgname/LICENSE<br />
}<br />
<br />
</pre><br />
<br />
'''NOTE''': The --optimize parameter compiles .pyo files so they can be tracked by pacman<br />
<br />
In most cases, you should put '''any''' in the ''arch'' array since most Python packages are architecture independent.<br />
<br />
==Automation==<br />
-</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=77859
Package Maintainer guidelines
2009-10-15T16:47:01Z
<p>Phrakture: /* TODO list for new Trusted Users */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
[[Category:AUR]]<br />
[[Category:Guidelines (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Explains Arch User Repository's Trusted Users.}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n_entry|English|AUR Trusted User Guidelines}}<br />
{{i18n_entry|简体中文|AUR Trusted User 导引}}<br />
{{i18n_entry|Español|TU (Trusted User) (Español)}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|AUR Q & A}}<br />
{{Article summary wiki|AUR User Guidelines}}<br />
{{Article summary wiki|AUR}}<br />
{{Article summary end}}<br />
<br />
=The Trusted User (TU)=<br />
The '''Trusted User (TU)''' is a member of the community charged with<br />
keeping the AUR in working order. He/she maintains popular packages, and<br />
votes in administrative matters. A TU is elected from active community<br />
members by current TUs in a democratic process. TUs are the only<br />
members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [http://aur.archlinux.org/trusted-user/TUbylaws.html TU bylaws]<br />
<br />
==TU Duties==<br />
<br />
===TODO list for new Trusted Users===<br />
* Install the ''devtools'' package.<br />
* Send your ssh public key to Loui Chang. If you don't have one, use ''ssh-keygen'' to generate. You can check the [[Using SSH Keys]] wiki page for more information about creating ssh keys and setting up an ssh-agent to use them.<br />
* Make the directory ''staging/community'' within your home directory on aur.archlinux.org. This step is '''important''' as the devtools scripts use this directory to process incoming packages.<br />
* Remind Allan to change your account on forums<br />
* Make sure your sponsor has given you TU status on the AUR<br />
* Ask some TU for the #archlinux-tu@freenode key<br />
* Add yourself to the [http://wiki.archlinux.org/index.php/Trusted_Users Trusted Users] page<br />
* Read the [http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines Trusted User Guidelines].<br />
* If you are not upgraded to a Trusted User group on bugtracker in two days, report this as a bug to Roman<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 />
Any packages to be added to the [community] repo must meet the guidelines listed on [[Rules Governing the Community Repo|this]] page.<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 http://aur.archlinux.org instead of http://archlinux.org. Thus most of the instructions in [http://wiki.archlinux.org/index.php/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/><br />
<code>svn checkout -N svn+ssh://aur.archlinux.org/srv/svn-packages</code><br />
<br />
This creates a directory named "svn-packages" which contains nothing.<br />
It does, however, know that it is an svn checkout. <br />
<br />
For '''checking''' out, '''updating''' all packages or '''adding''' a package see the<br />
[http://wiki.archlinux.org/index.php/DeveloperWiki:HOWTO_Be_A_Packager Packager Guide].<br />
<br />
To '''remove''' a package<br/><br />
<code>ssh aur.archlinux.org /arch/db-remove community pkgname arch</code><br />
<br />
Here and in the following text, arch can be one of i686 or x86_64<br />
which are the two architectures supported by Arch Linux.<br />
<br />
When you're done with editing the PKGBUILD, etc, you should '''commit''' the changes<br />
(<code>svn commit</code>).<br/>When you want to '''release''' a package, first<br />
copy the package to the ''staging/community'' directory on aur.archlinux.org using scp<br />
and then '''tag''' the package by going to the ''pkgname/trunk'' directory<br />
and issuing <code>archrelease community-arch</code>.<br />
<br />
This makes an svn copy of the trunk entries in a directory named ''community-i686''<br />
or ''community-x86_64'' indicating that this package is in the community repository for that architecture.<br />
<br />
<i>'''Note:''' In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1<br />
(and not +1). This indicates that the <strong> change to the PKGBUILD is x86_64 specific </strong> and<br />
i686 maintainers <strong> should not </strong> rebuild the package for i686. When the TU decides to bump<br />
the pkgrel , it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must<br />
not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.)<br />
releases exclusive to the x86_64 TU's to avoid confusion.</i><br />
<br />
Thus the '''process''' of updating a package can be summarised as<br />
<br />
* '''Update''' the package directory (<code>svn update some-package</code>)<br />
* '''Change''' to the package trunk directory (<code>cd some-package/trunk</code>)<br />
* '''Edit''' the PKGBUILD, make necessary changes and <code>makepkg</code>. It is recommended to build in a clean [http://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_Clean_Chroot chroot].<br />
* '''[[Namcap]]''' the PKGBUILD and the binary pkg.tar.gz.<br />
* '''Commit''' the changes to trunk (<code>svn commit</code>)<br />
* '''Copy''' the package to aur.archlinux.org (<code>scp pkgname-ver-rel-arch.pkg.tar.gz aur.archlinux.org:staging/community/</code>)<br />
* '''Tag''' the package (<code>archrelease community-{i686,x86_64}</code>)<br />
* '''Update''' the repository (<code>ssh aur.archlinux.org /arch/db-community{,64}</code>)<br />
<br />
Also see the ''Miscellaneous'' section in the [http://wiki.archlinux.org/index.php/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 can't or doesn't want to maintain a package any longer, a<br />
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<br />
to maintain it, but the TUs should try not to drop many packages (they<br />
shouldn't take on more than they have time for). If a package has<br />
become obsolete or isn't used any longer, it can be removed completely<br />
as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again<br />
(fresh) to UNSUPPORTED, where a regular user can maintain the package<br />
instead of the TU.<br />
<br />
==== Deleting packages from unsupported ====<br />
There's no point in removing dummy packages, because they will be<br />
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 />
For an example of a dummy package see:<br />
http://aur.archlinux.org/packages.php?ID=23600<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.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Internal_Projects&diff=76282
DeveloperWiki:Internal Projects
2009-09-22T20:29:08Z
<p>Phrakture: /* TODO Items */</p>
<hr />
<div>= Introduction = <br />
This article is part of the [[DeveloperWiki]].<br />
<br />
This page is meant to list a lot of the projects Arch developers keep busy with. Yes, there are things to do outside of packaging. If you are interested in anything, this page should help you get in contact with the right people. If you are looking for something to do, this is always a good place to start.<br />
<br />
Some of these projects have dedicated discussion areas, such as the release engineering and pacman development mailing lists. Other ones are less formal- some of the communication may just be person to person emails or on the arch-dev lists if it appeals to a larger crowd. Remember that if you are interested in these less-formal projects, you should let the names listed below know so they will include you on any communication regarding the project.<br />
<br />
= Infrastructure Projects =<br />
<br />
== Developer Tooling ==<br />
Primarily developer-side tools (devtools, namcap) and server-side (db-scripts) work.<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:Snowman|Eric Bélanger]]<br />
* [[User:Firmicus|François Charette]]<br />
<br />
=== TODO Items ===<br />
<br />
* dbscripts: Rewrite db-move to allow multiple packages, getting rid of the testing2* convienence scripts<br />
* dbscripts: Add community repo support to db-move to let us move packages from community to core/extra and vice versa.<br />
* dbscripts: Add community support to the sourceballs script - needs additional logic to use alternate SVN repos<br />
<br />
== Mirror Control ==<br />
Keep track of existing mirrors and ensure they are doing their job as good as possible (e.g. staying current). Ensure we have up to date contact information for as many mirrors as possible. Work on a tiered mirror system to relieve some stress from our primary rsync server.<br />
* [[User:Romashka|Roman Kyrylych]]<br />
=== Automated tests ===<br />
* sync state: http://users.archlinux.de/~gerbra/mirrorcheck.html<br />
* additional performance tests: http://www.archlinux.de/?page=MirrorStatus<br />
* [[User:Gerbra|Gerhard Brauer]]<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== Packaging Automation ==<br />
Automatic package generation based on changes in svn trunk. Errors should be reported to some mailing list, successful builds moved to a staging directory. Some guidelines of package moving into [extra]/[testing] should be created, for [core] we can use the current signoff procedure. <br />
* [[User:pressh|Ronald van Haren]]<br />
<br />
== Server Administration ==<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:JGC|Jan de Groot]]<br />
* [[User:Toofishes|Dan McGee]]<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== Developer Communication Team ==<br />
This isn't quite infrastructure, but it almost belongs here. Responsible for organizing developer meetings and making sure people attempt to be present; you newer guys might have no idea, but we used to actually schedule and have 80% of the developer staff present in IRC for 1-2 hour meetings. Responsible for any other coordination between developers, TUs, and maybe even the front page news.<br />
* TBA<br />
<br />
= Packaging Projects =<br />
<br />
== Bug Squashing ==<br />
Responsible for assigning bugs to package maintainers. If something is trivial and a fix can be easily made, then goes and does it. Organizes bug squashing days.<br />
* Andrea Scarpino<br />
* [[User:pjmattal|Paul Mattal]]<br />
* ...<br />
* (needs several people)<br />
<br />
== Rebuild Team ==<br />
Responsible for communicating and determining what rebuilds will cycle through [testing] and in what order. They are probably also the people doing large portions of the rebuilds.<br />
* [[User:Allan|Allan McRae]] (because my packages seem to cause big rebuilds...)<br />
* (more)<br />
<br />
== Package Review Team ==<br />
Some packages in our repos receive little attention due to not being updated frequently. These need to be checked for being able to build (especially after major toolchain updates) and compliance with current packaging standards. It would be good for packages that have not been rebuilt in a long time to be rebuilt to take advantage of new optimisations.<br />
* TODO fill me out please<br />
<br />
== Orphan Team ==<br />
Responsible for caring for those packages that no one seems to want and are being neglected. This may involve adoption by themselves or finding a foster caregiver, moving them to a willing maintainer in [community], or sending them to the AUR (or the trash).<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
= Web Projects =<br />
<br />
This is meant to be a quick overview of the web projects we have and who works on them. For more technical details, you will want to check out the [[DeveloperWiki:Gudrun (web)]] and [[:Category:DeveloperWiki:Server Configuration]] pages.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== AUR ==<br />
Responsible for coding and deploying the AUR.<br />
* [[User:Louipc|Loui Chang]]<br />
<br />
== BBS ==<br />
Responsible for keeping our BBS install up to date and secure.<br />
* Andrea Scarpino<br />
<br />
== Flyspray (bugtracker) ==<br />
Responsible for keeping our flyspray install up to date and secure.<br />
* TBA?<br />
<br />
== Main Site ==<br />
* [[User:Dusty|Dusty Phillips]]<br />
<br />
== Planet ==<br />
Responsible for keeping the planet scripts updated and running.<br />
* Andrea Scarpino<br />
<br />
== Wiki ==<br />
Responsible for keeping our wiki install up to date and secure.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
= Coding Projects =<br />
<br />
== Arch Linux Init Scripts ==<br />
The all-important scripts that make your machine go when you turn it on<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Arch Linux Release Engineering (Installer) ==<br />
The Arch Linux Install Framework (AIF) and official installation ISOs<br />
* [[User:Dieter_be|Dieter Plaetinck]]<br />
* [[User:Gerbra|Gerhard Brauer]]<br />
<br />
== mkinitcpio ==<br />
We have a program to create initrds for Arch systems.<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Pacman ==<br />
<br />
=== Development Team ===<br />
This team is responsible for general development, including new features and bugfixes, for the package manager that is a core part of Arch. Although many people contribute patches and code, the people listed here are generally the people that will be reviewing patches and making the final say as to what gets in the codebase.<br />
<br />
* [[User:Toofishes|Dan McGee]]<br />
* Xavier Chantry<br />
* Nagy Gabor<br />
* [[User:Allan|Allan McRae]] (focusing on makepkg)<br />
<br />
=== Translation Team ===<br />
Pacman, as of September 2009, has been translated to 15 languages. The upkeep and maintenance of these translations is pretty much a job in itself, with the times immediately preceding a release being the busiest. Ideally this team is responsible for creating a translations branch when a string freeze is set, and then takes incoming translations, ensures they are valid, and merges them into their branch. When a release is not imminent, their focus may be on improving clarity and usefulness of existing messages.<br />
* [[User:Voidnull|Giovanni Scafora]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Internal_Projects&diff=76277
DeveloperWiki:Internal Projects
2009-09-22T17:32:40Z
<p>Phrakture: /* Developer Tooling */</p>
<hr />
<div>= Introduction = <br />
This article is part of the [[DeveloperWiki]].<br />
<br />
This page is meant to list a lot of the projects Arch developers keep busy with. Yes, there are things to do outside of packaging. If you are interested in anything, this page should help you get in contact with the right people. If you are looking for something to do, this is always a good place to start.<br />
<br />
Some of these projects have dedicated discussion areas, such as the release engineering and pacman development mailing lists. Other ones are less formal- some of the communication may just be person to person emails or on the arch-dev lists if it appeals to a larger crowd. Remember that if you are interested in these less-formal projects, you should let the names listed below know so they will include you on any communication regarding the project.<br />
<br />
= Infrastructure Projects =<br />
<br />
== Developer Tooling ==<br />
Primarily developer-side tools (devtools, namcap) and server-side (db-scripts) work.<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:Snowman|Eric Bélanger]]<br />
* [[User:Firmicus|François Charette]]<br />
<br />
=== TODO Items ===<br />
<br />
* dbscripts: Rewrite db-move to allow multiple packages, getting rid of the testing2* convienence scripts<br />
<br />
== Mirror Control ==<br />
Keep track of existing mirrors and ensure they are doing their job as good as possible (e.g. staying current). Ensure we have up to date contact information for as many mirrors as possible. Work on a tiered mirror system to relieve some stress from our primary rsync server.<br />
* [[User:Romashka|Roman Kyrylych]]<br />
=== Automated tests ===<br />
* sync state: http://users.archlinux.de/~gerbra/mirrorcheck.html<br />
* additional performance tests: http://www.archlinux.de/?page=MirrorStatus<br />
* [[User:Gerbra|Gerhard Brauer]]<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== Packaging Automation ==<br />
Automatic package generation based on changes in svn trunk. Errors should be reported to some mailing list, successful builds moved to a staging directory. Some guidelines of package moving into [extra]/[testing] should be created, for [core] we can use the current signoff procedure. <br />
* [[User:pressh|Ronald van Haren]]<br />
<br />
== Server Administration ==<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:JGC|Jan de Groot]]<br />
* [[User:Toofishes|Dan McGee]]<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== Developer Communication Team ==<br />
This isn't quite infrastructure, but it almost belongs here. Responsible for organizing developer meetings and making sure people attempt to be present; you newer guys might have no idea, but we used to actually schedule and have 80% of the developer staff present in IRC for 1-2 hour meetings. Responsible for any other coordination between developers, TUs, and maybe even the front page news.<br />
* TBA<br />
<br />
= Packaging Projects =<br />
<br />
== Bug Squashing ==<br />
Responsible for assigning bugs to package maintainers. If something is trivial and a fix can be easily made, then goes and does it. Organizes bug squashing days.<br />
* Andrea Scarpino<br />
* [[User:pjmattal|Paul Mattal]]<br />
* ...<br />
* (needs several people)<br />
<br />
== Rebuild Team ==<br />
Responsible for communicating and determining what rebuilds will cycle through [testing] and in what order. They are probably also the people doing large portions of the rebuilds.<br />
* [[User:Allan|Allan McRae]] (because my packages seem to cause big rebuilds...)<br />
* (more)<br />
<br />
== Package Review Team ==<br />
Some packages in our repos receive little attention due to not being updated frequently. These need to be checked for being able to build (especially after major toolchain updates) and compliance with current packaging standards. It would be good for packages that have not been rebuilt in a long time to be rebuilt to take advantage of new optimisations.<br />
* TODO fill me out please<br />
<br />
== Orphan Team ==<br />
Responsible for caring for those packages that no one seems to want and are being neglected. This may involve adoption by themselves or finding a foster caregiver, moving them to a willing maintainer in [community], or sending them to the AUR (or the trash).<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
== The "I package more than the rest of you combined" Team ==<br />
Because I felt bad leaving him off any list and he does a hell of a job.<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
= Web Projects =<br />
<br />
This is meant to be a quick overview of the web projects we have and who works on them. For more technical details, you will want to check out the [[DeveloperWiki:Gudrun (web)]] and [[:Category:DeveloperWiki:Server Configuration]] pages.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
== AUR ==<br />
Responsible for coding and deploying the AUR.<br />
* [[User:Louipc|Loui Chang]]<br />
<br />
== BBS ==<br />
Responsible for keeping our BBS install up to date and secure.<br />
* Andrea Scarpino<br />
<br />
== Flyspray (bugtracker) ==<br />
Responsible for keeping our flyspray install up to date and secure.<br />
* TBA?<br />
<br />
== Main Site ==<br />
* [[User:Dusty|Dusty Phillips]]<br />
<br />
== Planet ==<br />
Responsible for keeping the planet scripts updated and running.<br />
* Andrea Scarpino<br />
<br />
== Wiki ==<br />
Responsible for keeping our wiki install up to date and secure.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
= Coding Projects =<br />
<br />
== Arch Linux Init Scripts ==<br />
The all-important scripts that make your machine go when you turn it on<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Arch Linux Release Engineering (Installer) ==<br />
The Arch Linux Install Framework (AIF) and official installation ISOs<br />
* [[User:Dieter_be|Dieter Plaetinck]]<br />
* [[User:Gerbra|Gerhard Brauer]]<br />
<br />
== mkinitcpio ==<br />
We have a program to create initrds for Arch systems.<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Pacman ==<br />
<br />
=== Development Team ===<br />
This team is responsible for general development, including new features and bugfixes, for the package manager that is a core part of Arch. Although many people contribute patches and code, the people listed here are generally the people that will be reviewing patches and making the final say as to what gets in the codebase.<br />
<br />
* [[User:Toofishes|Dan McGee]]<br />
* Xavier Chantry<br />
* Nagy Gabor<br />
* [[User:Allan|Allan McRae]] (focusing on makepkg)<br />
<br />
=== Translation Team ===<br />
Pacman, as of September 2009, has been translated to 15 languages. The upkeep and maintenance of these translations is pretty much a job in itself, with the times immediately preceding a release being the busiest. Ideally this team is responsible for creating a translations branch when a string freeze is set, and then takes incoming translations, ensures they are valid, and merges them into their branch. When a release is not imminent, their focus may be on improving clarity and usefulness of existing messages.<br />
* [[User:Voidnull|Giovanni Scafora]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Super_Quick_Git_Guide&diff=76100
Super Quick Git Guide
2009-09-18T22:33:19Z
<p>Phrakture: /* Making a patch */</p>
<hr />
<div>=Preface=<br />
<br />
This isn't meant to be an all-encompassing guide by any means - it is meant to<br />
be a really quick walk-through on how to do some basic operations on the<br />
pacman codebase in git, such as submitting a patch.<br />
<br />
For more extensive tutorials, check out the following:<br />
*http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html<br />
*http://www.kernel.org/pub/software/scm/git/docs/everyday.html<br />
*http://wiki.winehq.org/GitWine (talks a lot about maintaining patches)<br />
<br />
In addition, all git commands have decent manpages to refer to. They can be<br />
reached one of two ways - for the git-add command, type 'man git-add' or<br />
'git help add'.<br />
<br />
<br />
=Getting Started=<br />
<br />
The first step with git is cloning a remote repository. This is known in the<br />
CVS and SVN camps as checking out. GIT checkout has a different purpose, but<br />
that will be covered later.<br />
<br />
To grab the pacman source into a new directory named 'pacman', run the following:<br />
git clone git://projects.archlinux.org/pacman.git pacman<br />
<br />
This will check out a local copy of the repository for you. This means you have<br />
the FULL history of the project on your computer, not just the most recent<br />
revision. This allows you to get work done even when offline, for example.<br />
<br />
The first steps after cloning may be just to look around. If you have read the<br />
tutorials mentioned above, even if you do not understand everything in them,<br />
you will be much better off.<br />
<br />
You will probably want to set up your name and email address for use in commit<br />
logs:<br />
git config user.name "Your Name"<br />
git config user.email "me@example.com"<br />
If you pass the '--global' flag to the above commands, the name and email will<br />
be stored in ~/.gitconfig, so will be used for all git projects unless<br />
overridden by a setting in the individual project.<br />
<br />
To update your local repository with any new branches, run 'git pull'.<br />
<br />
=Next Steps=<br />
<br />
==Git Branches==<br />
<br />
'git branch' will show you a list of branches. Initially, master is the only<br />
branch. However, if you pulled from a remote repo, you may have grabbed other<br />
branches- these can be seen with 'git branch -r'. Read the manpage for details.<br />
<br />
When working with git, it is good practice to never do your work on the master<br />
branch. This should stay clean to allow you to run 'git pull' and ensure that<br />
conflicts do not happen on the update.<br />
<br />
To create your own working branch, do the following (naming it whatever your<br />
heart desires):<br />
git branch working<br />
git checkout working<br />
<br />
Or compress the above into one command:<br />
git checkout -b working<br />
<br />
To switch back to the master branch use:<br />
git checkout master<br />
<br />
but you can only leave a branch if there are no pending changes to commit. Find<br />
out what changes have not been committed using:<br />
$ git status<br />
# On branch working<br />
# Changed but not updated:<br />
# (use "git add <file>..." to update what will be committed)<br />
#<br />
# modified: lib/libalpm/util.c<br />
#<br />
no changes added to commit (use "git add" and/or "git commit -a")<br />
$<br />
<br />
Either commit the changes or revert them before switching branches.<br />
<br />
I highly recommend you read the man page for these commands.<br />
<br />
==Adding a remote repository==<br />
<br />
Each developer usually has his own repository, it might be interesting to have them all available locally.<br />
For example:<br />
git remote add toofishes http://code.toofishes.net/gitprojects/pacman.git<br />
<br />
You can see all available branches with 'git branch -r', and as above, create your own based on one of these remote branches:<br />
git checkout -b toofishes-working toofishes/working<br />
<br />
==Other Time Savers==<br />
<br />
If you use CVS or SVN and are used to 'co' being equivalent to 'checkout', try the following:<br />
git config --global alias.co "checkout"<br />
<br />
You can set any other aliases you like. For example:<br />
git config --global alias.chp "cherry-pick"<br />
git config --global alias.b "branch"<br />
git config --global alias.rf "checkout HEAD"<br />
<br />
'git status' is highly helpful, it is recommended to read up on that.<br />
<br />
=Making a patch=<br />
<br />
Woo! You found a bug in pacman (what a surprise) and know how to fix it. Ensure<br />
you have your working branch checked out ('git checkout working'). Then edit<br />
the file(s) you need in order to make your changes. Compiling is a good idea<br />
to ensure your patch didn't break anything, and if it is a big change, running<br />
'make check' is highly recommended.<br />
<br />
So what do you do now? First, run 'git status'. You should see a list or even a<br />
few lists of files. The descriptions by each are a bit confusing, but you<br />
should be able to figure it out. GIT takes a different approach than CVS or SVN<br />
to committing changes- it doesn't commit a thing by default. You have to tell<br />
it what to commit, usually by running 'git add <filename>'. At this point, the<br />
file in its current state will be sent to a staging area for the commit. If<br />
you go back and change something in the file, you will have to git-add it again<br />
if you want the changes to be reflected in the commit.<br />
<br />
To commit your patch to your branch:<br />
git add <all edited files><br />
git commit -s<br />
<br />
You will then be prompted for a commit message. When writing the message, keep the following in mind. The first line is<br />
used as a patch summary- keep it short and concise. Next, skip a line and type<br />
out a full description of what your patch does. By full, I don't mean long- if<br />
you described everything in the summary line, then don't even bother with a<br />
message. Finally, skip one more line and you will have your Signed-off-by.<br />
This should have been automatically added by passing the '-s' parameter to<br />
'git commit'.<br />
<br />
There is one more important step before submission. Because git is distributed,<br />
you don't have the most current version of the repository unless you go out and<br />
get it. In the easiest case, this is just running 'git pull' on the master branch.<br />
git checkout master<br />
git pull<br />
<br />
You also want to make sure your patches are based off the most recent revision,<br />
known as the 'head'. To do this, checkout your branch with your patches, and<br />
use the following command:<br />
git checkout my-branch<br />
git rebase master<br />
To visualize what the above command did, qgit can be very helpful.<br />
<br />
To format a patch for email submission and review:<br />
git format-patch master<br />
This command will format all patches that make up the difference between your<br />
working branch and the master branch. They will be saved in the local<br />
directory; to store them elsewhere read up on the '-o' option.<br />
<br />
=Fixing your patch=<br />
<br />
So you sent off your patch to the ML and you got a few suggestions back. How<br />
does one fix it? Hopefully you did it on a branch and not the master branch,<br />
otherwise you are going to have a much tougher time. :)<br />
<br />
If it was the last patch on a branch:<br />
(edit the required files)<br />
git add <edited files><br />
git commit --amend<br />
<br />
If it was deeper in your patch tree, use <tt>git rebase -i</tt>. Use <tt>git log</tt> to find the sha1 of the commit just before the one you wish to edit (or the unique prefix), and then:<br />
git rebase -i <sha1 from above><br />
(edit the text file that appears so 'edit' appears next to the commit you wish to modify)<br />
(edit the required files)<br />
git add -u<br />
git commit --amend<br />
git rebase --continue<br />
<br />
http://wiki.winehq.org/GitWine has good information on the above, that is where<br />
most of this came from. After fixing your patch, you will probably want to<br />
rebase it as described above, and then use format-patch to submit it again.<br />
<br />
=Sending patches=<br />
<br />
A nice way to send patches is to use git send-email, but it requires some initial setup, especially for the smtp client.<br />
If you follow the instructions carefully, it should go fine : [[Msmtp]] <br />
<br />
Then you just need to tell git to use msmtp:<br />
git config --global sendemail.smtpserver "/usr/bin/msmtp"<br />
<br />
For each git repo, you can specify the email address where the patches should be sent:<br />
git config sendemail.to "pacman-dev@archlinux.org"<br />
<br />
Then simply send your patches generated by git format-patch:<br />
git-send-email 0001-amazing-new-feature<br />
<br />
=Further reading=<br />
<br />
Commands you will definitely want to be knowledgeable on:<br />
clone (only once!), branch, checkout, status, pull, fetch, diff, add,<br />
commit, rebase, format-patch<br />
<br />
=Advanced Hints=<br />
<br />
qgit in extra is a great GUI viewer for git repositories. In addition, read up<br />
on 'git-instaweb'.<br />
<br />
Used to CVS or SVN-like behavior on commits, where all changes in the local tree are committed? Try using 'git-commit -a'.<br />
<br />
Not running a black and white console? Then you probably want color in a lot of GIT's console output.<br />
git config --global color.branch auto<br />
git config --global color.diff auto<br />
git config --global color.status auto<br />
<br />
Credits:<br />
*[http://www.archlinux.org/pipermail/pacman-dev/2007-March/002428.html Originally by Dan McGee]<br />
*Wikified by Roman Kyrylych</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Super_Quick_Git_Guide&diff=76098
Super Quick Git Guide
2009-09-18T22:31:26Z
<p>Phrakture: /* Making a patch */</p>
<hr />
<div>=Preface=<br />
<br />
This isn't meant to be an all-encompassing guide by any means - it is meant to<br />
be a really quick walk-through on how to do some basic operations on the<br />
pacman codebase in git, such as submitting a patch.<br />
<br />
For more extensive tutorials, check out the following:<br />
*http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html<br />
*http://www.kernel.org/pub/software/scm/git/docs/everyday.html<br />
*http://wiki.winehq.org/GitWine (talks a lot about maintaining patches)<br />
<br />
In addition, all git commands have decent manpages to refer to. They can be<br />
reached one of two ways - for the git-add command, type 'man git-add' or<br />
'git help add'.<br />
<br />
<br />
=Getting Started=<br />
<br />
The first step with git is cloning a remote repository. This is known in the<br />
CVS and SVN camps as checking out. GIT checkout has a different purpose, but<br />
that will be covered later.<br />
<br />
To grab the pacman source into a new directory named 'pacman', run the following:<br />
git clone git://projects.archlinux.org/pacman.git pacman<br />
<br />
This will check out a local copy of the repository for you. This means you have<br />
the FULL history of the project on your computer, not just the most recent<br />
revision. This allows you to get work done even when offline, for example.<br />
<br />
The first steps after cloning may be just to look around. If you have read the<br />
tutorials mentioned above, even if you do not understand everything in them,<br />
you will be much better off.<br />
<br />
You will probably want to set up your name and email address for use in commit<br />
logs:<br />
git config user.name "Your Name"<br />
git config user.email "me@example.com"<br />
If you pass the '--global' flag to the above commands, the name and email will<br />
be stored in ~/.gitconfig, so will be used for all git projects unless<br />
overridden by a setting in the individual project.<br />
<br />
To update your local repository with any new branches, run 'git pull'.<br />
<br />
=Next Steps=<br />
<br />
==Git Branches==<br />
<br />
'git branch' will show you a list of branches. Initially, master is the only<br />
branch. However, if you pulled from a remote repo, you may have grabbed other<br />
branches- these can be seen with 'git branch -r'. Read the manpage for details.<br />
<br />
When working with git, it is good practice to never do your work on the master<br />
branch. This should stay clean to allow you to run 'git pull' and ensure that<br />
conflicts do not happen on the update.<br />
<br />
To create your own working branch, do the following (naming it whatever your<br />
heart desires):<br />
git branch working<br />
git checkout working<br />
<br />
Or compress the above into one command:<br />
git checkout -b working<br />
<br />
To switch back to the master branch use:<br />
git checkout master<br />
<br />
but you can only leave a branch if there are no pending changes to commit. Find<br />
out what changes have not been committed using:<br />
$ git status<br />
# On branch working<br />
# Changed but not updated:<br />
# (use "git add <file>..." to update what will be committed)<br />
#<br />
# modified: lib/libalpm/util.c<br />
#<br />
no changes added to commit (use "git add" and/or "git commit -a")<br />
$<br />
<br />
Either commit the changes or revert them before switching branches.<br />
<br />
I highly recommend you read the man page for these commands.<br />
<br />
==Adding a remote repository==<br />
<br />
Each developer usually has his own repository, it might be interesting to have them all available locally.<br />
For example:<br />
git remote add toofishes http://code.toofishes.net/gitprojects/pacman.git<br />
<br />
You can see all available branches with 'git branch -r', and as above, create your own based on one of these remote branches:<br />
git checkout -b toofishes-working toofishes/working<br />
<br />
==Other Time Savers==<br />
<br />
If you use CVS or SVN and are used to 'co' being equivalent to 'checkout', try the following:<br />
git config --global alias.co "checkout"<br />
<br />
You can set any other aliases you like. For example:<br />
git config --global alias.chp "cherry-pick"<br />
git config --global alias.b "branch"<br />
git config --global alias.rf "checkout HEAD"<br />
<br />
'git status' is highly helpful, it is recommended to read up on that.<br />
<br />
=Making a patch=<br />
<br />
Woo! You found a bug in pacman (what a surprise) and know how to fix it. Ensure<br />
you have your working branch checked out ('git checkout working'). Then edit<br />
the file(s) you need in order to make your changes. Compiling is a good idea<br />
to ensure your patch didn't break anything, and if it is a big change, running<br />
'make check' is highly recommended.<br />
<br />
So what do you do now? First, run 'git status'. You should see a list or even a<br />
few lists of files. The descriptions by each are a bit confusing, but you<br />
should be able to figure it out. GIT takes a different approach than CVS or SVN<br />
to committing changes- it doesn't commit a thing by default. You have to tell<br />
it what to commit, usually by running 'git add <filename>'. At this point, the<br />
file in its current state will be sent to a staging area for the commit. If<br />
you go back and change something in the file, you will have to git-add it again<br />
if you want the changes to be reflected in the commit.<br />
<br />
To commit your patch to your branch:<br />
git add <all edited files><br />
git commit -s<br />
<br />
You will then be prompted for a commit message. When writing the message, keep the following in mind. The first line is<br />
used as a patch summary- keep it short and concise. Next, skip a line and type<br />
out a full description of what your patch does. By full, I don't mean long- if<br />
you described everything in the summary line, then don't even bother with a<br />
message. Finally, skip one more line and you will have your Signed-off-by.<br />
This should have been automatically added by passing the '-s' parameter to<br />
'git commit'.<br />
<br />
There is one more important step before submission. Because git is distributed,<br />
you don't have the most current version of the repository unless you go out and<br />
get it. In the easiest case, this is just running 'git pull' on the master branch.<br />
git checkout master<br />
git pull<br />
<br />
You also want to make sure your patches are based off the most recent revision,<br />
known as the 'head'. To do this, checkout your branch with your patches, and<br />
use the following command:<br />
git rebase master<br />
To visualize what the above command did, qgit can be very helpful.<br />
<br />
To format a patch for email submission and review:<br />
git format-patch master<br />
This command will format all patches that make up the difference between your<br />
working branch and the master branch. They will be saved in the local<br />
directory; to store them elsewhere read up on the '-o' option.<br />
<br />
=Fixing your patch=<br />
<br />
So you sent off your patch to the ML and you got a few suggestions back. How<br />
does one fix it? Hopefully you did it on a branch and not the master branch,<br />
otherwise you are going to have a much tougher time. :)<br />
<br />
If it was the last patch on a branch:<br />
(edit the required files)<br />
git add <edited files><br />
git commit --amend<br />
<br />
If it was deeper in your patch tree, use <tt>git rebase -i</tt>. Use <tt>git log</tt> to find the sha1 of the commit just before the one you wish to edit (or the unique prefix), and then:<br />
git rebase -i <sha1 from above><br />
(edit the text file that appears so 'edit' appears next to the commit you wish to modify)<br />
(edit the required files)<br />
git add -u<br />
git commit --amend<br />
git rebase --continue<br />
<br />
http://wiki.winehq.org/GitWine has good information on the above, that is where<br />
most of this came from. After fixing your patch, you will probably want to<br />
rebase it as described above, and then use format-patch to submit it again.<br />
<br />
=Sending patches=<br />
<br />
A nice way to send patches is to use git send-email, but it requires some initial setup, especially for the smtp client.<br />
If you follow the instructions carefully, it should go fine : [[Msmtp]] <br />
<br />
Then you just need to tell git to use msmtp:<br />
git config --global sendemail.smtpserver "/usr/bin/msmtp"<br />
<br />
For each git repo, you can specify the email address where the patches should be sent:<br />
git config sendemail.to "pacman-dev@archlinux.org"<br />
<br />
Then simply send your patches generated by git format-patch:<br />
git-send-email 0001-amazing-new-feature<br />
<br />
=Further reading=<br />
<br />
Commands you will definitely want to be knowledgeable on:<br />
clone (only once!), branch, checkout, status, pull, fetch, diff, add,<br />
commit, rebase, format-patch<br />
<br />
=Advanced Hints=<br />
<br />
qgit in extra is a great GUI viewer for git repositories. In addition, read up<br />
on 'git-instaweb'.<br />
<br />
Used to CVS or SVN-like behavior on commits, where all changes in the local tree are committed? Try using 'git-commit -a'.<br />
<br />
Not running a black and white console? Then you probably want color in a lot of GIT's console output.<br />
git config --global color.branch auto<br />
git config --global color.diff auto<br />
git config --global color.status auto<br />
<br />
Credits:<br />
*[http://www.archlinux.org/pipermail/pacman-dev/2007-March/002428.html Originally by Dan McGee]<br />
*Wikified by Roman Kyrylych</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Internal_Projects&diff=75964
DeveloperWiki:Internal Projects
2009-09-17T05:01:02Z
<p>Phrakture: </p>
<hr />
<div>= Introduction = <br />
This article is part of the [[DeveloperWiki]].<br />
<br />
This page is meant to list a lot of the projects Arch developers keep busy with. Yes, there are things to do outside of packaging. If you are interested in anything, this page should help you get in contact with the right people. If you are looking for something to do, this is always a good place to start.<br />
<br />
Some of these projects have dedicated discussion areas, such as the release engineering and pacman development mailing lists. Other ones are less formal- some of the communication may just be person to person emails or on the arch-dev lists if it appeals to a larger crowd. Remember that if you are interested in these less-formal projects, you should let the names listed below know so they will include you on any communication regarding the project.<br />
<br />
= Infrastructure Projects =<br />
<br />
== Developer Tooling ==<br />
Primarily developer-side tools (devtools, namcap) and server-side (db-scripts) work.<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
== Mirror Control ==<br />
Keep track of existing mirrors and ensure they are doing their job as good as possible (e.g. staying current). Ensure we have up to date contact information for as many mirrors as possible. Work on a tiered mirror system to relieve some stress from our primary rsync server.<br />
* [[User:Romashka|Roman Kyrylych]]<br />
<br />
== Packaging Automation ==<br />
Yeah, not only do we need a description, but some volunteers would be nice too!<br />
* TBA<br />
<br />
== Server Administration ==<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* Jan de Groot<br />
* [[User:Toofishes|Dan McGee]]<br />
<br />
== Developer Communication Team ==<br />
This isn't quite infrastructure, but it almost belongs here. Responsible for organizing developer meetings and making sure people attempt to be present; you newer guys might have no idea, but we used to actually schedule and have 80% of the developer staff present in IRC for 1-2 hour meetings. Responsible for any other coordination between developers, TUs, and maybe even the front page news.<br />
* TBA<br />
<br />
= Packaging Projects =<br />
<br />
== Bug Squishing ==<br />
Responsible for assigning bugs to package maintainers. If something is trivial and a fix can be easily made, then goes and does it. Organizes bug squishing days.<br />
* TODO fill me out please<br />
* ...<br />
* ...<br />
* (needs several people)<br />
<br />
== Rebuild Team ==<br />
Responsible for communicating and determining what rebuilds will cycle through [testing] and in what order. They are probably also the people doing large portions of the rebuilds.<br />
* [[User:Allan|Allan McRae]] (because my packages seem to cause big rebuilds...)<br />
* (more)<br />
<br />
== Package Review Team ==<br />
Some packages in our repos receive little attention due to not being updated frequently. These need to be checked for being able to build (especially after major toolchain updates) and compliance with current packaging standards. It would be good for packages that have not been rebuilt in a long time to be rebuilt to take advantage of new optimisations.<br />
* TODO fill me out please<br />
<br />
== Orphan Team ==<br />
Responsible for caring for those packages that no one seems to want and are being neglected. This may involve adoption by themselves or finding a foster caregiver, moving them to a willing maintainer in [community], or sending them to the AUR (or the trash).<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
== The "I package more than the rest of you combined" Team ==<br />
Because I felt bad leaving him off any list and he does a hell of a job.<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
= Web Projects =<br />
<br />
This is meant to be a quick overview of the web projects we have and who works on them. For more technical details, you will want to check out the [[DeveloperWiki:Gudrun (web)]] and [[:Category:DeveloperWiki:Server Configuration]] pages.<br />
<br />
== AUR ==<br />
Responsible for coding and deploying the AUR.<br />
* [[User:Louipc|Loui Chang]]<br />
<br />
== BBS ==<br />
Responsible for keeping our BBS install up to date and secure.<br />
* Andrea Scarpino<br />
<br />
== Flyspray (bugtracker) ==<br />
Responsible for keeping our flyspray install up to date and secure.<br />
* TBA?<br />
<br />
== Main Site ==<br />
* [[User:Dusty|Dusty Phillips]]<br />
<br />
== Planet ==<br />
Responsible for keeping the planet scripts updated and running.<br />
* Andrea Scarpino<br />
<br />
== Wiki ==<br />
Responsible for keeping our wiki install up to date and secure.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
= Coding Projects =<br />
<br />
== Arch Linux Init Scripts ==<br />
The all-important scripts that make your machine go when you turn it on<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Arch Linux Release Engineering (Installer) ==<br />
The Arch Linux Install Framework (AIF) and official installation ISOs<br />
* [[User:Dieter_be|Dieter Plaetinck]]<br />
* [[User:Gerbra|Gerhard Braue]]<br />
<br />
== mkinitcpio ==<br />
We have a program to create initrds for Arch systems.<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Pacman ==<br />
<br />
=== Development Team ===<br />
This team is responsible for general development, including new features and bugfixes, for the package manager that is a core part of Arch. Although many people contribute patches and code, the people listed here are generally the people that will be reviewing patches and making the final say as to what gets in the codebase.<br />
<br />
* [[User:Toofishes|Dan McGee]]<br />
* Xavier Chantry<br />
* Nagy Gabor<br />
* [[User:Allan|Allan McRae]] (focusing on makepkg)<br />
<br />
=== Translation Team ===<br />
Pacman, as of September 2009, has been translated to 15 languages. The upkeep and maintenance of these translations is pretty much a job in itself, with the times immediately preceding a release being the busiest. Ideally this team is responsible for creating a translations branch when a string freeze is set, and then takes incoming translations, ensures they are valid, and merges them into their branch. When a release is not imminent, their focus may be on improving clarity and usefulness of existing messages.<br />
* Giovanni Scafora ?</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Internal_Projects&diff=75963
DeveloperWiki:Internal Projects
2009-09-17T05:00:05Z
<p>Phrakture: </p>
<hr />
<div>= Introduction = <br />
This article is part of the [[DeveloperWiki]].<br />
<br />
This page is meant to list a lot of the projects Arch developers keep busy with. Yes, there are things to do outside of packaging. If you are interested in anything, this page should help you get in contact with the right people. If you are looking for something to do, this is always a good place to start.<br />
<br />
Some of these projects have dedicated discussion areas, such as the release engineering and pacman development mailing lists. Other ones are less formal- some of the communication may just be person to person emails or on the arch-dev lists if it appeals to a larger crowd. Remember that if you are interested in these less-formal projects, you should let the names listed below know so they will include you on any communication regarding the project.<br />
<br />
= Infrastructure Projects =<br />
<br />
== Developer Tooling ==<br />
Primarily developer-side tools (devtools, namcap) and server-side (db-scripts) work.<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
== Mirror Control ==<br />
Keep track of existing mirrors and ensure they are doing their job as good as possible (e.g. staying current). Ensure we have up to date contact information for as many mirrors as possible. Work on a tiered mirror system to relieve some stress from our primary rsync server.<br />
* [[User:Romashka|Roman Kyrylych]]<br />
<br />
== Packaging Automation ==<br />
Yeah, not only do we need a description, but some volunteers would be nice too!<br />
* TBA<br />
<br />
== Server Administration ==<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
* Jan de Groot<br />
* [[User:Toofishes|Dan McGee]]<br />
<br />
== Developer Communication Team ==<br />
This isn't quite infrastructure, but it almost belongs here. Responsible for organizing developer meetings and making sure people attempt to be present; you newer guys might have no idea, but we used to actually schedule and have 80% of the developer staff present in IRC for 1-2 hour meetings. Responsible for any other coordination between developers, TUs, and maybe even the front page news.<br />
* TBA<br />
<br />
= Packaging Projects =<br />
<br />
== Bug Squishing ==<br />
Responsible for assigning bugs to package maintainers. If something is trivial and a fix can be easily made, then goes and does it. Organizes bug squishing days.<br />
* TODO fill me out please<br />
* ...<br />
* ...<br />
* (needs several people)<br />
<br />
== Rebuild Team ==<br />
Responsible for communicating and determining what rebuilds will cycle through [testing] and in what order. They are probably also the people doing large portions of the rebuilds.<br />
* [[User:Allan|Allan McRae]] (because my packages seem to cause big rebuilds...)<br />
* (more)<br />
<br />
== Package Review Team ==<br />
Some packages in our repos receive little attention due to not being updated frequently. These need to be checked for being able to build (especially after major toolchain updates) and compliance with current packaging standards. It would be good for packages that have not been rebuilt in a long time to be rebuilt to take advantage of new optimisations.<br />
* TODO fill me out please<br />
<br />
== Orphan Team ==<br />
Responsible for caring for those packages that no one seems to want and are being neglected. This may involve adoption by themselves or finding a foster caregiver, moving them to a willing maintainer in [community], or sending them to the AUR (or the trash).<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
== The "I package more than the rest of you combined" Team ==<br />
Because I felt bad leaving him off any list and he does a hell of a job.<br />
* [[User:Snowman|Eric Bélanger]]<br />
<br />
= Web Projects =<br />
<br />
This is meant to be a quick overview of the web projects we have and who works on them. For more technical details, you will want to check out the [[DeveloperWiki:Gudrun (web)]] and [[:Category:DeveloperWiki:Server Configuration]] pages.<br />
<br />
== AUR ==<br />
Responsible for coding and deploying the AUR.<br />
* [[User:Louipc|Loui Chang]]<br />
<br />
== BBS ==<br />
Responsible for keeping our BBS install up to date and secure.<br />
* Andrea Scarpino<br />
<br />
== Flyspray (bugtracker) ==<br />
Responsible for keeping our flyspray install up to date and secure.<br />
* TBA?<br />
<br />
== Main Site ==<br />
* [[User:Dusty|Dusty Phillips]]<br />
<br />
== Planet ==<br />
Responsible for keeping the planet scripts updated and running.<br />
* Andrea Scarpino<br />
<br />
== Wiki ==<br />
Responsible for keeping our wiki install up to date and secure.<br />
* [[User:Pierre|Pierre Schmitz]]<br />
<br />
= Coding Projects =<br />
<br />
== Arch Linux Init Scripts ==<br />
The all-important scripts that make your machine go when you turn it on<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Arch Linux Release Engineering (Installer) ==<br />
The Arch Linux Install Framework (AIF) and official installation ISOs<br />
* [[User:Dieterbe|Dieter Plaetinck]]<br />
* [[User:Gerbra|Gerhard Braue]]<br />
<br />
== mkinitcpio ==<br />
We have a program to create initrds for Arch systems.<br />
* [[User:Brain0|Thomas Bächler]]<br />
* [[User:Phrakture|Aaron Griffin]]<br />
<br />
== Pacman ==<br />
<br />
=== Development Team ===<br />
This team is responsible for general development, including new features and bugfixes, for the package manager that is a core part of Arch. Although many people contribute patches and code, the people listed here are generally the people that will be reviewing patches and making the final say as to what gets in the codebase.<br />
<br />
* [[User:Toofishes|Dan McGee]]<br />
* Xavier Chantry<br />
* Nagy Gabor<br />
* [[User:Allan|Allan McRae]] (focusing on makepkg)<br />
<br />
=== Translation Team ===<br />
Pacman, as of September 2009, has been translated to 15 languages. The upkeep and maintenance of these translations is pretty much a job in itself, with the times immediately preceding a release being the busiest. Ideally this team is responsible for creating a translations branch when a string freeze is set, and then takes incoming translations, ensures they are valid, and merges them into their branch. When a release is not imminent, their focus may be on improving clarity and usefulness of existing messages.<br />
* Giovanni Scafora ?</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User:Cactus&diff=70812
User:Cactus
2009-06-18T16:26:15Z
<p>Phrakture: Unprotected "User:Cactus"</p>
<hr />
<div>My site: [http://cactuswax.net CactusWax.Net]<br />
<br />
Word</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User:Cactus&diff=70811
User:Cactus
2009-06-18T16:24:20Z
<p>Phrakture: </p>
<hr />
<div>My site: [http://cactuswax.net CactusWax.Net]<br />
<br />
Word</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User:Drankinatty&diff=70808
User:Drankinatty
2009-06-18T15:45:30Z
<p>Phrakture: Created page with 'What are you doing to my talk page? Just edit the wiki - that's WHY it's a wiki. Sheesh...'</p>
<hr />
<div>What are you doing to my talk page? Just edit the wiki - that's WHY it's a wiki. Sheesh...</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User_talk:Phrakture&diff=70807
User talk:Phrakture
2009-06-18T15:44:46Z
<p>Phrakture: </p>
<hr />
<div>WTF is this? Dude, it's a wiki... just edit the page instead of editing a page to edit a page.... or post a bug report. This is the most inane thing I've ever seen... ever<br />
<br />
=Edits Needed On FreeNX Wiki=<br />
<br />
Phrakture, you need to update your FreeNX wiki:<br />
<br />
The Listen Addresses line, i cannot just be 127.0.0.1 (No normal ssh connections allowed, it must also included the 0.0.0.0 address. See man sshd_config Listen Addresses. So the line must look like this:<br />
<br />
ListenAddress 0.0.0.0 127.0.0.1<br />
<br />
Otherwise the normal ssh connections are refused.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=67416
DeveloperWiki:Developer Checklist
2009-04-22T15:14:45Z
<p>Phrakture: /* For the admin */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
** Delete the user's password (passwd -d)<br />
** Upload the user's public ssh key<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums <br />
* upgrade to a "SysOp" on the wiki: [[Special:Userrights]]<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Index&diff=65595
DeveloperWiki:Index
2009-03-23T22:30:59Z
<p>Phrakture: </p>
<hr />
<div>=== Policies ===<br />
* [[DeveloperWiki:CoreSignoffs]]<br />
* [[DeveloperWiki:Patching]]<br />
* [[DeveloperWiki:ExtraPackages]]<br />
* [[DeveloperWiki:ExtraSignoffs]]<br />
<br />
=== Organization ===<br />
* [[DeveloperWiki:Divisions]]<br />
* [[DeveloperWiki:Division Proposals]]<br />
* [[DeveloperWiki:ArchlinuxOrg Services]]<br />
* [[DeveloperWiki:Linux Conferences]]<br />
* World Domination Plans<br />
** Moon Domination Plans<br />
** Other celestial bodies?<br />
* World Domination Status<br />
<br />
=== Packaging Guidelines ===<br />
* [[DeveloperWiki:HOWTO Be A Packager]]<br />
* [[DeveloperWiki:Building in a Clean Chroot]]<br />
* [[DeveloperWiki:Package Submittal Rules]]<br />
* [[DeveloperWiki:GNOME Guidelines]]<br />
* [http://www.archlinux.org/static/docs/arch-install-guide.html#guidelines Package Guidelines]<br />
* [[DeveloperWiki:Adopting Packages]]<br />
* [[DeveloperWiki:Package Testing]]<br />
* [[DeveloperWiki:Build machines]]<br />
* [[DeveloperWiki:Migration Procedure: Proposal]]<br />
* [[DeveloperWiki:Non-Free Packages]]<br />
<br />
=== Packaging Reference ===<br />
<br />
* [[DeveloperWiki:Core-Repository]]<br />
* [[DeveloperWiki:UID / GID Database]]<br />
* [[DeveloperWiki:Provides Database]]<br />
* [[DeveloperWiki:Repo Cleanup]]<br />
* [[DeveloperWiki:KDE]]<br />
* [[DeveloperWiki:Python Todo List]]<br />
* [[DeveloperWiki:Curl Todo List]]<br />
* [[DeveloperWiki:Ncurses Todo List]]<br />
<br />
=== Important Public Information ===<br />
* [[UID and GID list]]<br />
<br />
=== Internals ===<br />
* [[DeveloperWiki:NewMirrors]]<br />
* [[DeveloperWiki:Developer Checklist]]<br />
* [[DeveloperWiki:Developer Meetings]]<br />
* [[DeveloperWiki:Testers]]<br />
* [[DeveloperWiki:Contact Info]]<br />
* [[DeveloperWiki:IRC Ops]]<br />
* [[DeveloperWiki:GeroldeChangelog]]<br />
* [[DeveloperWiki:MirrorInfo]]<br />
* [[DeveloperWiki:NewsletterSteps]]<br />
* [[DeveloperWiki:GeroldeStats]]<br />
<br />
=== Future ===<br />
* [[DeveloperWiki:Goals]]<br />
* [[DeveloperWiki:Objectives]]<br />
<br />
=== Artwork and Branding ===<br />
* [[DeveloperWiki:Branding Proposals]]<br />
* [[DeveloperWiki:Branding Todo List]]<br />
* [[DeveloperWiki:TrademarkPolicyDRAFT]]<br />
<br />
=== Web Development ===<br />
* [[DeveloperWiki:Website Suggestions]]<br />
* [[DeveloperWiki:Website Hierarchy Proposal]]<br />
<br />
=== Release Engineering ===<br />
* [[DeveloperWiki:release cycle]]<br />
* [[DeveloperWiki:iso building]]<br />
* [[DeveloperWiki:aif]]<br />
* [[DeveloperWiki:testing]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Bug_Day/2010&diff=64781
Bug Day/2010
2009-03-10T20:49:32Z
<p>Phrakture: </p>
<hr />
<div>This is a categorized list of some old reports.<br />
<br />
'''Please use the bug title for the links' names. That way we don't need to click on the link to know what a bug is about'''<br />
<br />
'''If you have fixed some bug - enclose it with <nowiki><s></s></nowiki> tags.'''<br />
<br />
= Overall =<br />
* Ensure bugs are assigned to the right person. Package maintainers do change sometimes<br />
* Ensure bugs are in the right top-level project (Release Engineering, Pacman, etc)<br />
* If fixes are provided for some bugs, please test and report them as fixed<br />
<br />
= Installer =<br />
* <s>[http://bugs.archlinux.org/task/10754 BR #10754]</s><br />
* [http://bugs.archlinux.org/task/10831 FR #10831 - 2008.06-USB boot parameter to specify root directory ]<br />
<br />
= System =<br />
[http://bugs.archlinux.org/task/8832 Kernel panic upon init=/bin/bash] - Please test<br />
<br />
= Packages =<br />
* [http://bugs.archlinux.org/task/9971 BR #9971] - licenses missing in many packages! There are plans to fix them regardless of bug day: http://www.archlinux.org/pipermail/arch-dev-public/2009-February/010403.html<br />
<br />
==== decision? ====<br />
* [http://bugs.archlinux.org/task/4957 FR #4957 - Improve autofs default config ]<br />
* [http://bugs.archlinux.org/task/5078 BR #5078 - mcedit broken ]<br />
* [http://bugs.archlinux.org/task/7001 FR #7001 - Move amrnb and amrwb packages to [extra] ]<br />
* [http://bugs.archlinux.org/task/12314 FR #12314 - Change distribution logging system to rsyslog ]<br />
* [http://bugs.archlinux.org/task/12764 FR #12764 - Deluge should depends on libtorrent-rasterbar ]<br />
<br />
==== status? ====<br />
* [http://bugs.archlinux.org/task/6047 FR #6047 - provide more aspell-* packages ]<br />
* [http://bugs.archlinux.org/task/7549 FR #7549 - Default mount option for vfat media disk ]<br />
* [http://bugs.archlinux.org/task/7764 BR #7764 - namcap wrongly complains about missing dependencies ]<br />
<br />
==== trivial fixes ====<br />
* [http://bugs.archlinux.org/task/4812 BR #4812 - mailx should require an smtp-forwarder or server ]<br />
* <s>[http://bugs.archlinux.org/task/8334 BR #8334] - fix provided</s><br />
* [http://bugs.archlinux.org/task/8660 BR #8660 - ypbind-mt daemon script fails to set default domain name ] - fix provided<br />
* [http://bugs.archlinux.org/task/10208 FR #10208 - bash_completion for subversion ]<br />
* [http://bugs.archlinux.org/task/10383 FR #10383 - id3v2 has no documentation! ]<br />
* [http://bugs.archlinux.org/task/11250 FR #11250 - avahi need dbus-python as dependency ]<br />
* [http://bugs.archlinux.org/task/11436 FS #11436 - eclipse 3.4-3 no icon in menu ] - (description how to) fix provided<br />
* [http://bugs.archlinux.org/task/13376 FR #13376 - Logitech QuickCam E2500 does not work in 2.6.28 ] - fix provided<br />
* [http://bugs.archlinux.org/task/13675 FR #13675 - optional dependencies for avahi miss pygtk and python-dbus ] - duplicate of bug 11250<br />
<br />
= Website =<br />
* [http://bugs.archlinux.org/task/7006 FR #7006 - Supported protocols on mirrors page ]<br />
* [http://bugs.archlinux.org/task/12237 FS #12237 - Adding Cite extension to Arch Wiki ] - straight forward installation<br />
<br />
= Community =<br />
* IIRC, several packages still needs to be rebuilt against ffmpeg or openal.<br />
<br />
= Pacman =<br />
No promises on fixing these on bug day, but if any of the pacman devs or ML readers are around these would be good candidates to look at, especially if you like C and shell script coding more than fixing the above bugs. :)<br />
<br />
* (anything in the low priority section of the bug tracker...)<br />
<br />
<br />
[[Category: Package development (English)]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Bug_Day/2010&diff=64780
Bug Day/2010
2009-03-10T20:43:57Z
<p>Phrakture: </p>
<hr />
<div>This is a categorized list of some old reports.<br />
<br />
'''Please use the bug title for the links' names. That way we don't need to click on the link to know what a bug is about'''<br />
<br />
'''If you have fixed some bug - enclose it with <nowiki><s></s></nowiki> tags.'''<br />
<br />
= Overall =<br />
* Ensure bugs are assigned to the right person. Package maintainers do change sometimes<br />
* Ensure bugs are in the right top-level project (Release Engineering, Pacman, etc)<br />
* If fixes are provided for some bugs, please test and report them as fixed<br />
<br />
= Installer =<br />
* <s>[http://bugs.archlinux.org/task/10754 BR #10754]</s><br />
* [http://bugs.archlinux.org/task/10831 FR #10831 - 2008.06-USB boot parameter to specify root directory ]<br />
<br />
= System =<br />
[http://bugs.archlinux.org/task/13106?.# FS 13106] This bug still persists.<br />
<br />
= Packages =<br />
* [http://bugs.archlinux.org/task/9971 BR #9971] - licenses missing in many packages! There are plans to fix them regardless of bug day: http://www.archlinux.org/pipermail/arch-dev-public/2009-February/010403.html<br />
<br />
==== decision? ====<br />
* [http://bugs.archlinux.org/task/4957 FR #4957 - Improve autofs default config ]<br />
* [http://bugs.archlinux.org/task/5078 BR #5078 - mcedit broken ]<br />
* [http://bugs.archlinux.org/task/7001 FR #7001 - Move amrnb and amrwb packages to [extra] ]<br />
* [http://bugs.archlinux.org/task/12314 FR #12314 - Change distribution logging system to rsyslog ]<br />
* [http://bugs.archlinux.org/task/12764 FR #12764 - Deluge should depends on libtorrent-rasterbar ]<br />
<br />
==== status? ====<br />
* [http://bugs.archlinux.org/task/6047 FR #6047 - provide more aspell-* packages ]<br />
* [http://bugs.archlinux.org/task/7549 FR #7549 - Default mount option for vfat media disk ]<br />
* [http://bugs.archlinux.org/task/7764 BR #7764 - namcap wrongly complains about missing dependencies ]<br />
<br />
==== trivial fixes ====<br />
* [http://bugs.archlinux.org/task/4812 BR #4812 - mailx should require an smtp-forwarder or server ]<br />
* <s>[http://bugs.archlinux.org/task/8334 BR #8334] - fix provided</s><br />
* [http://bugs.archlinux.org/task/8660 BR #8660 - ypbind-mt daemon script fails to set default domain name ] - fix provided<br />
* [http://bugs.archlinux.org/task/10208 FR #10208 - bash_completion for subversion ]<br />
* [http://bugs.archlinux.org/task/10383 FR #10383 - id3v2 has no documentation! ]<br />
* [http://bugs.archlinux.org/task/11250 FR #11250 - avahi need dbus-python as dependency ]<br />
* [http://bugs.archlinux.org/task/11436 FS #11436 - eclipse 3.4-3 no icon in menu ] - (description how to) fix provided<br />
* [http://bugs.archlinux.org/task/13376 FR #13376 - Logitech QuickCam E2500 does not work in 2.6.28 ] - fix provided<br />
* [http://bugs.archlinux.org/task/13675 FR #13675 - optional dependencies for avahi miss pygtk and python-dbus ] - duplicate of bug 11250<br />
<br />
= Website =<br />
* [http://bugs.archlinux.org/task/7006 FR #7006 - Supported protocols on mirrors page ]<br />
* [http://bugs.archlinux.org/task/12237 FS #12237 - Adding Cite extension to Arch Wiki ] - straight forward installation<br />
<br />
= Community =<br />
* IIRC, several packages still needs to be rebuilt against ffmpeg or openal.<br />
<br />
= Pacman =<br />
No promises on fixing these on bug day, but if any of the pacman devs or ML readers are around these would be good candidates to look at, especially if you like C and shell script coding more than fixing the above bugs. :)<br />
<br />
* (anything in the low priority section of the bug tracker...)<br />
<br />
<br />
[[Category: Package development (English)]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:NewMirrors&diff=64252
DeveloperWiki:NewMirrors
2009-03-06T22:35:55Z
<p>Phrakture: </p>
<hr />
<div>=== Adding a new mirror ===<br />
<br />
This text should outline the procedure for adding a new mirror for Arch packages<br />
<br />
== For the Mirror Administrator ==<br />
Please open a [http://bugs.archlinux.org bug ticket] with a request to become an authorized mirror.<br />
<br />
Please provide the following:<br />
* Mirror domain name<br />
* Geographical Location of the mirror<br />
* Supported access methods (http, ftp, rsync, ...)<br />
* URLs for the above access methods<br />
* The IP from which the server will be rsyncing (this may or may not be the same as the ip of the domain)<br />
* An administrative contact email<br />
<br />
===rsync access===<br />
After this is complete, you will have access to sync from rsync.archlinux.org<br />
<br />
Please ensure the following, to keep our load low:<br />
* Do not rsync more rapidly than every hour.<br />
* rsync on a random minute so it is more likely the requests will be spaced out with other mirrors<br />
<br />
== The Arch Linux side ==<br />
<br />
* Add the IP to the the rsync whitelist on gerolde\<br />
* Add the mirror info to the Django admin site<br />
* Add the mirror to pacman's mirror list</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User:Phrakture&diff=63083
User:Phrakture
2009-02-26T19:34:54Z
<p>Phrakture: </p>
<hr />
<div><br />
===Awesomeness Factor===<br />
{{progressbar|95}}</div>
Phrakture
https://wiki.archlinux.org/index.php?title=User:Phrakture&diff=63082
User:Phrakture
2009-02-26T19:34:44Z
<p>Phrakture: Replaced content with '== Developer Roadmap ==
===Awesomeness Factor===
{{progressbar|95}}'</p>
<hr />
<div>== Developer Roadmap ==<br />
<br />
===Awesomeness Factor===<br />
{{progressbar|95}}</div>
Phrakture
https://wiki.archlinux.org/index.php?title=FreeNX&diff=63081
FreeNX
2009-02-26T19:33:47Z
<p>Phrakture: /* INFO from Package Maintainer tpowa */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
<br />
{{i18n_entry|English|FreeNX}}<br />
{{i18n_entry|Czech|FreeNX (Česky)}}<br />
{{i18n_links_end}}<br />
<br />
== INFO from Package Maintainer tpowa ==<br />
Please don't change the docu without notifying me, <br />
please send me a short mail about your changes.<br />
<br />
Isn't that the point of a wiki? Why not protect the page then?<br />
[[User:Phrakture|phrakture]] 14:33, 26 February 2009 (EST)<br />
<br />
== Installation ==<br />
package is split up into 2 parts:<br />
* freenx (the server)<br />
* nxclient (the client)<br />
<br />
If you plan using freenx to connect to a headless PC, keep in mind that you'll also need an X server configured, so you should install any relevant [[xorg]] package.<br />
<br />
== Setup ==<br />
<br />
=== Server ===<br />
<br />
The free server is the 'freenx' package. <br />
* To allow logins please add 'sshd' to daemons array in /etc/rc.conf <br />
<br />
The main configuration file is located at:<br />
/opt/NX/etc/node.conf<br />
If you use KDE or Gnome desktop environments you do not need to edit this file, as the defaults should work in this case. If you use another window manager such as Fluxbox/Openbox or Xfce, you may need to edit this file slightly (see below).<br />
<br />
==== Keys ====<br />
Keys are used to authenticate the clients with the server. By default a new set of random keys are generated during the install, one for the server and one for the clients. You will need to copy this client key to each of your clients that want to connect (Windows and linux).<br />
<br />
The client key can be found here:<br />
/opt/NX/home/nx/.ssh/client.id_dsa.key<br />
<br />
Alternatively you can use the default key that is provided by NoMachine with all clients. In this case you do not need to copy a custom generated key to each client. To get the server to accept the default client keys run:<br />
/opt/NX/bin/nxsetup --install --setup-nomachine-key --clean --purge<br />
<br />
<br />
Recreation of random keys:<br />
* /opt/NX/bin/nxsetup --install --clean --purge<br />
<br />
<br />
Transferring nx keys to another freenx server:<br />
* /opt/NX/home/nx/.ssh contains the key files<br />
-rw------- 1 nx root 697 9. Okt 12:55 authorized_keys<br />
-rw------- 1 nx root 668 9. Okt 11:48 client.id_dsa.key<br />
-rw------- 1 nx root 609 9. Okt 12:55 server.id_dsa.pub.key<br />
* Save those files.<br />
* Add those files to your new server, they need the same permissions, names, group and directory!<br />
# cp authorized_keys client.id_dsa.key server.id_dsa.pub.key /opt/NX/home/nx/.ssh/<br />
# chmod 600 /opt/NX/home/nx/.ssh/*<br />
# chown nx /opt/NX/home/nx/.ssh/*<br />
# chgrp root /opt/NX/home/nx/.ssh/*<br />
* Recreate known_hosts file:<br />
# echo -n 127.0.0.1 > /opt/NX/home/nx/.ssh/known_hosts<br />
# cat /etc/ssh/ssh_host_rsa_key.pub >> /opt/NX/home/nx/.ssh/known_hosts<br />
# chmod 633 /opt/NX/home/nx/.ssh/known_hosts<br />
# chown nx /opt/NX/home/nx/.ssh/known_hosts<br />
# chgrp root /opt/NX/home/nx/.ssh/known_hosts<br />
<br />
==== Starting the server ====<br />
<br />
Once installed the server is effectively running and ready to go, you do not have to do anything manually. The only thing that must be running in order to connect is the sshd daemon.<br />
<br />
In actual fact, if you check the process list (<code>ps aux</code>) you may not see the nxserver running even though it says it is. This is because the nxserver is actually started by logging into sshd as the special user 'nx'. This user has been set up to use the nxserver as its shell, much like a normal user has bash as the default shell.<br />
<br />
<br />
=== Client ===<br />
<br />
==== Arch Linux ====<br />
<br />
Get the client from pacman:<br />
pacman -S nxclient<br />
<br />
==== Windows ====<br />
<br />
Get the client from nomachine's homepage: http://www.nomachine.com<br />
<br />
Tip: Nomachine tends to remove old clients from their homepage,<br />
If your setup works with a client save it at a safe place ;)<br />
<br />
==== Configuration ====<br />
<br />
As mentioned above, the client must contain the correct key to connect to the server. If you are using the custom keys generated during install, you need to copy the client key to the following locations:<br />
* Windows: <code><yourinstalldironwindows>/share/keys/client.id_dsa.key</code><br />
* Arch Linux: <code>/opt/NX/share/keys/client.id_dsa.key</code><br />
<br />
After moving the keys you may have use the nxclient GUI to import the new keys. From the configuration dialog press the 'Key...' button and import the new client key.<br />
<br />
<br />
== Running ==<br />
<br />
=== Keyboard shortcuts ===<br />
<br />
<pre><br />
CTR+ALT+F Toggles full-screen mode. <br />
CTRL+ALT+T Shows the terminate, suspend dialog.<br />
CTRL+ALT+M Maximizes of minimizes the window <br />
CTRL+ALT+Mouse Drags the viewport, so you can view different portions <br />
of the desktop. <br />
CTRL+ALT+Arrows <br />
or Moves the viewport by an incremental amount of pixels. <br />
CTRL+ALT+Keypad <br />
CTRL+ALT+S It will activate "screen-scraping" mode, so all the GetImage<br />
originated by the clients will be forwarded to the real<br />
display. This should make happy those who love taking<br />
screenshots ;-). By pressing the sequence again, nxagent<br />
will revert to the usual "fast" mode.<br />
CTRL+ALT+E lazy image encoding<br />
CTRL+ALT+Shift+ESC Emergency-exit and kill-window<br />
</pre><br />
<br />
=== Leaving fullscreen ===<br />
<br />
There is a magic-pixel in the top right corner of nearly every nx-application<br />
in fullscreenmode. Right-click the pixel and application-window gets iconified.<br />
<br />
=== Tips on resume ===<br />
<br />
* Resume is a bit experimental, crashes might appear after session has resumed. You have to find out which apps like resuming and which do not ;) .<br />
* Resuming between Linux and Windows sessions does not work. UPDATE: It appears that version 3.2.0-14 is able to resume Windows-suspended sessions.<br />
* If resume fails let it time out and don't use the cancel button, else sessions will stay open and consume RAM on server. To kill such sessions use the Session Admin program to kill them.<br />
<br />
=== Fix DPI settings ===<br />
<br />
If you like to have the same font-sizes/dpi sizes on all your client session,<br />
set the X resource "Xft.dpi". For example putting the following line into a<br />
user's "~/.Xresources" makes her/his "desktop" a 100dpi.<br />
Xft.dpi: 100<br />
<br />
<br />
== Setting up non-KDE or Gnome desktop managers ==<br />
<br />
Before following anything in this part, make sure the server working setup and accepting connections. This section only deals with problems once NXClient has logged on.<br />
<br />
It is quite simple (once the server is setup) to connect to Gnome and KDE sessions, however connecting to other window managers (fluxbox, xfce, whatever) is slightly different.<br />
<br />
Choosing "custom" and using a command like startx of startfluxbox will either result in a blank screen after the !M logo or the Client to present an error complaining about lack of a X server. A way around this is open a session with the command "startx", and the another with the command to start your window-manager-of-choice.<br />
<br />
If you do not want to do this, you can start X by [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup|installing a login manager like SLIM or XDM]]. I would recomend using SLiM because of it's small size.<br />
<br />
(Authors note: This is how I got fluxbox, xfce and others to work on my arch installation- however, I have now removed slim from inittab and set the run level back to 3, and yet I can still login perfectly with NXClient. Possibly try this if you get your system working this way, if like me you have a low memory machine.)<br />
<br />
==== Alternative fix ====<br />
A simple fix without resorting to the above seems to involve a simple edit to the config file. This should work for fluxbox/openbox/xfce or any other window manager that uses the '''.xinitrc''' startup file in a call to '''startx'''.<br />
<br />
Simply edit the config file (as root):<br />
/opt/NX/etc/node.conf<br />
and change<br />
#USER_X_STARTUP_SCRIPT=.Xclients<br />
to<br />
USER_X_STARTUP_SCRIPT=.xinitrc<br />
Remember to remove the # symbol from the start of the line.<br />
<br />
Then in the client under configuration settings, choose '''Custom''' as the desktop, and click on settings:<br />
* In the first group select - '''<code>Run the default X client Script on server</code>'''<br />
* In the second group select - '''<code>New virtual desktop</code>'''<br />
<br />
<br />
== Problems ==<br />
<br />
<br />
=== Debug problems ===<br />
<br />
<br />
Edit the nxserver config file:<br />
<br />
vi /opt/NX/etc/node.conf<br />
<br />
Change:<br />
<br />
#SESSION_LOG_CLEAN=1<br />
<br />
to <br />
<br />
SESSION_LOG_CLEAN=0<br />
<br />
Then you can look/debug the log files in:<br />
<br />
$HOME/.nx/T-C-<hostname>-<display>-<session-id><br />
For succesfull connections and:<br />
<br />
$HOME/.nx/F-C-<hostname>-<display>-<session-id><br />
For failed ones.<br />
<br />
<br />
=== Authentication OK, but connection fails ===<br />
<br />
If you are trying to startkde <br />
<br />
<br />
vi /opt/NX/etc/node.conf<br />
<br />
<br />
<br />
And search for:<br />
<br />
COMMAND_START_KDE=startkde<br />
<br />
Replace for:<br />
<br />
<br />
COMMAND_START_KDE=/usr/bin/startkde<br />
<br />
=== Key changes ===<br />
Change the key in GUI setup to new generated key.<br />
<br />
=== Xorg 7 ===<br />
Be aware that you have to remove the /usr/X11R6 directory, else strange things<br />
can happen.<br />
<br />
=== Wrong password / No connection possible ===<br />
* If you get always wrong password or no connection after authentication was done and you are sure that you typed it correct, check that your server can connect to itself using localhost by ssh and that it is not blocked either by /etc/hosts.deny or not allowed by /etc/hosts.allow.<br />
<br />
* If you messed up your key files, create new ones or fix the old ones, it's probably caused by a wrong known_hosts file.<br />
<br />
==== NX Crashes on session startup ====<br />
If your NX Client shows the NX logo then disappears with a Connection Problem dialog afterwards.<br />
<br />
Then it could be due to missing fonts. Mostly applies if you have installed Arch Linux base and then installed freenx after without the whole X11 set.<br />
<br />
Solution until FreeNX Dependencies is fixed is to install xorg-fonts-misc on your NX Server (pacman -S xorg-fonts-misc) and your NX should work.<br />
<br />
Note: This does not apply to freenx 0.6.1-3 and above, fix has been incorporated in it and following versions.<br />
<br />
=== NX logo then blank screen ===<br />
<br />
If you see the NX logo (!M) then a blank screen.<br />
<br />
This problem can be solved by running a login manager- The problem is that X11 is not started, and it appears that "startx" or similar do not work from the freenx client.<br />
Follow these instructions to setup a login manager and load it at startup: [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]]<br />
<br />
Blind: If this does not resolve your issues, be aware that freenx and bash_completion do not play well together. I only got things to work after removing bash_completion from the .bashrc.<br />
<br />
=== GDM/XDM Session Menu Error with non-KDE or Gnome Desktop Managers (more common with non-Arch Linux users) ===<br />
<br />
Problem: A session menu comes up talking about "chooseSessionListWidget." A window manager never loads.<br />
<br />
Fix :<br />
<br />
Double check to see if ~/.xinitrc is executable.<br />
<br />
ls -la ~/ | grep .xinitrc<br />
<br />
If the file is not executable, simply<br />
<br />
chmod +x ~/.xinitrc<br />
<br />
Keep in mind this command should be executed along with pertinent instructions on this page about "Setting up non-KDE or Gnome desktop managers"</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Building_in_a_clean_chroot&diff=62945
DeveloperWiki:Building in a clean chroot
2009-02-23T23:39:30Z
<p>Phrakture: /* Alternate Rebuild Handling */</p>
<hr />
<div>= Introduction =<br />
<br />
This article is part of the [[DeveloperWiki]].<br />
<br />
= Why =<br />
<br />
Building in a clean chroot prevents missing dependancies in packages, whether due to unwanted linking or packages missing in the depends array in the PKGBUILD. It also allows you to build a package for the stable repositories (core, extra, community) while having packages from [testing] installed on your system.<br />
<br />
= Setting Up A Chroot =<br />
<br />
The devtools package provides tools for creating and building within clean chroots. To make a clean chroot, firstly create the directory you want it to reside in. For the purposes of this article this will be called <chrootdir>. The create your chroot using<br />
<br />
sudo mkarchroot -C <pacman.conf> -M <makepkg.conf> <chrootdir>/root base base-devel sudo<br />
<br />
The -C and -M flags are optional, but it is recommended to provide these with clean pacman.conf and makepkg.conf files (directly from the pacman package) during first creation of clean chroot to ensure lack of user specific adjustments.<br />
<br />
Edit the <chrootdir>/root/etc/makepkg.conf file to set the packager name and any makeflags. Also adjust the mirror list in <chrootdir>/root/etc/pacman.d/mirrorlist and enable [testing] in <chrootdir>/root/etc/pacman.conf if wanted.<br />
<br />
= Building in the Chroot =<br />
<br />
Firstly, make sure your chroot is up to date with:<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
Then, to build a package in your chroot run<br />
<br />
sudo makechrootpkg -c -r <chrootdir><br />
<br />
A unionfs is used to maintain the clean chroot during building. All installed dependencies or makedepends and other changes made during building are done in <chrootdir>/rw. Passing the -c flag to makechrootpkg ensures that this directory is cleaned before building starts.<br />
<br />
= Handling Major Rebuilds =<br />
<br />
The cleanest way to handle a major rebuild is to create a new chroot and build your first package (typically the package you are doing the rebuild for). Then create a local repo in you chroot. To do this:<br />
<br />
sudo mkdir <chrootdir>/root/repo<br />
sudo chmod 777 <chrootdir>/root/repo<br />
<br />
The chmod statement allows you to copy package files and create the local repo as your user rather than root.<br />
<br />
cp <package> <chrootdir>/root/repo<br />
cd <chrootdir>/root/repo<br />
repo-add local.db.tar.gz <package><br />
<br />
Then add the local repo to <chrootdir>/root/etc/pacman.conf<br />
<br />
[local]<br />
Server = file:///repo<br />
<br />
and update your repo<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
With every additional package rebuilt, copy the package to the local repo directory, add it to the repo database and update your chroot.<br />
<br />
= Alternate Rebuild Handling =<br />
<br />
The above directions will work fine, but they can dirty the "pristine" chroot that makechrootpkg tries to keep in check (that is the point of using unionfs - dirtying a separate 'rw' directory).<br />
<br />
== Using a custom repo ==<br />
Follow the steps above to setup a local repo inside the chroot.<br />
<br />
Build packages using:<br />
sudo makechrootpkg -r <chrootdir> -u<br />
The -u will update the chroot before building (-Syu) but updates will be installed to the rw layer, maintaining a clean chroot.<br />
<br />
== Manual package installation ==<br />
Packages can be installed manually to the rw layer of the chroot by using:<br />
sudo makechrootpkg -r <chrootdir> -I package-1.0-1-i686.pkg.tar.gz<br />
<br />
== Installation after building ==<br />
You can tell makechrootpkg to simply install a package to the rw layer of the chroot after building by passing the -i arg. Unrecognized args get passed to makepkg, so this calls `makepkg` with the -i arg.<br />
sudo makechrootpkg -r <chrootdir> -- -i</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Building_in_a_clean_chroot&diff=62944
DeveloperWiki:Building in a clean chroot
2009-02-23T23:07:52Z
<p>Phrakture: /* Alternate Rebuild Handling */</p>
<hr />
<div>= Introduction =<br />
<br />
This article is part of the [[DeveloperWiki]].<br />
<br />
= Why =<br />
<br />
Building in a clean chroot prevents missing dependancies in packages, whether due to unwanted linking or packages missing in the depends array in the PKGBUILD. It also allows you to build a package for the stable repositories (core, extra, community) while having packages from [testing] installed on your system.<br />
<br />
= Setting Up A Chroot =<br />
<br />
The devtools package provides tools for creating and building within clean chroots. To make a clean chroot, firstly create the directory you want it to reside in. For the purposes of this article this will be called <chrootdir>. The create your chroot using<br />
<br />
sudo mkarchroot -C <pacman.conf> -M <makepkg.conf> <chrootdir>/root base base-devel sudo<br />
<br />
The -C and -M flags are optional, but it is recommended to provide these with clean pacman.conf and makepkg.conf files (directly from the pacman package) during first creation of clean chroot to ensure lack of user specific adjustments.<br />
<br />
Edit the <chrootdir>/root/etc/makepkg.conf file to set the packager name and any makeflags. Also adjust the mirror list in <chrootdir>/root/etc/pacman.d/mirrorlist and enable [testing] in <chrootdir>/root/etc/pacman.conf if wanted.<br />
<br />
= Building in the Chroot =<br />
<br />
Firstly, make sure your chroot is up to date with:<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
Then, to build a package in your chroot run<br />
<br />
sudo makechrootpkg -c -r <chrootdir><br />
<br />
A unionfs is used to maintain the clean chroot during building. All installed dependencies or makedepends and other changes made during building are done in <chrootdir>/rw. Passing the -c flag to makechrootpkg ensures that this directory is cleaned before building starts.<br />
<br />
= Handling Major Rebuilds =<br />
<br />
The cleanest way to handle a major rebuild is to create a new chroot and build your first package (typically the package you are doing the rebuild for). Then create a local repo in you chroot. To do this:<br />
<br />
sudo mkdir <chrootdir>/root/repo<br />
sudo chmod 777 <chrootdir>/root/repo<br />
<br />
The chmod statement allows you to copy package files and create the local repo as your user rather than root.<br />
<br />
cp <package> <chrootdir>/root/repo<br />
cd <chrootdir>/root/repo<br />
repo-add local.db.tar.gz <package><br />
<br />
Then add the local repo to <chrootdir>/root/etc/pacman.conf<br />
<br />
[local]<br />
Server = file:///repo<br />
<br />
and update your repo<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
With every additional package rebuilt, copy the package to the local repo directory, add it to the repo database and update your chroot.<br />
<br />
= Alternate Rebuild Handling =<br />
<br />
The above directions will work fine, but they can dirty the "pristine" chroot that makechrootpkg tries to keep in check (that is the point of using unionfs - dirtying a separate 'rw' directory).<br />
<br />
== Using a custom repo ==<br />
Follow the steps above to setup a local repo inside the chroot.<br />
<br />
Build packages using:<br />
sudo makechrootpkg -r <chrootdir> -u<br />
The -u will update the chroot before building (-Syu) but updates will be installed to the rw layer, maintaining a clean chroot.<br />
<br />
== Manual package installation ==<br />
Packages can be installed manually to the rw layer of the chroot by using:<br />
sudo makechrootpkg -r <chrootdir> -I package-1.0-1-i686.pkg.tar.gz<br />
<br />
== Installation after building ==<br />
You can tell makechrootpkg to simply install a package to the rw layer of the chroot after building by passing the -i arg. Unrecognized args get passed to makepkg, so this calls `makepkg` with the -i arg.<br />
sudo makechrootpkg -r <chrootdir> -i</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Building_in_a_clean_chroot&diff=62943
DeveloperWiki:Building in a clean chroot
2009-02-23T23:06:17Z
<p>Phrakture: </p>
<hr />
<div>= Introduction =<br />
<br />
This article is part of the [[DeveloperWiki]].<br />
<br />
= Why =<br />
<br />
Building in a clean chroot prevents missing dependancies in packages, whether due to unwanted linking or packages missing in the depends array in the PKGBUILD. It also allows you to build a package for the stable repositories (core, extra, community) while having packages from [testing] installed on your system.<br />
<br />
= Setting Up A Chroot =<br />
<br />
The devtools package provides tools for creating and building within clean chroots. To make a clean chroot, firstly create the directory you want it to reside in. For the purposes of this article this will be called <chrootdir>. The create your chroot using<br />
<br />
sudo mkarchroot -C <pacman.conf> -M <makepkg.conf> <chrootdir>/root base base-devel sudo<br />
<br />
The -C and -M flags are optional, but it is recommended to provide these with clean pacman.conf and makepkg.conf files (directly from the pacman package) during first creation of clean chroot to ensure lack of user specific adjustments.<br />
<br />
Edit the <chrootdir>/root/etc/makepkg.conf file to set the packager name and any makeflags. Also adjust the mirror list in <chrootdir>/root/etc/pacman.d/mirrorlist and enable [testing] in <chrootdir>/root/etc/pacman.conf if wanted.<br />
<br />
= Building in the Chroot =<br />
<br />
Firstly, make sure your chroot is up to date with:<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
Then, to build a package in your chroot run<br />
<br />
sudo makechrootpkg -c -r <chrootdir><br />
<br />
A unionfs is used to maintain the clean chroot during building. All installed dependencies or makedepends and other changes made during building are done in <chrootdir>/rw. Passing the -c flag to makechrootpkg ensures that this directory is cleaned before building starts.<br />
<br />
= Handling Major Rebuilds =<br />
<br />
The cleanest way to handle a major rebuild is to create a new chroot and build your first package (typically the package you are doing the rebuild for). Then create a local repo in you chroot. To do this:<br />
<br />
sudo mkdir <chrootdir>/root/repo<br />
sudo chmod 777 <chrootdir>/root/repo<br />
<br />
The chmod statement allows you to copy package files and create the local repo as your user rather than root.<br />
<br />
cp <package> <chrootdir>/root/repo<br />
cd <chrootdir>/root/repo<br />
repo-add local.db.tar.gz <package><br />
<br />
Then add the local repo to <chrootdir>/root/etc/pacman.conf<br />
<br />
[local]<br />
Server = file:///repo<br />
<br />
and update your repo<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
With every additional package rebuilt, copy the package to the local repo directory, add it to the repo database and update your chroot.<br />
<br />
= Alternate Rebuild Handling =<br />
<br />
The above directions will work fine, but they can dirty the "pristine" chroot that makechrootpkg tries to keep in check (that is the point of using unionfs - dirtying a separate 'rw' directory).<br />
<br />
== Using a custom repo ==<br />
Follow the steps above to setup a local repo inside the chroot.<br />
<br />
Build packages using:<br />
sudo makechrootpkg -r <chrootdir> -u<br />
The -u will update the chroot before builting (-Syu) but updates will be installed to the rw layer, maintaining a clean chroot.<br />
<br />
== Manual package installation ==<br />
Packages can be installed manually to the rw layer of the chroot by using:<br />
sudo makechrootpkg -r <chrootdir> -I package-1.0-1-i686.pkg.tar.gz<br />
<br />
== Installation after building ==<br />
You can tell makechrootpkg to simply install a package to the rw layer of the chroot after building by passing the -i arg. Unrecognized args get passed to makepkg, so this calls `makepkg` with the -i arg.<br />
sudo makechrootpkg -r <chrootdir> -i</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Index&diff=62251
DeveloperWiki:Index
2009-02-17T16:16:19Z
<p>Phrakture: </p>
<hr />
<div>=== Policies ===<br />
* [[DeveloperWiki:CoreSignoffs]]<br />
* [[DeveloperWiki:Patching]]<br />
* [[DeveloperWiki:ExtraPackages]]<br />
<br />
=== Organization ===<br />
* [[DeveloperWiki:Divisions]]<br />
* [[DeveloperWiki:Division Proposals]]<br />
* [[DeveloperWiki:ArchlinuxOrg Services]]<br />
* [[DeveloperWiki:Linux Conferences]]<br />
* World Domination Plans<br />
** Moon Domination Plans<br />
** Other celestial bodies?<br />
* World Domination Status<br />
<br />
=== Packaging Guidelines ===<br />
* [[DeveloperWiki:HOWTO Be A Packager]]<br />
* [[DeveloperWiki:Building in a Clean Chroot]]<br />
* [[DeveloperWiki:Package Submittal Rules]]<br />
* [[DeveloperWiki:GNOME Guidelines]]<br />
* [http://www.archlinux.org/static/docs/arch-install-guide.html#guidelines Package Guidelines]<br />
* [[DeveloperWiki:Adopting Packages]]<br />
* [[DeveloperWiki:Package Testing]]<br />
* [[DeveloperWiki:Build machines]]<br />
* [[DeveloperWiki:Migration Procedure: Proposal]]<br />
* [[DeveloperWiki:Non-Free Packages]]<br />
<br />
=== Packaging Reference ===<br />
<br />
* [[DeveloperWiki:Core-Repository]]<br />
* [[DeveloperWiki:UID / GID Database]]<br />
* [[DeveloperWiki:Provides Database]]<br />
* [[DeveloperWiki:Repo Cleanup]]<br />
* [[DeveloperWiki:KDE]]<br />
* [[DeveloperWiki:Python Todo List]]<br />
* [[DeveloperWiki:Curl Todo List]]<br />
* [[DeveloperWiki:Ncurses Todo List]]<br />
<br />
=== Important Public Information ===<br />
* [[UID and GID list]]<br />
<br />
=== Internals ===<br />
* [[DeveloperWiki:NewMirrors]]<br />
* [[DeveloperWiki:Developer Checklist]]<br />
* [[DeveloperWiki:Developer Meetings]]<br />
* [[DeveloperWiki:Testers]]<br />
* [[DeveloperWiki:Contact Info]]<br />
* [[DeveloperWiki:IRC Ops]]<br />
* [[DeveloperWiki:GeroldeChangelog]]<br />
* [[DeveloperWiki:MirrorInfo]]<br />
* [[DeveloperWiki:NewsletterSteps]]<br />
* [[DeveloperWiki:GeroldeStats]]<br />
<br />
=== Future ===<br />
* [[DeveloperWiki:Goals]]<br />
* [[DeveloperWiki:Objectives]]<br />
<br />
=== Artwork and Branding ===<br />
* [[DeveloperWiki:Branding Proposals]]<br />
* [[DeveloperWiki:Branding Todo List]]<br />
* [[DeveloperWiki:TrademarkPolicyDRAFT]]<br />
<br />
=== Web Development ===<br />
* [[DeveloperWiki:Website Suggestions]]<br />
* [[DeveloperWiki:Website Hierarchy Proposal]]<br />
<br />
=== Release Engineering ===<br />
* [[DeveloperWiki:release cycle]]<br />
* [[DeveloperWiki:iso building]]<br />
* [[DeveloperWiki:aif]]<br />
* [[DeveloperWiki:testing]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Official_Installation_Guide&diff=62225
Official Installation Guide
2009-02-17T02:40:43Z
<p>Phrakture: Protected "Official Arch Linux Install Guide" [edit=sysop:move=sysop]</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|General installation documentation for the Arch Linux distribution.}}<br />
{{Article summary heading|Available Languages}}<br />
{{i18n_entry|English|Official Arch Linux Install Guide}}<br />
{{i18n_entry|简体中文|Arch Linux 官方安装指南}}<br />
{{i18n_entry|正體中文|Arch Linux 官方安裝指南}}<br />
{{i18n_entry|Česky|Oficiální instalační příručka (Česky)}}<br />
{{i18n_entry|Русский|Руководство по установке}}<br />
{{i18n_entry|Español|Guía oficial de Instalación}}<br />
{{i18n_entry|Italiano|Official Arch Linux Install Guide (Italiano)}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Beginners Guide}} (If you are new to Arch)<br />
{{Article summary end}}<br />
<br />
<br />
==Introduction==<br />
<br />
===What is Arch Linux?===<br />
<br />
Arch Linux is an independently developed i686 and x86_64 optimized Linux distribution that was originally based on ideas from CRUX.<br />
Development is focused on a balance of simplicity, elegance, code-correctness and bleeding edge software.<br />
It's lightweight and simple design makes it easy to extend and mold into whatever kind of system you're building.<br />
<br />
===License===<br />
<br />
Arch Linux and scripts are copyright<br />
<br />
2002-2007 Judd Vinet<br />
<br />
2007-2009 Aaron Griffin<br />
<br />
and are licensed under the GNU General Public License (GPL).<br />
<br />
==Installing Arch Linux==<br />
<br />
===Pre-Installation===<br />
<br />
Arch Linux is optimized for i686 and x86_64 processors and therefore will not run on any lower or incompatible generations of x86 CPUs (i386,i486 or i586). A Pentium II or AMD K6-2 processor or higher is required.<br />
Before installing Arch Linux, you should decide which installation method you would like to use. Arch Linux provides bootable ISO and USB disk images, using the GRUB bootloader. The ISO images will work on almost any machine with a CD-ROM drive, and the USB images will work on any system capable of booting from a USB drive. For those having problems with GRUB not loading, ISOs with the ISOLINUX bootloader are offered as well.<br />
There are two variants of each installation medium which only differ in terms of supplied packages.<br />
<br />
* The "core" images contain a snapshot of the core packages. These images are best suited for people who have an internet connection which is slow or difficult to set up.<br />
* The "ftp" images contain no packages at all, and will use the network to install packages. These images are preferred since you will end up with an up-to-date system and they are best suited for people with fast internet connections.<br />
<br />
You can instruct the installer to obtain the packages via FTP using either of these images, and all images can also be used as fully functioning recovery environments. The images run like any regular installed Arch Linux system. In fact, they're exactly the same, just installed to a CD or USB image instead of a hard disk. They include the entire "base" package set, as well as various networking utilities and drivers. If there's something else you happen to need at runtime, just get your Internet connection up and install it using pacman. A short pacman command reference is available at the end of this document.<br />
The most common (and recommended) installation procedure is to use the install media to initially install only the "base" package set and whatever utilities and drivers you need to get online. Then once you've successfully booted the installed system, run a full system upgrade and install any other packages you want.<br />
<br />
===Acquiring Arch Linux===<br />
<br />
* You can download Arch Linux from any of the mirrors listed on the [http://www.archlinux.org/download/ download] page.<br />
* You may also purchase an installation CD from Archux, OSDisc or LinuxCD and have it shipped anywhere in the world.<br />
<br />
===Preparing the Installation Media===<br />
<br />
'''CD-ROM'''<br />
* Download iso/<release>/archlinux-XXX.iso<br />
* Download iso/<release>/sha1sums.txt<br />
* Verify the integrity of the .iso image using sha1sum:<br />
sha1sum --check sha1sums.txt<br />
archlinux-XXX.iso: OK<br />
* Burn the ISO image to a CD-R or CD-RW using any software of your choice.<br />
<br />
'''USB'''<br />
* Download iso/<release>/archlinux-XXX.img<br />
* Download iso/<release>/sha1sums.txt<br />
* Verify the integrity of the .img image using sha1sum:<br />
sha1sum --check sha1sums.txt<br />
archlinux-XXX.img: OK<br />
* Write the disk image to a USB mass storage device, such as a thumb drive, using dd or similar raw-write software:<br />
dd if=archlinux-XXX.img of=/dev/sdX<br />
Make sure to use /dev/sdX and not /dev/sdX1. This command will irrevocably delete all files on your USB stick, so make sure you don't have any important files on it before doing this.<br />
<br />
===Using the Install Media===<br />
<br />
Make sure your BIOS is set in a way to allow booting from your CD-ROM or USB device. Reboot your computer with the Arch Linux Installation CD in the drive or the USB stick plugged in the port. Once the installation medium has booted you will see the Arch Linux logo and a grub menu waiting for your selection. Most likely you can just hit enter at this point.<br />
At the end of the boot procedure, you should be at a login prompt with some simple instructions at the top of the screen. You should login as root. At this point you are ready to commence the actual installation, or do any manual preparation you consider necessary.<br />
<br />
Using the available shell tools, experienced users are also able to prepare the hard drive or any devices needed for the installation before starting the installer. Note that the Arch Linux installation media also contains a /arch/quickinst script for experienced users. This script installs the "base" set of packages to a user-specified destination directory. If you are doing an install with things like RAID and LVM, or don't want to use the installer at all, you'll probably want to use the quickinst script. You will have to configure the system afterwards since no form of auto-configuration takes place.<br />
<br />
===Common Installation Procedure===<br />
<br />
'''Installation Steps:'''<br />
<br />
#Loading a non-US Keymap<br />
#Running Setup<br />
#Select Source<br />
##CD-ROM or OTHER SOURCE<br />
##FTP/HTTP<br />
###Setup Network<br />
###Choose Mirror<br />
#Set Clock<br />
#Prepare Hard Drive<br />
##Auto-Prepare<br />
##Partition Hard Drives<br />
##Set Filesystem Mountpoints<br />
#Select Packages<br />
#Install Packages<br />
#Configure System<br />
#Install Bootloader<br />
#Exit Install<br />
<br />
====Login and Loading a non-US Keymap====<br />
<br />
If you need to load a non-US keymap and/or want to set a different console font, use the "km" utility.<br />
km<br />
<br />
====Running Setup====<br />
<br />
Now you can run /arch/setup to invoke the installer program.<br />
/arch/setup<br />
After an informational welcome message you will be presented with the main installation menu. You can use UP and DOWN arrow to navigate menus. Use TAB to switch between buttons and ENTER to select. At any point during the install process, you can switch to your 7th virtual console (ALT-F7) to view the output from the commands the setup is running. Use (ALT-F1) to get back to your first console where the installer is running, and any F-key in between if you need to open another console to intervene manually for any reason.<br />
<br />
====Select Source====<br />
<br />
As a first step you must choose the method you want to install Arch Linux. If you have a fast Internet connection, you might prefer the FTP installation to ensure you get the latest packages instead of using the potentially outdated CD or USB image contents.<br />
<br />
=====CD-ROM or OTHER SOURCE=====<br />
<br />
When choosing a CD-ROM or OTHER SOURCE install you will only be able to install packages contained on the CD, which may be quite old, or packages stored on a medium you were able to mount (DVD, USB stick or similar) somewhere in the filesystem tree manually. Of course it has the advantage that you won't need an Internet connection, and is therefore the recommended choice for dialup users or those unable or unwilling to download the entire package set.<br />
<br />
=====FTP/HTTP=====<br />
<br />
======Setup Network======<br />
<br />
The first entry Setup Network will allow you to install and configure your network device. If you are using a wireless device you will still need to use the usual utilities to configure it manually, in which case this part of the installer isn't much use to you. A list of all currently available network devices is presented to you. If no ethernet device is available yet, or the one you wish to use is missing, either hit OK and go on to probe for it, or switch to another console and load the module manually. If you still can't configure your network card, make sure it's physically been properly installed, and that it is supported by the Linux kernel.<br />
<br />
When the correct module is loaded, and your desired network card is listed, you should select the ethernet device you want to configure and you will be given the option to configure your network with DHCP. If your network uses DHCP, hit YES and let the installer do the rest. If you select NO, you will be asked to enter the networking information manually. Either way, your network should be successfully configured, and you may check connectivity using standard tools like ping on another console.<br />
<br />
======Choose Mirror======<br />
<br />
Choose Mirror will allow you to choose the preferred mirror to download the packages that will be installed in your Arch Linux system. You should choose a mirror situated near where you live, in order to achieve faster download speed. At some later point of the installation, you will be given the option to use the mirror you choose at this step, as the default mirror to download packages from.<br />
{{Box Note | ftp.archlinux.org is throttled to 50 KB/s.}}<br />
<br />
These menu entries are only available when choosing FTP Installation, for rather obvious reasons. After successful preparation, choose Return to Main Menu.<br />
<br />
====Set Clock====<br />
<br />
Set Clock will allow you to set up your system clock and date. Choose UTC if your BIOS clock is set to UTC, or localtime if your BIOS clock is set to your local time. If you have an OS installed which cannot handle UTC BIOS times correctly, like Windows, choose localtime, otherwise you should prefer UTC. Next the setup will want you to select the continent and country you are from, and then set the date and time.<br />
<br />
====Prepare Hard Drive====<br />
<br />
Prepare Hard Drive will lead you into a submenu offering two alternatives of preparing your target drive for installation.<br />
<br />
=====Auto-Prepare=====<br />
<br />
The first choice is Auto-Prepare, which will automatically partition your hard drive into a /boot, swap, a root partition, and a /home using the remaining space and then create filesystems on all four. These partitions will also be automatically mounted in the proper place. To be exact, this option will create:<br />
* 32 MB ext2 /boot partition<br />
* 256 MB swap partition<br />
* 7.5 GB root partition<br />
* /home partition with the remaining space<br />
You will be prompted to modify the sizes to your requirements, but /home will always use the remaining disk space.<br />
<br />
'''AUTO-PREPARE WILL ERASE ALL DATA ON THE CHOSEN HARD DRIVE!'''<br />
<br />
If you prefer to do the partitioning manually, use the other two options, Partition Hard Drives and Set Filesystem Mountpoints to prepare the target media according to your specifications as outlined below. After successful preparation, choose Return to Main Menu.<br />
<br />
=====Partition Hard Drives=====<br />
<br />
Partition Hard Drives should be skipped if you chose Auto-Prepare already!<br />
<br />
Otherwise you should select the disk(s) you want to partition, and you'll be dropped into the cfdisk program where you can freely modify the partitioning information until you [Write] and [Quit]. You will need at least a root partition to continue the installation, and it's helpful to note somewhere which partition you're going to mount where, as you'll be asked exactly that in the next step.<br />
<br />
=====Set Filesystem Mountpoints=====<br />
<br />
Set Filesystem Mountpoints should also be skipped if you chose to Auto-Prepare your hard drive. You should select this choice once the partition information is edited to your liking with the previous menu selection, or already existent through whatever other means.<br />
<br />
The first question to answer is what partition to use as swap. Select the previously created swap partition from the list, or NONE, if you don't want to use a swap partition. Using a swap file is not directly supported by the installer. Instead choose NONE here, finish the mountpoint associations, and activate a swap file on your desired, formatted partition with the swapon command. If you chose to use a swap partition, you will be asked whether to create a filesystem on it, and since this partition uses a specific filesystem of it's own, you should always answer YES here.<br />
<br />
After setting up the swap partition, you'll be asked to specify the partition to be used as the root partition. This is mandatory. The association process is then repeated until you choose DONE from the list. The installer will suggest /boot for all following mountpoints after choosing swap and root. Each time a partition to mount is specified, you will be asked if you want to create a filesystem on the respective partition. Selecting YES, will prompt you for the filesystem type to create. The partition will then be formatted with the chosen filesystem type, destroying all data in the process. It should be no problem, however, to say NO at this point to preserve any existing files on the partition. Before the actual formatting is done, the installer will present a list of all of your choices for review. After formatting and mounting all partitions, you may return to the Main Menu and proceed with the next step.<br />
<br />
====Select Packages====<br />
<br />
Select Packages will let you select the packages you wish to install from the CD, USB or your FTP mirror. You have the opportunity to specify whole package groups from which you'd generally like to install packages, then fine-tune your coarse selection by (de)selecting individual packages from the groups you have chosen using the space bar. It is recommended that you install all the "base" packages, but not anything else at this point. The only exception to this rule is installing any packages you need for setting up Internet connectivity.<br />
<br />
Once you're done selecting the packages you need, leave the selection screen and continue to the next step.<br />
<br />
====Install Packages====<br />
<br />
Install Packages will now install the base system and any other packages you selected with resolved dependencies onto your harddisk.<br />
<br />
====Configure System====<br />
<br />
Configure System allows you to edit the configuration files crucial for your newly installed system. You will be asked for the editor you want to use for manually fine-tuning the generated configuration files, either VIM or nano.<br />
<br />
'''Configuration Files'''<br />
<br />
These are the core configuration files for Arch Linux. Only the most basic configuration files are listed here. If you need help configuring a specific service, please read the appropriate manpage or refer to any online documentation you need. In many cases, the Arch Linux [http://wiki.archlinux.org/ Wiki] and [http://bbs.archlinux.org/ forums] are a rich source for help as well.<br />
<br />
* /etc/rc.conf<br />
* [[Fstab | /etc/fstab]]<br />
* /etc/mkinitcpio.conf<br />
* /etc/modprobe.conf<br />
* /etc/resolv.conf<br />
* /etc/hosts<br />
* /etc/hosts.deny<br />
* /etc/hosts.allow<br />
* /etc/locale.gen<br />
* /etc/pacman.d/mirrorlist<br />
<br />
<br />
'''/etc/rc.conf'''<br />
<br />
This is the main configuration file for Arch Linux. It allows you to set your keyboard,timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more.<br />
<br />
'''LOCALE:''' This sets your system language, which will be used by all i18n-friendly applications and utilities. See locale.gen below for available options. This setting's default is fine for US English users.<br />
<br />
'''HARDWARECLOCK:''' Either UTC if your BIOS clock is set to UTC, or localtime if your BIOS clock is set to your local time. If you have an OS installed which cannot handle UTC BIOS times correctly, like Windows, choose localtime here, otherwise you should prefer UTC, which makes daylight savings time a non-issue and has a few other positive aspects.<br />
<br />
'''USEDIRECTISA:''' If set to "yes" it tells hwclock to use explicit I/O instructions to access the hardware clock. Otherwise, hwclock will try to use the /dev/rtc device it assumes to be driven by the rtc device driver. This setting's default "no" is fine for people not using an ISA machine.<br />
<br />
'''TIMEZONE:''' Specifies your time zone. Possible time zones are the relative path to a zoneinfo file starting from the directory /usr/share/zoneinfo. For example, a German timezone would be Europe/Berlin, which refers to the file /usr/share/zoneinfo/Europe/Berlin. If you don't know the exact name of your timezone file, worry about it later.<br />
<br />
'''KEYMAP:''' Defines the keymap to load with the loadkeys program on bootup. Possible keymaps are found in /usr/share/kbd/keymaps. Please note that this setting is only valid for your TTYs, not any graphical window managers or X! Again, the default is fine for US users.<br />
<br />
'''CONSOLEFONT:''' Defines the console font to load with the setfont program on bootup. Possible fonts are found in /usr/share/kbd/consolefonts.<br />
<br />
'''CONSOLEMAP:''' Defines the console map to load with the setfont program on bootup. Possible maps are found in /usr/share/kbd/consoletrans. You will want to set this to a map suitable for your locale (8859-1 for Latin1, for example) if you're using an UTF-8 locale above, and use programs that generate 8-bit output. If you're using X11 for everyday work, don't bother, as it only affects the output of Linux console applications.<br />
<br />
'''USECOLOR:''' Enable (or disable) colorized status messages during boot-up.<br />
<br />
'''MOD_AUTOLOAD:''' If set to "yes", udev will be allowed to load modules as necessary upon bootup. If set to "no", it will not.<br />
<br />
'''MODULES:''' In this array you can list the names of modules you want to load during bootup without the need to bind them to a hardware device as in the modprobe.conf. Simply add the name of the module here, and put any options into modprobe.conf if need be. Prepending a module with a bang ('!') will blacklist the module, and not allow it to be loaded.<br />
<br />
'''USELVM:''' Set to "yes" to run a vgchange during sysinit, thus activating any LVM groups<br />
<br />
'''HOSTNAME:''' Set this to the hostname of the machine, without the domain part. This is totally your choice, as long as you stick to letters, digits and a few common special characters like the dash.<br />
<br />
'''INTERFACES:''' Here you define the settings for your networking interfaces. The default lines and the included comments explain the setup well enough. If you use DHCP, 'eth0="dhcp"' should work for you. If you do not use DHCP just keep in mind that the value of the variable (whose name must be equal to the name of the device which is supposed to be configured) equals the line which would be appended to the ifconfig command if you were to configure the device manually in the shell.<br />
<br />
'''ROUTES:''' You can define your own static network routes with arbitrary names here. Look at the example for a default gateway to get the idea. Basically the quoted part is identical to what you'd pass to a manual route add command, therefore reading man route is recommended if you don't know what to write here, or simply leave this alone.<br />
<br />
'''[[Network_Profiles | NET_PROFILES]]:''' Enables certain network profiles at bootup. Network profiles provide a convenient way of managing multiple network configurations, and are intended to replace the standard INTERFACES/ROUTES setup that is still recommended for systems with only one network configuration. If your computer will be participating in various networks at various times (eg, a laptop) then you should take a look at the /etc/network-profiles/ directory to set up some profiles. There is a template file included there that can be used to create new profiles. This now requires the netcfg package.<br />
<br />
'''DAEMONS:''' This array simply lists the names of those scripts contained in /etc/rc.d/ which are supposed to be started during the boot process. If a script name is prefixed with a bang (!), it is not executed. If a script is prefixed with an "at" symbol (@), then it will be executed in the background, ie. the startup sequence will not wait for successful completion before continuing. Usually you do not need to change the defaults to get a running system, but you are going to edit this array whenever you install system services like sshd, and want to start these automatically during bootup.<br />
<br />
<br />
'''[[Fstab | /etc/fstab]]'''<br />
<br />
Your filesystem settings and mountpoints are configured here. The installer should have created the necessary entries for you, but you should look over it and make sure it's right. If you are using an encrypted root device, LVM or RAID, you will likely need to change the UUIDs the installer has inserted for you to device names.<br />
<br />
<br />
'''/etc/mkinitcpio.conf'''<br />
<br />
This file allows you to fine-tune the initial ramdisk for your system. The ramdisk is a gzipped image that is read by the kernel during bootup. Its purpose is to bootstrap the system to the point where it can access the root filesystem. This means it has to load any modules that are required to "see" things like IDE, SCSI, or SATA drives (or USB/FW, if you are booting off a USB/FW drive). Once the ramdisk loads the proper modules, either manually or through udev, it passes control to the Arch system and your bootup continues. For this reason, the ramdisk only needs to contain the modules necessary to access the root filesystem. It does not need to contain every module you would ever want to use. The majority of your everyday modules will be loaded later on by udev, during the init process.<br />
<br />
By default, mkinitcpio.conf is configured to autodetect all needed modules for IDE, SCSI, or SATA systems through so-called HOOKS. This means the default initrd should work for almost everybody. You can edit mkinitcpio.conf and remove the subsystem HOOKS (ie, IDE, SCSI, RAID, USB, etc) that you don't need. You can customize even further by specifying the exact modules you need in the MODULES array and remove even more of the hooks, but proceed with caution.<br />
<br />
If you're using RAID or encryption on your root filesystem, then you'll have to tweak the RAID/CRYPT settings near the bottom. See the wiki pages for RAID/LVM, filesystem encryption, and mkinitcpio for more info. If you're using a non-US keyboard uou should also add the 'keymap' hook, as well as the 'usbinput' hook if you are using a USB keyboard.<br />
<br />
<br />
'''/etc/modprobe.conf'''<br />
<br />
This tells the kernel which modules it needs to load for system devices, and what options to set. For example, to have the kernel load your Realtek 8139 ethernet module when it starts the network (ie. tries to setup eth0), use this line:<br />
alias eth0 8139too<br />
Most people will not need to edit this file.<br />
<br />
<br />
'''/etc/resolv.conf'''<br />
<br />
Use this file to manually setup your nameserver(s) that you want to use. It should basically look like this:<br />
search domain.tld<br />
nameserver 192.168.0.1<br />
nameserver 192.168.0.2<br />
Replace domain.tld and the ip addresses with your settings. The so-called search domain specifies the default domain that is appended to unqualified hostnames automatically. By setting this, a ping myhost will effectively become a ping myhost.domain.tld with the above values. These settings usually aren't mighty important, though, and most people should leave them alone for now. If you use DHCP, this file will be replaced with the correct values automatically when networking is started, meaning you can and should happily ignore this file.<br />
<br />
<br />
'''/etc/hosts'''<br />
<br />
This is where you stick hostname/ip associations of computers on your network. If a hostname isn't known to your DNS, you can add it here to allow proper resolving, or override DNS replies. You usually don't need to change anything here, but you might want to add the hostname and hostname + domain of the local machine to this file, resolving to the IP of your network interface. Some services, postfix for example, will bomb otherwise. If you don't know what you're doing, leave this file alone until you read man hosts.<br />
<br />
<br />
'''/etc/hosts.deny'''<br />
<br />
This file denies network services access. By default all network services are denied.<br />
ALL: ALL: DENY<br />
<br />
<br />
'''/etc/hosts.allow'''<br />
<br />
This file allows network services access. Enter the services you want to allow here. eg. to allow all machines to connect via ssh:<br />
sshd: ALL: ALLOW<br />
<br />
<br />
'''/etc/locale.gen'''<br />
<br />
This file contains a list of all supported locales and charsets available to you. When choosing a LOCALE in your /etc/rc.conf or when starting a program, it is required to uncomment the respective locale in this file, to make a "compiled" version available to the system, and run the locale-gen command as root to generate all uncommented locales and put them in their place afterwards. You should uncomment all locales you intend to use.<br />
<br />
During the installation process, you do not need to run locale-gen manually, this will be taken care of automatically after saving your changes to this file. By default, all locales are enabled that would make sense by rc.conf's LOCALE= setting. To make your system work smoothly, you should edit this file and uncomment at least the one locale you're using in your rc.conf.<br />
<br />
<br />
'''/etc/pacman.d/mirrorlist'''<br />
<br />
This file contains a list of mirrors from which pacman will download packages for the official Arch Linux repositories. The mirrors are tried in the order in which they are listed. The $repo macro is automatically expanded by pacman depending on the repository (core, extra, community or testing).<br />
<br />
If you are performing an FTP installation, the mirror you used to download the packages from will be added on top of the mirror list, in order to be used as the default mirror in your new Arch Linux system.<br />
<br />
<br />
'''Set Root Password'''<br />
<br />
At this step, you must set the root password for your system. Choose this password carefully, preferably as a mixture of alphanumeric and special characters, since this password allows you to modify critical parts of your system.<br />
<br />
When you are done editing the configuration files choose Return to return to the main menu. The setup will regenerate the initial ramdisk to enable the changes you made in mkinitcpio.conf.<br />
<br />
====Install Bootloader====<br />
<br />
Install Bootloader will install a bootloader on your hard drive, either GRUB or NONE in case you have a bootloader already installed and want to use that one instead. If you choose to install GRUB, the setup script will want you to examine the appropriate configuration file to confirm the proper settings.<br />
<br />
<br />
'''/boot/grub/menu.lst'''<br />
<br />
You should check and modify this file to accommodate your boot setup if you want to use GRUB, otherwise you will have to modify your existing bootloader's configuration file. The installer will have pre-populated this file using UUID entries which you may have to change in the same cases you'd need to change them in your fstab.<br />
<br />
After checking your bootloader configuration for correctness, you'll be prompted for a partition to install the loader to. Unless you're using yet another boot loader, you should install GRUB to the MBR of the installation disk, which is usually represented by the appropriate device name without a number suffix.<br />
<br />
====Exit Install====<br />
<br />
Exit the Installer, remove the media you used for the installation, type reboot at the command line and cross your fingers. If your system boots up, you can log in as root with the password you set during installation.<br />
<br />
Congratulations! Welcome to your new Arch Linux system!<br />
<br />
==Package Management==<br />
<br />
Pacman is the package manager which tracks all the software installed on your system. It has simple dependency support and uses the standard gzipped tar archive format for all packages. Some common tasks you might need to use during installation, are explained below with their respective commands. For an extensive explanation of pacman's options, read man pacman or consult the Arch Linux [http://wiki.archlinux.org/index.php/Pacman Wiki].<br />
<br />
<br />
'''Typical tasks:'''<br />
<br />
* Refreshing the package list<br />
# pacman --sync --refresh<br />
# pacman -Sy<br />
This will retrieve a fresh master package list from the repositories defined in the /etc/pacman.conf file and decompress it into the database area.<br />
* Search the repositories for a package<br />
# pacman --sync --search <regexp><br />
# pacman -Ss <regexp><br />
Search each package in the sync databases for names or descriptions that match regexp.<br />
* Display specific not installed package info<br />
# pacman --sync --info foo<br />
# pacman -Si foo<br />
Displays information on the not yet installed package foo (size, install date, build date, dependencies, conflicts, etc.)<br />
* Adding a package from the repositories<br />
# pacman --sync foo<br />
# pacman -S foo<br />
Retrieve and install package foo, complete with all dependencies it requires. Before using any sync option, make sure you refreshed the package list.<br />
* List installed packages<br />
# pacman --query<br />
# pacman -Q<br />
Displays a list of all installed packages in the system.<br />
* Check if a specific package is installed<br />
# pacman --query foo<br />
# pacman -Q foo<br />
This command will display the name and version of the foo package if it is installed, nothing otherwise.<br />
* Display specific package info<br />
# pacman --query --info foo<br />
# pacman -Qi foo<br />
Displays information on the installed package foo (size, install date, build date, dependencies, conflicts, etc.)<br />
* Display list of files contained in package<br />
# pacman --query --list foo<br />
# pacman -Ql foo<br />
Lists all files belonging to package foo.<br />
* Find out which package a specific file belongs to<br />
# pacman --query --owns /path/to/file<br />
# pacman -Qo /path/to/file<br />
This query displays the name and version of the package which contains the file referenced by it's full path as a parameter.<br />
<br />
==APPENDIX==<br />
<br />
See [[Official Arch Linux Install Guide Appendix]] for some related unofficial documentation, new users may find useful.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Official_Installation_Guide&diff=62209
Official Installation Guide
2009-02-16T23:35:54Z
<p>Phrakture: Protected "Official Arch Linux Install Guide" [edit=autoconfirmed:move=autoconfirmed]</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|General installation documentation for the Arch Linux distribution.}}<br />
{{Article summary heading|Available Languages}}<br />
{{i18n_entry|English|Official Arch Linux Install Guide}}<br />
{{i18n_entry|简体中文|Arch Linux 官方安装指南}}<br />
{{i18n_entry|正體中文|Arch Linux 官方安裝指南}}<br />
{{i18n_entry|Česky|Oficiální instalační příručka (Česky)}}<br />
{{i18n_entry|Русский|Руководство по установке}}<br />
{{i18n_entry|Español|Guía oficial de Instalación}}<br />
{{i18n_entry|Italiano|Official Arch Linux Install Guide (Italiano)}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Beginners Guide}} (If you are new to Arch)<br />
{{Article summary end}}<br />
<br />
<br />
==Introduction==<br />
<br />
===What is Arch Linux?===<br />
<br />
Arch Linux is an independently developed GNU/Linux distribution. Development is focused on a balance of simplicity, elegance, code-correctness and bleeding edge software. It's lightweight and simple design makes it easy to extend and mold into whatever kind of system you're building.<br />
<br />
The Arch system and binary packages are compiled for i686 and x86-64 processors.<br />
<br />
===License===<br />
<br />
Arch Linux, pacman, documentation, and scripts are copyright<br />
©2002-2007 by Judd Vinet, ©2007-2008 by Aaron Griffin and are licensed under the GNU General Public License Version 2.<br />
<br />
==Installing Arch Linux==<br />
<br />
===Pre-Installation===<br />
<br />
Arch Linux is optimized for the i686 processor and therefore will not<br />
run on any lower or incompatible generations of x86 CPUs<br />
(i386,i486,i586). A Pentium II or AMD Athlon processor or higher is<br />
required. Modern VIA C3 processors are also supported. x86-64 architectures are also officially supported.<br />
<br />
There is a community-driven project that provides packages for i586<br />
and ppc. See this site for more information.<br />
<br />
Before installing Arch Linux, you should decide which installation<br />
method you would like to use. Arch Linux provides two different<br />
bootable ISO images for a CD-ROM installation. Installing Arch from a USB stick or from within another already installed OS is also supported.<br />
<br />
As the preferred method of installation is the flexible CD-ROM based<br />
installation, we offer you two variants of the installation medium<br />
which only differ in terms of supplied packages. You can instruct the<br />
installer to obtain the packages via FTP using any of these images,<br />
and all images can also be used as fully functional live cds.<br />
<br />
* The core iso (~300MB) is a live environment which contains a snapshot of the entire /core repository. Packages are divided into 4 categories: BASE, SUPPORT, DEVEL and LIB. RAID/LVM are fully supported; all necessary packages are included within /core. Installing from a medium created with this image results in a completely functional GNU/Linux system, without any frills, expecting to be used from the command line; the Linux kernel, GNU toolchain and a few extra modules and libraries. This image is ideally suited for those who have a rather slow or nonexistent internet connection on the candidate machine, making an FTP install unfeasible. The name of the iso will be "archlinux-i686-2008.xx-x.core.iso", according to your architecture<br />
* The FTP iso (~175MB) is a live environment, containing no packages at all, but rather pulls in all software over your internet connection. If you have access to a fast and easily setup internet connection, this method may be preferred, since the completed system will be completely up-to-date, without requiring further upgrades from the package versions included on the Core CD. Of course all packages you choose to install have to be downloaded from somewhere, but at least you don't have to update the system directly after installation, saving yourself some hassle. If your network connection is cheap and fast, choose this image. <br />
{{Box Note | When choosing a pacman mirror during installation, keep in mind that archlinux.org is throttled to 50Kb/s.}}<br />
<br />
If you do not have a CD-ROM drive attached to your computer, you may refer to [[Install_from_USB_stick | this guide]] to install Arch Linux using a USB stick. If you do not have a USB stick, there are [[Hard_Disk_Installation | instructions]] for installing from a hard disk partition, such as a swap partition. If you want to use an existing distribution to install Arch Linux, please follow this [[Install_From_Existing_Linux | guide]].<br />
<br />
You can also purchase a cd online from OSDisc, shipping nearly<br />
world-wide.<br />
<br />
Using a dialup PPP connection to gain access to the internet during<br />
the install process is now supported. ppp utilities, rp-pppoe<br />
and the ISDN userspace utilities are included in the installation<br />
media.<br />
<br />
Since version 2007.08, isos are true live systems and run like any installed arch system.<br />
<br />
Some highlights: <br />
* pacman is included, to allow installation of any other needed packages for install environment.<br />
* complete /etc/rc.d/ and /etc/rc.conf support<br />
* complete Arch network support, including ssh,telnet and portmap services<br />
* '''links''' and '''naim''' included to be able to communicate over the internet.<br />
<br />
If, during the installation process, you find you require a more verbose guide or explanation, you may also find the Arch Linux [[Beginners Guide]] helpful. <br />
<br />
What You Will Need<br />
<br />
* a working knowledge of GNU/Linux and the candidate machine's hardware<br />
* Arch Linux installation media (see the mirror list)<br />
* an i686 or x86-64 processor (PPro, Pentium 2 or higher, Athlon/Duron, etc. Note that AMD K6, Transmeta Crusoe, CyrixIII, and VIA-C3 are NOT supported.)<br />
* 160 MB RAM<br />
* some time to kill<br />
<br />
===Acquiring Arch Linux===<br />
<br />
You can download Arch Linux from any of the Arch Linux [http://www.archlinux.org/download/ mirrors]. Just follow the links into the "iso" directory and choose the version you wish to install. In general, you are advised to download the latest version as this helps avoid any difficulties during your initial update.<br />
<br />
===Preparing Installation Media===<br />
<br />
*Download <mirror>/iso/<your_architecture>/archlinux-<version>.iso (path relative to mirror root)<br />
*Download <mirror>/iso/<your_architecture>/md5sum-<version>.txt<br />
*Verify the integrity of the .iso image using md5sum:<br />
md5sum archlinux-<version>.iso<br />
*Burn the .iso image to a blank CD-R (this step varies depending on the OS/software you're using). If you want to download the core, ftp or a beta ISO instead, use the appropriate filename, ie: arch-0.8-core.iso instead of arch-0.8.iso, likewise for the md5sum.<br />
*Write down all your network settings so you can enter them into setup later, if you want to install via FTP:<br />
**IP Address<br />
**Subnet Mask<br />
**Gateway<br />
**Ethernet Module for your network card (eg.: eepro100, 8139too, ne2k-pci, etc.)<br />
<br />
===Using the CD-ROM===<br />
If you are familiar with the boot process, you may skip this <br />
explanation and continue with [[#Common Installation Procedure | Common Installation Procedure]], which outlines <br />
the actual process of installing Arch Linux.<br />
<br />
Reboot your computer with the Arch Linux Installation CD in the drive.<br />
Make sure your BIOS is configured to boot from your CD-ROM.<br />
Refer to your motherboard manual or system manufacturer documentation for<br />
details.<br />
<br />
At the end of the boot procedure, you shall be dropped into a root<br />
shell. At this point you are ready to commence the actual<br />
installation.<br />
<br />
===Common Installation Procedure===<br />
<br />
Installation Steps:<br />
<br />
#Loading a non-US Keymap<br />
#Running Setup<br />
#Configure Network (FTP Install only)<br />
#Prepare Hard Drive<br />
##Auto-Prepare<br />
##Partition Hard Drives<br />
##Set Filesystem Mountpoints<br />
#Select Packages<br />
#Install Packages<br />
#Configure System<br />
#Install Bootloader<br />
#Exit Install<br />
<br />
Using the available shell tools, experienced users are also able to<br />
prepare the hard drive or any devices needed for the installation<br />
before starting the installer. You may simply skip this paragraph if<br />
you don't see any immediate need for further manual interaction. Note<br />
that the Arch Linux installation media also contains a /arch/quickinst<br />
script for experienced users. This script installs the "base" set of<br />
packages to a user-specified destination directory. If you are doing<br />
an exotic install with fun things like RAID and LVM, or do not want to<br />
use the installer at all, you will probably want to use the quickinst<br />
script. All the cool kids are doing it.<br />
<br />
====Login and Loading a non-US Keymap====<br />
<br />
Login as 'root'. If you have a non-US keyboard layout do:<br />
km<br />
at the prompt.<br />
<br />
====Running Setup====<br />
<br />
Begin the installer script:<br />
/arch/setup<br />
After an informational message you will be prompted for the installation method<br />
of your choice. If you have a fast internet connection, you might<br />
prefer the FTP installation to ensure you get the latest packages<br />
instead of using the potentially outdated CD contents. <br />
<br />
When navigating the setup script, make sure to select DONE from<br />
the submenus after performing each step. This saves any settings you<br />
make in preparation for the next step. Further, avoid arbitrary steps<br />
throughout the installation process as this can also confuse the<br />
installer.<br />
<br />
It's actually rather easy to set up your own FTP package mirror or<br />
create your own bootable installation CD with the packages you need,<br />
making the task of installing several instances of Arch Linux across<br />
multiple machines rather simple, while at the same time saving a lot<br />
of mirror bandwidth. Make your life and ours easier, and look into<br />
these alternatives!<br />
<br />
When choosing a CD-ROM or OTHER SOURCE install you will only be able<br />
to install packages contained on the CD, which may be quite old, or<br />
packages stored on a medium you were able to mount (DVD, USB stick or<br />
similar) somewhere in the filesystem tree manually. Of course, it has<br />
the advantage of not needing an internet connection, and is therefore<br />
the recommended choice for dialup users or those unable or unwilling to download the entire package set via ftp.<br />
<br />
Next, you will be presented with the installer menu, listing the necessary steps in the order in which they should be completed.<br />
<br />
Virtual consoles 1-6 are active in the live environment. At any point in the install process, you can switch to your 5th virtual console (ALT-F5) to view the shell output from installer script. Use (ALT-F1) to get back to your first console where<br />
the installer is running.<br />
<br />
====Configure Network (FTP Install only)====<br />
<br />
Configure Network will allow you to install and configure your network<br />
device.<br />
<br />
A list of all currently available network devices is presented to you.<br />
If no ethernet device is available, load the necessary modules manually from another virtual console. Alternatively,<br />
you may probe for a network module on the following screen by selecting the Probe command. <br />
<br />
When the correct module is loaded, your network card will be<br />
listed. Select the ethernet device you wish to configure<br />
and you will be given the option to configure your network with DHCP.<br />
If you're connected to a DHCP server, hit YES and let the installer do<br />
the rest. If you select NO, you will be asked to enter the networking<br />
information manually.<br />
Either way, your network should be successfully configured, and if<br />
you're of the skeptical kind, you may check connectivity using<br />
standard tools like ping on another console.<br />
<br />
As automations are not perfect, you may not be able to successfully<br />
use the installer to set up your network. In these rare cases, set up you network device manually in one of the consoles.<br />
<br />
====Prepare Hard Drive====<br />
<br />
Prepare Hard Drive presents a submenu offering two<br />
alternatives of preparing the target drive for installation.<br />
<br />
The first choice is Auto-Prepare, which will automatically partition<br />
your hard drive into a /boot, swap, and root partition, and then<br />
create filesystems on all three. These partitions will also be<br />
automatically mounted in the proper place. To be exact, this option<br />
will create:<br />
* 32 MB ext2 /boot partition<br />
* 256 MB swap partition<br />
* root and /home partition with the remaining space. (Root and /home will share the same file system type if choosing the auto-prepare option).<br />
<br />
Actual sizes may vary slightly, due to different hard disk geometries.<br />
You can choose this option if you don't know much about hard drive<br />
partitions, but be warned:<br />
<br />
AUTO-PREPARE WILL ERASE ALL DATA ON THE CHOSEN HARD DRIVE!<br />
Read the warning presented by the installer very carefully, and make<br />
sure the correct device is about to be partitioned!<br />
<br />
A way to verify your choice for a device to partition would be to open<br />
another terminal (ALT-F2, Enter) and enter<br />
cfdisk -P s <name of device><br />
<br />
This will display the current partition table of the selected device,<br />
which should suffice to identify the hard disk.<br />
<br />
If you prefer to do the partitioning manually, use '''Partition Hard Drives''' and '''Set Filesystem Mountpoints''' to prepare the target media according to your specifications, as outlined below. After successful preparation, choose Return to Main Menu.<br />
<br />
====Partition Hard Drives====<br />
<br />
Partition Hard Drives should be skipped if you chose Auto-Prepare<br />
already!<br />
<br />
Otherwise you should select the disk(s) you want to partition, and<br />
you'll be dropped into the cfdisk program where you can freely modify<br />
the partitioning information until you [Write] and [Quit].<br />
<br />
You will need at least a root partition to continue the installation,<br />
and it's helpful to note somewhere which partition you're going to<br />
mount where, as you'll be asked exactly that in the next step.<br />
<br />
====Set Filesystem Mountpoints====<br />
<br />
Set Filesystem Mountpoints should also be skipped if you chose to<br />
Auto-Prepare your hard drive. You should select this option once the<br />
partition information is edited to your liking with the previous menu<br />
selection, or already existent through whatever other means.<br />
<br />
First, select the previously created swap partition from the list, or NONE, if you<br />
do not want to use a swap partition. Using a swap ''file'' is not directly<br />
supported by the installer; Instead choose NONE here, finish the<br />
mountpoint associations, and activate a swap file on your desired,<br />
formatted partition with the swapon command.<br />
<br />
After setting up the swap partition, you will be asked to specify the<br />
partition to be used as the root partition. This is mandatory.<br />
<br />
The association process is then repeated until you choose DONE from<br />
the list, ideally after all listed partitions have been associated<br />
with their intended mountpoints. The installer will suggest /boot for<br />
all following mountpoints after choosing swap and root.<br />
<br />
Each time a partition to mount is specified, you will be asked if you<br />
want to create a filesystem on the respective partition. Selecting<br />
YES, will prompt you for the filesystem type to create. The partition will then be<br />
formatted with the chosen filesystem type, destroying all data in the<br />
process. <br />
<br />
If additional mountpoints are desired, for example, a separate /boot or /home partition, you will be able to do so. Simply<br />
* select a partition to mount<br />
* choose a filesystem (if you want to create one instead of keeping existing data)<br />
* enter a unique mountpoint for the partition<br />
<br />
Repeat these steps until satisfied, then select DONE to create<br />
any filesystems and mount the partitions in their respective places.<br />
Before the actual formatting is done, the installer will present to<br />
you a list of all choices for review. After formatting and<br />
mounting all partitions, you may return to the Main Menu and proceed<br />
with the next step.<br />
<br />
===Select Packages===<br />
Now we shall select packages to install in our system.<br />
*Core ISO: Choose CD as source and select the appropriate CD drive if you have more than one.<br />
*FTP ISO: Select an FTP/HTTP mirror. ''Note that archlinux.org is throttled to 50KB/s''. ''Note also that some mirrors don't support resuming in case of download failure (e.g. ftp.free.fr)''<br />
<br />
The installer will always install a basic working system. You are given the option to install some basic development tools, such as GCC, autoconf, automake, make and some other useful packages such as openssh, sudo, iptable and some wifi packages.<br />
<br />
If you don't want to install any of the extra packages during the installation, you need to select the one and only package category '''BASE-DEVEL''' using the space bar.<br />
<br />
The next screen will present you with the selected packages within '''BASE-DEVEL'''.<br />
<br />
Once you're done selecting the packages you need, leave the selection<br />
screen and continue to the next step, Install Packages.<br />
<br />
====Install Packages====<br />
<br />
Install Packages will now install the base system and any other packages you<br />
selected with resolved dependencies onto your harddisk. Don't be<br />
surprised if more packages are installed than you selected! Those<br />
packages are dependencies for your selection, and the installer will<br />
not explicitly ask for permission to install these extra packages, as<br />
it assumes you know what you're doing.<br />
<br />
After the package selection, the installer will not check for free<br />
space on the target! This seemingly trivial task would eat up<br />
considerable time, and therefore the installer simply assumes to have<br />
enough free space on the target partition(s). In case it doesn't, the<br />
installation will fail in various funny ways. A df -h in another<br />
terminal might show that one or more of the targets mounted below /mnt<br />
have been filled up, causing mischief. Consider repartitioning or<br />
selecting a smaller set of packages.<br />
<br />
Error messages and debugging output is echoed to vc/5 (ALT-F5). After the packages have been installed, proceed to the next step, Configure System.<br />
<br />
Pacman will ask you whether it should keep the installed packages in cache. As you can delete them later using 'pacman -Scc', selecting 'yes' is recommended.<br />
<br />
==Configure System==<br />
<br />
Configure System allows you to edit the configuration files crucial<br />
for your newly installed system. Initially you will be asked whether<br />
to allow the hwdetect script to try and detect your hardware, and<br />
produce some (even more) sensible defaults for your configuration<br />
files. Unless you're having problems/crashes, you should let it have<br />
its way, and work from what it generates.<br />
<br />
Answer the following questions about RAID, LVM and encrypted volumes<br />
with Yes, if your root partition resides on a RAID, LVM or encrypted<br />
volume, respectively, to automatically add the necessary HOOKS to the<br />
mkinitcpio.conf. Otherwise you will get a kernel panic during boot, as<br />
your root partition will not be accessible at the time of boot. Most<br />
people will answer these questions with No, though, and not waste a<br />
second thought about it.<br />
<br />
After this automatic preconfiguration you'll be asked for your<br />
favourite editor to use for manually fine-tuning the generated<br />
configuration files, either VIM or nano. When in doubt, choose nano.<br />
<br />
===Configuration Files===<br />
These are the core configuration files for Arch Linux, to be configured with a text-editor. Only the most basic configuration<br />
files are listed here. If you need help configuring a specific<br />
service, please read the appropriate manpage or refer to any online<br />
documentation you need. In many cases, the Arch Linux Wiki and forums<br />
are a rich source for help as well.<br />
<br />
{{Box Note | Arch Linux does not use any abstraction layers to administrate your system. As a result, you can usually stick to any instructions published by the author of a particular software package, or whatever you find in a search engine of your choice, and it likely will work without confusing your system, because your system simply does not 'care'.}}<br />
<br />
'''List of Configuration Files'''<br />
* Setup-relevant configuration files:<br />
** /etc/rc.conf<br />
** /etc/hosts<br />
** [[Fstab | /etc/fstab]]<br />
** /etc/mkinitcpio.conf<br />
** /etc/modprobe.conf<br />
** /etc/resolv.conf<br />
** /etc/locale.gen<br />
** /boot/grub/menu.lst<br />
** /etc/lilo.conf<br />
* Additional configuration files:<br />
** /etc/conf.d/*<br />
** /etc/profile<br />
<br />
<br />
'''/etc/rc.conf'''<br />
<br />
This is the main configuration file for Arch Linux. It allows you to<br />
set your keyboard, timezone, hostname, network, daemons to run and<br />
modules to load at bootup, profiles, and more. You should read through<br />
all the settings in this file and make sure you understand them, and<br />
change them where appropriate:<br />
<br />
LOCALE<br />
This sets your system language, which will be used by all<br />
i18n-friendly applications and utilities. See locale.gen below<br />
for available options. This setting's default is fine for US <br />
English users.<br />
<br />
HARDWARECLOCK<br />
Either UTC if your BIOS clock is set to UTC, or localtime if<br />
your BIOS clock is set to your local time. If you have an OS<br />
installed which cannot handle UTC BIOS times correctly, like<br />
Windows, choose localtime here, otherwise you should prefer<br />
UTC, which makes daylight savings time a non-issue and has a<br />
few other positive aspects.<br />
<br />
TIMEZONE<br />
Specifies your time zone. Possible time zones are the relative<br />
path to a zoneinfo file starting from the directory<br />
/usr/share/zoneinfo. For example, a german timezone would be<br />
Europe/Berlin, which refers to the file<br />
/usr/share/zoneinfo/Europe/Berlin. If you don't know the exact<br />
name of your timezone file, worry about it later.<br />
<br />
KEYMAP<br />
Defines the keymap to load with the loadkeys program on bootup.<br />
Possible keymaps are found in /usr/share/kbd/keymaps. Please<br />
note that this setting is only valid for your TTYs, not any<br />
graphical window managers or X! Again, the default is fine for<br />
US users.<br />
<br />
CONSOLEFONT<br />
Defines the console font to load with the setfont program on<br />
bootup. Possible fonts are found in<br />
/usr/share/kbd/consolefonts.<br />
<br />
CONSOLEMAP<br />
Defines the console map to load with the setfont program on<br />
bootup. Possible maps are found in /usr/share/kbd/consoletrans.<br />
You will want to set this to a map suitable for your locale<br />
(8859-1 for Latin1, for example) if you're using an utf8 locale<br />
above, and use programs that generate 8-bit output. If you're<br />
using X11 for everyday work, don't bother, as it only affects<br />
the output of GNU/Linux console applications.<br />
<br />
USECOLOR<br />
Enable (or disable) colorized status messages during boot-up.<br />
<br />
MOD_AUTOLOAD<br />
If set to "yes", Arch will scan your hardware at bootup and<br />
attempt to automatically load the proper modules for your<br />
system. This is done with the hwdetect utility.<br />
<br />
MOD_BLACKLIST<br />
This is an array of modules that you do not want to be loaded<br />
at bootup. For example, if you don't want that annoying PC<br />
speaker, you could blacklist the pcspkr module.<br />
<br />
MODULES<br />
In this array you can list the names of modules you want to<br />
load during bootup without the need to bind them to a hardware<br />
device as in the modprobe.conf. Simply add the name of the<br />
module here, and put any options into the modprobe.conf if need<br />
be. Prepending a module with a bang ('!') will not load the<br />
module during bootup (this is not the same as MOD_BLACKLIST!),<br />
thus allowing to "comment out" certain modules if necessary. A<br />
benefit of specifying networking modules here is that ethernet<br />
cards covered by the listed modules will always be detected in<br />
the order the modules are listed. This prevents the dreaded<br />
interface confusion where your ethernet hardware is assigned to<br />
seemingly random interfaces after each boot. An even better way<br />
to handle this is using static interface labels by configuring<br />
udev appropriately, though.<br />
<br />
USELVM<br />
Set to "YES" to run a vgchange during sysinit, thus activating<br />
any LVM groups. If you have no idea what this means, don't<br />
bother.<br />
<br />
HOSTNAME<br />
Set this to the hostname of the machine, without the domain<br />
part. This is totally your choice, as long as you stick to<br />
letters, digits and a few common special characters like the<br />
dash. Don't be too creative here, though, and when in doubt,<br />
use the default.<br />
<br />
INTERFACES<br />
Here you define the settings for your networking interfaces.<br />
The default lines and the included comments explain the setup<br />
well enough. If you use DHCP, 'eth0="dhcp"' should work for you. If you do not use DHCP to configure a device, just<br />
keep in mind that the value of the variable (whose name must be<br />
equal to the name of the device which is supposed to be<br />
configured) equals the line which would be appended to the<br />
ifconfig command if you were to configure the device manually<br />
in the shell.<br />
<br />
ROUTES<br />
You can define your own static network routes with arbitrary<br />
names here. Look at the example for a default gateway to get<br />
the idea. Basically the quoted part is identical to what you'd<br />
pass to a manual route add command, therefore reading man route<br />
is recommended if you don't know what to write here, or simply<br />
leave this alone.<br />
<br />
[[Network_Profiles | NET_PROFILES]]<br />
Enables certain network profiles at bootup. Network profiles<br />
provide a convenient way of managing multiple network<br />
configurations, and are intended to replace the standard<br />
INTERFACES/ROUTES setup that is still recommended for systems<br />
with only one network configuration. If your computer will be<br />
participating in various networks at various times (eg, a<br />
laptop) then you should take a look at the<br />
/etc/network-profiles/ directory to set up some profiles. There<br />
is a template file included there that can be used to create<br />
new profiles.<br />
<br />
DAEMONS<br />
This array simply lists the names of those scripts contained in<br />
/etc/rc.d/ which are supposed to be started during the boot<br />
process, as well as the order in which they start. If a script name is prefixed with a bang (!), it is<br />
not executed. If a script is prefixed with an "at" symbol (@),<br />
then it will be executed in the background, ie. the startup<br />
sequence will not wait for successful completion before<br />
continuing. Usually you do not need to change the defaults to<br />
get a running system, but you are going to edit this array<br />
whenever you install system services like sshd, and want to<br />
start these automatically during bootup. This is basically<br />
Arch's way of handling what others handle with various symlinks<br />
to an init.d directory.<br />
<br />
<br />
'''/etc/hosts'''<br />
<br />
This is where you stick hostname/ip associations of computers on your<br />
network. If a hostname isn't known to your DNS, you can add it here to<br />
allow proper resolving, or override DNS replies. You usually don't<br />
need to change anything here, but you might want to add the hostname<br />
and hostname + domain of the local machine to this file, resolving to<br />
the IP of your network interface. Some services, postfix for example,<br />
will bomb otherwise. If you don't know what you're doing, leave this<br />
file alone until you read man hosts.<br />
<br />
<br />
'''[[Fstab | /etc/fstab]]'''<br />
<br />
Your filesystem settings and mountpoints are configured here. The<br />
installer should have created the necessary entries for you, but you<br />
should look over it and make sure it's right, especially when using an<br />
encrypted root device, LVM or RAID.<br />
<br />
With the current kernel, an important change has been introduced<br />
pertaining to the ATA/IDE subsystem. The new pata (Parallel ATA)<br />
drivers replace the legacy IDE subsystem, and one important change is<br />
that the naming scheme for IDE disks has changed from the old hda,<br />
hdb, etc. to also use device names of the type sda, sdb, etc, just<br />
like SCSI and SATA devices do. Because of this, when using the new<br />
pata driver in the HOOKS of the /etc/mkinitcpio.conf, remember to use<br />
the appropriate device names in your /etc/fstab and bootloader<br />
configuration! Alternatively, you could use the /dev/disk/by-uuid/...<br />
or /dev/disk/by-label/... representations of your disk drives where<br />
available to make absolutely sure you're referring to the right<br />
partitions, and save yourself the trouble of sorting out whether<br />
you're supposed to use sda or hda. If that's not an option, here's the<br />
rundown; If you're using pata instead of ide in the HOOKS array of the<br />
/etc/mkinitcpio.conf, you'll be using the sd? names. If not, use the<br />
old style hd? names. It is therefore crucial to check the HOOKS array<br />
in the /etc/mkinitcpio.conf, to be able to adapt the other files<br />
accordingly.<br />
<br />
<br />
'''/etc/mkinitcpio.conf'''<br />
<br />
This file allows you to fine-tune the initial ramdisk (also commonly<br />
referred to as the "initrd") for your system. The initrd is a gzipped<br />
image that is read by the kernel during bootup. The purpose of the<br />
initrd is to bootstrap the system to the point where it can access the<br />
root filesystem. This means it has to load any modules that are<br />
required to "see" things like IDE, SCSI, or SATA drives (or USB/FW, if<br />
you are booting off a USB/FW drive). Once the initrd loads the proper<br />
modules, either manually or through udev, it passes control to the<br />
Arch system and your bootup continues. For this reason, the initrd<br />
only needs to contain the modules necessary to access the root<br />
filesystem. It does not need to contain every module you would ever<br />
want to use. The majority of your everyday modules will be loaded<br />
later on by udev, during the init process.<br />
<br />
By default, mkinitcpio.conf is configured to provide all known modules<br />
for IDE, SCSI, or SATA systems through so-called HOOKS. This means the<br />
default initrd should work for almost everybody. The downside to this<br />
is that there are many modules loaded that you will not need. This is<br />
easily visible by examining your module table after booting up (with<br />
the lsmod command). While this doesn't actually hurt anything, some<br />
people find it annoying. To cull this list down to only what you<br />
actually need, you can edit mkinitcpio.conf and remove the subsystem<br />
HOOKS (ie, IDE, SCSI, RAID, USB, etc) that you don't need.<br />
<br />
You can customize even further by specifying the exact modules you<br />
need in the MODULES array and remove even more of the hooks, but take<br />
heed to the comments in the file, as this is a touchy place to go<br />
crazy with removing entries!<br />
<br />
If you're using RAID or encryption on your root filesystem, then<br />
you'll have to tweak the RAID/CRYPT settings near the bottom. See the<br />
wiki pages for RAID/LVM, filesystem encryption, and mkinitcpio for<br />
more info.<br />
<br />
When you're finished tweaking mkinitcpio.conf, you must run mkinitcpio<br />
-p kernel26 as root to regenerate the images, unless you're still<br />
installing the system; In that case this step will be done<br />
automatically after choosing Install Kernel later in the process.<br />
<br />
WARNING: If you fail to set up your mkinitcpio.conf correctly, your<br />
system will not boot! For this reason, you should be especially<br />
careful when tweaking this file.<br />
<br />
If you do manage to render your system unbootable, you can try using<br />
the fallback image that is installed alongside the stock kernel. A<br />
boot option for this is included in the default GRUB and LILO <br />
configuration.<br />
<br />
Read the warning about the pata transition problems elaborated in the<br />
fstab section carefully!<br />
<br />
<br />
'''/etc/modprobe.conf'''<br />
<br />
This tells the kernel which modules it needs to load for system<br />
devices, and what options to set. For example, to have the kernel load<br />
your Realtek 8139 ethernet module when it starts the network (ie.<br />
tries to setup eth0), use this line:<br />
alias eth0 8139too<br />
<br />
The syntax of this file is nearly identical to the old modules.conf<br />
scheme, unless you use some of the more exotic options like<br />
post-install. Then you should invest a little time into reading man<br />
modprobe.conf.<br />
<br />
Most people will not need to edit this file.<br />
<br />
<br />
'''/etc/resolv.conf'''<br />
<br />
Use this file to manually setup your nameserver(s) that you want to<br />
use. It should basically look like this:<br />
search domain.tld<br />
nameserver 192.168.0.1<br />
nameserver 192.168.0.2<br />
<br />
Replace domain.tld and the ip addresses with your settings. The<br />
so-called search domain specifies the default domain that is appended<br />
to unqualified hostnames automatically. By setting this, a ping myhost<br />
will effectively become a ping myhost.domain.tld with the above<br />
values. These settings usually aren't mighty important, though, and<br />
most people should leave them alone for now. If you use DHCP, this<br />
file will be replaced with the correct values automatically when<br />
networking is started, meaning you can and should happily ignore this<br />
file.<br />
<br />
<br />
'''/etc/locale.gen'''<br />
<br />
This file contains a list of all supported locales and charsets<br />
available to you. When choosing a LOCALE in your /etc/rc.conf or when<br />
starting a program, it is required to uncomment the respective locale<br />
in this file, to make a "compiled" version available to the system,<br />
and run the locale-gen command as root to generate all uncommented<br />
locales and put them in their place afterwards. You should uncomment<br />
all locales you intend to use.<br />
<br />
During the installation process, you do not need to run locale-gen<br />
manually, this will be taken care of automatically after saving your<br />
changes to this file.<br />
<br />
By default, all locales are commented out, including the default<br />
en_US.utf8 locale referred to in the /etc/rc.conf file. To make your<br />
system work smoothly, you must edit this file and uncomment at least<br />
the one locale you're using in your rc.conf.<br />
<br />
<br />
'''/boot/grub/menu.lst'''<br />
<br />
GRUB is the default bootloader for Arch Linux. You should check and<br />
modify this file to accommodate your boot setup if you want to use<br />
GRUB, otherwise read on about the LILO configuration.<br />
<br />
Make sure you read the warning regarding the pata transition<br />
elaborated on in the fstab section!<br />
<br />
Configuring GRUB is quite easy, the biggest hurdle is that it uses yet<br />
another device naming scheme different from /dev; Your hard disks as a<br />
whole are referred to as (hd0), (hd1), etc., sequentially numbered in<br />
order of appearance on the IDE/SCSI bus, just like the hda, hdb, etc.<br />
names in GNU/Linux. The partitions of a disk are referred to with (hd0,0),<br />
(hd0,1) and so on, with 0 meaning the first partition. A few<br />
conversion examples are included in the default menu.lst to aid your<br />
understanding.<br />
<br />
Once you grasped the concept of device naming, all you need to do is<br />
to choose a nice title for your boot section(s), supply the correct<br />
root partition device as a parameter to the root option to have it<br />
mounted as / on bootup, and create a kernel line that includes the<br />
partition and path where the kernel is located as well as any boot<br />
parameters. If using the stock Arch 2.6.x kernel, you'll also need an<br />
initrd line that points to the kernel26.img file in your /boot<br />
directory. The path you put on your initrd line should be the same as<br />
the path to vmlinuz26 that you provide on the kernel line. You should<br />
be fine with the defaults, just check whether the partition<br />
information is correct in the root and kernel lines, especially in<br />
regard to the pata issue!<br />
<br />
To create a boot option that loads the bootsector of a different OS,<br />
the following example might be helpful. You will probably succeed in<br />
starting any Microsoft-based operating system with it, just add this<br />
block to the file after any other sections, and modify the partition<br />
device accordingly to refer to the partition containing the bootsector<br />
of the OS you are intending to boot.<br />
(1) Other OS<br />
title My Other OS<br />
rootnoverify (hd0,1)<br />
makeactive<br />
chainloader +1<br />
<br />
For advanced configuration of other OSes, please refer to the online<br />
GRUB manual.<br />
<br />
After checking your bootloader configuration for correctness, you'll<br />
be prompted for a partition to install the loader to. Unless you're<br />
using yet another boot loader, you should install GRUB to the MBR of<br />
the installation disk, which is usually represented by the appropriate<br />
device name without a number suffix.<br />
<br />
<br />
'''/etc/lilo.conf'''<br />
<br />
This is the configuration file for the LILO bootloader. Make sure you<br />
check this one and get it right if you want to use LILO to boot your<br />
system. See LILO documentation for help on this.<br />
<br />
Things you should check are the root= lines in the image sections and<br />
the boot= line right at the beginning of the file. The root lines<br />
specify the device which shall be mounted as the root filesystem on<br />
bootup. If you don't know what is supposed to be entered here, change<br />
to another terminal and type mount to see a list of all currently<br />
mounted drives, and look for the line which displays a device name<br />
mounted on /mnt type [...]. The device path at the beginning of this<br />
very line should be entered in the root lines of your lilo.conf.<br />
Change if necessary, and keep the pata issue in mind!<br />
<br />
The boot line should be okay by default in most cases. Unless you have<br />
a weird boot manager setup in mind with multiple OSes, the device<br />
referenced here should be having the same prefix your root lines have,<br />
but not end with a number. For example, a root of /dev/hda3 means you<br />
probably want to install LILO into the Master Boot Record of the hard<br />
disk, so you would set boot to /dev/hda, which references the disk as<br />
a whole. During installation, the boot device must be the current name<br />
of the device where you want to write the boot sector to; This may<br />
differ from the name of the device after the first boot, thanks to the<br />
pata transition! Check carefully what device to write to during the<br />
installation stage, for example with the mount command.<br />
<br />
To prevent some serious grief, you should make sure you know how to<br />
restore the bootsector of your other OSes, for example with Windows's<br />
FIXBOOT/FIXMBR tools.<br />
<br />
To be on the safe side, you should keep the option lba32 listed. This<br />
will prevent some geometry issues from happening.<br />
<br />
In some cases, depending on your BIOS, LILO will not run on bootup and<br />
spill out an error code infinitely. In most cases you either removed<br />
the lba32 option, or your hardware setup is a little special, meaning<br />
that maybe your CD-ROM drive is primary master and the hard disk you<br />
installed secondary slave. This can very well confuse your BIOS, and<br />
thus stop the boot process. To prevent that you can try and make the<br />
install drive the primary master on your IDE bus. If you've got a<br />
mixed IDE and SCSI system and the problem persists, you'll probably<br />
need some experimentation with the disk and bios options of LILO to<br />
provide a working mapping; The disk drives in your system are numbered<br />
sequentially by your BIOS, starting with 0x80. If you're lucky your<br />
SCSI controller tells you which drive has which BIOS ID, but usually<br />
you're not. How the drives are effectively numbered is depending on<br />
your BIOS, so in the worst case you can only guess until it works. A<br />
typical disk line would look like this:<br />
boot=/dev/hda<br />
disk=/dev/hda bios=0x80<br />
<br />
The disk option maps a BIOS ID to the disk device known to the system. Note<br />
that there is still no guarantee that things will work as other things<br />
can be wrong, so do not despair if all your tries fail, but rather try<br />
rearranging your hardware in a way that's not totally odd. In this<br />
area too much can go wrong and needs special handling to be explained<br />
here. In most cases the lba32 option will suffice anyway. Old hard<br />
drives will usually need a little more special care until they do as<br />
told.<br />
<br />
Don't become fidgety when reading this section, I (Dennis) just<br />
happened to stumble over this problem when experimenting with a rather<br />
odd system, and figured it'd be a good idea to mention this show<br />
stopper and workarounds here. You probably won't ever experience this,<br />
as you should be using GRUB anyway.<br />
<br />
How to recreate a LILO boot sector with only a rescue disk is<br />
explained later in this document.<br />
<br />
<br />
'''/etc/conf.d/*'''<br />
<br />
During setup, this is totally unimportant. Consider this as reference<br />
for the interested.<br />
<br />
Some daemon scripts will have a matching configuration file in this<br />
directory that contains some more-or-less useful default values. When<br />
a daemon is started, it will first source the settings from its<br />
config file within this directory, and then source the /etc/rc.conf.<br />
This means you can easily centralize all your daemon configuration<br />
options in your /etc/rc.conf simply by setting an appropriate variable<br />
value, or split up your configuration over multiple files if you<br />
prefer a decentralized approach to this issue. Isn't life great if<br />
it's all just simple scripting?<br />
<br />
<br />
'''/etc/profile'''<br />
<br />
This script is run on each user login to initialize the system. It is<br />
kept quite simple under Arch Linux, as most things are. You may wish<br />
to edit or customize it to suit your needs.<br />
<br />
====Kernel====<br />
<br />
The CD-ROM includes the latest kernel available at time of release. If you are using the FTP<br />
Installation method, the kernel about to be installed will be the<br />
current version waiting on your FTP source, and might therefore<br />
introduce changes and/or incompatibilities unknown at the present<br />
time. This is unlikely, but keep it in mind.<br />
<br />
====Install Bootloader====<br />
<br />
Install Bootloader will install a bootloader on your hard drive,<br />
either GRUB (recommended) or LILO, depending on your personal<br />
preference.<br />
<br />
Before installing the bootloader, the setup script will want you to<br />
examine the appropriate configuration file to confirm the proper<br />
settings. <br />
<br />
If you choose to install LILO, the bootloader will be automatically<br />
installed according to your settings in the configuration file, whilst<br />
GRUB demands the selection of a partition to install the bootloader<br />
to. Here you should choose what you would enter as the boot option of<br />
LILO, which is usually the entry named /dev/hda, as it refers the<br />
master boot record of the first hard disk. Detailed error messages can<br />
be found as usual on VC5 (virtual console 5), if anything goes wrong.<br />
<br />
If you plan on setting up a multiboot system, you may wish to install the bootloader in your / or /boot partition, and<br />
refer to that boot sector from whatever other boot loader you want to<br />
reside in the master boot record. (chainloading)<br />
<br />
Installing a boot loader in the MBR will relentlessly overwrite any<br />
existing bootloader! Make sure you understand the implications of that<br />
if you're running a multiboot system, or want to preserve an installed<br />
bootloader from another OS!<br />
<br />
====Exit Install====<br />
<br />
Exit the Installer, eject the CD, and:<br />
reboot<br />
<br />
Login as root and add a user as outlined in the<br />
[[User_Management | User Management]] section, and set up your Internet Connection.<br />
<br />
Congratulations! Welcome to your new Arch Linux base system!<br />
<br />
==APPENDIX==<br />
<br />
See [[Official Arch Linux Install Guide Appendix]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Building_in_a_clean_chroot&diff=62040
DeveloperWiki:Building in a clean chroot
2009-02-14T23:59:28Z
<p>Phrakture: /* Handling Major Rebuilds */</p>
<hr />
<div>= Introduction =<br />
<br />
This article is part of the [[DeveloperWiki]].<br />
<br />
= Why =<br />
<br />
Building in a clean chroot prevents missing dependancies in packages, whether due to unwanted linking or packages missing in the depends array in the PKGBUILD. It also allows you to build a package for the stable repositories (core, extra, community) while having packages from [testing] installed on your system.<br />
<br />
= Setting Up A Chroot =<br />
<br />
The devtools package provides tools for creating and building within clean chroots. To make a clean chroot, firstly create the directory you want it to reside in. For the purposes of this article this will be called <chrootdir>. The create your chroot using<br />
<br />
sudo mkarchroot -C <pacman.conf> -M <makepkg.conf> <chrootdir>/root base base-devel sudo<br />
<br />
The -C and -M flags are optional, but it is recommended to provide these with clean pacman.conf and makepkg.conf files (directly from the pacman package) during first creation of clean chroot to ensure lack of user specific adjustments.<br />
<br />
Edit the <chrootdir>/root/etc/makepkg.conf file to set the packager name and any makeflags. Also adjust the mirror list in <chrootdir>/root/etc/pacman.d/mirrorlist and enable [testing] in <chrootdir>/root/etc/pacman.conf if wanted.<br />
<br />
= Building in the Chroot =<br />
<br />
Firstly, make sure your chroot is up to date with:<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
Then, to build a package in your chroot run<br />
<br />
sudo makechrootpkg -c -r <chrootdir><br />
<br />
A unionfs is used to maintain the clean chroot during building. All installed dependencies or makedepends and other changes made during building are done in <chrootdir>/rw. Passing the -c flag to makechrootpkg ensures that this directory is cleaned before building starts.<br />
<br />
= Handling Major Rebuilds =<br />
<br />
The cleanest way to handle a major rebuild is to create a new chroot and build your first package (typically the package you are doing the rebuild for). Then create a local repo in you chroot. To do this:<br />
<br />
sudo mkdir <chrootdir>/root/repo<br />
sudo chmod 777 <chrootdir>/root/repo<br />
<br />
The chmod statement allows you to copy package files and create the local repo as your user rather than root.<br />
<br />
cp <package> <chrootdir>/root/repo<br />
cd <chrootdir>/root/repo<br />
repo-add local.db.tar.gz <package><br />
<br />
Then add the local repo to <chrootdir>/root/etc/pacman.conf<br />
<br />
[local]<br />
Server = file:///repo<br />
<br />
and update your repo<br />
<br />
sudo mkarchroot -u <chrootdir>/root<br />
<br />
With every additional package rebuilt, copy the package to the local repo directory, add it to the repo database and update your chroot.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Disable_root_password_and_gain_su_sudo_with_no_password&diff=61899
Disable root password and gain su sudo with no password
2009-02-13T16:44:12Z
<p>Phrakture: </p>
<hr />
<div>[[Category:Security (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Disable_root_password_and_gain_su_sudo_with_no_password}}<br />
{{i18n_entry|Français|Disable_root_password_and_gain_su_sudo_with_no_password_(Français)}}<br />
{{i18n_links_end}}<br />
<br />
=Warning=<br />
Arch Linux is not fine tuned to work with a disabled root account. You will most likely run into problems if you don't know exactly what you're doing. Additional, the developers feel that disabling the root account entirely is stupid. <br />
<br />
=Caution=<br />
If your sudo settings break you won't be able to use the root account on your box. When using a remote or headless machine, this can be something of a pain to fix.<br />
<br />
=Why=<br />
# User password strength is equal to root's password, and one must first login to use sudo.<br />
# Root password will be disabled -- anyone trying to log in as root will be denied. Anyone wanting to access the machine must first know the correct username.<br />
# Once local security is compromised the root password is meaningless -- a LiveCD is a perfect backdoor.<br />
<br />
=Requirements=<br />
You'll need "sudo" installed. You can grab it from pacman:<br />
# pacman -S sudo<br />
<br />
=Visudo=<br />
==Opening /etc/sudoers==<br />
You should always use visudo to edit the sudoers file since visudo performs some checks to ensure that the edited file remains valid. Type visudo at a root prompt and edit. The command '''i''' will start edit mode in vi, '''Esc''' will end it, ''':wq''' will save the file and quit, while ''':q!''' will quit without saving.<br />
<br />
If you are uncomfortable with vi, you can use nano instead.<br />
# export EDITOR=nano; visudo<br />
<br />
==Editing /etc/sudoers==<br />
Allow user ziggy sudo from local machine only using HOSTNAME in rc.conf:<br />
ziggy <hostname>=(ALL) ALL<br />
<br />
Allow user arch sudo from anywhere (local/net):<br />
arch ALL=(ALL) ALL<br />
<br />
Allow group wheel sudo access requiring no password:<br />
%wheel ALL=(ALL) NOPASSWD: ALL<br />
<br />
Don't forget to add the desired users to any groups with sudo abilities.<br />
# gpasswd -a ''username'' ''group''<br />
<br />
Note that it is perfectly valid to mix-and-match these options to create a more custom sudo environment. For more complete information on the capabilities of the sudoers file, visit http://www.gratisoft.us/sudo/man/sudoers.html.<br />
<br />
==Extra Security==<br />
To allow wheel users login via local '''only''', add the following line to /etc/security/access.conf:<br />
-:wheel:ALL EXCEPT LOCAL<br />
<br />
=Disabling root=<br />
Test the user's sudo abilities, then disable the root account by removing its password.<br />
# passwd -l root<br />
<br />
A similar command unlocks root.<br />
$ sudo passwd -u root<br />
<br />
That's it. You should have a newly-disabled root.<br />
<br />
==Alternative method of disabling root==<br />
Edit your /etc/shadow.<br />
$ sudo vipw -s<br />
Then replacing root's encrypted password with !.<br />
The full line will look something like:<br />
root:!:12345::::::<br />
<br />
It would let us to run package's installer script that need to add/remove new user/group in our system (gpasswd things) when you use pacman. It impossible to achieve if you lock the root by using 'passwd -u root'.<br />
<br />
To enable root login again:<br />
$ sudo passwd root<br />
<br />
=KDE - kdesu=<br />
kdesu may be used under KDE to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately we can tell kdesu to use sudo instead of su.<br />
<br />
There are two ways to do so:<br />
# Recompile kdebase with '--with-sudo-kdesu-backend' configure switch.<br />
# Create a kdesurc file in '/usr/share/config/' with the following:<br />
[super-user-command]<br />
super-user-command=sudo</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Official_Installation_Guide&diff=60274
Official Installation Guide
2009-02-06T18:59:54Z
<p>Phrakture: Protected "Official Arch Linux Install Guide": Official Docs [edit=sysop:move=sysop]</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|General installation documentation for the Arch Linux distribution.}}<br />
{{Article summary heading|Available Languages}}<br />
{{i18n_entry|English|Official Arch Linux Install Guide}}<br />
{{i18n_entry|简体中文|Arch Linux 官方安装指南}}<br />
{{i18n_entry|正體中文|Arch Linux 官方安裝指南}}<br />
{{i18n_entry|Česky|Oficiální instalační příručka (Česky)}}<br />
{{i18n_entry|Русский|Руководство по установке}}<br />
{{i18n_entry|Español|Guía oficial de Instalación}}<br />
{{i18n_entry|Italiano|Official Arch Linux Install Guide (Italiano)}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Beginners Guide}} (If you are new to Arch)<br />
{{Article summary end}}<br />
<br />
<br />
==Introduction==<br />
<br />
===What is Arch Linux?===<br />
<br />
Arch Linux is an independently developed GNU/Linux distribution. Development is focused on a balance of simplicity, elegance, code-correctness and bleeding edge software. It's lightweight and simple design makes it easy to extend and mold into whatever kind of system you're building.<br />
<br />
The Arch system and binary packages are compiled for i686 and x86-64 processors.<br />
<br />
===License===<br />
<br />
Arch Linux, pacman, documentation, and scripts are copyright<br />
©2002-2007 by Judd Vinet, ©2007-2008 by Aaron Griffin and are licensed under the GNU General Public License Version 2.<br />
<br />
==Installing Arch Linux==<br />
<br />
===Pre-Installation===<br />
<br />
Arch Linux is optimized for the i686 processor and therefore will not<br />
run on any lower or incompatible generations of x86 CPUs<br />
(i386,i486,i586). A Pentium II or AMD Athlon processor or higher is<br />
required. Modern VIA C3 processors are also supported. x86-64 architectures are also officially supported.<br />
<br />
There is a community-driven project that provides packages for i586<br />
and ppc. See this site for more information.<br />
<br />
Before installing Arch Linux, you should decide which installation<br />
method you would like to use. Arch Linux provides two different<br />
bootable ISO images for a CD-ROM installation. Installing Arch from a USB stick or from within another already installed OS is also supported.<br />
<br />
As the preferred method of installation is the flexible CD-ROM based<br />
installation, we offer you two variants of the installation medium<br />
which only differ in terms of supplied packages. You can instruct the<br />
installer to obtain the packages via FTP using any of these images,<br />
and all images can also be used as fully functional live cds.<br />
<br />
* The core iso (~300MB) is a live environment which contains a snapshot of the entire /core repository. Packages are divided into 4 categories: BASE, SUPPORT, DEVEL and LIB. RAID/LVM are fully supported; all necessary packages are included within /core. Installing from a medium created with this image results in a completely functional GNU/Linux system, without any frills, expecting to be used from the command line; the Linux kernel, GNU toolchain and a few extra modules and libraries. This image is ideally suited for those who have a rather slow or nonexistent internet connection on the candidate machine, making an FTP install unfeasible. The name of the iso will be "archlinux-i686-2008.xx-x.core.iso", according to your architecture<br />
* The FTP iso (~175MB) is a live environment, containing no packages at all, but rather pulls in all software over your internet connection. If you have access to a fast and easily setup internet connection, this method may be preferred, since the completed system will be completely up-to-date, without requiring further upgrades from the package versions included on the Core CD. Of course all packages you choose to install have to be downloaded from somewhere, but at least you don't have to update the system directly after installation, saving yourself some hassle. If your network connection is cheap and fast, choose this image. <br />
{{Box Note | When choosing a pacman mirror during installation, keep in mind that archlinux.org is throttled to 50Kb/s.}}<br />
<br />
If you do not have a CD-ROM drive attached to your computer, you may refer to [[Install_from_USB_stick | this guide]] to install Arch Linux using a USB stick. If you do not have a USB stick, there are [[Hard_Disk_Installation | instructions]] for installing from a hard disk partition, such as a swap partition. If you want to use an existing distribution to install Arch Linux, please follow this [[Install_From_Existing_Linux | guide]].<br />
<br />
You can also purchase a cd online from OSDisc, shipping nearly<br />
world-wide.<br />
<br />
Using a dialup PPP connection to gain access to the internet during<br />
the install process is now supported. ppp utilities, rp-pppoe<br />
and the ISDN userspace utilities are included in the installation<br />
media.<br />
<br />
Since version 2007.08, isos are true live systems and run like any installed arch system.<br />
<br />
Some highlights: <br />
* pacman is included, to allow installation of any other needed packages for install environment.<br />
* complete /etc/rc.d/ and /etc/rc.conf support<br />
* complete Arch network support, including ssh,telnet and portmap services<br />
* custom config files support: any media with /config directory and files can be copied to /etc/ install environment<br />
* loading packages as addons during boot: any media with /packages directory including pacman packages can be installed during bootup.<br />
* '''links''' and '''naim''' included to be able to communicate over the internet.<br />
* complete kexec support<br />
<br />
If, during the installation process, you find you require a more verbose guide or explanation, you may also find the Arch Linux [[Beginners Guide]] helpful. <br />
<br />
What You Will Need<br />
<br />
* a working knowledge of GNU/Linux and the candidate machine's hardware<br />
* Arch Linux installation media (see the mirror list)<br />
* an i686 or x86-64 processor (PPro, Pentium 2 or higher, Athlon/Duron, etc. Note that AMD K6, Transmeta Crusoe, CyrixIII, and VIA-C3 are NOT supported.)<br />
* 160 MB RAM<br />
* some time to kill<br />
<br />
===Acquiring Arch Linux===<br />
<br />
You can download Arch Linux from any of the Arch Linux [http://www.archlinux.org/download/ mirrors]. Just follow the links into the "iso" directory and choose the version you wish to install. In general, you are advised to download the latest version as this helps avoid any difficulties during your initial update.<br />
<br />
===Preparing Installation Media===<br />
<br />
*Download <mirror>/iso/<your_architecture>/archlinux-<version>.iso (path relative to mirror root)<br />
*Download <mirror>/iso/<your_architecture>/md5sum-<version>.txt<br />
*Verify the integrity of the .iso image using md5sum:<br />
md5sum archlinux-<version>.iso<br />
*Burn the .iso image to a blank CD-R (this step varies depending on the OS/software you're using). If you want to download the core, ftp or a beta ISO instead, use the appropriate filename, ie: arch-0.8-core.iso instead of arch-0.8.iso, likewise for the md5sum.<br />
*Write down all your network settings so you can enter them into setup later, if you want to install via FTP:<br />
**IP Address<br />
**Subnet Mask<br />
**Gateway<br />
**Ethernet Module for your network card (eg.: eepro100, 8139too, ne2k-pci, etc.)<br />
<br />
===Using the CD-ROM===<br />
If you are familiar with the boot process, you may skip this <br />
explanation and continue with [[#Common Installation Procedure | Common Installation Procedure]], which outlines <br />
the actual process of installing Arch Linux.<br />
<br />
Reboot your computer with the Arch Linux Installation CD in the drive.<br />
Make sure your BIOS is configured to boot from your CD-ROM.<br />
Refer to your motherboard manual or system manufacturer documentation for<br />
details.<br />
<br />
At the end of the boot procedure, you shall be dropped into a root<br />
shell. At this point you are ready to commence the actual<br />
installation.<br />
<br />
===Common Installation Procedure===<br />
<br />
Installation Steps:<br />
<br />
#Loading a non-US Keymap<br />
#Running Setup<br />
#Configure Network (FTP Install only)<br />
#Prepare Hard Drive<br />
##Auto-Prepare<br />
##Partition Hard Drives<br />
##Set Filesystem Mountpoints<br />
#Select Packages<br />
#Install Packages<br />
#Configure System<br />
#Install Bootloader<br />
#Exit Install<br />
<br />
Using the available shell tools, experienced users are also able to<br />
prepare the hard drive or any devices needed for the installation<br />
before starting the installer. You may simply skip this paragraph if<br />
you don't see any immediate need for further manual interaction. Note<br />
that the Arch Linux installation media also contains a /arch/quickinst<br />
script for experienced users. This script installs the "base" set of<br />
packages to a user-specified destination directory. If you are doing<br />
an exotic install with fun things like RAID and LVM, or do not want to<br />
use the installer at all, you will probably want to use the quickinst<br />
script. All the cool kids are doing it.<br />
<br />
====Login and Loading a non-US Keymap====<br />
<br />
Login as 'root'. If you have a non-US keyboard layout do:<br />
km<br />
at the prompt.<br />
<br />
====Running Setup====<br />
<br />
Begin the installer script:<br />
/arch/setup<br />
After an informational message you will be prompted for the installation method<br />
of your choice. If you have a fast internet connection, you might<br />
prefer the FTP installation to ensure you get the latest packages<br />
instead of using the potentially outdated CD contents. <br />
<br />
When navigating the setup script, make sure to select DONE from<br />
the submenus after performing each step. This saves any settings you<br />
make in preparation for the next step. Further, avoid arbitrary steps<br />
throughout the installation process as this can also confuse the<br />
installer.<br />
<br />
It's actually rather easy to set up your own FTP package mirror or<br />
create your own bootable installation CD with the packages you need,<br />
making the task of installing several instances of Arch Linux across<br />
multiple machines rather simple, while at the same time saving a lot<br />
of mirror bandwidth. Make your life and ours easier, and look into<br />
these alternatives!<br />
<br />
When choosing a CD-ROM or OTHER SOURCE install you will only be able<br />
to install packages contained on the CD, which may be quite old, or<br />
packages stored on a medium you were able to mount (DVD, USB stick or<br />
similar) somewhere in the filesystem tree manually. Of course, it has<br />
the advantage of not needing an internet connection, and is therefore<br />
the recommended choice for dialup users or those unable or unwilling to download the entire package set via ftp.<br />
<br />
Next, you will be presented with the installer menu, listing the necessary steps in the order in which they should be completed.<br />
<br />
Virtual consoles 1-6 are active in the live environment. At any point in the install process, you can switch to your 5th virtual console (ALT-F5) to view the shell output from installer script. Use (ALT-F1) to get back to your first console where<br />
the installer is running.<br />
<br />
====Configure Network (FTP Install only)====<br />
<br />
Configure Network will allow you to install and configure your network<br />
device.<br />
<br />
A list of all currently available network devices is presented to you.<br />
If no ethernet device is available, load the necessary modules manually from another virtual console. Alternatively,<br />
you may probe for a network module on the following screen by selecting the Probe command. <br />
<br />
When the correct module is loaded, your network card will be<br />
listed. Select the ethernet device you wish to configure<br />
and you will be given the option to configure your network with DHCP.<br />
If you're connected to a DHCP server, hit YES and let the installer do<br />
the rest. If you select NO, you will be asked to enter the networking<br />
information manually.<br />
Either way, your network should be successfully configured, and if<br />
you're of the skeptical kind, you may check connectivity using<br />
standard tools like ping on another console.<br />
<br />
As automations are not perfect, you may not be able to successfully<br />
use the installer to set up your network. In these rare cases, set up you network device manually in one of the consoles.<br />
<br />
====Prepare Hard Drive====<br />
<br />
Prepare Hard Drive presents a submenu offering two<br />
alternatives of preparing the target drive for installation.<br />
<br />
The first choice is Auto-Prepare, which will automatically partition<br />
your hard drive into a /boot, swap, and root partition, and then<br />
create filesystems on all three. These partitions will also be<br />
automatically mounted in the proper place. To be exact, this option<br />
will create:<br />
* 32 MB ext2 /boot partition<br />
* 256 MB swap partition<br />
* root and /home partition with the remaining space. (Root and /home will share the same file system type if choosing the auto-prepare option).<br />
<br />
Actual sizes may vary slightly, due to different hard disk geometries.<br />
You can choose this option if you don't know much about hard drive<br />
partitions, but be warned:<br />
<br />
AUTO-PREPARE WILL ERASE ALL DATA ON THE CHOSEN HARD DRIVE!<br />
Read the warning presented by the installer very carefully, and make<br />
sure the correct device is about to be partitioned!<br />
<br />
A way to verify your choice for a device to partition would be to open<br />
another terminal (ALT-F2, Enter) and enter<br />
cfdisk -P s <name of device><br />
<br />
This will display the current partition table of the selected device,<br />
which should suffice to identify the hard disk.<br />
<br />
If you prefer to do the partitioning manually, use '''Partition Hard Drives''' and '''Set Filesystem Mountpoints''' to prepare the target media according to your specifications, as outlined below. After successful preparation, choose Return to Main Menu.<br />
<br />
====Partition Hard Drives====<br />
<br />
Partition Hard Drives should be skipped if you chose Auto-Prepare<br />
already!<br />
<br />
Otherwise you should select the disk(s) you want to partition, and<br />
you'll be dropped into the cfdisk program where you can freely modify<br />
the partitioning information until you [Write] and [Quit].<br />
<br />
You will need at least a root partition to continue the installation,<br />
and it's helpful to note somewhere which partition you're going to<br />
mount where, as you'll be asked exactly that in the next step.<br />
<br />
====Set Filesystem Mountpoints====<br />
<br />
Set Filesystem Mountpoints should also be skipped if you chose to<br />
Auto-Prepare your hard drive. You should select this option once the<br />
partition information is edited to your liking with the previous menu<br />
selection, or already existent through whatever other means.<br />
<br />
First, select the previously created swap partition from the list, or NONE, if you<br />
do not want to use a swap partition. Using a swap ''file'' is not directly<br />
supported by the installer; Instead choose NONE here, finish the<br />
mountpoint associations, and activate a swap file on your desired,<br />
formatted partition with the swapon command.<br />
<br />
After setting up the swap partition, you will be asked to specify the<br />
partition to be used as the root partition. This is mandatory.<br />
<br />
The association process is then repeated until you choose DONE from<br />
the list, ideally after all listed partitions have been associated<br />
with their intended mountpoints. The installer will suggest /boot for<br />
all following mountpoints after choosing swap and root.<br />
<br />
Each time a partition to mount is specified, you will be asked if you<br />
want to create a filesystem on the respective partition. Selecting<br />
YES, will prompt you for the filesystem type to create. The partition will then be<br />
formatted with the chosen filesystem type, destroying all data in the<br />
process. <br />
<br />
If additional mountpoints are desired, for example, a separate /boot or /home partition, you will be able to do so. Simply<br />
* select a partition to mount<br />
* choose a filesystem (if you want to create one instead of keeping existing data)<br />
* enter a unique mountpoint for the partition<br />
<br />
Repeat these steps until satisfied, then select DONE to create<br />
any filesystems and mount the partitions in their respective places.<br />
Before the actual formatting is done, the installer will present to<br />
you a list of all choices for review. After formatting and<br />
mounting all partitions, you may return to the Main Menu and proceed<br />
with the next step.<br />
<br />
===Select Packages===<br />
Now we shall select packages to install in our system.<br />
*Core ISO: Choose CD as source and select the appropriate CD drive if you have more than one.<br />
*FTP ISO: Select an FTP/HTTP mirror. ''Note that archlinux.org is throttled to 50KB/s''. ''Note also that some mirrors don't support resuming in case of download failure (e.g. ftp.free.fr)''<br />
<br />
The installer will always install a basic working system. You are given the option to install some basic development tools, such as GCC, autoconf, automake, make and some other useful packages such as openssh, sudo, iptable and some wifi packages.<br />
<br />
If you don't want to install any of the extra packages during the installation, you need to select the one and only package category '''BASE-DEVEL''' using the space bar.<br />
<br />
The next screen will present you with the selected packages within '''BASE-DEVEL'''.<br />
<br />
Once you're done selecting the packages you need, leave the selection<br />
screen and continue to the next step, Install Packages.<br />
<br />
====Install Packages====<br />
<br />
Install Packages will now install the base system and any other packages you<br />
selected with resolved dependencies onto your harddisk. Don't be<br />
surprised if more packages are installed than you selected! Those<br />
packages are dependencies for your selection, and the installer will<br />
not explicitly ask for permission to install these extra packages, as<br />
it assumes you know what you're doing.<br />
<br />
After the package selection, the installer will not check for free<br />
space on the target! This seemingly trivial task would eat up<br />
considerable time, and therefore the installer simply assumes to have<br />
enough free space on the target partition(s). In case it doesn't, the<br />
installation will fail in various funny ways. A df -h in another<br />
terminal might show that one or more of the targets mounted below /mnt<br />
have been filled up, causing mischief. Consider repartitioning or<br />
selecting a smaller set of packages.<br />
<br />
Error messages and debugging output is echoed to vc/5 (ALT-F5). After the packages have been installed, proceed to the next step, Configure System.<br />
<br />
Pacman will ask you whether it should keep the installed packages in cache. As you can delete them later using 'pacman -Scc', selecting 'yes' is recommended.<br />
<br />
==Configure System==<br />
<br />
Configure System allows you to edit the configuration files crucial<br />
for your newly installed system. Initially you will be asked whether<br />
to allow the hwdetect script to try and detect your hardware, and<br />
produce some (even more) sensible defaults for your configuration<br />
files. Unless you're having problems/crashes, you should let it have<br />
its way, and work from what it generates.<br />
<br />
Answer the following questions about RAID, LVM and encrypted volumes<br />
with Yes, if your root partition resides on a RAID, LVM or encrypted<br />
volume, respectively, to automatically add the necessary HOOKS to the<br />
mkinitcpio.conf. Otherwise you will get a kernel panic during boot, as<br />
your root partition will not be accessible at the time of boot. Most<br />
people will answer these questions with No, though, and not waste a<br />
second thought about it.<br />
<br />
After this automatic preconfiguration you'll be asked for your<br />
favourite editor to use for manually fine-tuning the generated<br />
configuration files, either VIM or nano. When in doubt, choose nano.<br />
<br />
===Configuration Files===<br />
These are the core configuration files for Arch Linux, to be configured with a text-editor. Only the most basic configuration<br />
files are listed here. If you need help configuring a specific<br />
service, please read the appropriate manpage or refer to any online<br />
documentation you need. In many cases, the Arch Linux Wiki and forums<br />
are a rich source for help as well.<br />
<br />
{{Box Note | Arch Linux does not use any abstraction layers to administrate your system. As a result, you can usually stick to any instructions published by the author of a particular software package, or whatever you find in a search engine of your choice, and it likely will work without confusing your system, because your system simply does not 'care'.}}<br />
<br />
'''List of Configuration Files'''<br />
* Setup-relevant configuration files:<br />
** /etc/rc.conf<br />
** /etc/hosts<br />
** [[Fstab | /etc/fstab]]<br />
** /etc/mkinitcpio.conf<br />
** /etc/modprobe.conf<br />
** /etc/resolv.conf<br />
** /etc/locale.gen<br />
** /boot/grub/menu.lst<br />
** /etc/lilo.conf<br />
* Additional configuration files:<br />
** /etc/conf.d/*<br />
** /etc/profile<br />
<br />
<br />
'''/etc/rc.conf'''<br />
<br />
This is the main configuration file for Arch Linux. It allows you to<br />
set your keyboard, timezone, hostname, network, daemons to run and<br />
modules to load at bootup, profiles, and more. You should read through<br />
all the settings in this file and make sure you understand them, and<br />
change them where appropriate:<br />
<br />
LOCALE<br />
This sets your system language, which will be used by all<br />
i18n-friendly applications and utilities. See locale.gen below<br />
for available options. This setting's default is fine for US <br />
English users.<br />
<br />
HARDWARECLOCK<br />
Either UTC if your BIOS clock is set to UTC, or localtime if<br />
your BIOS clock is set to your local time. If you have an OS<br />
installed which cannot handle UTC BIOS times correctly, like<br />
Windows, choose localtime here, otherwise you should prefer<br />
UTC, which makes daylight savings time a non-issue and has a<br />
few other positive aspects.<br />
<br />
TIMEZONE<br />
Specifies your time zone. Possible time zones are the relative<br />
path to a zoneinfo file starting from the directory<br />
/usr/share/zoneinfo. For example, a german timezone would be<br />
Europe/Berlin, which refers to the file<br />
/usr/share/zoneinfo/Europe/Berlin. If you don't know the exact<br />
name of your timezone file, worry about it later.<br />
<br />
KEYMAP<br />
Defines the keymap to load with the loadkeys program on bootup.<br />
Possible keymaps are found in /usr/share/kbd/keymaps. Please<br />
note that this setting is only valid for your TTYs, not any<br />
graphical window managers or X! Again, the default is fine for<br />
US users.<br />
<br />
CONSOLEFONT<br />
Defines the console font to load with the setfont program on<br />
bootup. Possible fonts are found in<br />
/usr/share/kbd/consolefonts.<br />
<br />
CONSOLEMAP<br />
Defines the console map to load with the setfont program on<br />
bootup. Possible maps are found in /usr/share/kbd/consoletrans.<br />
You will want to set this to a map suitable for your locale<br />
(8859-1 for Latin1, for example) if you're using an utf8 locale<br />
above, and use programs that generate 8-bit output. If you're<br />
using X11 for everyday work, don't bother, as it only affects<br />
the output of GNU/Linux console applications.<br />
<br />
USECOLOR<br />
Enable (or disable) colorized status messages during boot-up.<br />
<br />
MOD_AUTOLOAD<br />
If set to "yes", Arch will scan your hardware at bootup and<br />
attempt to automatically load the proper modules for your<br />
system. This is done with the hwdetect utility.<br />
<br />
MOD_BLACKLIST<br />
This is an array of modules that you do not want to be loaded<br />
at bootup. For example, if you don't want that annoying PC<br />
speaker, you could blacklist the pcspkr module.<br />
<br />
MODULES<br />
In this array you can list the names of modules you want to<br />
load during bootup without the need to bind them to a hardware<br />
device as in the modprobe.conf. Simply add the name of the<br />
module here, and put any options into the modprobe.conf if need<br />
be. Prepending a module with a bang ('!') will not load the<br />
module during bootup (this is not the same as MOD_BLACKLIST!),<br />
thus allowing to "comment out" certain modules if necessary. A<br />
benefit of specifying networking modules here is that ethernet<br />
cards covered by the listed modules will always be detected in<br />
the order the modules are listed. This prevents the dreaded<br />
interface confusion where your ethernet hardware is assigned to<br />
seemingly random interfaces after each boot. An even better way<br />
to handle this is using static interface labels by configuring<br />
udev appropriately, though.<br />
<br />
USELVM<br />
Set to "YES" to run a vgchange during sysinit, thus activating<br />
any LVM groups. If you have no idea what this means, don't<br />
bother.<br />
<br />
HOSTNAME<br />
Set this to the hostname of the machine, without the domain<br />
part. This is totally your choice, as long as you stick to<br />
letters, digits and a few common special characters like the<br />
dash. Don't be too creative here, though, and when in doubt,<br />
use the default.<br />
<br />
INTERFACES<br />
Here you define the settings for your networking interfaces.<br />
The default lines and the included comments explain the setup<br />
well enough. If you use DHCP, 'eth0="dhcp"' should work for you. If you do not use DHCP to configure a device, just<br />
keep in mind that the value of the variable (whose name must be<br />
equal to the name of the device which is supposed to be<br />
configured) equals the line which would be appended to the<br />
ifconfig command if you were to configure the device manually<br />
in the shell.<br />
<br />
ROUTES<br />
You can define your own static network routes with arbitrary<br />
names here. Look at the example for a default gateway to get<br />
the idea. Basically the quoted part is identical to what you'd<br />
pass to a manual route add command, therefore reading man route<br />
is recommended if you don't know what to write here, or simply<br />
leave this alone.<br />
<br />
[[Network_Profiles | NET_PROFILES]]<br />
Enables certain network profiles at bootup. Network profiles<br />
provide a convenient way of managing multiple network<br />
configurations, and are intended to replace the standard<br />
INTERFACES/ROUTES setup that is still recommended for systems<br />
with only one network configuration. If your computer will be<br />
participating in various networks at various times (eg, a<br />
laptop) then you should take a look at the<br />
/etc/network-profiles/ directory to set up some profiles. There<br />
is a template file included there that can be used to create<br />
new profiles.<br />
<br />
DAEMONS<br />
This array simply lists the names of those scripts contained in<br />
/etc/rc.d/ which are supposed to be started during the boot<br />
process, as well as the order in which they start. If a script name is prefixed with a bang (!), it is<br />
not executed. If a script is prefixed with an "at" symbol (@),<br />
then it will be executed in the background, ie. the startup<br />
sequence will not wait for successful completion before<br />
continuing. Usually you do not need to change the defaults to<br />
get a running system, but you are going to edit this array<br />
whenever you install system services like sshd, and want to<br />
start these automatically during bootup. This is basically<br />
Arch's way of handling what others handle with various symlinks<br />
to an init.d directory.<br />
<br />
<br />
'''/etc/hosts'''<br />
<br />
This is where you stick hostname/ip associations of computers on your<br />
network. If a hostname isn't known to your DNS, you can add it here to<br />
allow proper resolving, or override DNS replies. You usually don't<br />
need to change anything here, but you might want to add the hostname<br />
and hostname + domain of the local machine to this file, resolving to<br />
the IP of your network interface. Some services, postfix for example,<br />
will bomb otherwise. If you don't know what you're doing, leave this<br />
file alone until you read man hosts.<br />
<br />
<br />
'''[[Fstab | /etc/fstab]]'''<br />
<br />
Your filesystem settings and mountpoints are configured here. The<br />
installer should have created the necessary entries for you, but you<br />
should look over it and make sure it's right, especially when using an<br />
encrypted root device, LVM or RAID.<br />
<br />
With the current kernel, an important change has been introduced<br />
pertaining to the ATA/IDE subsystem. The new pata (Parallel ATA)<br />
drivers replace the legacy IDE subsystem, and one important change is<br />
that the naming scheme for IDE disks has changed from the old hda,<br />
hdb, etc. to also use device names of the type sda, sdb, etc, just<br />
like SCSI and SATA devices do. Because of this, when using the new<br />
pata driver in the HOOKS of the /etc/mkinitcpio.conf, remember to use<br />
the appropriate device names in your /etc/fstab and bootloader<br />
configuration! Alternatively, you could use the /dev/disk/by-uuid/...<br />
or /dev/disk/by-label/... representations of your disk drives where<br />
available to make absolutely sure you're referring to the right<br />
partitions, and save yourself the trouble of sorting out whether<br />
you're supposed to use sda or hda. If that's not an option, here's the<br />
rundown; If you're using pata instead of ide in the HOOKS array of the<br />
/etc/mkinitcpio.conf, you'll be using the sd? names. If not, use the<br />
old style hd? names. It is therefore crucial to check the HOOKS array<br />
in the /etc/mkinitcpio.conf, to be able to adapt the other files<br />
accordingly.<br />
<br />
<br />
'''/etc/mkinitcpio.conf'''<br />
<br />
This file allows you to fine-tune the initial ramdisk (also commonly<br />
referred to as the "initrd") for your system. The initrd is a gzipped<br />
image that is read by the kernel during bootup. The purpose of the<br />
initrd is to bootstrap the system to the point where it can access the<br />
root filesystem. This means it has to load any modules that are<br />
required to "see" things like IDE, SCSI, or SATA drives (or USB/FW, if<br />
you are booting off a USB/FW drive). Once the initrd loads the proper<br />
modules, either manually or through udev, it passes control to the<br />
Arch system and your bootup continues. For this reason, the initrd<br />
only needs to contain the modules necessary to access the root<br />
filesystem. It does not need to contain every module you would ever<br />
want to use. The majority of your everyday modules will be loaded<br />
later on by udev, during the init process.<br />
<br />
By default, mkinitcpio.conf is configured to provide all known modules<br />
for IDE, SCSI, or SATA systems through so-called HOOKS. This means the<br />
default initrd should work for almost everybody. The downside to this<br />
is that there are many modules loaded that you will not need. This is<br />
easily visible by examining your module table after booting up (with<br />
the lsmod command). While this doesn't actually hurt anything, some<br />
people find it annoying. To cull this list down to only what you<br />
actually need, you can edit mkinitcpio.conf and remove the subsystem<br />
HOOKS (ie, IDE, SCSI, RAID, USB, etc) that you don't need.<br />
<br />
You can customize even further by specifying the exact modules you<br />
need in the MODULES array and remove even more of the hooks, but take<br />
heed to the comments in the file, as this is a touchy place to go<br />
crazy with removing entries!<br />
<br />
If you're using RAID or encryption on your root filesystem, then<br />
you'll have to tweak the RAID/CRYPT settings near the bottom. See the<br />
wiki pages for RAID/LVM, filesystem encryption, and mkinitcpio for<br />
more info.<br />
<br />
When you're finished tweaking mkinitcpio.conf, you must run mkinitcpio<br />
-p kernel26 as root to regenerate the images, unless you're still<br />
installing the system; In that case this step will be done<br />
automatically after choosing Install Kernel later in the process.<br />
<br />
WARNING: If you fail to set up your mkinitcpio.conf correctly, your<br />
system will not boot! For this reason, you should be especially<br />
careful when tweaking this file.<br />
<br />
If you do manage to render your system unbootable, you can try using<br />
the fallback image that is installed alongside the stock kernel. A<br />
boot option for this is included in the default GRUB and LILO <br />
configuration.<br />
<br />
Read the warning about the pata transition problems elaborated in the<br />
fstab section carefully!<br />
<br />
<br />
'''/etc/modprobe.conf'''<br />
<br />
This tells the kernel which modules it needs to load for system<br />
devices, and what options to set. For example, to have the kernel load<br />
your Realtek 8139 ethernet module when it starts the network (ie.<br />
tries to setup eth0), use this line:<br />
alias eth0 8139too<br />
<br />
The syntax of this file is nearly identical to the old modules.conf<br />
scheme, unless you use some of the more exotic options like<br />
post-install. Then you should invest a little time into reading man<br />
modprobe.conf.<br />
<br />
Most people will not need to edit this file.<br />
<br />
<br />
'''/etc/resolv.conf'''<br />
<br />
Use this file to manually setup your nameserver(s) that you want to<br />
use. It should basically look like this:<br />
search domain.tld<br />
nameserver 192.168.0.1<br />
nameserver 192.168.0.2<br />
<br />
Replace domain.tld and the ip addresses with your settings. The<br />
so-called search domain specifies the default domain that is appended<br />
to unqualified hostnames automatically. By setting this, a ping myhost<br />
will effectively become a ping myhost.domain.tld with the above<br />
values. These settings usually aren't mighty important, though, and<br />
most people should leave them alone for now. If you use DHCP, this<br />
file will be replaced with the correct values automatically when<br />
networking is started, meaning you can and should happily ignore this<br />
file.<br />
<br />
<br />
'''/etc/locale.gen'''<br />
<br />
This file contains a list of all supported locales and charsets<br />
available to you. When choosing a LOCALE in your /etc/rc.conf or when<br />
starting a program, it is required to uncomment the respective locale<br />
in this file, to make a "compiled" version available to the system,<br />
and run the locale-gen command as root to generate all uncommented<br />
locales and put them in their place afterwards. You should uncomment<br />
all locales you intend to use.<br />
<br />
During the installation process, you do not need to run locale-gen<br />
manually, this will be taken care of automatically after saving your<br />
changes to this file.<br />
<br />
By default, all locales are commented out, including the default<br />
en_US.utf8 locale referred to in the /etc/rc.conf file. To make your<br />
system work smoothly, you must edit this file and uncomment at least<br />
the one locale you're using in your rc.conf.<br />
<br />
<br />
'''/boot/grub/menu.lst'''<br />
<br />
GRUB is the default bootloader for Arch Linux. You should check and<br />
modify this file to accommodate your boot setup if you want to use<br />
GRUB, otherwise read on about the LILO configuration.<br />
<br />
Make sure you read the warning regarding the pata transition<br />
elaborated on in the fstab section!<br />
<br />
Configuring GRUB is quite easy, the biggest hurdle is that it uses yet<br />
another device naming scheme different from /dev; Your hard disks as a<br />
whole are referred to as (hd0), (hd1), etc., sequentially numbered in<br />
order of appearance on the IDE/SCSI bus, just like the hda, hdb, etc.<br />
names in GNU/Linux. The partitions of a disk are referred to with (hd0,0),<br />
(hd0,1) and so on, with 0 meaning the first partition. A few<br />
conversion examples are included in the default menu.lst to aid your<br />
understanding.<br />
<br />
Once you grasped the concept of device naming, all you need to do is<br />
to choose a nice title for your boot section(s), supply the correct<br />
root partition device as a parameter to the root option to have it<br />
mounted as / on bootup, and create a kernel line that includes the<br />
partition and path where the kernel is located as well as any boot<br />
parameters. If using the stock Arch 2.6.x kernel, you'll also need an<br />
initrd line that points to the kernel26.img file in your /boot<br />
directory. The path you put on your initrd line should be the same as<br />
the path to vmlinuz26 that you provide on the kernel line. You should<br />
be fine with the defaults, just check whether the partition<br />
information is correct in the root and kernel lines, especially in<br />
regard to the pata issue!<br />
<br />
To create a boot option that loads the bootsector of a different OS,<br />
the following example might be helpful. You will probably succeed in<br />
starting any Microsoft-based operating system with it, just add this<br />
block to the file after any other sections, and modify the partition<br />
device accordingly to refer to the partition containing the bootsector<br />
of the OS you are intending to boot.<br />
(1) Other OS<br />
title My Other OS<br />
rootnoverify (hd0,1)<br />
makeactive<br />
chainloader +1<br />
<br />
For advanced configuration of other OSes, please refer to the online<br />
GRUB manual.<br />
<br />
After checking your bootloader configuration for correctness, you'll<br />
be prompted for a partition to install the loader to. Unless you're<br />
using yet another boot loader, you should install GRUB to the MBR of<br />
the installation disk, which is usually represented by the appropriate<br />
device name without a number suffix.<br />
<br />
<br />
'''/etc/lilo.conf'''<br />
<br />
This is the configuration file for the LILO bootloader. Make sure you<br />
check this one and get it right if you want to use LILO to boot your<br />
system. See LILO documentation for help on this.<br />
<br />
Things you should check are the root= lines in the image sections and<br />
the boot= line right at the beginning of the file. The root lines<br />
specify the device which shall be mounted as the root filesystem on<br />
bootup. If you don't know what is supposed to be entered here, change<br />
to another terminal and type mount to see a list of all currently<br />
mounted drives, and look for the line which displays a device name<br />
mounted on /mnt type [...]. The device path at the beginning of this<br />
very line should be entered in the root lines of your lilo.conf.<br />
Change if necessary, and keep the pata issue in mind!<br />
<br />
The boot line should be okay by default in most cases. Unless you have<br />
a weird boot manager setup in mind with multiple OSes, the device<br />
referenced here should be having the same prefix your root lines have,<br />
but not end with a number. For example, a root of /dev/hda3 means you<br />
probably want to install LILO into the Master Boot Record of the hard<br />
disk, so you would set boot to /dev/hda, which references the disk as<br />
a whole. During installation, the boot device must be the current name<br />
of the device where you want to write the boot sector to; This may<br />
differ from the name of the device after the first boot, thanks to the<br />
pata transition! Check carefully what device to write to during the<br />
installation stage, for example with the mount command.<br />
<br />
To prevent some serious grief, you should make sure you know how to<br />
restore the bootsector of your other OSes, for example with Windows's<br />
FIXBOOT/FIXMBR tools.<br />
<br />
To be on the safe side, you should keep the option lba32 listed. This<br />
will prevent some geometry issues from happening.<br />
<br />
In some cases, depending on your BIOS, LILO will not run on bootup and<br />
spill out an error code infinitely. In most cases you either removed<br />
the lba32 option, or your hardware setup is a little special, meaning<br />
that maybe your CD-ROM drive is primary master and the hard disk you<br />
installed secondary slave. This can very well confuse your BIOS, and<br />
thus stop the boot process. To prevent that you can try and make the<br />
install drive the primary master on your IDE bus. If you've got a<br />
mixed IDE and SCSI system and the problem persists, you'll probably<br />
need some experimentation with the disk and bios options of LILO to<br />
provide a working mapping; The disk drives in your system are numbered<br />
sequentially by your BIOS, starting with 0x80. If you're lucky your<br />
SCSI controller tells you which drive has which BIOS ID, but usually<br />
you're not. How the drives are effectively numbered is depending on<br />
your BIOS, so in the worst case you can only guess until it works. A<br />
typical disk line would look like this:<br />
boot=/dev/hda<br />
disk=/dev/hda bios=0x80<br />
<br />
The disk option maps a BIOS ID to the disk device known to the system. Note<br />
that there is still no guarantee that things will work as other things<br />
can be wrong, so do not despair if all your tries fail, but rather try<br />
rearranging your hardware in a way that's not totally odd. In this<br />
area too much can go wrong and needs special handling to be explained<br />
here. In most cases the lba32 option will suffice anyway. Old hard<br />
drives will usually need a little more special care until they do as<br />
told.<br />
<br />
Don't become fidgety when reading this section, I (Dennis) just<br />
happened to stumble over this problem when experimenting with a rather<br />
odd system, and figured it'd be a good idea to mention this show<br />
stopper and workarounds here. You probably won't ever experience this,<br />
as you should be using GRUB anyway.<br />
<br />
How to recreate a LILO boot sector with only a rescue disk is<br />
explained later in this document.<br />
<br />
<br />
'''/etc/conf.d/*'''<br />
<br />
During setup, this is totally unimportant. Consider this as reference<br />
for the interested.<br />
<br />
Some daemon scripts will have a matching configuration file in this<br />
directory that contains some more-or-less useful default values. When<br />
a daemon is started, it will first source the settings from its<br />
config file within this directory, and then source the /etc/rc.conf.<br />
This means you can easily centralize all your daemon configuration<br />
options in your /etc/rc.conf simply by setting an appropriate variable<br />
value, or split up your configuration over multiple files if you<br />
prefer a decentralized approach to this issue. Isn't life great if<br />
it's all just simple scripting?<br />
<br />
<br />
'''/etc/profile'''<br />
<br />
This script is run on each user login to initialize the system. It is<br />
kept quite simple under Arch Linux, as most things are. You may wish<br />
to edit or customize it to suit your needs.<br />
<br />
====Kernel====<br />
<br />
The CD-ROM includes the latest kernel available at time of release. If you are using the FTP<br />
Installation method, the kernel about to be installed will be the<br />
current version waiting on your FTP source, and might therefore<br />
introduce changes and/or incompatibilities unknown at the present<br />
time. This is unlikely, but keep it in mind.<br />
<br />
====Install Bootloader====<br />
<br />
Install Bootloader will install a bootloader on your hard drive,<br />
either GRUB (recommended) or LILO, depending on your personal<br />
preference.<br />
<br />
Before installing the bootloader, the setup script will want you to<br />
examine the appropriate configuration file to confirm the proper<br />
settings. <br />
<br />
If you choose to install LILO, the bootloader will be automatically<br />
installed according to your settings in the configuration file, whilst<br />
GRUB demands the selection of a partition to install the bootloader<br />
to. Here you should choose what you would enter as the boot option of<br />
LILO, which is usually the entry named /dev/hda, as it refers the<br />
master boot record of the first hard disk. Detailed error messages can<br />
be found as usual on VC5 (virtual console 5), if anything goes wrong.<br />
<br />
If you plan on setting up a multiboot system, you may wish to install the bootloader in your / or /boot partition, and<br />
refer to that boot sector from whatever other boot loader you want to<br />
reside in the master boot record. (chainloading)<br />
<br />
Installing a boot loader in the MBR will relentlessly overwrite any<br />
existing bootloader! Make sure you understand the implications of that<br />
if you're running a multiboot system, or want to preserve an installed<br />
bootloader from another OS!<br />
<br />
====Exit Install====<br />
<br />
Exit the Installer, eject the CD, and:<br />
reboot<br />
<br />
Login as root and add a user as outlined in the<br />
[[User_Management | User Management]] section, and set up your Internet Connection.<br />
<br />
Congratulations! Welcome to your new Arch Linux base system!<br />
<br />
==APPENDIX==<br />
<br />
See [[Official Arch Linux Install Guide Appendix]]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=GNOME_2&diff=58653
GNOME 2
2009-01-20T17:02:09Z
<p>Phrakture: MouserTweaks -> MouseTweaks typo</p>
<hr />
<div>[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|GNOME}}<br />
{{i18n_entry|Español|GNOME (Español)}}<br />
{{i18n_entry|Русский|GNOME (Русский)}}<br />
{{i18n_entry|Czech|GNOME (Česky)}}<br />
{{i18n_entry|简体中文|GNOME (简体中文)}}<br />
{{i18n_entry|Português do Brasil|GNOME (pt_br)}}<br />
{{i18n_entry|ไทย|GNOME (ไทย)}}<br />
{{i18n_entry|Nederlands|GNOME(Nederlands)}}<br />
{{i18n_entry|Italiano|GNOME (Italiano)}}<br />
{{i18n_entry|Türkçe|GNOME (Türkçe)}}<br />
{{i18n_links_end}}<br />
<br />
==What is GNOME?==<br />
<br />
The [http://www.gnome.org/ GNOME] project provides two things: The GNOME desktop environment, an intuitive and attractive desktop for end-users, and the GNOME development platform, an extensive framework for building applications that integrate into the rest of the desktop.<br />
<br />
==How to install the GNOME Desktop==<br />
<br />
Before installing GNOME Desktop make sure you have updated pacman itself by: <br />
# pacman -Syu <br />
# pacman -Syy<br />
<br />
This will bypass the error which is encountered while installing gnome-media package that depends on gstreamer0.10-gconf but its not there in the package list with the pacman out of the box version. An update is necessary prior to installation of GNOME.<br />
<br />
Install the base GNOME Desktop by: <br />
# pacman -S gnome<br />
<br />
This is a metapackage; which is a group of packages. An option will be given to install all or some of the packages in this group. All the packages can safely be installed and is highly recommended, but here is a list of some that may not be needed.<br />
<br />
*'''Epiphany''' is a web browser that comes with GNOME. If you are planning on using a different browser e.g. Firefox then this package is not needed. It is recommended that you at least try Epiphany as it is an excellent browser that unfortunately gets over shadowed by Firefox.<br />
*'''Evolution''' is a Personal Information Management PIM (e-mail, calendar, contacts, etc.) application for GNOME. If you are planning on using a different PIM; e.g. Thunderbird, or a web PIM like a google or yahoo account then you have no need for this package.<br />
*'''gnome-backgrounds''' is a collection of desktop backgrounds (wallpapers) that the GNOME community has selected for you to use. If you already know what you will be using for your background e.g. a picture of you sweetheart, then this package is not needed. <br />
*'''gnome-screensaver''' is a collection of screensavers for the GNOME desktop. If you will not be using a screensaver, i.e. using the GNOME power manager to shut the monitor off when not in use then this package is not needed.<br />
*'''gnome-themes''' is a collection of desktop themes. If you will be using a specific theme that you will be downloading separately then this package is not needed.<br />
*'''gnome2-user-docs''' and '''yelp''' are the help documents and help document reader for the GNOME desktop. If you are the kind of person that does not read documentation or you would rather use the large help documents known as google, then there would be no need to install these packages. This is not recommended. (Ironically, if you are the kind of person that does not read documentation then chances are you won’t be reading this.) <br />
*'''libgail-gnome''' is a GNOME accessibility implementation library used by the screen reader Orca. If you and everyone else that will be using this desktop have good vision then this package is not needed.<br />
<br />
Install the rest of the GNOME Desktop (highly recommended, see [[Gnome Tips]])by:<br />
# pacman -S gnome-extra<br />
<br />
Like before this is a metapackage, and it is recommended to install all packages in this group, but here is a list of some that may not be needed.<br />
<br />
*'''Cheese''' uses your webcam to take photos and videos; if you don’t have a webcam then this package is not needed.<br />
*'''Dasher''' is a text entry application that uses the pointer instead of a keyboard. If you and everyone that will be using this desktop can use a keyboard then this package is not needed.<br />
*'''Deskbar-applet''' is an all-in-one search bar for the GNOME desktop. If you don't need a desktop search then this package is not needed.<br />
*'''Ekiga''' is a VOIP/Videoconferencing application. If you have no need for VOIP or use a different application like Skype, then this package is not needed.<br />
*'''Evince''' is a simple document (e.g. pdf) viewer. If you are planning on using a different viewer e.g. Adobe Reader then this package is not needed.<br />
*'''Evolution-exchange''' is a plug in for Evolution that allows Evolution to connect to Exchange. If you don't use Exchange or Evolution then you have no need for this package. <br />
*'''Evolution-webcal''' is a web calendar plug in for Evolution. If you don't use Evolution then you have no need for this package.<br />
*'''Fast-user-switch-applet''' is an applet that allows the switching of users without going through a log out, and log in screen, i.e. you can switch users fast. If there is only one user on your computer or you like seeing the log in screen then you have no need for this package.<br />
*'''Gdm''' facilitates the starting of GNOME at boot up. If you like your computer to boot into a nice traditional command line and you will start GNOME only when you need it, then this package is not for you.<br />
*'''Gedit''' is a GUI based text editor. If you plan on using a different text editor – as most people’s devotion to their favorite text editor is religious you more than likely have an example in mind – then you have no need to install this package. (If you are devoted to gedit I apologize for suggesting it not be installed; I only did so for completeness.)<br />
*'''Gnome-games''' and '''gnome-games-extra-data''' is a collection of simple desktop games; e.g. Nibbles, Sudoku, etc. If you feel that childish games are a waste of your time, hard drive space and bandwidth then this package is not for you.<br />
*'''Gnome-mag''' is a screen magnifier for people with poor vision. If you and everyone that will be using this desktop have good vision then you have no need for this package.<br />
*'''Gnome-nettool''' is a collection of GUI based networking tools. If you do all your networking stuff from the command line then this package is not for you.<br />
*'''Gok''' is the GNOME on screen keyboard. If you and every one using this desktop plan on using a standard keyboard for all your keyboard needs then don't install this package.<br />
*'''Hamster-applet''' is a time tracking applet. Please visited its web site [http://projecthamster.wordpress.com/ Project Hamster] to decide if you should install it or not. I am afraid that describing this applet in one or two sentences does not do the project justice.<br />
*'''Mousetweaks''' is accessibility software for users that have limited control of a mouse (e.g. can manipulate only one button). If you and every one that will be using this desktop have full control of the mouse then there is no need to install this package.<br />
*'''Nautilus-cd-burner''' allows the burning of files to CDs by dragging-and-dropping in the GNOME file manager, Nautilus. The only reason not to install this package is if you don’t have a CD burner on your computer. <br />
*'''Orca''' is a screen reader for the GNOME desktop to help users with limited vision. If you and everyone else that will be using this desktop have good vision then this package is not needed.<br />
*'''Sound-juicer''' is a CD ripping application for Gnome. If you are planning on using a different application for ripping CD e.g. Banshee or don’t have a CD drive then you have no need to install this package.<br />
*'''Tomboy''' is a simple desktop note taking application. If you don’t take notes or simply use pen and paper for your simple note taking needs then you have no need for this package.<br />
*'''Totem''' is the official movie player of the GNOME desktop. If you plan on using a different movie player e.g. VLC then you have no need for this package.<br />
*'''Vinagre''' is a VNC client for the GNOME desktop. If you have no need for a VNC client then you have no need for this package.<br />
*'''Vino''' is a remote desktop client for the GNOME desktop. If you have no need for a remote desktop client then you have no need for this package.<br />
<br />
==Daemons and Modules Needed by the GNOME Desktop==<br />
The GNOME desktop requires two daemons, '''FAM''' and '''HAL''' for proper operation. The File Alteration Monitor '''FAM''' daemon allows real-time representation of file alterations; i.e. give the GUI instant access to recently installed programs or changes in the file system. The Hardware Abstraction Layer '''HAL''' daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI.<br />
<br />
To start the HAL and FAM daemons:<br />
# /etc/rc.d/hal start<br />
# /etc/rc.d/fam start<br />
Or add these daemons to the '''DAEMONS''' array in '''/etc/rc.conf''' so they will start on boot up, e.g.:<br />
#<br />
# /etc/rc.conf - Main Configuration for Arch Linux<br />
#<br />
.<br />
.<br />
# -----------------------------------------------------------------------<br />
# DAEMONS<br />
# -----------------------------------------------------------------------<br />
#<br />
# Daemons to start at boot-up (in this order)<br />
# - prefix a daemon with a ! to disable it<br />
# - prefix a daemon with a @ to start it up in the background<br />
#<br />
.<br />
.<br />
DAEMONS=(syslog-ng network crond '''hal''' '''fam''')<br />
<br />
'''Note''': You may instead want to remove FAM and install gamin, which doesn't require a system daemon to be running. <br />
<br />
'''GVFS''' allows the mounting of virtual file systems (e.g. file systems over FTP or SMB) to be used by other applications, including the GNOME file manager Nautilus. This is done with the use of '''FUSE''': a user space virtual file system layer kernel module.<br />
<br />
To load the FUSE kernel module:<br />
<br />
# modprobe fuse<br />
<br />
Or add the module to the '''MODULES''' array in '''/etc/rc.conf''' so they will load at boot up, e.g.:<br />
#<br />
# /etc/rc.conf - Main Configuration for Arch Linux<br />
#<br />
.<br />
.<br />
# -----------------------------------------------------------------------<br />
# HARDWARE<br />
# -----------------------------------------------------------------------<br />
#<br />
# MOD_AUTOLOAD: Allow autoloading of modules at boot and when needed<br />
# MOD_BLACKLIST: Prevent udev from loading these modules<br />
# MODULES: Modules to load at boot-up. Prefix with a ! to blacklist.<br />
#<br />
# NOTE: Use of 'MOD_BLACKLIST' is deprecated. Please use ! in the MODULES array.<br />
#<br />
MOD_AUTOLOAD="yes"<br />
#MOD_BLACKLIST=() #deprecated<br />
MODULES=('''fuse''' usblp)<br />
.<br />
.<br />
'''Note''': FUSE is a kernel module not a daemon and does not go in the same array as HAL and FAM.<br />
<br />
==Running the GNOME Desktop==<br />
<br />
To start GNOME from the console, run:<br />
gnome-session<br />
<br />
If you add the following to your $HOME/.xinitrc file (and make sure it is the only line that starts with "exec"):<br />
exec gnome-session<br />
<br />
To make it a global setting which has effect on all users in stead of only one, in stead of $HOME/.xinitrc add the line to the file /etc/X11/xinit/xinitrc:<br />
exec gnome-session<br />
<br />
Note: Only needed for gnome 2.14, gnome 2.16 and up do this for you:<br />
exec dbus-launch --exit-with-session /opt/gnome/bin/gnome-session<br />
<br />
GNOME will start when you enter the following command.<br />
startx<br />
<br />
==GDM (GNOME Display Manager)==<br />
<br />
If you want a graphical login, you will need to install [http://www.gnome.org/projects/gdm/ GDM] (which is also part of gnome-extra). To do so, type the following at a command prompt:<br />
pacman -S gdm<br />
<br />
To make the graphical login the default method of logging into the system, add gdm to your list of daemons in /etc/rc.conf<br />
<br />
If you are used to using the '''$HOME/.xinitrc''' file to pass arguments to the x server when it is started, such as '''xmodmap''' or '''xsetroot''', you should note that you can add the same commands to the '''$HOME/.xprofile''' file. My .xprofile looks like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
#<br />
# ~/.xprofile<br />
#<br />
# Executed by gdm at login<br />
#<br />
<br />
xmodmap -e "pointer = 1 2 3 6 7 4 5" #set mouse buttons up correctly<br />
xsetroot -solid black #sets the background to black<br />
</pre><br />
<br />
You can configure GDM (for changing default theme for example) in System->Administration->Login Window. Or you can use this command (as root) :<br />
gdmsetup <br />
<br />
For more information about Graphical Logins (DMs), see [http://endor.clublinux.org/RHCE-21.html this excellent page].<br />
<br />
==Troubleshooting==<br />
<br />
===Your computer crashes and gnome won't startup anymore.===<br />
<br />
solution: delete ~/.gnome2/session<br />
<br />
===Panels wouldn't work correctly===<br />
<br />
Sourced from [http://bbs.archlinux.org/viewtopic.php?pid=248399 this forum page]<br />
<br />
Solution: Try with a fresh configuration by moving you old configs out of the way:<br />
for d in .gnome* .gconf*; do mv $d $d.old; done<br />
<br />
===GDM won't start===<br />
<br />
If you get this message:<br />
<i>"The greeter application appears to be crashing. Attempting to use a different one"</i><br />
<br />
One possible reason is that your /tmp folder has the wrong permissions set. Run:<br />
chmod 1777 /tmp<br />
<br />
As root and try again.<br />
<br />
===GNOME lags===<br />
<br />
If opening programs in GNOME takes an unusual long time. You may be able to fix this by editing /etc/hosts and adding your host name.<br />
nano /etc/hosts<br />
<br />
Now, you should add the host name you have defined in /etc/rc.conf or your network profile if you have one (if you don't know, you probably don't).<br />
<br />
The /etc/hosts file usually looks like this:<br />
<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost<br />
<br />
# End of file<br />
<br />
Add your host name (in this example the host name `example_hostname' was picked) to the end of the line which starts with `127.0.0.1'.<br />
Now it looks like this:<br />
<br />
#<br />
# /etc/hosts: static lookup table for host names<br />
#<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost example_hostname<br />
<br />
# End of file<br />
<br />
===Screen gets dark while GNOME loading===<br />
<br />
If screen gets dark while GNOME loading, you may correct this problem as following.<br />
<br />
Open a terminal and run:<br />
gconf-editor<br />
<br />
Find:<br />
<br />
/ -> apps -> gnome-power-manager -> backlight<br />
<br />
and change the value of<br />
<br />
brightness_ac<br />
<br />
from 100 to 0 by clicking on it. After restart the system, the problem should not be occur.<br />
<br />
Tip: If the problem will be corrected, the same problem will occur. Change to brightness_ac value from 0 to 100 to solve this problem if it will occur again.<br />
<br />
<br />
Done.<br />
<br />
==See also==<br />
* [[Gnome Tips]]<br />
* [[Gnome Menu tweaking]]<br />
* [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]]<br />
* [[Build_order_for_Gnome|Build Order]]<br />
* [[Howto make GTK apps look nice| HOWTO: Make GTK1 apps look nice]]<br />
<br />
==External links==<br />
* [http://www.gnome.org/ The Official Website]<br />
* [http://www.gnome.org/learn/ The Official Documentation]<br />
* [http://gnomehelp.org/ GnomeHelp.org]<br />
* Themes, icons, and backgrounds:<br />
** [http://art.gnome.org/ Gnome Art]<br />
** [http://www.gnome-look.org/ Gnome Look]<br />
* GTK/Gnome programs:<br />
** [http://www.gnomefiles.org/ Gnome Files]<br />
** [http://www.gnome.org/projects/ Gnome Project Listing]<br />
* [http://archux.com/page/installing-and-setting-gnome Installing Gnome]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57503
DeveloperWiki:Developer Checklist
2009-01-09T18:45:28Z
<p>Phrakture: /* For the admin */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums <br />
* upgrade to a "SysOp" on the wiki: [[Special:Userrights]]<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57502
DeveloperWiki:Developer Checklist
2009-01-09T18:44:57Z
<p>Phrakture: /* For the admin */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "SysOp" on the [[Special:Userrights wiki]]<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57501
DeveloperWiki:Developer Checklist
2009-01-09T18:43:48Z
<p>Phrakture: /* For the admin */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "SysOp" on the wiki<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Community_move_to_devtools&diff=57500
DeveloperWiki:Community move to devtools
2009-01-09T17:50:29Z
<p>Phrakture: </p>
<hr />
<div>Proposal: '''Make [community] use the same repository system as [core] or [extra].'''<br />
<br />
Reference: http://archlinux.org/pipermail/aur-general/2008-December/003325.html<br />
<br/>The above thread contains the initial discussion on this proposal.<br />
<br />
For quite a while, [community] in Arch has led an almost independent<br />
existence, being tightly coupled with the AUR. Many improvements have<br />
been made in the workflow of package distribution in 'devtools' which<br />
are used for uploading and managing packages in the [core] and [extra]<br />
repositories.<br />
<br />
This proposal suggests that the [community] repository move to using the<br />
same repository system as [core] or [extra]. The benefits and detriments<br />
of the proposal, along with the technical steps to complete the transition<br />
(if the proposal were to be passed) are discussed below.<br />
<br />
=Detriments=<br />
<br />
* It might affect the autonomy of Trusted Users, and this is a big change from the way we've been used to.<br />
* The effort to make the transition happen is not trivial.<br />
* You'd lose votes for community packages.<br />
* You'd lose package comments and notifications.<br />
* Combining community packages with official packages will contribute a performance hit for all repos when dealing with build files.<br />
<br />
=Benefits=<br />
<br />
* There'll be fewer tools to support, since Trusted Users would then use the same tools as Arch developers, but with reduced permissions (only permission to write to the [community] repository)<br />
<br />
* It'd be much easier to create and maintain a [community-testing] repository (or even the [testing] repository, if it's possible to cleanly separate the relevant permissions). A testing repository for [community] would be a great help in doing rebuilds.<br />
<br />
* It'll be easier to migrate from being a Trusted User to a developer, since all the repositories would be using the same infrastructure. A simple permissions change, and they could be uploading packages to [core] or [extra].<br />
<br />
* [community] would naturally become more decoupled from the AUR. Packages in [community] would become visible on the main Arch website, giving greater visibility to [community]. Also the search function on the website would then be able to search across all the repositories.<br />
<br />
* The AUR code becomes greatly simplified, making code refactoring or rewrites easier.<br />
<br />
* The server daemon (tupkgupdate.py) for adding packages to [community] and other associated cruft which has been lying around for ages can be got rid of.<br />
<br />
=Technical steps for the transition=<br />
<br />
Reference: http://archlinux.org/pipermail/aur-general/2009-January/003460.html<br />
<br />
* devtools/db-scripts have to be patched for [community]. ABS also has to be patched.<br />
* Decide what's to be done on the web frontend side (AUR, main Arch site) and then do it!<br />
* CVS to SVN migration. This would not be much of a problem since there would be scripts from the main repository migration lying around.<br />
<br />
== Behind the scenes ==<br />
<br />
* Admins would now need to maintain user accounts for new TUs or when TUs leave.<br />
* Quotas will probably need to be implemented for disk/cpu/ram usage, as we open gerolde up to way more user accounts in one fell swoop<br />
: [[User:Phrakture|phrakture]] 12:50, 9 January 2009 (EST)<br />
<br />
<br />
The most important objective of this proposal is to make [community]<br />
use the same infrastructure (devtools, etc.) as the Arch official<br />
repositories [core] and [extra]. Technical details about how the<br />
transition is to be made (whether [community] and AUR should be totally<br />
decoupled, for example) need to be discussed.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57499
DeveloperWiki:Developer Checklist
2009-01-09T17:34:31Z
<p>Phrakture: /* For the new developer */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "developer" on the AUR<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it<br />
* git projects are "fenced in" to prevent people from pushing code willy-nilly. If you think you should have push access to a git repo, talk to the owner of the repo (listed on [http://projects.archlinux.org projects]). If they accept, any admin can add you to the proper group</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57498
DeveloperWiki:Developer Checklist
2009-01-09T17:33:02Z
<p>Phrakture: /* For the new developer */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "developer" on the AUR<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap. You may also want the base-devel package if you do not have it</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=57497
DeveloperWiki:Developer Checklist
2009-01-09T17:32:39Z
<p>Phrakture: /* For the new developer */</p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "developer" on the AUR<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh (See [[DeveloperWiki:HOWTO_Be_A_Packager]])<br />
* Install devtools and namcap</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Pacman/Pacnew_and_Pacsave&diff=55982
Pacman/Pacnew and Pacsave
2008-12-22T18:29:32Z
<p>Phrakture: .pacorig stub</p>
<hr />
<div>[[Category:Package management (English)]]<br />
<br />
==Introduction==<br />
<br />
During package upgrades or removal <code>pacman</code> sometimes warns that files &mdash; usually configurations in <code>/etc</code> &mdash; are being installed with a <code>.pacnew</code> extension or backed up with a <code>.pacsave</code> extension.<br />
<br />
A <code>'''.pacnew'''</code> file is created during a package upgrade (<code>pacman -U</code> or <code>pacman -Su</code>) to avoid overwriting a file which already exists and was previously modified by the user. When this happens a message like the following will appear in the output of <code>pacman</code>:<br />
<br />
warning: /etc/pam.d/usermod installed as /etc/pam.d/usermod.pacnew<br />
<br />
A <code>'''.pacsave'''</code> file is created during a package removal (<code>pacman -R</code>, which is also called automatically by <code>pacman -U</code> and <code>pacman -Su</code>) when the <code>pacman</code> database indicates that a certain file owned by the package should be renamed with a <code>.pacsave</code> extension if it was previously modified by the user. When this happens <code>pacman</code> outputs a message like the following:<br />
<br />
warning: /etc/pam.d/usermod saved as /etc/pam.d/usermod.pacsave<br />
<br />
These files require manual intervention from the user and it is good practice to handle them immediately after every invocation of <code>pacman</code>. If left unhandled they will accumulate and clutter up the filesystem, and installed software may become misconfigured, causing undesired behavior that can be difficult to troubleshoot.<br />
<br />
==When .pac* Files Are Created==<br />
<br />
===.pacnew===<br />
<br />
For each file in a package being upgraded, <code>pacman</code> cross-compares three [http://en.wikipedia.org/wiki/Md5 MD5 sums] generated from the file's contents: one sum for the version originally installed by the package, one for the version currently in the filesystem, and one for the version in the new package. If the version of the file currently in the filesystem has been modified from the version originally installed by the package, <code>pacman</code> cannot know how to merge those changes with the new version of the file. Therefore, instead of overwriting the modified file when upgrading, <code>pacman</code> saves the new version with a <code>.pacnew</code> extension and leaves the modified version untouched.<br />
<br />
Going into further detail, the 3-way MD5 sum comparison results in one of the following outcomes:<br />
<br />
; original = ''X'', current = ''X'', new = ''X'' : All three versions of the file have identical contents, so overwriting is not a problem. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''X'', new = ''Y'' : The current version's contents are identical to the original's, but the new version is different. Since the user hasn't modified the current version and the new version may contain improvements or bugfixes, overwrite the current version with the new version and do not notify the user. This is the only auto-merging of new changes that <code>pacman</code> is capable of performing.<br />
<br />
; original = ''X'', current = ''Y'', new = ''X'' : The original package and the new package both contain exactly the same version of the file, but the version currently in the filesystem has been modified. Leave the current version in place and discard the new version without notifying the user.<br />
<br />
; original = ''X'', current = ''Y'', new = ''Y'' : The new version is identical to the current version. Overwrite the current version with the new version and do not notify the user. (Although the file contents are the same, this overwrite will update the filesystem's information regarding the file's installed, modified, and accessed times, as well as ensure that any file permission changes are applied.)<br />
<br />
; original = ''X'', current = ''Y'', new = ''Z'' : All three versions are different, so leave the current version in place, install the new version with a <code>.pacnew</code> extension and warn the user about the new version. The user will be expected to manually merge any changes necessary from the new version into the current version.<br />
<br />
===.pacsave===<br />
<br />
A package's <code>PKGBUILD</code> file specifies which files should be backed up when the package is upgraded or removed. For example, the <code>PKGBUILD</code> for <code>pulseaudio</code> contains the following line:<br />
<br />
backup=('etc/pulse/client.conf' 'etc/pulse/daemon.conf' 'etc/pulse/default.pa')<br />
<br />
If the user has modified one of the files specified in <code>backup</code> then that file will be renamed with a <code>.pacsave</code> extension and will remain in the filesystem after the rest of the package is upgraded or removed.<br />
<br />
{{Box Note | Use of the <code>-n</code> option with <code>pacman -R</code> will result in complete removal of ''all'' files in the specified package, therefore no <code>.pacsave</code> files will be created.}}<br />
<br />
===.pacorig===<br />
<br />
.pacorig files are created when... TODO<br />
<br />
==Managing .pac* Files==<br />
<br />
Always pay attention to the output of <code>pacman</code>. When upgrading or removing a large number of packages, important messages may scroll by too quickly or beyond the terminal's buffer; fortunately there are other ways to discover whether a <code>pacman</code> operation created any <code>.pac*</code> files.<br />
<br />
If the user or a <code>cron</code> job has run <code>updatedb</code> to update the <code>locate</code> database since <code>pacman</code> was last run, the files can be located with:<br />
<br />
locate .pac<br />
<br />
A slower method (unless the user manually runs <code>updatedb</code> before <code>locate</code>) that always yields up-to-date results is the <code>find</code> command:<br />
<br />
find / -name "*.pac*"<br />
<br />
Searching the <code>pacman</code> log with <code>egrep</code> can be as fast as the <code>locate</code> method above and it will always yield up-to-date results; however, it doesn't record which files remain in the filesystem or have been removed:<br />
<br />
egrep "pac(new|save)" /var/log/pacman.log<br />
<br />
{{Box Note | <code>pacman</code> currently doesn't log <code>.pacsave</code> warnings, rendering the <code>egrep</code> method less useful than the other two methods. A [http://bugs.archlinux.org/task/12531 bug has been filed] to have this corrected.}}<br />
<br />
Once all existing <code>.pac*</code> files have been located the user may handle them manually using merge tools such as <code>vimdiff</code> (part of [[Vim|<code>vim</code>]]) or <code>ediff</code> (part of [[Emacs|<code>emacs</code>]]) and by deleting the <code>.pac*</code> files which the user is certain they no longer need. A few third-party utilities providing various levels of automation for these tasks are available from the <code>[[AUR_User_Guidelines#.5Bcommunity.5D|community]]</code> repo and [[ArchLinux User-community Repository (AUR)|AUR]] (Arch doesn't provide official utilities for <code>.pac*</code> file management):<br />
<br />
*[[Dotpac]] &mdash; Basic interactive script with ncurses-based text interface and helpful walkthrough. No merging or auto-merging features.<br />
*[http://aur.archlinux.org/packages.php?ID=15326 pacdiff] &mdash; Very minimal and undocumented CLI script. Part of the <code>pacman-contrib</code> package in the <code>community</code> repo.<br />
*[http://aur.archlinux.org/packages.php?ID=5863 pacdiffviewer] &mdash; Full-featured interactive CLI script with auto-merging capability. Part of the [[Yaourt|<code>yaourt</code>]] package.<br />
<br />
==External Links==<br />
*Arch Linux Forums: [http://bbs.archlinux.org/viewtopic.php?id=53532 Dealing With .pacnew Files]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:CoreSignoffs&diff=55660
DeveloperWiki:CoreSignoffs
2008-12-16T17:29:29Z
<p>Phrakture: /* List of potential signees for low-usage core packages */</p>
<hr />
<div>= Core Signoffs =<br />
<br />
This policy is intended to ensure the [core] repository, and thus the core of Arch Linux, is as functional as possible at all times.<br />
<br />
=== Process ===<br />
The process is simple:<br />
<br />
* All [core] packages '''MUST''' go to [testing] first.<br />
* When a [core] package is placed in [testing] an email '''SHOULD''' be sent to the arch-dev-public mailing list with the subject "[signoff] foobar-1.0-1", where ''foobar-1.0-1'' is the package name and version.<br />
* All developers are encouraged to test this package.<br />
* If a package works fine, a reply '''SHOULD''' be sent, telling the maintainer it worked, and on which architecture.<br />
* When a package receives 2 signoffs for each architecture, it can be moved from [testing] to [core].<br />
* A maintainer is free to leave a package in [testing] for further testing or signoffs, but should make this intention known in the signoff email.<br />
<br />
=== Caveats ===<br />
The maintainer himself *DOES* count as a signoff. We are working under the assumption that the maintainer did test the package before pushing it to [testing]. Thus, a package may only need one signoff if the original maintainer tested it on both architectures before uploading.<br />
<br />
=== List of potential signees for low-usage core packages ===<br />
<br />
This list is to improve the effectiveness of the signoffs by determining what packages can't get the required signoffs by the dev group. Please put your name (or nick) and the arch (i686, x86_64, both) along the low-usage packages you can test. I'm listing here all the core packages. The ones that I believe everyone use and can test (please fix if they are incorrect or missing) are marked by a 'EVERYONE' so you don't need to write your name beside them. <br />
<br />
{| border="1"<br />
| acl || EVERYONE<br />
|-<br />
| atl2 || <br />
|-<br />
| attr || EVERYONE<br />
|-<br />
| autoconf || EVERYONE<br />
|-<br />
| automake || EVERYONE<br />
|-<br />
| b43-fwcutter || <br />
|-<br />
| bash || EVERYONE<br />
|-<br />
| bin86 || EVERYONE<br />
|-<br />
| binutils || EVERYONE<br />
|-<br />
| bison || EVERYONE<br />
|-<br />
| bridge-utils || <br />
|-<br />
| bzip2 || EVERYONE<br />
|-<br />
| ca-certificates || <br />
|-<br />
| capi4k-utils || <br />
|-<br />
| coreutils || EVERYONE<br />
|-<br />
| cpio || <br />
|-<br />
| cracklib || EVERYONE<br />
|-<br />
| cryptsetup || <br />
|-<br />
| dash || <br />
|-<br />
| db || EVERYONE<br />
|-<br />
| dbus-core || <br />
|-<br />
| dcron || EVERYONE<br />
|-<br />
| device-mapper || Eric(both)<br />
|-<br />
| dhcpcd || Eric(x86_64)<br />
|-<br />
| dialog || Aaron(both)<br />
|-<br />
| diffutils || EVERYONE<br />
|-<br />
| dmapi || <br />
|-<br />
| dmraid || <br />
|-<br />
| dnsutils || <br />
|-<br />
| dosfstools || <br />
|-<br />
| e2fsprogs || Allan (both)<br />
|-<br />
| ed || EVERYONE<br />
|-<br />
| eventlog || makedep for syslog-ng<br />
|-<br />
| expat || <br />
|-<br />
| fakeroot || EVERYONE<br />
|-<br />
| file || EVERYONE<br />
|-<br />
| filesystem || EVERYONE<br />
|-<br />
| findutils || EVERYONE<br />
|-<br />
| flex || EVERYONE<br />
|-<br />
| gawk || EVERYONE<br />
|-<br />
| gcc || EVERYONE<br />
|-<br />
| gcc-libs || EVERYONE<br />
|-<br />
| gdbm || <br />
|-<br />
| gen-init-cpio || EVERYONE<br />
|-<br />
| gettext || Allan (both)<br />
|-<br />
| glib2 || EVERYONE<br />
|-<br />
| glibc || EVERYONE<br />
|-<br />
| gmp || EVERYONE<br />
|-<br />
| gpm || Eric(both)<br />
|-<br />
| grep || EVERYONE<br />
|-<br />
| groff || EVERYONE<br />
|-<br />
| grub || Eric(x86_64), Aaron(both)<br />
|-<br />
| gzip || EVERYONE<br />
|-<br />
| hdparm || <br />
|-<br />
| heimdal || EVERYONE<br />
|-<br />
| hwdetect || <br />
|-<br />
| ifenslave || <br />
|-<br />
| initscripts || EVERYONE<br />
|-<br />
| iproute || <br />
|-<br />
| iptables || <br />
|-<br />
| iputils || <br />
|-<br />
| ipw2100-fw || <br />
|-<br />
| ipw2200-fw || Pierre (i686)<br />
|-<br />
| isdn4k-utils || <br />
|-<br />
| iwlwifi-3945-ucode || Allan (both) / Thayer (i686)<br />
|-<br />
| iwlwifi-4965-ucode || <br />
|-<br />
| iwlwifi-5000-ucode || <br />
|-<br />
| jfsutils || <br />
|-<br />
| kbd || EVERYONE<br />
|-<br />
| kernel-headers || EVERYONE<br />
|-<br />
| kernel26 || EVERYONE<br />
|-<br />
| klibc || EVERYONE<br />
|-<br />
| klibc-extras || EVERYONE<br />
|-<br />
| klibc-kbd || EVERYONE<br />
|-<br />
| klibc-module-init-tools || EVERYONE<br />
|-<br />
| klibc-udev || EVERYONE<br />
|-<br />
| less || EVERYONE<br />
|-<br />
| libarchive || EVERYONE<br />
|-<br />
| libdownload || EVERYONE<br />
|-<br />
| libelf || <br />
|-<br />
| libevent || <br />
|-<br />
| libgcrypt || <br />
|-<br />
| libgpg-error || <br />
|-<br />
| libldap || <br />
|-<br />
| libpcap || <br />
|-<br />
| libsasl || <br />
|-<br />
| libtool || EVERYONE<br />
|-<br />
| libusb || <br />
|-<br />
| licenses || EVERYONE<br />
|-<br />
| lilo || Eric(i686)<br />
|-<br />
| links || Eric(both)<br />
|-<br />
| linux-atm || <br />
|-<br />
| logrotate || EVERYONE<br />
|-<br />
| lvm2 || Eric(both)<br />
|-<br />
| lzo2 || <br />
|-<br />
| m4 || EVERYONE<br />
|-<br />
| madwifi || <br />
|-<br />
| madwifi-utils || <br />
|-<br />
| mailx || <br />
|-<br />
| make || EVERYONE<br />
|-<br />
| man || EVERYONE<br />
|-<br />
| man-pages || EVERYONE<br />
|-<br />
| mdadm || Eric(x86_64)<br />
|-<br />
| mkinitcpio || EVERYONE<br />
|-<br />
| mlocate || EVERYONE<br />
|-<br />
| module-init-tools || EVERYONE<br />
|-<br />
| mpfr || EVERYONE<br />
|-<br />
| nano || Eric(both)<br />
|-<br />
| ncurses || EVERYONE<br />
|-<br />
| ndiswrapper || <br />
|-<br />
| ndiswrapper-utils || <br />
|-<br />
| net-tools || EVERYONE<br />
|-<br />
| netcfg || EVERYONE<br />
|-<br />
| netkit-telnet || <br />
|-<br />
| nfs-utils || <br />
|-<br />
| nfsidmap || <br />
|-<br />
| openssh || EVERYONE<br />
|-<br />
| openssl || EVERYONE<br />
|-<br />
| openswan || <br />
|-<br />
| openvpn || <br />
|-<br />
| pacman || EVERYONE<br />
|-<br />
| pam || EVERYONE<br />
|-<br />
| patch || EVERYONE<br />
|-<br />
| pciutils || Aaron(both)<br />
|-<br />
| pcmciautils || <br />
|-<br />
| pcre || EVERYONE<br />
|-<br />
| perl || EVERYONE<br />
|-<br />
| pkgconfig || EVERYONE<br />
|-<br />
| popt || EVERYONE<br />
|-<br />
| portmap || <br />
|-<br />
| ppp || <br />
|-<br />
| pptpclient || <br />
|-<br />
| procinfo || <br />
|-<br />
| procps || <br />
|-<br />
| psmisc || <br />
|-<br />
| readline || EVERYONE<br />
|-<br />
| reiserfsprogs || <br />
|-<br />
| rp-pppoe || <br />
|-<br />
| rt2500 || <br />
|-<br />
| rt2x00-rt61-fw || <br />
|-<br />
| rt2x00-rt71w-fw || <br />
|-<br />
| run-parts || <br />
|-<br />
| sdparm || <br />
|-<br />
| sed || EVERYONE<br />
|-<br />
| shadow || EVERYONE<br />
|-<br />
| sudo || EVERYONE<br />
|-<br />
| sysfsutils || <br />
|-<br />
| syslog-ng || EVERYONE<br />
|-<br />
| sysvinit || EVERYONE<br />
|-<br />
| tar || EVERYONE<br />
|-<br />
| tcp_wrappers || <br />
|-<br />
| texinfo || EVERYONE<br />
|-<br />
| tiacx || <br />
|-<br />
| tiacx-firmware || <br />
|-<br />
| tzdata || EVERYONE<br />
|-<br />
| udev || EVERYONE<br />
|-<br />
| usbutils || <br />
|-<br />
| util-linux-ng || <br />
|-<br />
| vi || Eric(both) / Aaron(both)<br />
|-<br />
| vpnc || Pierre (i686)<br />
|-<br />
| wget || EVERYONE<br />
|-<br />
| which || EVERYONE<br />
|-<br />
| wireless_tools || Thayer (i686)<br />
|-<br />
| wlan-ng26 || <br />
|-<br />
| wlan-ng26-utils || <br />
|-<br />
| wpa_supplicant || Pierre (i686) / Thayer (i686)<br />
|-<br />
| xfsprogs || <br />
|-<br />
| xinetd || <br />
|-<br />
| zd1211-firmware || <br />
|-<br />
| zlib || EVERYONE<br />
|}</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:Developer_Checklist&diff=54957
DeveloperWiki:Developer Checklist
2008-12-05T16:39:48Z
<p>Phrakture: </p>
<hr />
<div>= New developer setup and checklist =<br />
<br />
== For the admin ==<br />
To add a new user:<br />
<br />
* adduser on gerolde<br />
* add to svn-extra, ftp-extra (and possibly ftp-arch for core)<br />
* upgrade to a "developer" on flyspray<br />
* upgrade to a "developer" on the forums<br />
* upgrade to a "developer" on the AUR<br />
* subscribe them to arch-dev and arch-dev-public Mailing lists<br />
* add to https://dev.archlinux.org/admin users table<br />
* give password to #archlinux-dev<br />
* give password to #archlinux64-dev (for x86_64 developers)<br />
<br />
== For the new developer ==<br />
* Add your email address to ~/.forward (so exim can forward mail)<br />
* Make sure to checkout svn over ssh<br />
* Install devtools and namcap</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Package_Maintainer_guidelines&diff=53921
Package Maintainer guidelines
2008-11-21T06:27:34Z
<p>Phrakture: </p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
[[Category:Guidelines (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Explains Arch User Repository's Trusted Users.}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n_entry|English|AUR Trusted User Guidelines}}<br />
{{i18n_entry|简体中文|AUR Trusted User 导引}}<br />
{{i18n_entry|Español|TU (Trusted User) (Español)}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|AUR Q & A}}<br />
{{Article summary wiki|AUR User Guidelines}}<br />
{{Article summary wiki|AUR}}<br />
{{Article summary end}}<br />
<br />
=The Trusted User (TU)=<br />
The '''Trusted User (TU)''' is a member of the community charged with<br />
keeping the AUR in working order. He/she maintains popular packages, and<br />
votes in administrative matters. A TU is elected from active community<br />
members by current TUs in a democratic process. TUs are the only<br />
members who have a final say in the direction of the AUR.<br />
<br />
The TUs are governed using the [http://dev.archlinux.org/~simo/TUbylaws.html TU bylaws]<br />
<br />
==TU Duties==<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 />
==== Accessing the Repo ====<br />
<br />
Follow these instructions for uploading/modifying packages once you have become a TU:<br />
<ol><br />
<br />
<li>Install the "aurtools" package. Make sure you read the [[AURtools Tutorial]]</li><br />
<li>You will need to email your the output of "htpasswd -n" to whoever is in charge of the AUR CVS repo ( Simo Leone <simoATarchlinuxDOTorg> ). It comes with Apache.</li><br />
htpasswd -n <userid><br />
<li>Run the following commands to checkout the AUR CVS:<br><br />
<pre><br />
export CVSROOT=":pserver:<userid>@cvs.archlinux.org:/srv/cvs-community"<br />
cvs login<br />
cvs co community</pre></li><br />
<br />
<li> To add a new package:</li><br />
<pre><br />
cvs add &lt;directory&gt;<br />
cd &lt;directory&gt;<br />
cvs add PKGBUILD<br />
</pre><br />
<li>Make a commit:</li><br />
cvs commit<br />
<li> To upload a binary package:</li><br />
Please note that AUR password is to be used with tupkg (NOT the CVS password)<br />
tupkg --user &lt;userid&gt; --password &lt;aur-password&gt; &lt;packagefile.pkg.tar.gz&gt;<br />
<br />
<li> After uploading a package and committing the build files, tag the files with this command:</li><br />
cvs tag -cFR CURRENT &lt;newpackagebuilddir&gt;<br />
Package changes become available on every full and half of hour. Verify everything was uploaded properly, then select the newly added or updated package in the web interface and set yourself as the maintainer.<br />
</ol><br />
<i>'''Note:''' Steps 5-7 can be run with communitypkg in one command as mentioned below in the AURtools tutorial.</i><br />
<br />
<br />
<i><br />
'''Note:''' In some cases, especially for community packages, an x86_64 TU might bump the pkgrel by .1<br />
(and not +1). This indicates that the <strong> change to the PKGBUILD is x86_64 specific </strong> and<br />
i686 maintainers <strong> should not </strong> rebuild the package for i686. When the TU decides to bump<br />
the pkgrel , it should be done with the usual increment of +1. However, a previous pkgrel=2.1 must<br />
not become pkgrel=3.1 when bumped by the TU and must instead be pkgrel=3. In a nutshell, leave dot (.)<br />
releases exclusive to the x86_64 TU's to avoid confusion.<br />
</i><br />
<br />
==== Uploading packages to x86_64-version of community ====<br />
* step 1 till 5 are the same as mentioned above.<br />
* when using tupkg add "--port 1035" to the list of parameters<br />
* Tag the package with "cvs tag -cFR CURRENT-64"<br />
<br />
==== Adopting Packages ====<br />
A TU may adopt any package at any time. But because the TU's time is<br />
limited, he should try to only adopt popular packages. The voting<br />
mechanism in the AUR allows a TU to quickly gauge which packages users<br />
want.<br />
<br />
A maintainer should adopt his selected package(s) via the web interface. That maintainer is then responsible for bug fixes and new version updates. Packages must be properly cleaned and fixed after adoption.<br />
<br />
==== Disowning packages ====<br />
You can disown packages by choosing "Disown Packages" in the AUR webinterface.<br />
If a TU can't or doesn't want to maintain a package any longer, a<br />
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<br />
to maintain it, but the TUs should try not to drop many packages (they<br />
shouldn't take on more than they have time for). If a package has<br />
become obsolete or isn't used any longer, it can be removed completely<br />
as well.<br />
<br />
If a package has been removed completely, it can be uploaded once again<br />
(fresh) to UNSUPPORTED, where a regular user can maintain the package<br />
instead of the TU.<br />
<br />
==== Deleting packages from [community] ====<br />
<br />
Removing a package from [community] is easy but not straightforward.<br />
After you've removed it from community, you could re-add it to <br />
unsupported (make sure to keep a copy!) and orphan it, for adoption by <br />
some other user in unsupported.<br />
<br />
To remove a package, all you really need to do is remove the CURRENT (and possibly CURRENT-64) tag <br />
from the PKGBUILD. You do this by doing:<br />
<br />
cvs tag -d CURRENT PKGBUILD<br />
cvs tag -d CURRENT-64 PKGBUILD<br />
<br />
If you wish to remove the package materials from CVS for future <br />
revisions (because you don't want the old stuff lying around), you can <br />
do the following '''FROM THE PACKAGE'S DIRECTORY''' in your checked out <br />
version of the community repo (this is very important!):<br />
<br />
cd /path/to/<packagedirname><br />
cvs tag -dl CURRENT #or CURRENT-64<br />
cvs rm -fl<br />
cvs commit<br />
<br />
'''BE VERY CAREFUL''' with CVS delete commands! By untagging current on the whole repo you risk removing '''EVERYTHING''' in [community]. I've suggested commands that hope to minimize that possibility, but there's <br />
still danger where delete is involved. Especially note that the tag <br />
delete takes '''IMMEDIATELY''' before committing, so be very careful.<br />
<br />
Also, due to weirdness of CVS, actually removing the package directory <br />
is impossible. It will still show up in a checked out version unless you set up a ~/.cvsrc file that will help prune empty directories. The following is helpful:<br />
<br />
cvs -q<br />
diff -uN<br />
rdiff -u<br />
checkout -P<br />
update -dP<br />
<br />
Any TU can remove any package in [community] so keep this in mind and be <br />
extra super careful with this ability, lest you accidentally wipe out <br />
someone else's package.<br />
<br />
=== AURtools ===<br />
To help the Trusted Users with their duties, the AURtools were written based on the '''tupkg''' tool. If you are Trusted User, it is highly recommended that you use the AURtools. The [[AURtools Tutorial]] was written to help you to get used to them.</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Getting_PKGBUILDs_from_SVN&diff=53920
Getting PKGBUILDs from SVN
2008-11-21T06:25:51Z
<p>Phrakture: </p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Development (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
<br />
== IMPORTANT WARNING ==<br />
'''The entire SVN repo is huge. Not only will it take an obscene amount of disk space, but it will also tax the archlinux.org server for you to download it. Do not download the whole repo, only follow the instructions below.'''<br />
<br />
'''If you abuse this service, your address may be blocked.'''<br />
<br />
'''Never use the public SVN for any sort of scripting.'''<br />
<br />
=== Non-recursive checkout ===<br />
<br />
svn checkout -N svn://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 />
=== Checkout a package ===<br />
<br />
cd svn-packages<br />
svn update package-name<br />
<br />
This will pull the package you requested into your checkout. From now on, any time you `svn update` at the top level, this will be updated as well.<br />
<br />
=== Updating all packages ===<br />
<br />
cd svn-packages<br />
svn update<br />
<br />
=== Checkout an older revision of a package ===<br />
<br />
cd svn-packages<br />
svn log<br />
<br />
Find out the revision you want by examining the history<br />
<br />
svn update -r1729 package-name<br />
<br />
This will update an existing working copy of package-name to r1729</div>
Phrakture
https://wiki.archlinux.org/index.php?title=Locale&diff=51363
Locale
2008-10-17T19:05:23Z
<p>Phrakture: Added Collation section</p>
<hr />
<div>[[Category:Internationalization (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|Deutsch|Locales konfigurieren (Deutsch)}}<br />
{{i18n_entry|English|Configuring locales}}<br />
{{i18n_entry|Español|Locales (Español)}}<br />
{{i18n_entry|Česky|Nastavení locales}}<br />
{{i18n_entry|Українська|Локаль}}<br />
{{i18n_entry|简体中文|Locales (简体中文)}}<br />
{{i18n_links_end}}<br />
==Introduction==<br />
Locales are used in Linux to define which language the user uses. As the locales define the charset which the user uses as well, setting up the correct locale is especially important if the language contains non-ASCII characters.<br />
<br />
[[Locale Naming]] ist defined as following:<br />
<lang>_<territory>.<codeset>[@<modifiers>]<br />
<br />
In this howto we're setting up a system that uses the en_US.UTF-8 locale, but you can follow this article easily if you want to setup another locale.<br />
<br />
==Enabling necessary locales==<br />
First you have to enable the locales you want being supported by your system. To enable or disable them, the file '''/etc/locale.gen''' is used. It contains every locale you can enable, and you have just to uncomment lines you want to do so.<br />
<br />
As we want to setup an english UTF-8 conform system, we want to enable en_US.UTF-8. But for compatibility to programs that don't support UTF-8 yet, it's recommended to support any other locale, prefixed with en_US as well. Having this in mind, we enable this set of locales:<br />
en_US.UTF8 UTF-8<br />
en_US ISO-8859-1<br />
<br />
After you've enabled the necessary locales, you have to run locale-gen as root to update them:<br />
# locale-gen<br />
Generating locales...<br />
en_US.UTF-8... done<br />
en_US.ISO-8859-1... done<br />
Generation complete.<br />
<br />
'''Note:''' Though it's most likely just one language you use on your computer it can be helpful or even necessary to enable other locales as well. For example if you're running a multi-user system with users that don't speak en_US, they won't be happy until their individual locale is at least supported by your system.<br />
<br />
==Setting system wide locale==<br />
To define which locale should be used by the system, you can easily add your locale to your '''/etc/rc.conf''' file. As we've just added ISO-8859 support just for (backward-)compability, we add en_US.utf-8 here:<br />
LOCALE="en_US.utf8"<br />
<br />
The system wide locale will be updated after rebooting your computer.<br />
<br />
'''Important:''' You need to type the name of the locale '''exactly''' as shown in the output of <tt>`locale -a`</tt>. E.g. <tt>LOCALE="en_US.utf8"</tt> is valid, while <tt>LOCALE="en_US.UTF-8"</tt> is not.<br />
<br />
==Collation==<br />
Collation, or sorting, is a little different. Sorting is a goofy beast and different locales do things differently. To get around potential issues, we have set LC_COLLATE="C" in /etc/profile. This forces collation to "C mode". This is usually a good idea for most users. If you want to overwrite this with sorting rules from your locale, it is best to do one of the following:<br />
<br />
* Modify the line in /etc/profile directly<br />
* Comment out the LC_COLLATE line in /etc/profile (allowing locale aware apps to use LC_ALL or LOCALE)<br />
* Manually set LC_COLLATE in addition to LC_ALL or LOCALE in your user profile<br />
<br />
==Setting per user locale==<br />
As we discussed earlier, some users might want to define a different locale than the system-wide locale.<br />
In this case, you can export LC_ALL in your '''~/.bashrc'''.<br />
For example you can use the en_US.iso8859 locale, though there is no advantage of using it.<br />
export LC_ALL=en_US.iso8859<br />
<br />
Your locales will be updated as soon as you re-source your ~/.bashrc. This happens on login or alternatively you can type:<br />
$ source ~/.bashrc<br />
<br />
==Setting language==<br />
The language in which the system interacts with the user is also determined by the locales, namely the locale LC_LANG.<br />
To set the preferred language, you have to export the LANG variable in your ~/.bashrc. Or you can put it in rc.local for system wide<br />
export LANG=en_EN.utf8<br />
After sourcing your ~/.bashrc, programs ought to use the defined language, at least they do if they're using proper internationalization.<br />
<br />
==Setting starting weekday==<br />
In a lot of countries the first day of the week is Monday. To do change or add the following lines under the LC_TIME section in ''/usr/share/i18n/locales/<your_locale>''<br />
<br />
week 7;19971130;5<br />
first_weekday 2<br />
first_workday 2<br />
And then run<br />
<br />
# locale-gen<br />
and restart X.<br />
<br />
==Troubleshooting==<br />
===How can I obtain the available locale names?===<br />
You can get the correct names of all available locales with this command:<br />
$ locale -a<br />
===How can I see which locale I am using?===<br />
Which locale is currently in use is viewable simply by typing:<br />
$ locale<br />
===My terminal doesn't support UTF-8 characters===<br />
Unfortunately some terminals don't support UTF-8. In this case, you have to use a different terminal.<br />
<br />
'''List of terminals that support UTF-8:'''<br />
* gnome-terminal<br />
* gnustep-terminal<br />
* konsole<br />
* [[mlterm]]<br />
* urxvt (rxvt-unicode)<br />
* xfce-terminal<br />
* xterm<br />
'''Note:''' This list may be incomplete.<br />
<br />
===xterm doesn't support UTF-8 characters for me===<br />
xterm only supports UTF-8 if you run it as uxterm or xterm -u8.<br />
<br />
==Links==<br />
[http://gentoo-wiki.com/HOWTO_localedef GentooWiki: Localedef]</div>
Phrakture
https://wiki.archlinux.org/index.php?title=DeveloperWiki:NewMirrors&diff=50773
DeveloperWiki:NewMirrors
2008-10-07T05:22:19Z
<p>Phrakture: </p>
<hr />
<div>=== Adding a new mirror ===<br />
<br />
This text should outline the procedure for adding a new mirror for Arch packages<br />
<br />
== For the Mirror Administrator ==<br />
Please open a [http://bugs.archlinux.org bug ticket] with a request to become an authorized mirror.<br />
<br />
Please provide the following:<br />
* Mirror domain name<br />
* Geographical Location of the mirror<br />
* Supported access methods (http, ftp, rsync, ...)<br />
* URLs for the above access methods<br />
* The IP from which the server will be rsyncing (this may or may not be the same as the ip of the domain)<br />
* An administrative contact email<br />
<br />
== The ArchLinux side ==<br />
<br />
* Add the IP to the the rsync whitelist on gerolde\<br />
* Add the mirror info to the Django admin site<br />
* Add the mirror to pacman's mirror list</div>
Phrakture