https://wiki.archlinux.org/api.php?action=feedcontributions&user=Chicha&feedformat=atomArchWiki - User contributions [en]2024-03-28T11:16:35ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Pacman/Rosetta&diff=645578Pacman/Rosetta2020-12-14T08:32:50Z<p>Chicha: /* Querying package lists */ Apt has now "apt list --upgradable"</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Package manager]]<br />
[[de:Rosettastein_Paketverwaltung]]<br />
[[es:Pacman (Español)/Rosetta]]<br />
[[fi:Pacman (Suomi)/Rosetta]]<br />
[[ja:Pacman/比較表]]<br />
[[pt:Pacman (Português)/Rosetta]]<br />
[[sr:Pacman (Српски)/Rosetta]]<br />
[[zh-hans:Pacman (简体中文)/Rosetta]]<br />
This page uses a table to display the correspondence of [[Wikipedia:Package manager|package management]] commands among some of the most popular Linux distributions. The original inspiration was given by [https://old-en.opensuse.org/Software_Management_Command_Line_Comparison openSUSE's Software Management Command Line Comparison].<br />
<br />
{{Tip|Arch users having to temporarily deal with another Linux distribution can use [https://github.com/icy/pacapt pacapt], a simple wrapper around other package managers.}}<br />
<br />
{{Note|Some of the tools described here are specific to a certain version of ''pacman''. The {{ic|-Qk}} option is new in ''pacman'' 4.1.}}<br />
<br />
== Basic operations ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Install a package(s) by name || {{ic|pacman -S}} || {{ic|dnf install}} || {{ic|apt install}} || {{ic|zypper install}} or {{ic|zypper in}} || {{ic|emerge [-a]}}<br />
|-<br />
| Remove a package(s) by name || {{ic|pacman -Rs}} || {{ic|dnf remove}} || {{ic|apt remove}} || {{ic|zypper remove}} or {{ic|zypper rm}} || {{ic|emerge -[a]vc}}<br />
|-<br />
| Search for package(s) by searching the expression in name, description, short description. What exact fields are being searched by default varies in each tool. Mostly options bring tools on par. || {{ic|pacman -Ss}} || {{ic|dnf search}} || {{ic|apt search}} || {{ic|zypper search}} or {{ic|zypper se [-s]}} || {{ic|emerge -S}}<br />
|-<br />
| Upgrade Packages - Install packages which have an older version already installed || {{ic|pacman -Syu}} || {{ic|dnf upgrade}} || {{ic|apt update}} and then {{ic|apt upgrade}} || {{ic|zypper update}} or {{ic|zypper up}} || {{ic|emerge -[a]uDN @world}}<br />
|-<br />
| Upgrade Packages - Another form of the update command, which can perform more complex updates -- like distribution upgrades. When the usual update command will omit package updates, which include changes in dependencies, this command can perform those updates. || {{ic|pacman -Syu}} || {{ic|dnf distro-sync}} || {{ic|apt update}} and then {{ic|apt dist-upgrade}} || {{ic|zypper dup}} || {{ic|emerge -[a]uDN @world}}<br />
|-<br />
| Clean up all local caches. Options might limit what is actually cleaned. || {{ic|pacman -Sc}} or {{ic|pacman -Scc}} || {{ic|dnf clean all}} || {{ic|apt autoclean}} removes only unneeded, obsolete information or {{ic|apt clean}} || {{ic|zypper clean}} || {{ic|eclean distfiles}}<br />
|-<br />
| Remove dependencies that are no longer needed, because e.g. the package which needed the dependencies was removed. || {{ic|<nowiki>pacman -Qdtq | pacman -Rs -</nowiki>}} || {{ic|dnf autoremove}} || {{ic|apt autoremove}} || {{ic|zypper rm -u}} (just for removing a package) or {{ic|zypper packages --unneeded}} (listing only and without recursion) || {{ic|emerge [-a] --depclean}}<br />
|-<br />
| Remove packages no longer included in any repositories. || {{ic|<nowiki>pacman -Qmq | pacman -Rs -</nowiki>}} || {{ic|dnf repoquery --extras}} || {{ic|aptitude purge '~o'}} ||||<br />
|-<br />
| Mark a package previously installed as a dependency as explicitly required. || {{ic|pacman -D --asexplicit}} || {{ic|dnf mark install}} || {{ic|apt-mark manual}} || {{ic|zypper install --force}} (workaround which needs to reinstall the package) || {{ic|emerge --select}}<br />
|-<br />
| Install package(s) as dependency / without marking as explicitly required. || {{ic|pacman -S --asdeps}} || {{ic|dnf install}} and then {{ic|dnf mark remove}} || {{ic|apt-mark auto}} || n/a ([https://bugzilla.opensuse.org/show_bug.cgi?id=1175678 feature request]) || {{ic|emerge -[a]1}}<br />
|-<br />
| Only downloads the given package(s) without unpacking or installing them || {{ic|pacman -Sw}} || {{ic|dnf download}} || {{ic|apt install --download-only}} (into the package cache) or {{ic|apt download}} (bypass the package cache) || {{ic|zypper --download-only}} || {{ic|emerge [-a] --fetchonly}}<br />
|-<br />
| Start a shell to enter multiple commands in one session |||||| {{ic|apt-config shell}} || {{ic|zypper shell}} ||<br />
|-<br />
| Show a log of actions taken by the software management. || read {{ic|/var/log/pacman.log}} || {{ic|dnf history}} || read {{ic| /var/log/dpkg.log}} || read {{ic|/var/log/zypp/history}} || read {{ic|/var/log/portage}}<br />
|-<br />
| Get a dump of the whole system information - Prints, Saves or similar the current state of the package management system. Preferred output is text or XML. (Note: Why either-or here? No tool offers the option to choose the output format.) || see {{ic|/var/lib/pacman/local}} || see {{ic|/var/lib/rpm/Packages}} || {{ic|apt-cache stats}} |||| {{ic|emerge --info}}<br />
|-<br />
| e-mail delivery of package changes |||||| {{ic|apt install apt-listchanges}} ||||<br />
|-<br />
|}<br />
<br />
== Querying specific packages ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Show all or most information about a package. The tools' verbosity for the default command vary. But with options, the tools are on par with each other. || {{ic|pacman -Si}} or {{ic|pacman -Qi}} || {{ic|dnf list}} or {{ic|dnf info}} || {{ic|apt show}} or {{ic|apt-cache policy}} || {{ic|zypper info}} or {{ic|zypper if}} || {{ic|emerge -S}}, {{ic|emerge -pv}} or {{ic|eix}}<br />
|-<br />
| Display local package information: Name, version, description, etc. || {{ic|pacman -Qi}} || {{ic|rpm -qi}} / {{ic|dnf info installed}} || {{ic|dpkg -s}} or {{ic|aptitude show}} || {{ic|zypper info}} or {{ic|rpm -qi}} || {{ic|emerge -pv}} or {{ic|emerge -S}}<br />
|-<br />
| Display remote package information: Name, version, description, etc.|| {{ic|pacman -Si}} || {{ic|dnf info}} || {{ic|apt-cache show}} or {{ic|aptitude show}} || {{ic|zypper info}} || {{ic|emerge -pv}} and {{ic|emerge -S}} or {{ic|equery meta}}<br />
|-<br />
| Display files provided by local package || {{ic|pacman -Ql}} || {{ic|rpm -ql}} || {{ic|dpkg -L}} || {{ic|rpm -ql}} || {{ic|equery files}} or {{ic|qlist}}<br />
|-<br />
| Display files provided by a remote package || {{ic|pacman -Fl}} || {{ic|dnf repoquery -l}} or {{ic|repoquery -l}} (from package yum-utils) || {{ic|apt-file list}} |||| {{ic|pfl}}<br />
|-<br />
| Query the package which provides FILE || {{ic|pacman -Qo}} || {{ic|rpm -qf}} (installed only) or {{ic|dnf provides}} (everything) or {{ic|repoquery -f}} (from package yum-utils) || {{ic|dpkg -S}} or {{ic|dlocate}} || {{ic|zypper search -f}} || {{ic|equery belongs}} or {{ic|qfile}}<br />
|-<br />
| List the files that the package holds. Again, this functionality can be mimicked by other more complex commands. || {{ic|pacman -Ql}} or {{ic|pacman -Fl}} || {{ic|dnf repoquery -l}} || {{ic|dpkg-query -L}} || {{ic|rpm -ql}} || {{ic|equery files}} or {{ic|qlist}}<br />
|-<br />
| Displays packages which provide the given exp. aka reverse provides. Mainly a shortcut to search a specific field. Other tools might offer this functionality through the search command. || {{ic|pacman -F}} || {{ic|dnf provides}} || {{ic|apt-file search}} || {{ic|zypper what-provides}} or {{ic|zypper wp}}|| {{ic|equery belongs}} (only installed packages) or {{ic|pfl}}<br />
|-<br />
| Search all packages to find the one which holds the specified file. || {{ic|pacman -F}} || {{ic|dnf provides}} || {{ic|apt-file search}} or {{ic|auto-apt}} is using this functionality. || {{ic|zypper search -f}} || {{ic|equery belongs}} or {{ic|qfile}}<br />
|-<br />
| Show the changelog of a package|| {{ic|pacman -Qc}} || {{ic|rpm -q --changelog}} || {{ic|apt-get changelog}} || {{ic|rpm -q --changelog}} || {{ic|equery changes -f}}<br />
|-<br />
|}<br />
<br />
== Querying package lists ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Search for package(s) by searching the expression in name, description, short description. What exact fields are being searched by default varies in each tool. Mostly options bring tools on par. || {{ic|pacman -Ss}} || {{ic|dnf search}} || {{ic|apt search}} || {{ic|zypper search}} or {{ic|zypper se -s}} || {{ic|emerge -S}} or {{ic|eix}}<br />
|-<br />
| Lists packages which have an update available. Note: Some provide special commands to limit the output to certain installation sources, others use options. || {{ic|pacman -Qu}} || {{ic|dnf list updates}} or {{ic|dnf check-update}} || {{ic|apt list --upgradable}} || {{ic|zypper list-updates}} or {{ic|zypper patch-check}} (just for patches) || {{ic|emerge -uDNp @world}}<br />
|-<br />
| Display a list of all packages in all installation sources that are handled by the packages management. Some tools provide options or additional commands to limit the output to a specific installation source. || {{ic|pacman -Sl}} || {{ic|dnf list available}} || {{ic|apt-cache dumpavail}} or {{ic|apt-cache dump}} (Cache only) or {{ic|apt-cache pkgnames}} || {{ic|zypper packages}} || {{ic|portageq all_best_visible /}}<br />
|-<br />
| Generates a list of installed packages || {{ic|pacman -Q}} || {{ic|dnf list installed}} || {{ic|<nowiki>dpkg --list | grep ^i</nowiki>}} || {{ic|zypper search --installed-only}} || {{ic|qlist -IC}}<br />
|-<br />
| List packages that are installed but are not available in any installation source (anymore). || {{ic|pacman -Qm}} || {{ic|dnf list extras}} || {{ic|deborphan}} || {{ic|<nowiki>zypper se -si | grep 'System Packages'</nowiki>}} || {{ic|eix-test-obsolete}}<br />
|-<br />
| List packages that were recently added to one of the installation sources, i.e. which are new to it. || || {{ic|dnf list recent}} || {{ic|aptitude search '~N'}} or {{ic|aptitude forget-new}} || || {{ic|eix-diff}}<br />
|-<br />
| List installed local packages along with version || {{ic|pacman -Q}} || {{ic|rpm -qa}} || {{ic|dpkg -l}} or {{ic|apt list --installed}} || {{ic|zypper search -s}} or {{ic|rpm -qa}} || {{ic|qlist -ICv}}<br />
|-<br />
| Search locally installed package for names or descriptions || {{ic|pacman -Qs}} || {{ic|rpm -qa '*<str>*'}} || {{ic|aptitude search <nowiki>'~i(~n $name|~d $description)'</nowiki>}} || || {{ic|eix -S -I}}<br />
|-<br />
| List packages not required by any other package || {{ic|pacman -Qt}} || {{ic|dnf leaves}} or {{ic|package-cleanup --leaves --all}} || {{ic|deborphan -anp1}} || || {{ic|emerge -pc}}<br />
|-<br />
| List packages installed explicitly (not as dependencies) || {{ic|pacman -Qe}} || {{ic|dnf history userinstalled}} || {{ic|apt-mark showmanual}} || {{ic|zypper search '' {{!}} grep -E '^i\+'}} (workaround) || {{ic|emerge -pvO @selected}} or {{ic|eix --selected}}<br />
|-<br />
| List packages installed automatically (as dependencies)}} || {{ic|pacman -Qd}} || {{ic|zypper search '' {{!}} grep -E '^i[^+]'}} (workaround) || {{ic|apt-mark showauto}} || ||<br />
|-<br />
|}<br />
<br />
== Querying package dependencies ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Display packages which require X to be installed, aka show reverse dependencies. || {{ic|pacman -Sii}} || {{ic|dnf repoquery --alldeps --whatrequires}} or {{ic|repoquery --whatrequires}} || {{ic|apt-cache rdepends}} or {{ic|aptitude search ~D$pattern}} || {{ic|zypper search --requires}} || {{ic|emerge -pvc}}<br />
|-<br />
| Display packages which conflict with given expression (often package). Search can be used as well to mimic this function. || || {{ic|dnf repoquery --conflicts}} || {{ic|aptitude search '~C$pattern'}} || ||<br />
|-<br />
| List all packages which are required for the given package, aka show dependencies. || {{ic|pacman -Si}} or {{ic|pacman -Qi}} || {{ic|dnf repoquery --requires}} or {{ic|repoquery -R}} || {{ic|apt-cache depends}} or {{ic|apt-cache show}} || {{ic|zypper info --requires}} || {{ic|emerge -ep}}<br />
|-<br />
| List what the current package provides || || {{ic|dnf provides}} || {{ic|dpkg -s}} or {{ic|aptitude show}} || {{ic|zypper info --provides}} || {{ic|equery files}} or {{ic|qlist}}<br />
|-<br />
| List all packages that require a particular package || || {{ic|dnf repoquery --installed --alldeps --whatrequires}} || {{ic|aptitude search ~D{depends,recommends,suggests}:$pattern}} or {{ic|aptitude why}} || {{ic|zypper search --requires}} || {{ic|equery depends -a}}<br />
|-<br />
| Display all packages that the specified packages obsoletes. || || {{ic|dnf list obsoletes}} || {{ic|apt-cache show}} || ||<br />
|-<br />
| Generates an output suitable for processing with dotty for the given package(s). || || || {{ic|apt-cache dotty}} || ||<br />
|-<br />
|}<br />
<br />
== Installation sources management ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Installation sources management ||edit {{ic|/etc/pacman.conf}} || edit {{ic|/etc/yum.repos.d/${REPO}.repo}}|| edit {{ic|/etc/apt/sources.list}} || edit {{ic|/etc/zypp/repos.d/${REPO}.repo}} || {{ic|layman}} or {{ic|eselect repository}}<br />
|-<br />
| Add an installation source to the system. Some tools provide additional commands for certain sources, others allow all types of source URI for the add command. Again others, like apt and dnf force editing a sources list. apt-cdrom is a special command, which offers special options design for CDs/DVDs as source. || edit {{ic|/etc/pacman.conf}} || {{ic|/etc/yum.repos.d/*.repo}} || {{ic|apt-cdrom add}} || {{ic|zypper service-add}} || {{ic|layman}} or {{ic|overlays}}<br />
|-<br />
| Refresh the information about the specified installation source(s) or all installation sources. || {{ic|pacman -Sy}} ([[System_maintenance#Partial upgrades are unsupported|always upgrade the whole system afterwards]]) || {{ic|dnf clean expire-cache}} and then {{ic|dnf check-update}} || {{ic|apt-get update}} || {{ic|zypper refresh}} or {{ic|zypper ref}} || {{ic|emerge --sync}} or {{ic|layman -S}}<br />
|-<br />
| Prints a list of all installation sources including important information like URI, alias etc. || {{ic|cat /etc/pacman.d/mirrorlist}} || {{ic|cat /etc/yum.repos.d/*}} || {{ic|apt-cache policy}} || {{ic|zypper service-list}} || {{ic|layman -l}} or {{ic|eselect repository list}}<br />
|-<br />
| List all packages from a certain repo|| {{ic|paclist <repo>}} || || || || {{ic|eix --in-overlay}}<br />
|-<br />
| Disable an installation source for an operation || || {{ic|1=dnf --disablerepo=}}|| || || {{ic|emerge package::repo-to-use}}<br />
|-<br />
| Download packages from a different version of the distribution than the one installed. || || {{ic|1=dnf --releasever=}} || {{ic|apt-get install -t release package}} or {{ic|apt-get install package/release}} (dependencies not covered) || || {{ic|echo "category/package ~amd64" >> /etc/portage/package.keywords}} and then {{ic|emerge package}}<br />
|-<br />
|}<br />
<br />
== Overrides ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Add a package lock rule to keep its current state from being changed || edit {{ic|/etc/pacman.conf}} modifying IgnorePkg array || edit {{ic|dnf.conf}} adding/amending the {{ic|exclude}} option || {{ic|apt-mark hold pkg}} || {{ic|zypper al}} or put package name in {{ic|/etc/zypp/locks}} || {{ic|/etc/portage/package.mask}}<br />
|-<br />
| Delete a package lock rule || edit {{ic|/etc/pacman.conf}} removing package from IgnorePkg line || || {{ic|apt-mark unhold pkg}} || {{ic|zypper rl}} or remove package name from {{ic|/etc/zypp/locks}} || {{ic|/etc/portage/package.mask}} (or {{ic|package.unmask}})<br />
|-<br />
| Show a listing of all lock rules || {{ic|cat /etc/pacman.conf}} || || {{ic|/etc/apt/preferences}} || {{ic|zypper ll}} or view {{ic|/etc/zypp/locks}} || {{ic|cat /etc/portage/package.mask}}<br />
|-<br />
| Set the priority of the given package to avoid upgrade, force downgrade or to overwrite any default behavior. Can also be used to prefer a package version from a certain installation source. || edit {{ic|/etc/pacman.conf}} modifying HoldPkg and/or IgnorePkg arrays || || {{ic|/etc/apt/preferences}}, {{ic|apt-cache policy}}|| {{ic|zypper mr -p}} || edit {{ic|/etc/portage/package.accept_keywords}} adding a line with {{ic|1==category/package-version}}<br />
|-<br />
| Remove a previously set priority || || || {{ic|/etc/apt/preferences}} || {{ic|zypper mr -p}} || edit {{ic|/etc/portage/package.accept_keywords}} removing offending line<br />
|-<br />
| Show a list of set priorities || || || {{ic|apt-cache policy}} or {{ic|/etc/apt/preferences}} || {{ic|zypper lr -p}} || {{ic|grep -r . /etc/portage/package.accept_keywords}}<br />
|-<br />
| Ignore problems that priorities may trigger. || || || || n/a ||<br />
|-<br />
|}<br />
<br />
== Verification and repair ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Verify single package || {{ic|pacman -Qk}} (can add another {{ic|k}}) || {{ic|rpm -V}} || {{ic|debsums}} || {{ic|rpm -V}} || {{ic|equery check}}<br />
|-<br />
| Verify all packages || {{ic|pacman -Qk}} (can add another {{ic|k}}) || {{ic|rpm -Va}} || {{ic|debsums}} || {{ic|rpm -Va}} || {{ic|equery check}}<br />
|-<br />
| Reinstall given package; this will reinstall the given package without dependency hassle || {{ic|pacman -S}} || {{ic|dnf reinstall}} || {{ic|apt install --reinstall}} || {{ic|zypper install --force}} || {{ic|emerge -1O}}<br />
|-<br />
| Verify dependencies of the complete system; used if installation process was forcefully killed || {{ic|pacman -Dk}} || {{ic|dnf repoquery --requires}} || {{ic|apt-get check}} || {{ic|zypper verify}} || {{ic|emerge -uDN @world}}<br />
|-<br />
| Use some magic to fix broken dependencies in a system || for ''pacman'' dependency level, use {{ic|pacman -Dk}}; for shared library level, use {{AUR|findbrokenpkgs}} or {{ic|lddd}} (from {{pkg|devtools}}) || {{ic|dnf repoquery --unsatisfied}} || {{ic|apt-get --fix-broken}} and then {{ic|aptitude install}} || {{ic|zypper verify}} || {{ic|revdep-rebuild}}<br />
|-<br />
| Add a checkpoint to the package system for later rollback || || (unnecessary, it is done on every transaction) || || n/a ||<br />
|-<br />
| Remove a checkpoint from the system || n/a || n/a || || n/a ||<br />
|-<br />
| Provide a list of all system checkpoints || n/a || {{ic|dnf history list}} || || n/a ||<br />
|-<br />
| Rolls entire packages back to a certain date or checkpoint || n/a || {{ic|dnf history rollback}} || || n/a ||<br />
|-<br />
| Undo a single specified transaction || n/a || {{ic|dnf history undo}} || || n/a ||<br />
|-<br />
|}<br />
<br />
== Using package files and building packages ==<br />
<br />
{| class="wikitable"<br />
! Action !! Arch !! Red Hat/Fedora !! Debian/Ubuntu !! SLES/openSUSE !! Gentoo<br />
|-<br />
| Query a package supplied on the command line rather than an entry in the package management database || {{ic|pacman -Qp}} || {{ic|rpm -qp}} || {{ic|dpkg -I}} || ||<br />
|-<br />
| List the contents of a package file || {{ic|pacman -Qpl}} || {{ic|rpmls rpm -qpl}} || {{ic|dpkg -c}} || {{ic|rpm -qpl}} ||<br />
|-<br />
| Install local package file, e.g. app.rpm and uses the installation sources to resolve dependencies || {{ic|pacman -U}} || {{ic|dnf install}} || {{ic|apt install}} || {{ic|zypper in}} || {{ic|emerge}}<br />
|-<br />
| Updates package(s) with local packages and uses the installation sources to resolve dependencies || {{ic|pacman -U}} || {{ic|dnf upgrade}} || {{ic|debi}} || || {{ic|emerge}}<br />
|-<br />
| Add a local package to the local package cache mostly for debugging purposes. || {{ic|cp ''package-filename'' /var/cache/pacman/pkg/}} || || {{ic|apt-cache add ''package-filename''}} || n/a || {{ic|cp ''package-filename'' /usr/portage/distfiles}}<br />
|-<br />
| Extract a package || {{ic|tar -Jxvf}} || {{ic|<nowiki>rpm2cpio | cpio -vid</nowiki>}} || {{ic|dpkg-deb -x}} || {{ic|<nowiki>rpm2cpio | cpio -vid</nowiki>}} || {{ic|tar -jxvf}}<br />
|-<br />
| Install/Remove packages to satisfy build-dependencies. Uses information in the source package || Use [[ABS]] and {{ic|makepkg -seoc}} || {{ic|dnf builddep}} || {{ic|apt-get build-dep}} || {{ic|zypper si -d}} || {{ic|emerge -o}}<br />
|-<br />
| Display the source package to the given package name(s) || || {{ic|dnf repoquery -s}} || {{ic|apt-cache showsrc}} || n/a ||<br />
|-<br />
| Download the corresponding source package(s) to the given package name(s) || Use [[ABS]] and {{ic|makepkg -o}} || {{ic|dnf download --source}} || {{ic|apt-get source}} or {{ic|debcheckout}} || {{ic|zypper source-install}} || {{ic|emerge --fetchonly}}<br />
|-<br />
| Build a package || {{ic|makepkg -s}} || {{ic|rpmbuild -ba}} (normal) or ''mock'' (in chroot) || {{ic|debuild}} || {{ic|rpmbuild -ba}}, then build, and then {{ic|osc build}} || {{ic|ebuild}} or {{ic|quickpkg}}<br />
|-<br />
| Check for possible packaging issues || ''namcap''<br>(requires {{Pkg|namcap}}) || ''rpmlint'' || ''lintian'' || ''rpmlint'' || ''repoman''<br />
|-<br />
|}<br />
<br />
== Log file rotation ==<br />
<br />
By default, Arch Linux does not rotate {{ic|pacman.log}}. See, for example, {{Bug|11272}} and {{Bug|20428#comment66480}}. This is in contrast to the default policy of most other Linux distributions. Some distributions, notably Gentoo, hardly write log files by default.<br />
<br />
== See also ==<br />
<br />
* [https://dnf.readthedocs.org/en/latest/cli_vs_yum.html Changes in DNF CLI compared to Yum]</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=581887User:Chicha2019-09-09T19:59:21Z<p>Chicha: /* Job/Hobbies */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Nationality''' : French<br><br />
'''Location''' : France<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a software developer</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=581886User:Chicha2019-09-09T19:59:07Z<p>Chicha: /* Job/Hobbies */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Nationality''' : French<br><br />
'''Location''' : France<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer'''</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=581885User:Chicha2019-09-09T19:58:53Z<p>Chicha: /* Who am I ? */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Nationality''' : French<br><br />
'''Location''' : France<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer''' (ASM, C/C++, Java, Python, Shell ...) at [[wikipedia:Amadeus_IT_Group|Amadeus]].</div>Chichahttps://wiki.archlinux.org/index.php?title=Wake-on-LAN&diff=579660Wake-on-LAN2019-08-12T19:47:10Z<p>Chicha: /* NetworkManager */ devices -> connections</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Wake-on-LAN]]<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] (WoL) is a feature to switch on a computer via the network.<br />
<br />
== Hardware settings ==<br />
<br />
The target computer's motherboard and [[wikipedia:Network interface controller|Network Interface Controller]] have to support Wake-on-LAN. The target computer has to be physically connected (with a cable) to a router or to the source computer, wireless cards do not support WoL.<br />
<br />
The Wake-on-LAN feature also has to be enabled in the computer's BIOS. Different motherboard manufacturers use slightly different language for this feature. Look for terminology such as "PCI Power up", "Allow PCI wake up event" or "Boot from PCI/PCI-E".<br />
<br />
Note that some motherboards are affected by a bug that can cause immediate or random [[#Wake-up after shutdown]] whenever the BIOS WoL feature is enabled.<br />
<br />
== Software configuration ==<br />
<br />
=== Enable WoL on the network adapter ===<br />
<br />
Depending on the hardware, the network driver may have WoL switched off by default.<br />
<br />
To query this status or to change the settings, install {{Pkg|ethtool}}, determine the name of the [[network interface]], and query it using the command:<br />
<br />
{{hc|# ethtool ''interface'' {{!}} grep Wake-on|<br />
Supports Wake-on: pumbag<br />
Wake-on: d}}<br />
The ''Wake-on'' values define what activity triggers wake up: {{ic|d}} (disabled), {{ic|p}} (PHY activity), {{ic|u}} (unicast activity), {{ic|m}} (multicast activity), {{ic|b}} (broadcast activity), {{ic|a}} (ARP activity), and {{ic|g}} (magic packet activity). The value {{ic|g}} is required for WoL to work, if not, the following command enables the WoL feature in the driver:<br />
<br />
# ethtool -s ''interface'' wol g<br />
<br />
{{Note|Setting one of {{ic|u}}, {{ic|m}} or {{ic|b}} along with {{ic|g}} might also be necessary to enable the feature.}}<br />
<br />
This command might not last beyond the next reboot and in this case must be repeated via some mechanism. Common solutions are listed in the following subsections.<br />
<br />
=== Make it persistent ===<br />
<br />
==== systemd.link ====<br />
<br />
Link-level configuration is possible through [[systemd-networkd#link files]]. The actual setup is performed by the {{ic|net_setup_link}} udev builtin. Add the {{ic|WakeOnLan}} option to the network link file:<br />
<br />
{{hc|/etc/systemd/network/50-wired.link|2=<br />
[Match]<br />
MACAddress=''aa:bb:cc:dd:ee:ff''<br />
<br />
[Link]<br />
NamePolicy=kernel database onboard slot path<br />
MACAddressPolicy=persistent<br />
'''WakeOnLan=magic'''}}<br />
Also see {{man|5|systemd.link}} for more information.<br />
{{Note|<br />
* This configuration applies only to the link-level, and is independent of network-level daemons such as [[NetworkManager]] or [[systemd-networkd]].<br />
* To be considered, the file name should alphabetically come before the default {{ic|99-default.link}} link file shipped with systemd. For example {{ic|50-wired.link}} works.<br />
* In the {{ic|Match}} section, {{ic|1=OriginalName=}} can also be used to identify the interface.}}<br />
<br />
==== systemd service ====<br />
<br />
This is an equivalent of previous {{ic|systemd.link}} option, but uses a standalone systemd service.<br />
<br />
{{hc|/etc/systemd/system/wol@.service|2=<br />
[Unit]<br />
Description=Wake-on-LAN for %i<br />
Requires=network.target<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/ethtool -s %i wol g<br />
Type=oneshot<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Alternatively install the {{AUR|wol-systemd}} package, then activate this new service by [[starting]] {{ic|wol@''interface''.service}}.<br />
<br />
==== udev ====<br />
<br />
[[udev]] is capable of running any command as soon as a device is visible. The following rule will turn on WOL on all [[network interface]]s whose name matches {{ic|enp*}}. The file name is important and must start with a number between 81 and 99 so that it runs '''after''' {{ic|80-net-setup-link.rules}}, which renames interfaces with predicable names. Otherwise, {{ic|NAME}} would be undefined and the rule would not run.<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wol.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", NAME=="enp*", RUN+="/usr/bin/ethtool -s $name wol g"<br />
}}<br />
<br />
The {{ic|$name}} placeholder will be replaced by the value of the {{ic|NAME}} variable for the matched device.<br />
<br />
==== cron ====<br />
<br />
A command can be run each time the computer is (re)booted using "@reboot" in a crontab. First, make sure [[Cron#Installation|cron]] is enabled, and then [[Cron#Basic_commands|edit a crontab]] for the root user that contains the following line:<br />
<br />
@reboot /usr/bin/ethtool -s ''interface'' wol g<br />
<br />
==== netctl ====<br />
<br />
If using [[netctl]], one can make this setting persistent by adding the following the netctl profile:<br />
<br />
{{hc|/etc/netctl/''profile''|2=<br />
ExecUpPost='/usr/bin/ethtool -s ''interface'' wol g'<br />
}}<br />
<br />
==== NetworkManager ====<br />
NetworkManager provides [https://www.phoronix.com/scan.php?page=news_item&px=NetworkManager-WoL-Control Wake-on-LAN ethernet support]. One way to enable Wake-on-LAN by magic packet is through ''nmcli''.<br />
<br />
First, search for the name of the wired connection:<br />
<br />
{{hc|# nmcli con show|2=<br />
NAME UUID TYPE DEVICE<br />
wired1 612e300a-c047-4adb-91e2-12ea7bfe214e 802-3-ethernet enp0s25<br />
}}<br />
<br />
By following, one can view current status of Wake-on-LAN settings:<br />
<br />
{{hc|# nmcli c show "wired1" <nowiki>|</nowiki> grep 802-3-ethernet.wake-on-lan|2=<br />
802-3-ethernet.wake-on-lan: default<br />
802-3-ethernet.wake-on-lan-password: --<br />
}}<br />
<br />
Enable Wake-on-LAN by magic packet on that connection:<br />
<br />
# nmcli c modify "wired1" 802-3-ethernet.wake-on-lan magic<br />
<br />
Then reboot, possibly two times. To disable Wake-on-Lan, substitute {{ic|magic}} with {{ic|ignore}}.<br />
<br />
The Wake-on-LAN settings can also be changed from the GUI using {{Pkg|nm-connection-editor}}.<br />
<br />
You can disable Wake-on-Lan for all connections permanently by adding a dedicated configuration file :<br />
{{hc|/etc/NetworkManager/conf.d/''wake-on-lan.conf''|2=<br />
[connection]<br />
ethernet.wake-on-lan = ignore<br />
wifi.wake-on-wlan = ignore<br />
}}<br />
<br />
=== Enable WoL in TLP ===<br />
<br />
When using [[TLP]] for suspend/hibernate, the {{ic|WOL_DISABLE}} setting should be set to {{ic|N}} in {{ic|/etc/default/tlp}} to allow resuming the computer with WoL.<br />
<br />
== Trigger a wake up ==<br />
To trigger WoL on a target machine, its '''MAC address''' must be known.<br />
To obtain it, execute the following command from the machine:<br />
{{hc|$ ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp1s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000<br />
link/ether '''48:05:ca:09:0e:6a''' brd ff:ff:ff:ff:ff:ff}}<br />
<br />
Here the MAC address is {{ic|48:05:ca:09:0e:6a}}.<br />
<br />
In its simplest form, Wake-on-LAN broadcasts the magic packet containing the MAC address within the current network subnet, below the IP protocol layer. The knowledge of an IP address for the target computer is not necessary.<br />
<br />
If used to wake up a computer over the internet or in a different subnet, it typically relies on the router to relay the packet and broadcast it.<br />
In this scenario, the external IP address of the router must be known and in some cases the internal IP address of the target machine is needed to ensure the NAT (Network Address Translator) router manages to communicate with the target machine.<br />
<br />
Applications that are able to send magic packets for Wake-on-LAN:<br />
* {{App|gWakeOnLAN|GTK utility to awake turned off computers through the Wake-on-LAN feature.|https://muflone.com/gwakeonlan/english/|{{Pkg|gwakeonlan}}}}<br />
* {{App|wol|Implements Wake-on-LAN functionality in a small program. It wakes up hardware that is Magic Packet compliant. Note: This application will need the port changed to 9 from the default(40000) using the -p argument/flag.|https://sourceforge.net/projects/wake-on-lan/|{{Pkg|wol}}}}<br />
<br />
=== On the same LAN ===<br />
<br />
If you are connected directly to another computer through a network cable, or the traffic within a LAN is not firewalled, then using Wake-on-LAN should be straightforward since there is no need to worry about port redirects.<br />
<br />
In the simplest case the default broadcast address {{ic|255.255.255.255}} is used:<br />
<br />
$ wol ''target_MAC_address''<br />
<br />
To broadcast the magic packet only to a specific subnet or host, use the {{ic|-i}} switch:<br />
<br />
$ wol -i ''target_IP'' ''target_MAC_address''<br />
<br />
=== Across the internet ===<br />
<br />
When the source and target computers are separated by a NAT router, different solution can be envisaged: <br />
* If the router supports ''WoL'', one can rely on it to properly broadcast the packet into the local network.<br />
<br />
Otherwise Wake-on-Lan can be achieved via [[wikipedia:Port forwarding|port forwarding]]. The router needs to be configured using one of these two options:<br />
<br />
* Forward a different port to each target machine. This requires any target machine to have a static IP address on its LAN.<br />
* Forward a single port to the [[wikipedia:Broadcast_address|broadcast address]]. Most routers do not allow to forward to broadcast, however if you can get shell access to your router, through telnet, ssh, serial cable or other mean, run the command: {{bc|$ ip neighbor add 192.168.1.254 lladdr FF:FF:FF:FF:FF:FF dev net0}} This example assumes the network is ''192.168.1.0/24'' and uses ''net0'' as network interface. Now, forward UDP port 9 to 192.168.1.254. This solution was successfully tested on a Linksys WRT54G running [[Wikipedia:Tomato_(firmware)|Tomato]], and on the Verizon FIOS ActionTec router. For notes on how to do it on a router with [[Wikipedia:DD-WRT|DD-WRT]] firmware, see [http://www.dd-wrt.com/wiki/index.php/WOL#Remote_Wake_On_LAN_via_Port_Forwarding this tutorial] and for a router with [[Wikipedia:OpenWrt|OpenWrt]] firmware, see [https://wiki.openwrt.org/doc/uci/wol this tutorial]. <br />
<br />
In any case, run the following command from the source computer to trigger wake-up:<br />
<br />
$ wol -p ''forwarded_port'' -i ''router_IP'' ''target_MAC_address''<br />
<br />
== Miscellaneous ==<br />
<br />
=== Check reception of the magic packets ===<br />
In order to make sure the WoL packets reach the target computer, one can listen to the UDP port, usually port 9, for magic packets.<br />
The magic packet frame expected contains 6 bytes of FF followed by 16 repetitions of the target computer's MAC (6 bytes each) for a total of 102 bytes.<br />
<br />
==== Using netcat ====<br />
This can be performed by installing {{pkg|gnu-netcat}} on the target computer and using the following command:<br />
<br />
# nc --udp --listen --local-port=9 --hexdump<br />
<br />
Then wait for the incoming traffic to appear in the {{ic|nc}} terminal.<br />
<br />
==== Using ngrep ====<br />
Install {{pkg|ngrep}} on the target computer and type the following command:<br />
<br />
# ngrep '\xff{6}(.{6})\1{15}' -x port 9<br />
<br />
=== Example of WoL script ===<br />
Here is a script that illustrates the use of {{ic|wol}} with different machines:<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
# definition of MAC addresses<br />
monster=01:12:46:82:ab:4f<br />
ghost=01:1a:d2:56:6b:e6<br />
<br />
echo "Which PC to wake?"<br />
echo "m) monster"<br />
echo "g) ghost"<br />
echo "q) quit"<br />
read input1<br />
case $input1 in<br />
m)<br />
/usr/bin/wol $monster<br />
;;<br />
g)<br />
# uses wol over the internet provided that port 9 is forwarded to ghost on ghost's router<br />
/usr/bin/wol --port=9 --host=ghost.mydomain.org $ghost<br />
;;<br />
Q|q)<br />
break<br />
;;<br />
esac</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Wake-up after shutdown ===<br />
It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a ''shutdown'' whenever the BIOS WoL feature is enabled (as discussed in [https://bbs.archlinux.org/viewtopic.php?id=173648 this thread] for example).<br />
==== Fix using BIOS Settings ====<br />
The following actions in the BIOS preferences can solve this issue with some motherboards:<br />
# Disable all references to ''xHCI'' in the USB settings (note this will also disable USB 3.0 at boot time)<br />
# Disable ''EuP 2013'' if it is explicitly an option<br />
# Optionally enable wake-up on keyboard actions<br />
{{Note|There are mixed opinions as to the value of #3 above and it may be motherboard dependent.}}<br />
<br />
==== Fix by Kernel quirks ====<br />
The issue can also be solved by adding the following kernel boot parameter: {{ic|1=xhci_hcd.quirks=270336}}<br />
This activates the following quirks:<br />
* {{ic|XHCI_SPURIOUS_REBOOT}}<br />
* {{ic|XHCI_SPURIOUS_WAKEUP}}<br />
<br />
=== Battery draining problem ===<br />
Some laptops have a battery draining problem after shutdown [http://ubuntuforums.org/archive/index.php/t-1729782.html]. This might be caused by enabled WOL. To solve this problem, disable it by using ethtool as mentioned above.<br />
<br />
# ethtool -s net0 wol d<br />
<br />
=== Realtek ===<br />
<br />
Users with Realtek 8168 8169 8101 8111(C) based NICs (cards / and on-board) may notice a problem where the NIC seems to be disabled on boot and has no Link light. See [[Network configuration#Realtek no link / WOL problem]].<br />
<br />
If the link light on the network switch is enabled when the computer is turned off but wake on LAN is still not working, booting the system using the {{Pkg|r8168}} kernel module at least once and then switching back to the r8169 kernel module included with the kernel seems to fix it at least in the following configurations:<br />
* MSI B85M-E45 motherboard, BIOS version V10.9, onboard Realtek 8111G chipset<br />
<br />
For the {{ic|r8168}} module you might need to set the {{ic|1=s5wol=1}} [[Kernel_modules#Setting_module_options|module option]] to enable the wake on LAN functionality.<br />
<br />
===alx driver support===<br />
<br />
For some newer Atheros-based NICs (such as Atheros AR8161 and Killer E2500), WOL support has been disabled in the mainline {{ic|alx}} module due to a bug causing unintentional wake-up (see [http://www.spinics.net/lists/netdev/msg242477.html this patch discussion]). A patch can be applied (or installed as a [[dkms]] module) which both restores WOL support and fixes the underlying bug, as outlined in [https://bugzilla.kernel.org/show_bug.cgi?id=61651 this thread].<br />
<br />
See also the pre-patched sources in [https://github.com/Snugface/alx].<br />
<br />
== See also ==<br />
<br />
* [http://www.depicus.com/wake-on-lan/woli.aspx Wake-On-Lan]</div>Chichahttps://wiki.archlinux.org/index.php?title=Wake-on-LAN&diff=579659Wake-on-LAN2019-08-12T19:45:45Z<p>Chicha: /* NetworkManager */ Add tip to disable wol permanently for all devices</p>
<hr />
<div>[[Category:Networking]]<br />
[[ja:Wake-on-LAN]]<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] (WoL) is a feature to switch on a computer via the network.<br />
<br />
== Hardware settings ==<br />
<br />
The target computer's motherboard and [[wikipedia:Network interface controller|Network Interface Controller]] have to support Wake-on-LAN. The target computer has to be physically connected (with a cable) to a router or to the source computer, wireless cards do not support WoL.<br />
<br />
The Wake-on-LAN feature also has to be enabled in the computer's BIOS. Different motherboard manufacturers use slightly different language for this feature. Look for terminology such as "PCI Power up", "Allow PCI wake up event" or "Boot from PCI/PCI-E".<br />
<br />
Note that some motherboards are affected by a bug that can cause immediate or random [[#Wake-up after shutdown]] whenever the BIOS WoL feature is enabled.<br />
<br />
== Software configuration ==<br />
<br />
=== Enable WoL on the network adapter ===<br />
<br />
Depending on the hardware, the network driver may have WoL switched off by default.<br />
<br />
To query this status or to change the settings, install {{Pkg|ethtool}}, determine the name of the [[network interface]], and query it using the command:<br />
<br />
{{hc|# ethtool ''interface'' {{!}} grep Wake-on|<br />
Supports Wake-on: pumbag<br />
Wake-on: d}}<br />
The ''Wake-on'' values define what activity triggers wake up: {{ic|d}} (disabled), {{ic|p}} (PHY activity), {{ic|u}} (unicast activity), {{ic|m}} (multicast activity), {{ic|b}} (broadcast activity), {{ic|a}} (ARP activity), and {{ic|g}} (magic packet activity). The value {{ic|g}} is required for WoL to work, if not, the following command enables the WoL feature in the driver:<br />
<br />
# ethtool -s ''interface'' wol g<br />
<br />
{{Note|Setting one of {{ic|u}}, {{ic|m}} or {{ic|b}} along with {{ic|g}} might also be necessary to enable the feature.}}<br />
<br />
This command might not last beyond the next reboot and in this case must be repeated via some mechanism. Common solutions are listed in the following subsections.<br />
<br />
=== Make it persistent ===<br />
<br />
==== systemd.link ====<br />
<br />
Link-level configuration is possible through [[systemd-networkd#link files]]. The actual setup is performed by the {{ic|net_setup_link}} udev builtin. Add the {{ic|WakeOnLan}} option to the network link file:<br />
<br />
{{hc|/etc/systemd/network/50-wired.link|2=<br />
[Match]<br />
MACAddress=''aa:bb:cc:dd:ee:ff''<br />
<br />
[Link]<br />
NamePolicy=kernel database onboard slot path<br />
MACAddressPolicy=persistent<br />
'''WakeOnLan=magic'''}}<br />
Also see {{man|5|systemd.link}} for more information.<br />
{{Note|<br />
* This configuration applies only to the link-level, and is independent of network-level daemons such as [[NetworkManager]] or [[systemd-networkd]].<br />
* To be considered, the file name should alphabetically come before the default {{ic|99-default.link}} link file shipped with systemd. For example {{ic|50-wired.link}} works.<br />
* In the {{ic|Match}} section, {{ic|1=OriginalName=}} can also be used to identify the interface.}}<br />
<br />
==== systemd service ====<br />
<br />
This is an equivalent of previous {{ic|systemd.link}} option, but uses a standalone systemd service.<br />
<br />
{{hc|/etc/systemd/system/wol@.service|2=<br />
[Unit]<br />
Description=Wake-on-LAN for %i<br />
Requires=network.target<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/ethtool -s %i wol g<br />
Type=oneshot<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Alternatively install the {{AUR|wol-systemd}} package, then activate this new service by [[starting]] {{ic|wol@''interface''.service}}.<br />
<br />
==== udev ====<br />
<br />
[[udev]] is capable of running any command as soon as a device is visible. The following rule will turn on WOL on all [[network interface]]s whose name matches {{ic|enp*}}. The file name is important and must start with a number between 81 and 99 so that it runs '''after''' {{ic|80-net-setup-link.rules}}, which renames interfaces with predicable names. Otherwise, {{ic|NAME}} would be undefined and the rule would not run.<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wol.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", NAME=="enp*", RUN+="/usr/bin/ethtool -s $name wol g"<br />
}}<br />
<br />
The {{ic|$name}} placeholder will be replaced by the value of the {{ic|NAME}} variable for the matched device.<br />
<br />
==== cron ====<br />
<br />
A command can be run each time the computer is (re)booted using "@reboot" in a crontab. First, make sure [[Cron#Installation|cron]] is enabled, and then [[Cron#Basic_commands|edit a crontab]] for the root user that contains the following line:<br />
<br />
@reboot /usr/bin/ethtool -s ''interface'' wol g<br />
<br />
==== netctl ====<br />
<br />
If using [[netctl]], one can make this setting persistent by adding the following the netctl profile:<br />
<br />
{{hc|/etc/netctl/''profile''|2=<br />
ExecUpPost='/usr/bin/ethtool -s ''interface'' wol g'<br />
}}<br />
<br />
==== NetworkManager ====<br />
NetworkManager provides [https://www.phoronix.com/scan.php?page=news_item&px=NetworkManager-WoL-Control Wake-on-LAN ethernet support]. One way to enable Wake-on-LAN by magic packet is through ''nmcli''.<br />
<br />
First, search for the name of the wired connection:<br />
<br />
{{hc|# nmcli con show|2=<br />
NAME UUID TYPE DEVICE<br />
wired1 612e300a-c047-4adb-91e2-12ea7bfe214e 802-3-ethernet enp0s25<br />
}}<br />
<br />
By following, one can view current status of Wake-on-LAN settings:<br />
<br />
{{hc|# nmcli c show "wired1" <nowiki>|</nowiki> grep 802-3-ethernet.wake-on-lan|2=<br />
802-3-ethernet.wake-on-lan: default<br />
802-3-ethernet.wake-on-lan-password: --<br />
}}<br />
<br />
Enable Wake-on-LAN by magic packet on that connection:<br />
<br />
# nmcli c modify "wired1" 802-3-ethernet.wake-on-lan magic<br />
<br />
Then reboot, possibly two times. To disable Wake-on-Lan, substitute {{ic|magic}} with {{ic|ignore}}.<br />
<br />
The Wake-on-LAN settings can also be changed from the GUI using {{Pkg|nm-connection-editor}}.<br />
<br />
You can disable Wake-on-Lan for all devices permanently by adding a dedicated configuration file :<br />
{{hc|/etc/NetworkManager/conf.d/''wake-on-lan.conf''|2=<br />
[connection]<br />
ethernet.wake-on-lan = ignore<br />
wifi.wake-on-wlan = ignore<br />
}}<br />
<br />
=== Enable WoL in TLP ===<br />
<br />
When using [[TLP]] for suspend/hibernate, the {{ic|WOL_DISABLE}} setting should be set to {{ic|N}} in {{ic|/etc/default/tlp}} to allow resuming the computer with WoL.<br />
<br />
== Trigger a wake up ==<br />
To trigger WoL on a target machine, its '''MAC address''' must be known.<br />
To obtain it, execute the following command from the machine:<br />
{{hc|$ ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp1s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000<br />
link/ether '''48:05:ca:09:0e:6a''' brd ff:ff:ff:ff:ff:ff}}<br />
<br />
Here the MAC address is {{ic|48:05:ca:09:0e:6a}}.<br />
<br />
In its simplest form, Wake-on-LAN broadcasts the magic packet containing the MAC address within the current network subnet, below the IP protocol layer. The knowledge of an IP address for the target computer is not necessary.<br />
<br />
If used to wake up a computer over the internet or in a different subnet, it typically relies on the router to relay the packet and broadcast it.<br />
In this scenario, the external IP address of the router must be known and in some cases the internal IP address of the target machine is needed to ensure the NAT (Network Address Translator) router manages to communicate with the target machine.<br />
<br />
Applications that are able to send magic packets for Wake-on-LAN:<br />
* {{App|gWakeOnLAN|GTK utility to awake turned off computers through the Wake-on-LAN feature.|https://muflone.com/gwakeonlan/english/|{{Pkg|gwakeonlan}}}}<br />
* {{App|wol|Implements Wake-on-LAN functionality in a small program. It wakes up hardware that is Magic Packet compliant. Note: This application will need the port changed to 9 from the default(40000) using the -p argument/flag.|https://sourceforge.net/projects/wake-on-lan/|{{Pkg|wol}}}}<br />
<br />
=== On the same LAN ===<br />
<br />
If you are connected directly to another computer through a network cable, or the traffic within a LAN is not firewalled, then using Wake-on-LAN should be straightforward since there is no need to worry about port redirects.<br />
<br />
In the simplest case the default broadcast address {{ic|255.255.255.255}} is used:<br />
<br />
$ wol ''target_MAC_address''<br />
<br />
To broadcast the magic packet only to a specific subnet or host, use the {{ic|-i}} switch:<br />
<br />
$ wol -i ''target_IP'' ''target_MAC_address''<br />
<br />
=== Across the internet ===<br />
<br />
When the source and target computers are separated by a NAT router, different solution can be envisaged: <br />
* If the router supports ''WoL'', one can rely on it to properly broadcast the packet into the local network.<br />
<br />
Otherwise Wake-on-Lan can be achieved via [[wikipedia:Port forwarding|port forwarding]]. The router needs to be configured using one of these two options:<br />
<br />
* Forward a different port to each target machine. This requires any target machine to have a static IP address on its LAN.<br />
* Forward a single port to the [[wikipedia:Broadcast_address|broadcast address]]. Most routers do not allow to forward to broadcast, however if you can get shell access to your router, through telnet, ssh, serial cable or other mean, run the command: {{bc|$ ip neighbor add 192.168.1.254 lladdr FF:FF:FF:FF:FF:FF dev net0}} This example assumes the network is ''192.168.1.0/24'' and uses ''net0'' as network interface. Now, forward UDP port 9 to 192.168.1.254. This solution was successfully tested on a Linksys WRT54G running [[Wikipedia:Tomato_(firmware)|Tomato]], and on the Verizon FIOS ActionTec router. For notes on how to do it on a router with [[Wikipedia:DD-WRT|DD-WRT]] firmware, see [http://www.dd-wrt.com/wiki/index.php/WOL#Remote_Wake_On_LAN_via_Port_Forwarding this tutorial] and for a router with [[Wikipedia:OpenWrt|OpenWrt]] firmware, see [https://wiki.openwrt.org/doc/uci/wol this tutorial]. <br />
<br />
In any case, run the following command from the source computer to trigger wake-up:<br />
<br />
$ wol -p ''forwarded_port'' -i ''router_IP'' ''target_MAC_address''<br />
<br />
== Miscellaneous ==<br />
<br />
=== Check reception of the magic packets ===<br />
In order to make sure the WoL packets reach the target computer, one can listen to the UDP port, usually port 9, for magic packets.<br />
The magic packet frame expected contains 6 bytes of FF followed by 16 repetitions of the target computer's MAC (6 bytes each) for a total of 102 bytes.<br />
<br />
==== Using netcat ====<br />
This can be performed by installing {{pkg|gnu-netcat}} on the target computer and using the following command:<br />
<br />
# nc --udp --listen --local-port=9 --hexdump<br />
<br />
Then wait for the incoming traffic to appear in the {{ic|nc}} terminal.<br />
<br />
==== Using ngrep ====<br />
Install {{pkg|ngrep}} on the target computer and type the following command:<br />
<br />
# ngrep '\xff{6}(.{6})\1{15}' -x port 9<br />
<br />
=== Example of WoL script ===<br />
Here is a script that illustrates the use of {{ic|wol}} with different machines:<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
# definition of MAC addresses<br />
monster=01:12:46:82:ab:4f<br />
ghost=01:1a:d2:56:6b:e6<br />
<br />
echo "Which PC to wake?"<br />
echo "m) monster"<br />
echo "g) ghost"<br />
echo "q) quit"<br />
read input1<br />
case $input1 in<br />
m)<br />
/usr/bin/wol $monster<br />
;;<br />
g)<br />
# uses wol over the internet provided that port 9 is forwarded to ghost on ghost's router<br />
/usr/bin/wol --port=9 --host=ghost.mydomain.org $ghost<br />
;;<br />
Q|q)<br />
break<br />
;;<br />
esac</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Wake-up after shutdown ===<br />
It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a ''shutdown'' whenever the BIOS WoL feature is enabled (as discussed in [https://bbs.archlinux.org/viewtopic.php?id=173648 this thread] for example).<br />
==== Fix using BIOS Settings ====<br />
The following actions in the BIOS preferences can solve this issue with some motherboards:<br />
# Disable all references to ''xHCI'' in the USB settings (note this will also disable USB 3.0 at boot time)<br />
# Disable ''EuP 2013'' if it is explicitly an option<br />
# Optionally enable wake-up on keyboard actions<br />
{{Note|There are mixed opinions as to the value of #3 above and it may be motherboard dependent.}}<br />
<br />
==== Fix by Kernel quirks ====<br />
The issue can also be solved by adding the following kernel boot parameter: {{ic|1=xhci_hcd.quirks=270336}}<br />
This activates the following quirks:<br />
* {{ic|XHCI_SPURIOUS_REBOOT}}<br />
* {{ic|XHCI_SPURIOUS_WAKEUP}}<br />
<br />
=== Battery draining problem ===<br />
Some laptops have a battery draining problem after shutdown [http://ubuntuforums.org/archive/index.php/t-1729782.html]. This might be caused by enabled WOL. To solve this problem, disable it by using ethtool as mentioned above.<br />
<br />
# ethtool -s net0 wol d<br />
<br />
=== Realtek ===<br />
<br />
Users with Realtek 8168 8169 8101 8111(C) based NICs (cards / and on-board) may notice a problem where the NIC seems to be disabled on boot and has no Link light. See [[Network configuration#Realtek no link / WOL problem]].<br />
<br />
If the link light on the network switch is enabled when the computer is turned off but wake on LAN is still not working, booting the system using the {{Pkg|r8168}} kernel module at least once and then switching back to the r8169 kernel module included with the kernel seems to fix it at least in the following configurations:<br />
* MSI B85M-E45 motherboard, BIOS version V10.9, onboard Realtek 8111G chipset<br />
<br />
For the {{ic|r8168}} module you might need to set the {{ic|1=s5wol=1}} [[Kernel_modules#Setting_module_options|module option]] to enable the wake on LAN functionality.<br />
<br />
===alx driver support===<br />
<br />
For some newer Atheros-based NICs (such as Atheros AR8161 and Killer E2500), WOL support has been disabled in the mainline {{ic|alx}} module due to a bug causing unintentional wake-up (see [http://www.spinics.net/lists/netdev/msg242477.html this patch discussion]). A patch can be applied (or installed as a [[dkms]] module) which both restores WOL support and fixes the underlying bug, as outlined in [https://bugzilla.kernel.org/show_bug.cgi?id=61651 this thread].<br />
<br />
See also the pre-patched sources in [https://github.com/Snugface/alx].<br />
<br />
== See also ==<br />
<br />
* [http://www.depicus.com/wake-on-lan/woli.aspx Wake-On-Lan]</div>Chichahttps://wiki.archlinux.org/index.php?title=Power_management&diff=571366Power management2019-04-16T13:25:09Z<p>Chicha: Network interfaces: Use "wl*" instead of "wlp*" in the udev rule to make it actually work, see related talk.</p>
<hr />
<div>[[Category:Power management]]<br />
[[es:Power management]]<br />
[[it:Shutdown Pressing Power Button]]<br />
[[ja:電源管理]]<br />
[[zh-hans:Power management]]<br />
{{Related articles start}}<br />
{{Related|Power management/Suspend and hibernate}}<br />
{{Related|Display Power Management Signaling}}<br />
{{Related|CPU frequency scaling}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Kernel modules}}<br />
{{Related|sysctl}}<br />
{{Related|udev}}<br />
{{Related articles end}}<br />
[[Wikipedia:Power management|Power management]] is a feature that turns off the power or switches system's components to a low-power state when inactive.<br />
<br />
In Arch Linux, power management consists of two main parts:<br />
<br />
# Configuration of the Linux kernel, which interacts with the hardware.<br />
#* [[Kernel parameters]]<br />
#* [[Kernel modules]]<br />
#* [[udev]] rules<br />
# Configuration of userspace tools, which interact with the kernel and react to its events. Many userspace tools also allow to modify kernel configuration in a "user-friendly" way. See [[#Userspace tools]] for the options.<br />
<br />
== Userspace tools ==<br />
<br />
Using these tools can replace setting a lot of settings by hand. Only run '''one''' of these tools to avoid possible conflicts as they all work more or less similarly. Have a look at the [[:Category:Power management|power management category]] to get an overview on what power management options exist in Arch Linux.<br />
<br />
These are the more popular scripts and tools designed to help power saving:<br />
<br />
=== Console ===<br />
<br />
* {{App|[[acpid]]| A daemon for delivering ACPI power management events with netlink support.|http://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}<br />
* {{App|[[Laptop Mode Tools]]|Utility to configure laptop power saving settings, considered by many to be the de facto utility for power saving though may take a bit of configuration.|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}<br />
* {{App|[[powertop]]|A tool to diagnose issues with power consumption and power management to help set power saving settings.|https://01.org/powertop/|{{Pkg|powertop}}}}<br />
* {{App|[[systemd]]|A system and service manager.|https://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[TLP]]|Advanced power management for Linux.|http://linrunner.de/tlp|{{Pkg|tlp}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|batterymon-clone|Simple battery monitor tray icon.|https://github.com/jareksed/batterymon-clone|{{AUR|batterymon-clone}}}}<br />
* {{App|cbatticon|Lightweight and fast battery icon that sits in your system tray.|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}<br />
* {{App|GNOME Power Statistics|System power information and statistics for GNOME.|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}<br />
* {{App|KDE Power Devil|Power management module for Plasma.|https://userbase.kde.org/Power_Devil|{{Pkg|powerdevil}} {{aur|powerdevil-light}}}}<br />
* {{App|LXQt Power Management|Power management module for LXQt.|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}<br />
* {{App|MATE Power Management|Power management tool for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|MATE Power Statistics|System power information and statistics for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|Xfce Power Manager|Power manager for Xfce.|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}<br />
* {{App|vattery|Battery monitoring application written in Vala that will display the status of a laptop battery in a system tray.|http://www.jezra.net/projects/vattery|{{AUR|vattery}}}}<br />
<br />
== Power management with systemd ==<br />
<br />
=== ACPI events ===<br />
<br />
''systemd'' handles some power-related [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] events, whose actions can be configured in {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} — see {{man|5|logind.conf}}. On systems with no dedicated power manager, this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
The specified action for each event can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}}, {{ic|suspend-then-hibernate}}, {{ic|lock}} or {{ic|kexec}}. In case of hibernation and suspension, they must be properly [[Power management/Suspend and hibernate|set up]]. If an event is not configured, ''systemd'' will use a default action.<br />
<br />
{| class="wikitable sortable" border=1<br />
!Event handler<br />
!Description<br />
!Default action<br />
|-<br />
|{{ic|HandlePowerKey}}<br />
|Triggered when the power key/button is pressed.<br />
|{{ic|poweroff}}<br />
|-<br />
|{{ic|HandleSuspendKey}}<br />
|Triggered when the suspend key/button is pressed.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleHibernateKey}}<br />
|Triggered when the hibernate key/button is pressed.<br />
|{{ic|hibernate}}<br />
|-<br />
|{{ic|HandleLidSwitch}}<br />
|Triggered when the lid is closed, except in the cases below.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleLidSwitchDocked}}<br />
|Triggered when the lid is closed if the system is inserted in a docking station, or more than one display is connected.<br />
|{{ic|ignore}}<br />
|-<br />
|{{ic|HandleLidSwitchExternalPower}}<br />
|Triggered when the lid is closed if the system is connected to external power.<br />
|action set for {{ic|HandleLidSwitch}}<br />
|}<br />
<br />
To apply any changes, [[restart]] {{ic|systemd-logind.service}} (be warned that this will terminate all login sessions that might still be open).<br />
<br />
{{Note|''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.}}<br />
<br />
==== Power managers ====<br />
<br />
Some [[desktop environment]]s include power managers which [http://www.freedesktop.org/wiki/Software/systemd/inhibit/ inhibit] (temporarily turn off) some or all of the ''systemd'' ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager. <br />
<br />
Note that if the power manager does not inhibit ''systemd'' for the appropriate events you can end up with a situation where ''systemd'' suspends your system and then when the system is woken up the other power manager suspends it again. As of December 2016, the power managers of [[KDE]], [[GNOME]], [[Xfce]] and [[MATE]] issue the necessary ''inhibited'' commands. If the ''inhibited'' commands are not being issued, such as when using [[acpid]] or others to handle ACPI events, set the {{ic|Handle}} options to {{ic|ignore}}. See also {{man|1|systemd-inhibit}}.<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} subscribes to the systemd-events {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker). ''xss-lock'' also reacts to [[DPMS]] events and runs or kills the locker in response.<br />
<br />
Start xss-lock in your [[autostart]], for example<br />
<br />
xss-lock -- i3lock -n -i ''background_image.png'' &<br />
<br />
=== Suspend and hibernate ===<br />
<br />
''systemd'' provides commands to suspend to RAM or hibernate using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.<br />
<br />
{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Suspend and hibernate#Hibernation]].<br />
<br />
There are also two modes combining suspend and hibernate:<br />
<br />
* {{ic|systemctl hybrid-sleep}} suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called [[Power management/Suspend and hibernate|suspend to both]].<br />
* {{ic|systemctl suspend-then-hibernate}} initially suspends the system to RAM and if it is not interrupted within the delay specified by {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}, then the system will be woken using an RTC alarm and hibernated.<br />
<br />
{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}<br />
<br />
==== Hybrid-sleep on suspend or hibernation request ====<br />
<br />
It is possible to configure systemd to always do a ''hybrid-sleep'' even on a ''suspend'' or ''hibernation'' request.<br />
<br />
The default ''suspend'' and ''hibernation'' action can be configured in the {{ic|/etc/systemd/sleep.conf}} file. To set both actions to ''hybrid-sleep'':<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
# suspend=hybrid-sleep<br />
SuspendMode=suspend<br />
SuspendState=disk<br />
# hibernate=hybrid-sleep<br />
HibernateMode=suspend<br />
HibernateState=disk<br />
}}<br />
<br />
See the {{man|5|sleep.conf.d}} manual page for details and the [https://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation linux kernel documentation on power states].<br />
<br />
=== Sleep hooks ===<br />
<br />
==== Suspend/resume service files ====<br />
<br />
Service files can be hooked into ''suspend.target'', ''hibernate.target'', ''sleep.target'', ''hybrid-sleep.target'' and ''suspend-then-hibernate.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. [[Enable]] the {{ic|suspend@''user''}} and {{ic|resume@''user''}} services to have them started at boot. Examples:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki><br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop<br />
ExecStart=/usr/bin/sflock<br />
ExecStartPost=/usr/bin/sleep 1<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<nowiki><br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStart=/usr/local/bin/ssh-connect.sh<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
</nowiki>}}<br />
<br />
{{Note|As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via {{ic|1=ExecStartPost=/usr/bin/sleep 1}} helps prevent this.}}<br />
<br />
For root/system actions ([[enable]] the {{ic|root-resume}} and {{ic|root-suspend}} services to have them started at boot):<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki><br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki><br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
</nowiki>}}<br />
<br />
A couple of handy hints about these service files (more in {{man|5|systemd.service}}):<br />
<br />
* If {{ic|1=<nowiki>Type=oneshot</nowiki>}} then you can use multiple {{ic|1=<nowiki>ExecStart=</nowiki>}} lines. Otherwise only one {{ic|ExecStart}} line is allowed. You can add more commands with either {{ic|ExecStartPre}} or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are ''required'').<br />
* A command prefixed with {{ic|-}} will cause a non-zero exit status to be ignored and treated as a successful command. <br />
* The best place to find errors when troubleshooting these service files is of course with [[journalctl]].<br />
<br />
==== Combined Suspend/resume service file ====<br />
<br />
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Example and explanation:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki><br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
</nowiki>}}<br />
<br />
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after ''sleep.target'' is stopped.<br />
* Because ''sleep.target'' is pulled in by ''suspend.target'', ''hibernate.target'' and ''hybrid-sleep.target'' and because ''sleep.target'' itself is a ''StopWhenUnneeded'' service, the hook is guaranteed to start/stop properly for different tasks.<br />
<br />
==== Hooks in /usr/lib/systemd/system-sleep ====<br />
<br />
''systemd'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked<br />
<br />
''systemd'' will run these scripts concurrently and not one after another.<br />
<br />
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[systemd#Journal|journal]]{{Broken section link}}:<br />
<br />
# journalctl -b -u systemd-suspend.service<br />
<br />
{{Note|You can also use ''sleep.target'', ''suspend.target'', ''hibernate.target'' or ''hybrid-sleep.target'' to hook units into the sleep state logic instead of using custom scripts.}}<br />
<br />
An example of a custom sleep script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac<br />
}}<br />
<br />
Do not forget to make your script executable:<br />
<br />
# chmod a+x /usr/lib/systemd/system-sleep/example.sh<br />
<br />
See {{man|7|systemd.special}} and {{man|8|systemd-sleep}} for more details.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== Delayed lid switch action ====<br />
<br />
When performing lid switches in short succession, ''logind'' will delay the suspend action for up to 90s to detect possible docks. [http://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] This delay was made configurable with systemd v220:[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba]<br />
<br />
{{hc|/etc/systemd/logind.conf|2=<br />
...<br />
HoldoffTimeoutSec=30s<br />
...<br />
}}<br />
<br />
==== Suspend from corresponding laptop Fn key not working ====<br />
<br />
If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [http://lists.freedesktop.org/archives/systemd-devel/2015-February/028325.html] Do:<br />
<br />
# journalctl --grep="Watching system buttons"<br />
<br />
You might see something like this:<br />
<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)<br />
<br />
Notice no keyboard device. Now obtain ATTRS{name} for the parent keyboard device [http://systemd-devel.freedesktop.narkive.com/Rbi3rjNN/patch-1-2-logind-add-support-for-tps65217-power-button] :<br />
<br />
{{hc|# udevadm info -a /dev/input/by-path/*-kbd|2=<br />
...<br />
KERNEL=="event0"<br />
...<br />
ATTRS{name}=="AT Translated Set 2 keyboard"<br />
}}<br />
<br />
Now write a custom udev rule to add the "power-switch" tag:<br />
<br />
{{hc|/etc/udev/rules.d/70-power-switch-my.rules|<nowiki><br />
ACTION=="remove", GOTO="power_switch_my_end"<br />
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="AT Translated Set 2 keyboard", TAG+="power-switch"<br />
LABEL="power_switch_my_end"<br />
</nowiki>}}<br />
<br />
{{Style|Explicit {{ic|systemctl}} commands should not be provided.}}<br />
<br />
Restart services and reload rules:<br />
<br />
# systemctl restart systemd-udevd.service<br />
# udevadm trigger<br />
# systemctl restart systemd-logind.service<br />
<br />
Now you should see {{ic|Watching system buttons on /dev/input/event0}} in syslog.<br />
<br />
== Power saving ==<br />
<br />
{{Note|See [[Laptop#Power management]] for power management specific to laptops, such as battery monitoring.}}<br />
<br />
This section is a reference for creating custom scripts and power saving settings such as by udev rules. Make sure that the settings are not managed by some [[#Userspace tools|other utility]] to avoid conflicts.<br />
<br />
Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
=== Processors with HWP (Hardware P-state) support ===<br />
<br />
{{Merge|CPU frequency scaling|More context in the main article.}}<br />
<br />
The available energy preferences of a HWP supported processor are {{ic|default performance balance_performance balance_power power}}.<br />
<br />
This can be validated by {{ic|$ cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_available_preferences}}<br />
<br />
To conserve more energy, you can config by creating the following file:<br />
<br />
{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|<br />
w /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference - - - - balance_power<br />
}}<br />
<br />
See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
=== Audio ===<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the {{ic|power_save}} parameter; a time (in seconds) to go into idle mode. To idle the audio card after one second, create the following file for Intel soundcards.<br />
<br />
{{hc|/etc/modprobe.d/audio_powersave.conf|2=<br />
options snd_hda_intel power_save=1<br />
}}<br />
<br />
Alternatively, use the following for ac97:<br />
<br />
options snd_ac97_codec power_save=1<br />
<br />
{{Note|<br />
* To retrieve the manufacturer and the corresponding kernel driver which is used for your sound card, run {{ic|lspci -k}}.<br />
* Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.<br />
}}<br />
<br />
It is also possible to further reduce the audio power requirements by disabling the HDMI audio output, which can done by [[blacklisting]] the appropriate kernel modules (e.g. {{ic|snd_hda_codec_hdmi}} in case of Intel hardware).<br />
<br />
=== Backlight ===<br />
<br />
See [[Backlight]].<br />
<br />
=== Bluetooth ===<br />
<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
<br />
To disable bluetooth completely, [[blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
To turn off bluetooth only temporarily, use ''rfkill'':<br />
<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
<br />
{{hc|/etc/udev/rules.d/50-bluetooth.rules|<nowiki><br />
# disable bluetooth<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
</nowiki>}}<br />
<br />
=== Web camera ===<br />
<br />
If you will not use integrated web camera then [[blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
=== Kernel parameters ===<br />
<br />
This section uses configs in {{ic|/etc/sysctl.d/}}, which is ''"a drop-in directory for kernel sysctl parameters."'' See [http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] and more specifically {{man|5|sysctl.d}} for more information.<br />
<br />
==== Disabling NMI watchdog ====<br />
<br />
{{Expansion|This or {{ic|nowatchdog}} as can be seen in [[Improving performance#Watchdogs]]}}<br />
<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs that cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage:<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=<br />
kernel.nmi_watchdog = 0<br />
}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} to the [[kernel line]] to disable it completely from early boot.<br />
<br />
==== Writeback Time ====<br />
<br />
Increasing the virtual memory dirty writeback time helps to aggregate disk I/O together, thus reducing spanned disk writes, and increasing power saving. To set the value to 60 seconds (default is 5 seconds):<br />
<br />
{{hc|/etc/sysctl.d/dirty.conf|2=<br />
vm.dirty_writeback_centisecs = 6000<br />
}}<br />
<br />
To do the same for journal commits on supported filesystems (e.g. ext4, btrfs...), use {{ic|1=commit=60}} as a option in [[fstab]].<br />
<br />
Note that this value is modified as a side effect of the Laptop Mode setting below.<br />
See also [[sysctl#Virtual memory]] for other parameters affecting I/O performance and power saving.<br />
<br />
==== Laptop Mode ====<br />
<br />
See the [https://www.kernel.org/doc/Documentation/laptops/laptop-mode.txt kernel documentation] on the laptop mode 'knob.' ''"A sensible value for the knob is 5 seconds."''<br />
<br />
{{hc|/etc/sysctl.d/laptop.conf|2=<br />
vm.laptop_mode = 5<br />
}}<br />
<br />
{{Note|This setting is mainly relevant to spinning-disk drives.}}<br />
<br />
=== Network interfaces ===<br />
<br />
[[Wake-on-LAN]] can be a useful feature, but if you are not making use of it then it is simply draining extra power waiting for a magic packet while in suspend. You can adapt the [[Wake-on-LAN#udev]] rule to disable the feature for all ethernet interfaces.<br />
To enable powersaving with {{Pkg|iw}} on all wireless interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"}}<br />
<br />
The name of the configuration file is important. With the use of [[Network configuration#Change interface name|persistent device names]] in systemd, the above network rule, named lexicographically '''after''' {{ic|80-net-setup-link.rules}}, is applied after the device is renamed with a persistent name e.g. {{ic|wlan0}} renamed {{ic|wlp3s0}}.<br />
Be aware that the {{ic|RUN}} command is executed after all rules have been processed and must anyway use the persistent name, available in {{ic|$name}} for the matched device.<br />
<br />
==== Intel wireless cards (iwlwifi) ====<br />
<br />
Additional power saving functions of Intel wireless cards with {{ic|iwlwifi}} driver can be enabled by passing the correct parameters to the kernel module. Making it persistent can be achieved by adding the line below to {{ic|/etc/modprobe.d/iwlwifi.conf}} file:<br />
<br />
options iwlwifi power_save=1 d0i3_disable=0 uapsd_disable=0<br />
options iwldvm force_cam=0<br />
<br />
Keep in mind that these power saving options are experimental and can cause an unstable system.<br />
<br />
=== Bus power management ===<br />
<br />
==== Active State Power Management ====<br />
<br />
If the computer is believed not to support [[Wikipedia:Active State Power Management|ASPM]] it will be disabled on boot:<br />
<br />
# lspci -vv | grep 'ASPM.*abled;'<br />
<br />
ASPM is handled by the BIOS, if ASPM is disabled it will be because [http://wireless.kernel.org/en/users/Documentation/ASPM ref]:<br />
<br />
# The BIOS disabled it for some reason (for conflicts?).<br />
# PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).<br />
# The BIOS might not have been programmed for it.<br />
# The BIOS is buggy.<br />
<br />
If believing the computer has support for ASPM it can be forced on for the kernel to handle with the {{ic|1=pcie_aspm=force}} [[kernel parameter]].<br />
<br />
{{Warning|<br />
* Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it does not work.<br />
* On systems that do not support it forcing on ASPM can even increase power consumption.<br />
* This forces ASPM in kernel while it can still remain disabled in hardware and not work. To check whether this is the case the {{ic|dmesg {{!}} grep ASPM}} command can be used and if that is the case, hardware-specific Wiki article should be consulted.<br />
}}<br />
<br />
To adjust to {{ic|powersave}} do (the following command will not work unless enabled):<br />
<br />
# echo powersave > /sys/module/pcie_aspm/parameters/policy<br />
<br />
By default it looks like this:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|<br />
[default] performance powersave<br />
}}<br />
<br />
==== PCI Runtime Power Management ====<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
}}<br />
<br />
The rule above powers all unused devices down, but some devices will not wake up again.<br />
To allow runtime power management only for devices that are known to work, use simple matching against vendor and device IDs (use {{ic|lspci -nn}} to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|<nowiki><br />
# whitelist for pci autosuspend<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"<br />
</nowiki>}}<br />
<br />
Alternatively, to blacklist devices that are not working with PCI runtime power management and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|<nowiki><br />
# blacklist for pci runtime power management<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"<br />
<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
LABEL="pci_pm_end"<br />
</nowiki>}}<br />
<br />
==== USB autosuspend ====<br />
<br />
The Linux kernel can automatically suspend USB devices when they are not in use. This can sometimes save quite a bit of power, however some USB devices are not compatible with USB power saving and start to misbehave (common for USB mice/keyboards). [[udev]] rules based on whitelist or blacklist filtering can help to mitigate the problem.<br />
<br />
The most simple and likely useless example is enabling autosuspend for all USB devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
</nowiki>}}<br />
<br />
To allow autosuspend only for devices that are known to work, use simple matching against vendor and product IDs (use ''lsusb'' to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|<nowiki><br />
# whitelist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"<br />
</nowiki>}}<br />
<br />
Alternatively, to blacklist devices that are not working with USB autosuspend and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|<nowiki><br />
# blacklist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"<br />
<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
LABEL="power_usb_rules_end"<br />
</nowiki>}}<br />
<br />
The default autosuspend idle delay time is controlled by the {{ic|autosuspend}} parameter of the {{ic|usbcore}} [[kernel module]]. To set the delay to 5 seconds instead of the default 2 seconds:<br />
<br />
{{hc|/etc/modprobe.d/usb-autosuspend.conf|<nowiki><br />
options usbcore autosuspend=5<br />
</nowiki>}}<br />
<br />
Similarly to {{ic|power/control}}, the delay time can be fine-tuned per device by setting the {{ic|power/autosuspend}} attribute.<br />
<br />
See the [https://www.kernel.org/doc/Documentation/usb/power-management.txt Linux kernel documentation] for more information on USB power management.<br />
<br />
==== SATA Active Link Power Management ====<br />
<br />
{{Warning|SATA Active Link Power Management can lead to data loss on some devices. Do not enable this setting unless you have frequent backups.}}<br />
<br />
Since Linux 4.15 there is a [https://hansdegoede.livejournal.com/18412.html new setting] called {{ic|med_power_with_dipm}} that matches the behaviour of Windows IRST driver settings and should not cause data loss with recent SSD/HDD drives. The power saving can be significant, ranging [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b from 1.0 to 1.5 Watts (when idle)]. It will become a default setting for Intel based laptops in Linux 4.16 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b].<br />
<br />
The current setting can be read from {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} as follows:<br />
<br />
# cat /sys/class/scsi_host/host*/link_power_management_policy<br />
<br />
{| class="wikitable"<br />
|+ Available ALPM settings<br />
! Setting<br />
! Description<br />
! Power saving<br />
|-<br />
| max_performance<br />
| current default<br />
| None<br />
|-<br />
| medium_power<br />
| -<br />
| ~1.0 Watts<br />
|-<br />
| med_power_with_dipm<br />
| recommended setting<br />
| ~1.5 Watts<br />
|-<br />
| min_power<br />
| '''WARNING: possible data loss'''<br />
| ~1.5 Watts<br />
|}<br />
<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"<br />
}}<br />
<br />
{{Note|This adds latency when accessing a drive that has been idle, so it is one of the few settings that may be worth toggling based on whether you are on AC power.}}<br />
<br />
=== Hard disk drive ===<br />
<br />
See [[hdparm#Power management configuration]] for drive parameters that can be set.<br />
<br />
Power saving is not effective when too many programs are frequently writing to the disk. Tracking all programs, and how and when they write to disk is the way to limit disk usage. Use {{Pkg|iotop}} to see which programs use the disk frequently. See [[Improving performance#Storage devices]] for other tips.<br />
<br />
Also little things like setting the [[Fstab#atime options|noatime]] option can help. If enough RAM is available, consider disabling or limiting [[swappiness]] as it has the possibility to limit a good number of disk writes.<br />
<br />
=== CD-ROM or DVD drive ===<br />
<br />
See [[Udisks#Devices do not remain unmounted (udisks)]].<br />
<br />
== Tools and scripts ==<br />
<br />
{{Style|Merged from [[Power saving]], needs reorganization to fit into this page.}}<br />
<br />
=== Using a script and an udev rule ===<br />
<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove ''pm-utils'' and [[acpid]]. There is just one thing systemd cannot do (as of systemd-204): power management depending on whether the system is running on AC or battery. To fill this gap, you can create a single [[udev]] rule that runs a script when the AC adapter is plugged and unplugged:<br />
<br />
{{hc|/etc/udev/rules.d/powersave.rules|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
<br />
{{Note|You can use the same script that ''pm-powersave'' uses. You just have to make it executable and place it somewhere else (for example {{ic|/usr/local/bin/}}).}}<br />
<br />
Examples of powersave scripts:<br />
<br />
* [https://github.com/supplantr/ftw ftw], package: {{AUR|ftw-git}}<br />
* [https://github.com/Unia/powersave powersave]<br />
* [https://github.com/quequotion/pantheon-bzr-qq/blob/master/EXTRAS/indicator-powersave/throttle throttle], from {{AUR|indicator-powersave}}<br />
<br />
The above udev rule should work as expected, but if your power settings are not updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac<br />
exit 0<br />
</nowiki>}}<br />
<br />
Do not forget to make it executable!<br />
<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
=== Print power settings ===<br />
<br />
This script prints power settings and a variety of other properties for USB and PCI devices. Note that root permissions are needed to see all settings.<br />
<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
for i in $(find /sys/devices -name "bMaxPower")<br />
do<br />
busdir=${i%/*}<br />
busnum=$(<$busdir/busnum)<br />
devnum=$(<$busdir/devnum)<br />
title=$(lsusb -s $busnum:$devnum)<br />
<br />
printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"<br />
<br />
for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)<br />
do<br />
v=$(cat $ff 2>/dev/null|tr -d "\n")<br />
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
<br />
printf "\n\n\n+++ %s\n" "Kernel Modules"<br />
for mod in $(lspci -k | sed -n '/in use:/s,^.*: ,,p' | sort -u)<br />
do<br />
echo "+ $mod";<br />
systool -v -m $mod 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]<br />
* [http://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=377772User:Chicha2015-06-07T14:49:39Z<p>Chicha: /* Job/Hobbies */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Firstname''' : Charles-Henri<br><br />
'''Lastname''' : d'Adhémar<br><br />
'''Nationality''' : French<br><br />
'''Location''' : Nice (France)<br><br />
'''Birthdate''' : 23/11/1979<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer''' (ASM, C/C++, Java, Python, Shell ...) at [[wikipedia:Amadeus_IT_Group|Amadeus]].</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=377771User:Chicha2015-06-07T14:49:14Z<p>Chicha: /* Me and Arch */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Firstname''' : Charles-Henri<br><br />
'''Lastname''' : d'Adhémar<br><br />
'''Nationality''' : French<br><br />
'''Location''' : Nice (France)<br><br />
'''Birthdate''' : 23/11/1979<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer''' (ASM, C/C++, Java, Python, Shell ...) at [[wikipedia:Amadeus_IT_Group|Amadeus]].<br />
<br />
Free Software is my major 'cerebral' hobby. I am also a great kind of nature (sea, mountains, country) and sailing in particular.</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=377770User:Chicha2015-06-07T14:48:31Z<p>Chicha: /* Who am I ? */</p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Firstname''' : Charles-Henri<br><br />
'''Lastname''' : d'Adhémar<br><br />
'''Nationality''' : French<br><br />
'''Location''' : Nice (France)<br><br />
'''Birthdate''' : 23/11/1979<br><br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer''' (ASM, C/C++, Java, Python, Shell ...) at [[wikipedia:Amadeus_IT_Group|Amadeus]].<br />
<br />
Free Software is my major 'cerebral' hobby. I am also a great kind of nature (sea, mountains, country) and sailing in particular.<br />
<br />
<br />
=== Me and Arch ===<br />
After having looking around for the distro of my dream and a great community I think '''I found with Arch all I was looking for''' :<br />
<br />
* Ease of use and stability.<br />
* Nice technologies.<br />
* Knowledge provider.<br />
* Open and accessible community.<br />
<br />
<br />
'''I do not participate to the French Arch Community''' for several reasons:<br />
<br />
* The first one is that as usual in France it is divided in 2 communities : archlinuxfr.org and archlinux.fr. Isn't it ridiculous ?<br />
* I do not like local communities as long as you loose the opportunity to meet foreign people and new culture. Every time I went to a localized community (french or other) I felt like it was totally living outside the "real" world.<br />
* I believe helping here will help more people than working for a smaller community.<br />
* Having local communities duplicate the documentation. Having a localized forum is nice. Having a French or whatever language Wiki is a waste of ressources. I really like better a single entry point and wiki for documentation with translated pages, like it is the case here.<br />
<br />
<br />
Like many people I do not have enought time to participate in all I would like to.<br />
Here is a (too small) list of things I am contributing to :<br />
<br />
* '''Gnome technologies''' : testing and bug reporting mainly.<br />
* '''Arch forums''' : I try to help as much as I can (and sometimes need help), especially with people having problems with Gnome.<br />
* '''Arch bug tracker''' : It is my new hobby at Arch. I enjoy tracking (hunting) bugs, and close invalid ones.<br />
* '''Arch wiki''' : I help at some translations. Recently I wrote a documentation on [[Reporting_Bug_Guidelines|how to report bugs]].<br />
* '''AUR''' : There is nearly all I need in there. For what I miss see [https://aur.archlinux.org/packages.php?SeB=m&K=chicha my contributions].</div>Chichahttps://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=377609Simple stateful firewall2015-06-06T13:08:01Z<p>Chicha: Removed extra dash (typo error) in --reject-with icmp6-port-unreachable</p>
<hr />
<div>[[Category:Firewalls]]<br />
[[es:Simple stateful firewall]]<br />
[[ja:シンプルなステートフルファイアウォール]]<br />
[[ru:Simple stateful firewall]]<br />
This page explains how to set up a stateful firewall using [[iptables]]. It also explains what the rules mean and why they are needed. For simplicity, it is split into two major sections. The first section deals with a firewall for a single machine, the second sets up a NAT gateway in addition to the firewall from the first section.<br />
<br />
{{Warning| The rules are given in the order that they are executed. If you are logged into a remote machine, you may be locked out of the machine while setting up the rules. You should only follow the steps below while you are logged in locally.<br />
<br />
The [https://wiki.archlinux.org/index.php/Simple_Stateful_Firewall#Example_iptables.rules_file example config file] can be used to get around this problem.<br />
}}<br />
<br />
== Prerequisites ==<br />
<br />
{{Note|Your kernel needs to be compiled with iptables support. All stock Arch Linux kernels have iptables support.}}<br />
<br />
First, install the userland utilities {{Pkg|iptables}} or verify that they are already installed.<br />
<br />
This article assumes that there are currently no iptables rules set. To check the current ruleset and verify that there are currently no rules run the following:<br />
<br />
{{hc|# iptables-save|<nowiki><br />
# Generated by iptables-save v1.4.19.1 on Thu Aug 1 19:28:53 2013<br />
*filter<br />
:INPUT ACCEPT [50:3763]<br />
:FORWARD ACCEPT [0:0]<br />
:OUTPUT ACCEPT [30:3472]<br />
COMMIT<br />
# Completed on Thu Aug 1 19:28:53 2013<br />
</nowiki>}}<br />
<br />
or<br />
<br />
{{hc|# iptables -nvL --line-numbers|<nowiki><br />
Chain INPUT (policy ACCEPT 156 packets, 12541 bytes)<br />
num pkts bytes target prot opt in out source destination<br />
<br />
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)<br />
num pkts bytes target prot opt in out source destination<br />
<br />
Chain OUTPUT (policy ACCEPT 82 packets, 8672 bytes)<br />
num pkts bytes target prot opt in out source destination<br />
</nowiki>}}<br />
<br />
If there are rules, you may be able to reset the rules by loading a default rule set:<br />
<br />
# iptables-restore < /etc/iptables/empty.rules<br />
<br />
Otherwise, see [[Iptables#Resetting rules]].<br />
<br />
== Firewall for a single machine ==<br />
<br />
{{Note|Because iptables processes rules in linear order, from top to bottom within a chain, it is advised to put frequently-hit rules near the start of the chain. Of course there is a limit, depending on the logic that is being implemented. Also, rules have an associated runtime cost, so rules should not be reordered solely based upon empirical observations of the byte/packet counters.}}<br />
<br />
=== Creating necessary chains ===<br />
<br />
For this basic setup, we will create two user-defined chains that we will use to open up ports in the firewall.<br />
<br />
# iptables -N TCP<br />
# iptables -N UDP<br />
<br />
The chains can of course have arbitrary names. We pick these just to match the protocols we want handle with them in the later rules, which are specified with the protocol options, e.g. {{ic|-p tcp}}, always.<br />
<br />
=== The FORWARD chain ===<br />
<br />
If you want to set up your machine as a NAT gateway, please look at [[#Setting up a NAT gateway]]. For a single machine, however, we simply set the policy of the '''FORWARD''' chain to '''DROP''' and move on:<br />
<br />
# iptables -P FORWARD DROP<br />
<br />
=== The OUTPUT chain ===<br />
<br />
We have no intention of filtering any outgoing traffic, as this would make the setup much more complicated and would require some extra thought. In this simple case, we set the '''OUTPUT''' policy to '''ACCEPT'''.<br />
<br />
# iptables -P OUTPUT ACCEPT<br />
<br />
=== The INPUT chain ===<br />
<br />
Similar to the previous chains, we set the default policy for the '''INPUT''' chain to '''DROP''' in case something somehow slips by our rules. Dropping all traffic and specifying what is allowed is the best way to make a secure firewall.<br />
<br />
{{Warning|If you are logged in via SSH, the following will immediately disconnect the SSH session. To avoid it: (1) add the first INPUT chain rule below (it will keep the session open), (2) add a regular rule to allow inbound SSH (to be able to reconnect in case of a connection drop) and (3) set the policy.}}<br />
<br />
# iptables -P INPUT DROP<br />
<br />
Every packet that is received by any network interface will pass the '''INPUT''' chain first, if it is destined for this machine. In this chain, we make sure that only the packets that we want are accepted.<br />
<br />
The first rule added to the INPUT chain will allow traffic that belongs to established connections, or new valid traffic that is related to these connections such as ICMP errors, or echo replies (the packets a host returns when pinged). '''ICMP''' stands for '''Internet Control Message Protocol'''. Some ICMP messages are very important and help to manage congestion and MTU, and are accepted by this rule. <br />
<br />
The connection state {{ic|ESTABLISHED}} implies that either another rule previously allowed the initial ({{ic|--ctstate NEW}}) connection attempt or the connection was already active (for example an active remote SSH connection) when setting the rule: <br />
<br />
# iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
<br />
The second rule will accept all traffic from the "loopback" (lo) interface, which is necessary for many applications and services.<br />
<br />
{{Note|You can add more trusted interfaces here such as "eth1" if you do not want/need the traffic filtered by the firewall, but be warned that if you have a NAT setup that redirects any kind of traffic to this interface from anywhere else in the network (let's say a router), it will get through, regardless of any other settings you may have.}}<br />
<br />
# iptables -A INPUT -i lo -j ACCEPT<br />
<br />
The third rule will drop all traffic with an "INVALID" state match. Traffic can fall into four "state" categories: NEW, ESTABLISHED, RELATED or INVALID and this is what makes this a "stateful" firewall rather than a less secure "stateless" one. States are tracked using the "nf_conntrack_*" kernel modules which are loaded automatically by the kernel as you add rules.<br />
<br />
{{Note|<br />
* This rule will drop all packets with invalid headers or checksums, invalid TCP flags, invalid ICMP messages (such as a port unreachable when we did not send anything to the host), and out of sequence packets which can be caused by sequence prediction or other similar attacks. The "DROP" target will drop a packet without any response, contrary to REJECT which politely refuses the packet. We use DROP because there is no proper "REJECT" response to packets that are INVALID, and we do not want to acknowledge that we received these packets.<br />
* ICMPv6 Neighbor Discovery packets remain untracked, and will always be classified "INVALID" though they are not corrupted or the like. Keep this in mind, and accept them before this rule! iptables -A INPUT -p 41 -j ACCEPT<br />
}}<br />
<br />
# iptables -A INPUT -m conntrack --ctstate INVALID -j DROP<br />
<br />
The next rule will accept all new incoming '''ICMP echo requests''', also known as pings. Only the first packet will count as NEW, the rest will be handled by the RELATED,ESTABLISHED rule. Since the computer is not a router, no other ICMP traffic with state NEW needs to be allowed.<br />
<br />
# iptables -A INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT<br />
<br />
Now we attach the TCP and UDP chains to the INPUT chain to handle all new incoming connections. Once a connection is accepted by either TCP or UDP chain, it is handled by the RELATED/ESTABLISHED traffic rule. The TCP and UDP chains will either accept new incoming connections, or politely reject them. New TCP connections must be started with SYN packets.<br />
<br />
{{Note| NEW but not SYN is the only invalid TCP flag not covered by the INVALID state. The reason is because they are rarely malicious packets, and they should not just be dropped. Instead, we simply do not accept them, so they are rejected with a TCP RST by the next rule.}}<br />
<br />
# iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP<br />
# iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP<br />
<br />
We reject TCP connections with TCP RST packets and UDP streams with ICMP port unreachable messages if the ports are not opened. This imitates default Linux behavior (RFC compliant), and it allows the sender to quickly close the connection and clean up.<br />
<br />
# iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable<br />
# iptables -A INPUT -p tcp -j REJECT --reject-with tcp-rst<br />
<br />
For other protocols, we add a final rule to the INPUT chain to reject all remaining incoming traffic with icmp protocol unreachable messages. This imitates Linux's default behavior.<br />
<br />
# iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable<br />
<br />
=== Example iptables.rules file===<br />
<br />
Example of {{ic|iptables.rules}} file after running all the commands from above:<br />
<br />
{{hc|/etc/iptables/iptables.rules|<br />
# Generated by iptables-save v1.4.18 on Sun Mar 17 14:21:12 2013<br />
*filter<br />
:INPUT DROP [0:0]<br />
:FORWARD DROP [0:0]<br />
:OUTPUT ACCEPT [0:0]<br />
:TCP - [0:0]<br />
:UDP - [0:0]<br />
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
-A INPUT -i lo -j ACCEPT<br />
-A INPUT -m conntrack --ctstate INVALID -j DROP<br />
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT<br />
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP<br />
-A INPUT -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP<br />
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable<br />
-A INPUT -p tcp -j REJECT --reject-with tcp-reset<br />
-A INPUT -j REJECT --reject-with icmp-proto-unreachable<br />
COMMIT<br />
# Completed on Sun Mar 17 14:21:12 2013<br />
}}<br />
<br />
This file can be generated with:<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
and can be used to continue with the following sections. If you are setting up the firewall remotely via SSH, append the following rule to allow new SSH connections before continuing (adjust port as required):<br />
<br />
-A TCP -p tcp --dport 22 -j ACCEPT<br />
<br />
=== The TCP and UDP chains ===<br />
<br />
The TCP and UDP chains contain rules for accepting new incoming TCP connections and UDP streams to specific ports.<br />
<br />
{{Note|This is where you need to add rules to accept incoming connections, such as SSH, HTTP or other services that you want to access remotely.}}<br />
<br />
==== Opening ports to incoming connections ====<br />
<br />
To accept incoming TCP connections on port 80 for a web server:<br />
<br />
# iptables -A TCP -p tcp --dport 80 -j ACCEPT<br />
<br />
To accept incoming TCP connections on port 443 for a web server (HTTPS):<br />
<br />
# iptables -A TCP -p tcp --dport 443 -j ACCEPT<br />
<br />
To allow remote SSH connections (on port 22):<br />
<br />
# iptables -A TCP -p tcp --dport 22 -j ACCEPT<br />
<br />
To accept incoming UDP streams on port 53 for a DNS server:<br />
<br />
# iptables -A UDP -p udp --dport 53 -j ACCEPT<br />
<br />
See {{Ic|man iptables}} for more advanced rules, like matching multiple ports.<br />
<br />
==== Port knocking ====<br />
Port knocking is a method to externally open ports that, by default, the firewall keeps closed. It works by requiring connection attempts to a series of predefined closed ports. When the correct sequence of port "knocks" (connection attempts) is received, the firewall opens certain port(s) to allow a connection. See [[Port Knocking]] for more information.<br />
<br />
=== Protection against spoofing attacks ===<br />
<br />
{{Note|{{ic|rp_filter}} is currently set to {{ic|1}} by default in {{ic|/usr/lib/sysctl.d/50-default.conf}}, so the following step is not necessary.}}<br />
<br />
Blocking reserved local addresses incoming from the internet or local network is normally done through setting {{Ic|rp_filter}} (Reverse Path Filter) in sysctl to 1. To do so, add the following line to your {{Ic|/etc/sysctl.d/90-firewall.conf}} file (see [[sysctl]] for details) to enable source address verification which is built into Linux kernel itself. The verification by the kernel will handle spoofing better than individual iptables rules for each case.<br />
<br />
net.ipv4.conf.all.rp_filter=1<br />
<br />
This can be done with netfilter instead if statistics (and better logging) are desired:<br />
<br />
# iptables -t raw -I PREROUTING -m rpfilter --invert -j DROP<br />
<br />
{{Note|There is no reason to enable this in both places. The netfilter method is the modern choice and works with IPv6 too.}}<br />
<br />
For niche setups where asynchronous routing is used, the {{ic|1=rp_filter=2}} sysctl option needs to be used instead. Passing the {{ic|--loose}} switch to the {{ic|rpfilter}} module will accomplish the same thing with netfilter.<br />
<br />
=== "Hide" your computer ===<br />
<br />
If you are running a desktop machine, it might be a good idea to block some incoming requests.<br />
<br />
==== Block ping request ====<br />
<br />
A 'Ping' request is an ICMP packet sent to the destination address to ensure connectivity between the devices. If your network works well, you can safely block all ping requests. It is important to note that this ''does not'' actually hide your computer — any packet sent to you is rejected, so you will still show up in a simple nmap "ping scan" of an IP range.<br />
<br />
This is rudimentary "protection" and makes life difficult when debugging issues in the future. You should only do this for education purposes.<br />
<br />
To block echo requests, add the following line to your {{Ic|/etc/sysctl.d/90-firewall.conf}} file (see [[sysctl]] for details):<br />
<br />
net.ipv4.icmp_echo_ignore_all = 1<br />
<br />
{{Deletion|Pings take little effort for the kernel. Limiting rates itself is explained later in [[#Bruteforce_attacks]].|2=Talk:Simple_stateful_firewall#ICMP rate limiting considered harmful}}<br />
<br />
Rate-limiting is a better way to control possible abuse. This first method implements a global limit (ie, only X packets per minute for all source addresses):<br />
<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 30/min --limit-burst 8 -j ACCEPT<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -j DROP<br />
<br />
Or using the 'recent' module, you can impose a limit per source address:<br />
<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -m recent --name ping_limiter --set<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -m recent --name ping_limiter --update --hitcount 6 --seconds 4 -j DROP<br />
# iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT<br />
<br />
If you choose to use either the rate limiting or the source limiting rules the PING rule that already exists in the INPUT chain needs to be deleted. This can be done as shown below, or alternatively do not use it in the first place. <br />
# iptables -D INPUT -p icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT<br />
<br />
Next you need to decide where you wish to place the rate limiting or source limiting rules. If you place the rules below the RELATED,ESTABLISHED rule then you will be counting and limiting new ping connections, not each ping sent to your machine. If you place them before the RELATED,ESTABLISHED rule then these rules will count and limit each ping sent to your machine, not each ping connection made. <br />
<br />
More information is in the iptables man page, or reading the docs and examples on the webpage http://snowman.net/projects/ipt_recent/ {{Dead link|2015|04|08}}<br />
<br />
==== Tricking port scanners ====<br />
<br />
{{Note|This opens you up to a form of [[Wikipedia:Denial-of-service attack|DoS]]. An attack can send packets with spoofed IPs and get them blocked from connecting to your services.}}<br />
<br />
Port scans are used by attackers to identify open ports on your computer. This allows them to identify and fingerprint your running services and possibly launch exploits against them.<br />
<br />
The INVALID state rule will take care of every type of port scan except UDP, ACK and SYN scans (-sU, -sA and -sS in nmap respectively). <br />
<br />
''ACK scans'' are not used to identify open ports, but to identify ports filtered by a firewall. Due to the SYN check for all TCP connections with the state NEW, every single packet sent by an ACK scan will be correctly rejected by a TCP RST packet. Some firewalls drop these packets instead, and this allows an attacker to map out the firewall rules.<br />
<br />
The recent module can be used to trick the remaining two types of port scans. The recent module is used to add hosts to a "recent" list which can be used to fingerprint and stop certain types of attacks. Current recent lists can be viewed in {{Ic|/proc/net/xt_recent/}}.<br />
<br />
===== SYN scans =====<br />
<br />
In a SYN scan, the port scanner sends SYN packet to every port. Closed ports return a TCP RST packet, or get dropped by a strict firewall. Open ports return a SYN ACK packet regardless of the presence of a firewall.<br />
<br />
The recent module can be used to keep track of hosts with rejected connection attempts and return a TCP RST for any SYN packet they send to open ports as if the port was closed. If an open port is the first to be scanned, a SYN ACK will still be returned, so running applications such as ssh on non-standard ports is required for this to work consistently.<br />
<br />
First, insert a rule at the top of the TCP chain. This rule responds with a TCP RST to any host that got onto the TCP-PORTSCAN list in the past sixty seconds. The {{Ic|--update}} switch causes the recent list to be updated, meaning the 60 second counter is reset.<br />
<br />
# iptables -I TCP -p tcp -m recent --update --seconds 60 --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst<br />
<br />
Next, the rule for rejecting TCP packets need to be modified to add hosts with rejected packets to the TCP-PORTSCAN list.<br />
<br />
# iptables -D INPUT -p tcp -j REJECT --reject-with tcp-rst<br />
# iptables -A INPUT -p tcp -m recent --set --name TCP-PORTSCAN -j REJECT --reject-with tcp-rst<br />
<br />
===== UDP scans =====<br />
<br />
UDP port scans are similar to TCP SYN scans except that UDP is a "connectionless" protocol. There are no handshakes or acknowledgements. Instead, the scanner sends UDP packets to each UDP port. Closed ports should return ICMP port unreachable messages, and open ports do not return a response. Since UDP is not a "reliable" protocol, the scanner has no way of knowing if packets were lost, and has to do multiple checks for each port that does not return a response.<br />
<br />
The Linux kernel sends out ICMP port unreachable messages very slowly, so a full UDP scan against a Linux machine would take over 10 hours. However, common ports could still be identified, so applying the same countermeasures against UDP scans as SYN scans is a good idea.<br />
<br />
First, add a rule to reject packets from hosts on the UDP-PORTSCAN list to the top of the UDP chain.<br />
<br />
# iptables -I UDP -p udp -m recent --update --seconds 60 --name UDP-PORTSCAN -j REJECT --reject-with icmp-port-unreachable<br />
<br />
Next, modify the reject packets rule for UDP:<br />
<br />
# iptables -D INPUT -p udp -j REJECT --reject-with icmp-port-unreachable<br />
# iptables -A INPUT -p udp -m recent --set --name UDP-PORTSCAN -j REJECT --reject-with icmp-port-unreachable<br />
<br />
===== Restore the Final Rule =====<br />
<br />
If either or both of the portscanning tricks above were used the final default rule is no longer the last rule in the INPUT chain. It needs to be the last rule otherwise it will intercept the trick port scanner rules you just added and they will never be used. Simply delete the rule (-D), then add it once again using append (-A) which will place it at the end of the chain.<br />
<br />
# iptables -D INPUT -j REJECT --reject-with icmp-proto-unreachable<br />
# iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable<br />
<br />
=== Protection against other attacks ===<br />
<br />
See the [[sysctl#TCP/IP stack hardening]] for relevant kernel parameters.<br />
<br />
==== Bruteforce attacks ====<br />
<br />
Unfortunately, bruteforce attacks on services accessible via an external IP address are common. One reason for this is that the attacks are easy to do with the many tools available. Fortunately, there are a number of ways to protect the services against them. One is the use of appropriate {{ic|iptables}} rules which activate and blacklist an IP after a set number of packets attempt to initiate a connection. Another is the use of specialised daemons that monitor the logfiles for failed attempts and blacklist accordingly. <br />
{{Warning| Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. [[SSH keys]] provide an elegant solution to the problem of brute forcing without these problems.}}<br />
Two packages that ban IPs after too many password failures are [[Fail2ban]] or, for {{ic|sshd}} in particular, [[Sshguard]]. These two applications update iptables rules to reject future connections from blacklisted IP addresses.<br />
<br />
The following rules give an example configuration to mitigate SSH bruteforce attacks using {{ic|iptables}}.<br />
<br />
# iptables -N IN_SSH<br />
# iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH<br />
# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 3 --seconds 10 -j DROP<br />
# iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 4 --seconds 1800 -j DROP <br />
# iptables -A IN_SSH -m recent --name sshbf --set -j ACCEPT<br />
<br />
Most of the options should be self-explanatory, they allow for three connection packets in ten seconds. Further tries in that time will blacklist the IP. The next rule adds a quirk by allowing a total of four attempts in 30 minutes. This is done because some bruteforce attacks are actually performed slow and not in a burst of attempts. The rules employ a number of additional options. To read more about them, check the original reference for this example: [http://compilefailure.blogspot.com/2011/04/better-ssh-brute-force-prevention-with.html compilefailure.blogspot.com]<br />
<br />
Using the above rules, now ensure that:<br />
# iptables -A INPUT -p tcp --dport ssh -m conntrack --ctstate NEW -j IN_SSH<br />
is in an appropriate position in the iptables.rules file. <br />
<br />
This arrangement works for the IN_SSH rule if you followed this entire wiki so far:<br />
*<br />
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT<br />
-A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j IN_SSH<br />
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP<br />
*<br />
<br />
The above rules can, of course, be used to protect any service, though protecting the SSH daemon is probably the most often required one.<br />
<br />
{{Tip|For self-testing the rules after setup, the actual blacklist happening can slow the test making it difficult to fine-tune parameters. One can watch the incoming attempts via {{ic|cat /proc/net/xt_recent/sshbf}}. To unblock the own IP during testing, root is needed {{ic|# echo / > /proc/net/xt_recent/sshbf}}}}<br />
<br />
=== Saving the rules ===<br />
<br />
The ruleset is now finished and should be saved to your hard drive so that it can be loaded on every boot.<br />
<br />
The systemd unit file points to the location where the rule configuration will be saved:<br />
<br />
iptables=/etc/iptables/iptables.rules<br />
ip6tables=/etc/iptables/ip6tables.rules<br />
<br />
Save the rules with this command:<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
and make sure your rules are loaded on boot enabling the '''iptables''' [[daemon]].<br />
<br />
Check that the rules load correctly using:<br />
<br />
# systemctl start iptables.service && systemctl status iptables.service<br />
<br />
=== IPv6 ===<br />
<br />
If you do not use IPv6 (most ISPs do not support it), you should [[Disabling IPv6|disable it]]. <br />
<br />
Otherwise, you should enable the firewall rules for IPv6. After copying the IPv4 rules as a base: <br />
<br />
# cp /etc/iptables/iptables.rules /etc/iptables/ip6tables.rules<br />
the first step is to change IPs referenced in the rules from IPv4 format to IPv6 format. <br />
<br />
Next, a few of the rules (built as example in this article for IPv4) have to be adapted. IPv6 obtained a new ICMPv6 protocol, replacing ICMP. Hence, the reject error return codes {{ic|--reject-with icmp-port-unreachable}} and {{ic|--reject-with icmp-proto-unreachable}} have to be converted to ICMPv6 codes. <br />
<br />
The available ICMPv6 error codes are listed in [https://tools.ietf.org/html/rfc4443#section-3.1 RFC 4443], which specifies connection attempts blocked by a firewall rule should use {{ic|--reject-with icmp6-adm-prohibited}}. Doing so will basically inform the remote system that the connection was rejected by a firewall, rather than a listening service. <br />
<br />
If it is preferred not to explicitly inform about the existence of a firewall filter, the packet may also be rejected without the message: <br />
<br />
-A INPUT -j REJECT<br />
<br />
The above will reject with the default return error of {{ic|--reject-with icmp6-port-unreachable}}. You should note though, that identifying a firewall is a basic feature of port scanning applications and most will identify it regardless. <br />
<br />
In the next step make sure the protocol and extension are changed to be IPv6 appropriate for the rule regarding all new incoming ICMP echo requests (pings):<br />
<br />
# ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -m conntrack --ctstate NEW -j ACCEPT<br />
<br />
Netfilter conntrack does not appear to track ICMPv6 Neighbor Discovery Protocol (the IPv6 equivalent of ARP), so we need to allow ICMPv6 traffic regardless of state for all directly attached subnets. The following should be inserted after dropping {{ic|--ctstate INVALID}}, but before any other DROP or REJECT targets, along with a corresponding line for each directly attached subnet:<br />
<br />
# ip6tables -A INPUT -s fe80::/10 -p icmpv6 -j ACCEPT<br />
<br />
Since there is no kernel reverse path filter for IPv6, you may want to enable one in ''ip6tables'' with the following:<br />
<br />
# ip6tables -t raw -A PREROUTING -m rpfilter -j ACCEPT<br />
# ip6tables -t raw -A PREROUTING -j DROP<br />
<br />
After the configuration is done, [[enable]] the '''ip6tables''' service, it is meant to run in parallel to ''iptables''.<br />
<br />
== Setting up a NAT gateway ==<br />
<br />
This section of the guide deals with NAT gateways. It is assumed that you already read the [[#Firewall for a single machine|first part of the guide]] and set up the '''INPUT''', '''OUTPUT''', '''TCP''' and '''UDP''' chains like described above. All rules so far have been created in the '''filter''' table. In this section, we will also have to use the '''nat''' table.<br />
<br />
=== Setting up the filter table ===<br />
<br />
==== Creating necessary chains ====<br />
<br />
In our setup, we will use another two chains in the filter table, the '''fw-interfaces''' and '''fw-open''' chains. Create them with the commands<br />
<br />
# iptables -N fw-interfaces<br />
# iptables -N fw-open<br />
<br />
==== Setting up the FORWARD chain ====<br />
<br />
Setting up the '''FORWARD''' chain is similar to the '''INPUT''' chain in the first section.<br />
<br />
Now we set up a rule with the '''conntrack''' match, identical to the one in the '''INPUT''' chain:<br />
<br />
# iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT<br />
<br />
The next step is to enable forwarding for trusted interfaces and to make all packets pass the '''fw-open''' chain.<br />
<br />
# iptables -A FORWARD -j fw-interfaces <br />
# iptables -A FORWARD -j fw-open <br />
<br />
The remaining packets are denied with an '''ICMP''' message:<br />
<br />
# iptables -A FORWARD -j REJECT --reject-with icmp-host-unreachable<br />
# iptables -P FORWARD DROP<br />
<br />
==== Setting up the fw-interfaces and fw-open chains ====<br />
<br />
The meaning of the '''fw-interfaces''' and '''fw-open''' chains is explained later, when we deal with the '''POSTROUTING''' and '''PREROUTING''' chains in the '''nat''' table, respectively.<br />
<br />
=== Setting up the nat table ===<br />
<br />
All over this section, we assume that the outgoing interface (the one with the public internet IP) is '''ppp0'''. Keep in mind that you have to change the name in all following rules if your outgoing interface has another name.<br />
<br />
==== Setting up the POSTROUTING chain ====<br />
<br />
Now, we have to define who is allowed to connect to the internet. Let's assume we have the subnet '''192.168.0.0/24''' (which means all addresses that are of the form 192.168.0.*) on '''eth0'''. We first need to accept the machines on this interface in the FORWARD table, that is why we created the '''fw-interfaces''' chain above:<br />
<br />
# iptables -A fw-interfaces -i eth0 -j ACCEPT<br />
<br />
Now, we have to alter all outgoing packets so that they have our public IP address as the source address, instead of the local LAN address. To do this, we use the '''MASQUERADE''' target:<br />
<br />
# iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o ppp0 -j MASQUERADE<br />
<br />
Do not forget the '''-o ppp0''' parameter above. If you omit it, your network will be screwed up.<br />
<br />
Let's assume we have another subnet, '''10.3.0.0/16''' (which means all addresses 10.3.*.*), on the interface '''eth1'''. We add the same rules as above again:<br />
<br />
# iptables -A fw-interfaces -i eth1 -j ACCEPT<br />
# iptables -t nat -A POSTROUTING -s 10.3.0.0/16 -o ppp0 -j MASQUERADE<br />
<br />
The last step is to enable IP Forwarding (if it is not already enabled):<br />
<br />
# echo 1 > /proc/sys/net/ipv4/ip_forward<br />
<br />
Then edit the relevant line in {{ic|/etc/sysctl.d/90-firewall.conf}} so it persists through reboot (see [[sysctl]] for details):<br />
<br />
net.ipv4.ip_forward = 1<br />
<br />
Machines from these subnets can now use your new NAT machine as their gateway. Note that you may want to set up a DNS and DHCP server like '''dnsmasq''' or a combination of '''bind''' and '''dhcpd''' to simplify network settings DNS resolution on the client machines. This is not the topic of this guide.<br />
<br />
==== Setting up the PREROUTING chain ====<br />
<br />
Sometimes, we want to change the address of an incoming packet from the gateway to a LAN machine. To do this, we use the '''fw-open''' chain defined above, as well as the '''PREROUTING''' chain in the '''nat''' table in the following two simple examples. <br />
<br />
First, we want to change all incoming SSH packets (port 22) to the ssh server of the machine '''192.168.0.5''':<br />
<br />
# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 22 -j DNAT --to 192.168.0.5<br />
# iptables -A fw-open -d 192.168.0.5 -p tcp --dport 22 -j ACCEPT<br />
<br />
The second example will show you how to change packets to a different port than the incoming port. We want to change any incoming connection on port '''8000''' to our web server on '''192.168.0.6''', port '''80''':<br />
<br />
# iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 8000 -j DNAT --to 192.168.0.6:80<br />
# iptables -A fw-open -d 192.168.0.6 -p tcp --dport 80 -j ACCEPT<br />
<br />
The same setup also works with udp packets.<br />
<br />
=== Saving the rules ===<br />
<br />
Save the rules:<br />
<br />
# iptables-save > /etc/iptables/iptables.rules<br />
<br />
and make sure your rules are loaded when you boot enabling the '''iptables''' [[daemon]].<br />
<br />
== See Also ==<br />
<br />
*[[Internet sharing]]<br />
*[[Router]]<br />
*[[Firewalls]]<br />
*[[Uncomplicated Firewall]]<br />
*[http://www.webhostingtalk.com/showthread.php?t=456571 Methods to block SSH attacks]<br />
*[http://www.ducea.com/2006/06/28/using-iptables-to-block-brute-force-attacks/ Using iptables to block brute force attacks]<br />
*[http://linuxconfig.org/collection-of-basic-linux-firewall-iptables-rules 20 Iptables Examples For New SysAdmins]<br />
*[http://www.thegeekstuff.com/2011/06/iptables-rules-examples/ 25 Most Frequently Used Linux IPTables Rules Examples]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=41272Bug reporting guidelines2008-05-14T14:07:59Z<p>Chicha: /* Looking for duplicates */ Add link to recently closed bugs</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible ways to '''help the community'''. However, if this is done badly it can turn out being a pain instead of being useful - when too many bugs are badly reported the community and the developers lose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' anyone wanting to help the community efficiently by '''reporting''' or '''hunting bugs'''.<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most useful part of the job'''. Unfortunately few people take the time to do this work, they prefer others to do it for them...<br />
<br />
However, preparing a good bug report is not difficult and can be achieved by anyone (beginner or developer).<br />
The following steps will help you in preparing your bug report or feature request. They should be followed in the order they come in.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually referred to as the community which developed a piece of software packaged by Archlinux. It is the team which is responsible for creating, publishing and documenting that software. Archlinux can be referred to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates:<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum]: most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System]: It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exist if people looked for duplicates before reporting bugs ... Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed recently. That is why it is important to '''[http://bugs.archlinux.org/index.php?string=&project=1&status%5B%5D=closed&closedfrom=-1+week look for recently closed bugs as well as new bugs]'''.<br />
<br />
*[http://www.google.com Google] or your favorite search engine: Search using your software name, version and a relevant part of the error message that you got, if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker: Look directly at the source of your problem! Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''': The Free Software community is wide, and people other than archers may have a good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums], [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other sources of useful information feel free to add them here.<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not work as intended by the developer.<br />
*A '''feature''' is something a software does or would do if somebody coded it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If Arch is not responsible for a bug, the problem will not get solved by reporting the bug to Arch'''.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but you will also help other people in the Free Software Community.<br />
<br />
Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post them in Arch bug tracker so that both Arch developers and users get aware of it.<br />
<br />
So what is Archlinux responsible for?<br />
<br />
*'''Arch Linux Projects''' : Pacman, AUR, Initscripts, Arch Websites. If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the URL.<br />
<br />
*'''Packaging''' : Packaging basically consists of fetching the source code from upstream, compiling it with relevant options, making sure that the package will be installed correctly on an Arch system and the main functionality of a package works. Packaging at Arch does not consist of adding new functionality or patches for existing bugs. This is the job of the upstream developer.<br />
<br />
If a bug/feature is not under Arch's responsibility report it upstream. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a piece of software to do, which is not implemented by the upstream developers. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' but not used in the package then this is a bug.<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather useful information==<br />
<br />
Here is a list of useful information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know exactly what information to provide then wait for a bug hunter to ask you for it ...<br />
<br />
*Version of the kernel used if you are having hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it stopped working.<br />
<br />
*Indicate your '''hardware brand''' when you are having hardware related problems<br />
<br />
*Add '''relevant log information''' when any is available. This can be obtained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file. When running an application in a terminal make sure relevant information will be displayed in '''english''' so that many people can understand it. This can be done by using ''export LC_ALL="c"''. Example with a software named ''foobar'' from which you would like to have relevant information at runtime and provided that foobar has a --verbose option :<br />
someone@somecomputer # export LC_ALL="C"<br />
someone@somecomputer # foobar --verbose<br />
This will affect only the current terminal and will stop taking effect when the terminal is closed.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack trace'''. It is a list of calls made by program during its execution, and helps in finding part of program where the bug is located, especially if bug involves the program crashing. You can obtain a stack trace using gdb (The GNU Debugger) by running the program with "gdb name_of_program" and then typing "run" at the gdb prompt. When the program crashes, type "bt" at the gdb prompt to obtain the stack trace and then "quit" to exit gdb.<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to create an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as creating an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving the email address you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
Once you have determined your feature or bug is related to Arch and not an upstream issue, you will need to file your problem in the correct place:<br />
<br />
*'''Arch Linux'''- for packages in ''testing'', ''core'', ''extra'', or ''unstable''. It is also a place for documentation, websites (except AUR), and security issues.<br />
<br />
*'''Arch User Repository (AUR)'''- for the website and the tools used to manage packages in ''community'' and ''unsupported''. It is not a place for software in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages'''- for packages in ''community''. It is not a place for packages in ''unsupported''.<br />
<br />
*'''Pacman'''- for ''pacman'' and the official scripts and tools associated with it. This includes things like makepkg and abs; it does not include community-developed packages such as [[yaourt]].<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help to solve the bug faster. It will only make truely critical problems less visible and probably make the developer assigned to your bug a bit less open to fixing it.<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical'''- System crash, severe boot failure that is likely to affect more than just you, or an exploitable security issue in either a core or outward-facing service package.<br />
*'''High'''- The main functionality of the application does not work, less critical security issues, etc.<br />
*'''Medium'''- A non-essential functionality does not work, UNIX standards not respected, etc.<br />
*'''Low'''- An optional functionality (plugin or compilation activated) does not work.<br />
*'''Very Low'''- Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release.<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult parts of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_useful_information|Gather useful information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant pieces of information are, do not be shy : '''it is better to give more information than needed than not enough'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunately after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
=Following up on Bugs=<br />
<br />
'''Do not think the work is done once you have reported a bug'''!<br />
<br />
Developers or other users will probably ask you for more details and give you some potential fixes to try. Without continued feedback, bugs cannot be closed and the end result is both angry users and developers.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates to the developers how many people are impacted by the bug. However, this is not a very effective way of getting the bug solved. Much more important would be posting any additional information you know about the bug if you were not the original reporter.<br />
<br />
'''Watching''' a bug is important- you will receive an email when new comments are added or the bug status has changed. If you opened a bug verify that the watching attribute is set to yes so you will be notified know when people ask you for more information or ask you to try a fix.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
People will take the time to look at your bug report and will try to help you. You need to continue to help them resolve your bug. Not answering to their questions will keep your bug unresolved and likely hamper enthusiasm to fix it.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
Developers or bug hunters will close your bug if you do not answer questions after a few weeks or a month.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report a bug but do not notify when they have solved it on their own, leaving people searching for a solution that has already been found. Please request a closure if you found a solution and give the solution in the bug report comments.<br />
<br />
<br />
==More about bug status==<br />
<br />
During its life a bug goes through several states :<br />
<br />
* '''Unconfirmed''' : This is the default state. You have just reported it and nobody managed to reproduce the problem or confirmed that it is actually a bug.<br />
<br />
* '''New''' : The bug is confirmed but it has not been assigned to the developer responsible for the related software. It is usually the case when more investigation is needed to determine which software is responsible for the bug.<br />
<br />
* '''Assigned''' : The bug has been assigned to a developer responsible for the software involved in the bug. It does not mean that the developer will be the one who will fix the bug. It does not even mean that the developer will work on a solution. It just mean that the developer will take care of the life cycle of the bug, including reviewing patches if any, releasing a fix and closing the bug when required. There is no point at contacting a developer directly to have a bug fixed more quickly, he/she will certainly not like it ...<br />
<br />
* '''Researching''' : Somebody is looking for a solution. This status is '''rarelly used at Arch''' and it is better this way. The ''researching'' status could make people believe they do not need to get interested in the bug report. But usually we need more than one person to fix a bug : having several experienced people on a bug help a lot.<br />
<br />
* '''Waiting on customer''' and '''Requires testing''' : The one who reported a bug is asked to provide more information or to try a proposed solution, but he/she did not give a feedback yet. Those status are '''rarelly used at Arch''' and should be used more often. However this is important that you '''watch the bug''' (see the [[Reporting_Bug_Guidelines#Voting_and_Watching|voting and watching section]]) as developers or bug hunters usually ask questions in the comments.<br />
<br />
* '''A task closure has been requested''' : this is not exactly a status, but you may found some bug reports with such a notification. This indicates that somebody requested a closure for the bug. A reason is added to the request most of the time. It is upon the assignee developer to decided whether he/she will accept the closure or not.<br />
<br />
* '''Closed''' : Either this is not a valid bug (see [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]]) or a solution has been found and released.<br />
<br />
<br />
Some people (developers, TUs ...) are responsible for dispatching the bugs and change their status.<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=41271Bug reporting guidelines2008-05-14T13:55:17Z<p>Chicha: /* Looking for duplicates */ Search also recently closed bugs</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible ways to '''help the community'''. However, if this is done badly it can turn out being a pain instead of being useful - when too many bugs are badly reported the community and the developers lose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' anyone wanting to help the community efficiently by '''reporting''' or '''hunting bugs'''.<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most useful part of the job'''. Unfortunately few people take the time to do this work, they prefer others to do it for them...<br />
<br />
However, preparing a good bug report is not difficult and can be achieved by anyone (beginner or developer).<br />
The following steps will help you in preparing your bug report or feature request. They should be followed in the order they come in.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually referred to as the community which developed a piece of software packaged by Archlinux. It is the team which is responsible for creating, publishing and documenting that software. Archlinux can be referred to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates:<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum]: most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System]: It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exist if people looked for duplicates before reporting bugs ... Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed recently. That is why it is important to '''look for recently closed bugs as well as new bugs'''.<br />
<br />
*[http://www.google.com Google] or your favorite search engine: Search using your software name, version and a relevant part of the error message that you got, if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker: Look directly at the source of your problem! Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''': The Free Software community is wide, and people other than archers may have a good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums], [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other sources of useful information feel free to add them here.<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not work as intended by the developer.<br />
*A '''feature''' is something a software does or would do if somebody coded it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If Arch is not responsible for a bug, the problem will not get solved by reporting the bug to Arch'''.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but you will also help other people in the Free Software Community.<br />
<br />
Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post them in Arch bug tracker so that both Arch developers and users get aware of it.<br />
<br />
So what is Archlinux responsible for?<br />
<br />
*'''Arch Linux Projects''' : Pacman, AUR, Initscripts, Arch Websites. If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the URL.<br />
<br />
*'''Packaging''' : Packaging basically consists of fetching the source code from upstream, compiling it with relevant options, making sure that the package will be installed correctly on an Arch system and the main functionality of a package works. Packaging at Arch does not consist of adding new functionality or patches for existing bugs. This is the job of the upstream developer.<br />
<br />
If a bug/feature is not under Arch's responsibility report it upstream. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a piece of software to do, which is not implemented by the upstream developers. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' but not used in the package then this is a bug.<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather useful information==<br />
<br />
Here is a list of useful information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know exactly what information to provide then wait for a bug hunter to ask you for it ...<br />
<br />
*Version of the kernel used if you are having hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it stopped working.<br />
<br />
*Indicate your '''hardware brand''' when you are having hardware related problems<br />
<br />
*Add '''relevant log information''' when any is available. This can be obtained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file. When running an application in a terminal make sure relevant information will be displayed in '''english''' so that many people can understand it. This can be done by using ''export LC_ALL="c"''. Example with a software named ''foobar'' from which you would like to have relevant information at runtime and provided that foobar has a --verbose option :<br />
someone@somecomputer # export LC_ALL="C"<br />
someone@somecomputer # foobar --verbose<br />
This will affect only the current terminal and will stop taking effect when the terminal is closed.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack trace'''. It is a list of calls made by program during its execution, and helps in finding part of program where the bug is located, especially if bug involves the program crashing. You can obtain a stack trace using gdb (The GNU Debugger) by running the program with "gdb name_of_program" and then typing "run" at the gdb prompt. When the program crashes, type "bt" at the gdb prompt to obtain the stack trace and then "quit" to exit gdb.<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to create an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as creating an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving the email address you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
Once you have determined your feature or bug is related to Arch and not an upstream issue, you will need to file your problem in the correct place:<br />
<br />
*'''Arch Linux'''- for packages in ''testing'', ''core'', ''extra'', or ''unstable''. It is also a place for documentation, websites (except AUR), and security issues.<br />
<br />
*'''Arch User Repository (AUR)'''- for the website and the tools used to manage packages in ''community'' and ''unsupported''. It is not a place for software in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages'''- for packages in ''community''. It is not a place for packages in ''unsupported''.<br />
<br />
*'''Pacman'''- for ''pacman'' and the official scripts and tools associated with it. This includes things like makepkg and abs; it does not include community-developed packages such as [[yaourt]].<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help to solve the bug faster. It will only make truely critical problems less visible and probably make the developer assigned to your bug a bit less open to fixing it.<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical'''- System crash, severe boot failure that is likely to affect more than just you, or an exploitable security issue in either a core or outward-facing service package.<br />
*'''High'''- The main functionality of the application does not work, less critical security issues, etc.<br />
*'''Medium'''- A non-essential functionality does not work, UNIX standards not respected, etc.<br />
*'''Low'''- An optional functionality (plugin or compilation activated) does not work.<br />
*'''Very Low'''- Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release.<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult parts of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_useful_information|Gather useful information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant pieces of information are, do not be shy : '''it is better to give more information than needed than not enough'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunately after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
=Following up on Bugs=<br />
<br />
'''Do not think the work is done once you have reported a bug'''!<br />
<br />
Developers or other users will probably ask you for more details and give you some potential fixes to try. Without continued feedback, bugs cannot be closed and the end result is both angry users and developers.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates to the developers how many people are impacted by the bug. However, this is not a very effective way of getting the bug solved. Much more important would be posting any additional information you know about the bug if you were not the original reporter.<br />
<br />
'''Watching''' a bug is important- you will receive an email when new comments are added or the bug status has changed. If you opened a bug verify that the watching attribute is set to yes so you will be notified know when people ask you for more information or ask you to try a fix.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
People will take the time to look at your bug report and will try to help you. You need to continue to help them resolve your bug. Not answering to their questions will keep your bug unresolved and likely hamper enthusiasm to fix it.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
Developers or bug hunters will close your bug if you do not answer questions after a few weeks or a month.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report a bug but do not notify when they have solved it on their own, leaving people searching for a solution that has already been found. Please request a closure if you found a solution and give the solution in the bug report comments.<br />
<br />
<br />
==More about bug status==<br />
<br />
During its life a bug goes through several states :<br />
<br />
* '''Unconfirmed''' : This is the default state. You have just reported it and nobody managed to reproduce the problem or confirmed that it is actually a bug.<br />
<br />
* '''New''' : The bug is confirmed but it has not been assigned to the developer responsible for the related software. It is usually the case when more investigation is needed to determine which software is responsible for the bug.<br />
<br />
* '''Assigned''' : The bug has been assigned to a developer responsible for the software involved in the bug. It does not mean that the developer will be the one who will fix the bug. It does not even mean that the developer will work on a solution. It just mean that the developer will take care of the life cycle of the bug, including reviewing patches if any, releasing a fix and closing the bug when required. There is no point at contacting a developer directly to have a bug fixed more quickly, he/she will certainly not like it ...<br />
<br />
* '''Researching''' : Somebody is looking for a solution. This status is '''rarelly used at Arch''' and it is better this way. The ''researching'' status could make people believe they do not need to get interested in the bug report. But usually we need more than one person to fix a bug : having several experienced people on a bug help a lot.<br />
<br />
* '''Waiting on customer''' and '''Requires testing''' : The one who reported a bug is asked to provide more information or to try a proposed solution, but he/she did not give a feedback yet. Those status are '''rarelly used at Arch''' and should be used more often. However this is important that you '''watch the bug''' (see the [[Reporting_Bug_Guidelines#Voting_and_Watching|voting and watching section]]) as developers or bug hunters usually ask questions in the comments.<br />
<br />
* '''A task closure has been requested''' : this is not exactly a status, but you may found some bug reports with such a notification. This indicates that somebody requested a closure for the bug. A reason is added to the request most of the time. It is upon the assignee developer to decided whether he/she will accept the closure or not.<br />
<br />
* '''Closed''' : Either this is not a valid bug (see [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]]) or a solution has been found and released.<br />
<br />
<br />
Some people (developers, TUs ...) are responsible for dispatching the bugs and change their status.<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=41269Bug reporting guidelines2008-05-14T13:42:57Z<p>Chicha: /* More about bug status */ Write this section</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible ways to '''help the community'''. However, if this is done badly it can turn out being a pain instead of being useful - when too many bugs are badly reported the community and the developers lose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' anyone wanting to help the community efficiently by '''reporting''' or '''hunting bugs'''.<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most useful part of the job'''. Unfortunately few people take the time to do this work, they prefer others to do it for them...<br />
<br />
However, preparing a good bug report is not difficult and can be achieved by anyone (beginner or developer).<br />
The following steps will help you in preparing your bug report or feature request. They should be followed in the order they come in.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually referred to as the community which developed a piece of software packaged by Archlinux. It is the team which is responsible for creating, publishing and documenting that software. Archlinux can be referred to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates:<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum]: most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System]: It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exist if people looked for duplicates before reporting bugs ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine: Search using your software name, version and a relevant part of the error message that you got, if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker: Look directly at the source of your problem! Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''': The Free Software community is wide, and people other than archers may have a good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums], [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other sources of useful information feel free to add them here.<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not work as intended by the developer.<br />
*A '''feature''' is something a software does or would do if somebody coded it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If Arch is not responsible for a bug, the problem will not get solved by reporting the bug to Arch'''.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but you will also help other people in the Free Software Community.<br />
<br />
Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post them in Arch bug tracker so that both Arch developers and users get aware of it.<br />
<br />
So what is Archlinux responsible for?<br />
<br />
*'''Arch Linux Projects''' : Pacman, AUR, Initscripts, Arch Websites. If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the URL.<br />
<br />
*'''Packaging''' : Packaging basically consists of fetching the source code from upstream, compiling it with relevant options, making sure that the package will be installed correctly on an Arch system and the main functionality of a package works. Packaging at Arch does not consist of adding new functionality or patches for existing bugs. This is the job of the upstream developer.<br />
<br />
If a bug/feature is not under Arch's responsibility report it upstream. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a piece of software to do, which is not implemented by the upstream developers. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' but not used in the package then this is a bug.<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather useful information==<br />
<br />
Here is a list of useful information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know exactly what information to provide then wait for a bug hunter to ask you for it ...<br />
<br />
*Version of the kernel used if you are having hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it stopped working.<br />
<br />
*Indicate your '''hardware brand''' when you are having hardware related problems<br />
<br />
*Add '''relevant log information''' when any is available. This can be obtained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file. When running an application in a terminal make sure relevant information will be displayed in '''english''' so that many people can understand it. This can be done by using ''export LC_ALL="c"''. Example with a software named ''foobar'' from which you would like to have relevant information at runtime and provided that foobar has a --verbose option :<br />
someone@somecomputer # export LC_ALL="C"<br />
someone@somecomputer # foobar --verbose<br />
This will affect only the current terminal and will stop taking effect when the terminal is closed.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack trace'''. It is a list of calls made by program during its execution, and helps in finding part of program where the bug is located, especially if bug involves the program crashing. You can obtain a stack trace using gdb (The GNU Debugger) by running the program with "gdb name_of_program" and then typing "run" at the gdb prompt. When the program crashes, type "bt" at the gdb prompt to obtain the stack trace and then "quit" to exit gdb.<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to create an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as creating an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving the email address you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
Once you have determined your feature or bug is related to Arch and not an upstream issue, you will need to file your problem in the correct place:<br />
<br />
*'''Arch Linux'''- for packages in ''testing'', ''core'', ''extra'', or ''unstable''. It is also a place for documentation, websites (except AUR), and security issues.<br />
<br />
*'''Arch User Repository (AUR)'''- for the website and the tools used to manage packages in ''community'' and ''unsupported''. It is not a place for software in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages'''- for packages in ''community''. It is not a place for packages in ''unsupported''.<br />
<br />
*'''Pacman'''- for ''pacman'' and the official scripts and tools associated with it. This includes things like makepkg and abs; it does not include community-developed packages such as [[yaourt]].<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help to solve the bug faster. It will only make truely critical problems less visible and probably make the developer assigned to your bug a bit less open to fixing it.<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical'''- System crash, severe boot failure that is likely to affect more than just you, or an exploitable security issue in either a core or outward-facing service package.<br />
*'''High'''- The main functionality of the application does not work, less critical security issues, etc.<br />
*'''Medium'''- A non-essential functionality does not work, UNIX standards not respected, etc.<br />
*'''Low'''- An optional functionality (plugin or compilation activated) does not work.<br />
*'''Very Low'''- Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release.<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult parts of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_useful_information|Gather useful information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant pieces of information are, do not be shy : '''it is better to give more information than needed than not enough'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunately after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
=Following up on Bugs=<br />
<br />
'''Do not think the work is done once you have reported a bug'''!<br />
<br />
Developers or other users will probably ask you for more details and give you some potential fixes to try. Without continued feedback, bugs cannot be closed and the end result is both angry users and developers.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates to the developers how many people are impacted by the bug. However, this is not a very effective way of getting the bug solved. Much more important would be posting any additional information you know about the bug if you were not the original reporter.<br />
<br />
'''Watching''' a bug is important- you will receive an email when new comments are added or the bug status has changed. If you opened a bug verify that the watching attribute is set to yes so you will be notified know when people ask you for more information or ask you to try a fix.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
People will take the time to look at your bug report and will try to help you. You need to continue to help them resolve your bug. Not answering to their questions will keep your bug unresolved and likely hamper enthusiasm to fix it.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
Developers or bug hunters will close your bug if you do not answer questions after a few weeks or a month.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report a bug but do not notify when they have solved it on their own, leaving people searching for a solution that has already been found. Please request a closure if you found a solution and give the solution in the bug report comments.<br />
<br />
<br />
==More about bug status==<br />
<br />
During its life a bug goes through several states :<br />
<br />
* '''Unconfirmed''' : This is the default state. You have just reported it and nobody managed to reproduce the problem or confirmed that it is actually a bug.<br />
<br />
* '''New''' : The bug is confirmed but it has not been assigned to the developer responsible for the related software. It is usually the case when more investigation is needed to determine which software is responsible for the bug.<br />
<br />
* '''Assigned''' : The bug has been assigned to a developer responsible for the software involved in the bug. It does not mean that the developer will be the one who will fix the bug. It does not even mean that the developer will work on a solution. It just mean that the developer will take care of the life cycle of the bug, including reviewing patches if any, releasing a fix and closing the bug when required. There is no point at contacting a developer directly to have a bug fixed more quickly, he/she will certainly not like it ...<br />
<br />
* '''Researching''' : Somebody is looking for a solution. This status is '''rarelly used at Arch''' and it is better this way. The ''researching'' status could make people believe they do not need to get interested in the bug report. But usually we need more than one person to fix a bug : having several experienced people on a bug help a lot.<br />
<br />
* '''Waiting on customer''' and '''Requires testing''' : The one who reported a bug is asked to provide more information or to try a proposed solution, but he/she did not give a feedback yet. Those status are '''rarelly used at Arch''' and should be used more often. However this is important that you '''watch the bug''' (see the [[Reporting_Bug_Guidelines#Voting_and_Watching|voting and watching section]]) as developers or bug hunters usually ask questions in the comments.<br />
<br />
* '''A task closure has been requested''' : this is not exactly a status, but you may found some bug reports with such a notification. This indicates that somebody requested a closure for the bug. A reason is added to the request most of the time. It is upon the assignee developer to decided whether he/she will accept the closure or not.<br />
<br />
* '''Closed''' : Either this is not a valid bug (see [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]]) or a solution has been found and released.<br />
<br />
<br />
Some people (developers, TUs ...) are responsible for dispatching the bugs and change their status.<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=41268Bug reporting guidelines2008-05-14T12:59:39Z<p>Chicha: /* Gather useful information */ Add LC_ALL="C" trick to have verbose information in english</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible ways to '''help the community'''. However, if this is done badly it can turn out being a pain instead of being useful - when too many bugs are badly reported the community and the developers lose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' anyone wanting to help the community efficiently by '''reporting''' or '''hunting bugs'''.<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most useful part of the job'''. Unfortunately few people take the time to do this work, they prefer others to do it for them...<br />
<br />
However, preparing a good bug report is not difficult and can be achieved by anyone (beginner or developer).<br />
The following steps will help you in preparing your bug report or feature request. They should be followed in the order they come in.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually referred to as the community which developed a piece of software packaged by Archlinux. It is the team which is responsible for creating, publishing and documenting that software. Archlinux can be referred to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates:<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum]: most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System]: It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exist if people looked for duplicates before reporting bugs ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine: Search using your software name, version and a relevant part of the error message that you got, if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker: Look directly at the source of your problem! Some bugs may have already been reported to the software developers, and even some bugs may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''': The Free Software community is wide, and people other than archers may have a good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums], [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other sources of useful information feel free to add them here.<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not work as intended by the developer.<br />
*A '''feature''' is something a software does or would do if somebody coded it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If Arch is not responsible for a bug, the problem will not get solved by reporting the bug to Arch'''.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but you will also help other people in the Free Software Community.<br />
<br />
Once you have reported a bug upstream or have found other relevant information from upstream, it might be helpful to post them in Arch bug tracker so that both Arch developers and users get aware of it.<br />
<br />
So what is Archlinux responsible for?<br />
<br />
*'''Arch Linux Projects''' : Pacman, AUR, Initscripts, Arch Websites. If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the URL.<br />
<br />
*'''Packaging''' : Packaging basically consists of fetching the source code from upstream, compiling it with relevant options, making sure that the package will be installed correctly on an Arch system and the main functionality of a package works. Packaging at Arch does not consist of adding new functionality or patches for existing bugs. This is the job of the upstream developer.<br />
<br />
If a bug/feature is not under Arch's responsibility report it upstream. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a piece of software to do, which is not implemented by the upstream developers. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuff. This is not a bug if such files are not included in the source tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' but not used in the package then this is a bug.<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or some other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather useful information==<br />
<br />
Here is a list of useful information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know exactly what information to provide then wait for a bug hunter to ask you for it ...<br />
<br />
*Version of the kernel used if you are having hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it stopped working.<br />
<br />
*Indicate your '''hardware brand''' when you are having hardware related problems<br />
<br />
*Add '''relevant log information''' when any is available. This can be obtained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file. When running an application in a terminal make sure relevant information will be displayed in '''english''' so that many people can understand it. This can be done by using ''export LC_ALL="c"''. Example with a software named ''foobar'' from which you would like to have relevant information at runtime and provided that foobar has a --verbose option :<br />
someone@somecomputer # export LC_ALL="C"<br />
someone@somecomputer # foobar --verbose<br />
This will affect only the current terminal and will stop taking effect when the terminal is closed.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack trace'''. It is a list of calls made by program during its execution, and helps in finding part of program where the bug is located, especially if bug involves the program crashing. You can obtain a stack trace using gdb (The GNU Debugger) by running the program with "gdb name_of_program" and then typing "run" at the gdb prompt. When the program crashes, type "bt" at the gdb prompt to obtain the stack trace and then "quit" to exit gdb.<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to create an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as creating an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving the email address you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
Once you have determined your feature or bug is related to Arch and not an upstream issue, you will need to file your problem in the correct place:<br />
<br />
*'''Arch Linux'''- for packages in ''testing'', ''core'', ''extra'', or ''unstable''. It is also a place for documentation, websites (except AUR), and security issues.<br />
<br />
*'''Arch User Repository (AUR)'''- for the website and the tools used to manage packages in ''community'' and ''unsupported''. It is not a place for software in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages'''- for packages in ''community''. It is not a place for packages in ''unsupported''.<br />
<br />
*'''Pacman'''- for ''pacman'' and the official scripts and tools associated with it. This includes things like makepkg and abs; it does not include community-developed packages such as [[yaourt]].<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help to solve the bug faster. It will only make truely critical problems less visible and probably make the developer assigned to your bug a bit less open to fixing it.<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical'''- System crash, severe boot failure that is likely to affect more than just you, or an exploitable security issue in either a core or outward-facing service package.<br />
*'''High'''- The main functionality of the application does not work, less critical security issues, etc.<br />
*'''Medium'''- A non-essential functionality does not work, UNIX standards not respected, etc.<br />
*'''Low'''- An optional functionality (plugin or compilation activated) does not work.<br />
*'''Very Low'''- Translation or documentation mistake. Something that really does not matter much but should be noticed for a future release.<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult parts of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_useful_information|Gather useful information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant pieces of information are, do not be shy : '''it is better to give more information than needed than not enough'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunately after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
=Following up on Bugs=<br />
<br />
'''Do not think the work is done once you have reported a bug'''!<br />
<br />
Developers or other users will probably ask you for more details and give you some potential fixes to try. Without continued feedback, bugs cannot be closed and the end result is both angry users and developers.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates to the developers how many people are impacted by the bug. However, this is not a very effective way of getting the bug solved. Much more important would be posting any additional information you know about the bug if you were not the original reporter.<br />
<br />
'''Watching''' a bug is important- you will receive an email when new comments are added or the bug status has changed. If you opened a bug verify that the watching attribute is set to yes so you will be notified know when people ask you for more information or ask you to try a fix.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
People will take the time to look at your bug report and will try to help you. You need to continue to help them resolve your bug. Not answering to their questions will keep your bug unresolved and likely hamper enthusiasm to fix it.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
Developers or bug hunters will close your bug if you do not answer questions after a few weeks or a month.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is fixed in a new version. If this is the case then indicate it in the bug report comments and request a closure.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report a bug but do not notify when they have solved it on their own, leaving people searching for a solution that has already been found. Please request a closure if you found a solution and give the solution in the bug report comments.<br />
<br />
<br />
==More about bug status==<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=41265User:Chicha2008-05-14T10:07:21Z<p>Chicha: </p>
<hr />
<div>=== Who am I ? ===<br />
'''Nick''' : Chicha<br><br />
'''Firstname''' : Charles-Henri<br><br />
'''Lastname''' : d'Adhémar<br><br />
'''Nationality''' : French<br><br />
'''Location''' : Nice (France)<br><br />
'''Birthdate''' : 23/11/1979<br><br />
'''Family''' : Married with a little boy.<br />
'''Website''' (in construction) : http://cdadhemar.free.fr<br />
<br />
[http://bbs.archlinux.org/misc.php?email=10613 Contact me !]<br />
<br />
<br />
=== Job/Hobbies ===<br />
I am a '''software developer''' (ASM, C/C++, Java, Python, Shell ...) at [[wikipedia:Amadeus_IT_Group|Amadeus]].<br />
<br />
Free Software is my major 'cerebral' hobby. I am also a great kind of nature (sea, mountains, country) and sailing in particular.<br />
<br />
<br />
=== Me and Arch ===<br />
After having looking around for the distro of my dream and a great community I think '''I found with Arch all I was looking for''' :<br />
<br />
* Ease of use and stability.<br />
* Nice technologies.<br />
* Knowledge provider.<br />
* Open and accessible community.<br />
<br />
<br />
'''I do not participate to the French Arch Community''' for several reasons:<br />
<br />
* The first one is that as usual in France it is divided in 2 communities : archlinuxfr.org and archlinux.fr. Isn't it ridiculous ?<br />
* I do not like local communities as long as you loose the opportunity to meet foreign people and new culture. Every time I went to a localized community (french or other) I felt like it was totally living outside the "real" world.<br />
* I believe helping here will help more people than working for a smaller community.<br />
* Having local communities duplicate the documentation. Having a localized forum is nice. Having a French or whatever language Wiki is a waste of ressources. I really like better a single entry point and wiki for documentation with translated pages, like it is the case here.<br />
<br />
<br />
Like many people I do not have enought time to participate in all I would like to.<br />
Here is a (too small) list of things I am contributing to :<br />
<br />
* '''Gnome technologies''' : testing and bug reporting mainly.<br />
* '''Arch forums''' : I try to help as much as I can (and sometimes need help), especially with people having problems with Gnome.<br />
* '''Arch bug tracker''' : It is my new hobby at Arch. I enjoy tracking (hunting) bugs, and close invalid ones.<br />
* '''Arch wiki''' : I help at some translations. Recently I wrote a documentation on [[Reporting_Bug_Guidelines|how to report bugs]].<br />
* '''AUR''' : There is nearly all I need in there. For what I miss see [http://aur.archlinux.org/packages.php?SeB=m&K=chicha my contributions].</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=41264User:Chicha2008-05-14T08:38:41Z<p>Chicha: /* Welcom to Chicha's wiki page :-) */</p>
<hr />
<div>== Welcome to Chicha's wiki page :-) ==<br />
=== Who am I ? ===<br />
Nick : Chicha<br><br />
Firstname : Charles-Henri<br><br />
Lastname : d'Adhémar<br><br />
Location : Nice (France)<br><br />
Birthdate : 23/11/1979<br><br />
<br />
I will tell you more about me when time permit...</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40914Bug reporting guidelines2008-05-07T16:00:47Z<p>Chicha: /* Projects and Categories */ cosmetic</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuffs. This is not a bug if such files are not included in the sources tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' and not used in the package then this is a bug.<br />
<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather usefull information==<br />
<br />
Here is a list of usefull information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know then wait for a bug hunter to ask you the question ...<br />
<br />
*Version of the kernel used if hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it did not work.<br />
<br />
*Indicate your '''hardware brand''' when hardware related problems<br />
<br />
*Add '''relevant log information''' when any available. This can be optained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack''' : TODO What is it ? How to fetch it ?<br />
<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all the useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to open an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as opening an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving an email adress you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
You have to choose the project where your problem will be reported :<br />
<br />
*'''Archlinux''' is for softwares in '''testing''', '''core''' and '''extra''' only. It is also a place for documentation, websites (except AUR), security issues ...<br />
<br />
*'''Arch User Repository (AUR)''' is for the '''website''' and the '''tools''' used to manage packages in ''community'' and ''unsupported''. It is not a place for softwares in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages''' is a place for ... packages in '''community'''. It is not a place for packages in ''unsupported''.<br />
<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help solving the bug faster. At most it will make really critical problems less visible ...<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical''' : The application crashed.<br />
*'''High''' : The main functionality of the application do not work or security related issue.<br />
*'''Medium''' : A non essential functionality do not work, UNIX standards not respected ...<br />
*'''Low''' : An optional functionality (plugin or compilation activated) do not work.<br />
*'''Very Low''' : Translation or documentation mistake. Something which really do not matter much but should be noticed for a futur release.<br />
<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult part of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_usefull_information|Gather usefull information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant information are, do not be shy : '''it is better to give more information than needed than not enought'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunatly after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
<br />
=Following a Bug=<br />
<br />
'''Do not think the work is done when you reported a bug'''!<br />
<br />
People will probably ask you '''more details''' and give you some '''potential fixes to try'''.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates the developers how many people are impacted by the bug. However this functionality is considered useless by many communities and you might not care about voting for bugs. In reallity it does not help a lot solving the bug, does it ?<br />
<br />
'''Watching''' a bug is important : you will receive an email when new comments are added or the bug status changed. If you opened a bug verify that the '''watching attribute is set to yes'''. Otherwise you will not know when people ask you some more information or some fixes to try.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
Some people will take the time to look at your bug report and will try to help you.<br />
In addition of being very rude, not answering to their questions will make your bug unresolved.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
'''Most developers or bug hunters will close your bug if you do not answer to questions after a month or two'''.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is '''fixed in a new version'''.<br />
If this is the case then indicate it in the bug report and '''request a closure'''.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report bugs but do not notify when it is solved, leaving people searching for a solution that has already been found.<br />
<br />
Please '''request a closure if you found a solution''' and '''give the solution back''' in the bug report.<br />
<br />
<br />
==More about bug status==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40913Bug reporting guidelines2008-05-07T16:00:08Z<p>Chicha: /* Projects and Categories */</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuffs. This is not a bug if such files are not included in the sources tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' and not used in the package then this is a bug.<br />
<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather usefull information==<br />
<br />
Here is a list of usefull information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know then wait for a bug hunter to ask you the question ...<br />
<br />
*Version of the kernel used if hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it did not work.<br />
<br />
*Indicate your '''hardware brand''' when hardware related problems<br />
<br />
*Add '''relevant log information''' when any available. This can be optained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack''' : TODO What is it ? How to fetch it ?<br />
<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all the useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to open an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as opening an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving an email adress you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
You have to choose the project where your problem will be reported :<br />
<br />
*'''Archlinux''' is for softwares in '''testing''', '''core''' and '''extra''' only. It is also a place for documentation, websites (except AUR), security issues ...<br />
<br />
*'''Arch User Repository (AUR)''' is for the '''website''' and the '''tools''' used to manage packages in ''community'' and ''unsupported''. It is not a place for softwares in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages''' is a place for ... packages in '''community'''. It is not a place for packages in ''unsupported''.<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help solving the bug faster. At most it will make really critical problems less visible ...<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical''' : The application crashed.<br />
*'''High''' : The main functionality of the application do not work or security related issue.<br />
*'''Medium''' : A non essential functionality do not work, UNIX standards not respected ...<br />
*'''Low''' : An optional functionality (plugin or compilation activated) do not work.<br />
*'''Very Low''' : Translation or documentation mistake. Something which really do not matter much but should be noticed for a futur release.<br />
<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult part of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_usefull_information|Gather usefull information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant information are, do not be shy : '''it is better to give more information than needed than not enought'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunatly after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
<br />
=Following a Bug=<br />
<br />
'''Do not think the work is done when you reported a bug'''!<br />
<br />
People will probably ask you '''more details''' and give you some '''potential fixes to try'''.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates the developers how many people are impacted by the bug. However this functionality is considered useless by many communities and you might not care about voting for bugs. In reallity it does not help a lot solving the bug, does it ?<br />
<br />
'''Watching''' a bug is important : you will receive an email when new comments are added or the bug status changed. If you opened a bug verify that the '''watching attribute is set to yes'''. Otherwise you will not know when people ask you some more information or some fixes to try.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
Some people will take the time to look at your bug report and will try to help you.<br />
In addition of being very rude, not answering to their questions will make your bug unresolved.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
'''Most developers or bug hunters will close your bug if you do not answer to questions after a month or two'''.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is '''fixed in a new version'''.<br />
If this is the case then indicate it in the bug report and '''request a closure'''.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report bugs but do not notify when it is solved, leaving people searching for a solution that has already been found.<br />
<br />
Please '''request a closure if you found a solution''' and '''give the solution back''' in the bug report.<br />
<br />
<br />
==More about bug status==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40900Bug reporting guidelines2008-05-07T15:38:25Z<p>Chicha: Continuing the work, still draft however</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
*A package which does not include a '''.desktop file''' or '''icons''' or other [http://www.freedesktop.org freedesktop] stuffs. This is not a bug if such files are not included in the sources tarball, and this must be requested as a feature request ''upstream''. If such files are provided by ''upstream'' and not used in the package then this is a bug.<br />
<br />
<br />
==Reasons for not being a feature==<br />
<br />
*When it is a bug ...<br />
*When it is not under Arch responsibility to implement the feature, ie an '''upstream feature'''.<br />
*A package is not up-to-date. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
<br />
<br />
==Gather usefull information==<br />
<br />
Here is a list of usefull information that should be mentioned in your bug report :<br />
<br />
*'''Version of the package''' being used.<br />
<br />
*Version of the main libraries used by the package (available in the ''depends'' variable in the PKGBUILD), when they are involved in the problem. If you do not know then wait for a bug hunter to ask you the question ...<br />
<br />
*Version of the kernel used if hardware related problems.<br />
<br />
*Indicate whether or not '''the functionality worked at one time or not'''. If so indicate since when it did not work.<br />
<br />
*Indicate your '''hardware brand''' when hardware related problems<br />
<br />
*Add '''relevant log information''' when any available. This can be optained in the following places depending on the problem :<br />
**/var/log/messages for kernel and hardware related issues.<br />
**/var/log/Xorg.0.log or /var/log/Xorg.2.log or any Xorg like log files if video related problems (nvidia, ati, xorg ...)<br />
**Run your program in a '''console''' and use '''verbose''' and/or '''debug''' mode if available (see your program documentation), and copy the output in a file.<br />
<br />
*'''Indicate how to reproduce the bug'''. This is very important, it will help people test the bug and potential patches on their own computer.<br />
<br />
*'''The stack''' : TODO What is it ? How to fetch it ?<br />
<br />
<br />
=Opening a Bug=<br />
<br />
When you are sure it is a bug or a feature and you gathered all the useful information, then you are ready to open a bug report or feature request.<br />
<br />
==Creating an account==<br />
<br />
You have to open an account on [http://bugs.archlinux.org/ Arch's bug tracker system]. This is as easy as opening an account on a wiki or a forum and there is nothing particular to mention here.<br />
Do not be afraid of giving an email adress you currently use : it will be hidden and you will receive mails only for bugs you follow.<br />
<br />
<br />
==Projects and Categories==<br />
<br />
You have to choose the project where your problem will be reported :<br />
<br />
*'''Archlinux''' is for softwares in '''testing''', '''core''' and '''extra''' only. It is also a place for documentation, websites (except AUR), security issues ...<br />
<br />
*'''Arch User Repository (AUR)''' is for the '''website''' and the '''tools''' used to manage packages in ''community'' and ''unsupported''. It is not a place for softwares in ''community'' or ''unsupported''.<br />
<br />
*'''Community Packages''' is a for ... packages in '''community'''. It is not a place for packages in ''unsupported''.<br />
<br />
There is no place for reporting problems with packages in ''unsupported''. AUR provides a way to add comments to a package in ''unsupported''. You should use this to report bugs to the package maintainer.<br />
<br />
<br />
==Severity==<br />
<br />
Choosing a ''critical'' severity will not help solving the bug faster. At most it will make really critical problems less visible ...<br />
<br />
Here is a general usage of severities :<br />
<br />
*'''Critical''' : The application crashed.<br />
*'''High''' : The main functionality of the application do not work or security related issue.<br />
*'''Medium''' : A non essential functionality do not work, UNIX standards not respected ...<br />
*'''Low''' : An optional functionality (plugin or compilation activated) do not work.<br />
*'''Very Low''' : Translation or documentation mistake. Something which really do not matter much but should be noticed for a futur release.<br />
<br />
<br />
==Including Relevant Information==<br />
<br />
This is maybe one of the most difficult part of bug reporting.<br />
You have to choose from the chapter [[Reporting_Bug_Guidelines#Gather_usefull_information|Gather usefull information]] which information you will add to your bug report. This will depend on which your problem is.<br />
If you do not know what the relevant information are, do not be shy : '''it is better to give more information than needed than not enought'''.<br />
<br />
However, developers or bug hunters will ask you for more information if needed.<br />
Fortunatly after a few bug reports you will know what information should be given.<br />
<br />
Short information can be inlined in your bug report, whereas '''long information (logs, screenshots ...) should be attached'''.<br />
<br />
<br />
=Following a Bug=<br />
<br />
'''Do not think the work is done when you reported a bug'''!<br />
<br />
People will probably ask you '''more details''' and give you some '''potential fixes to try'''.<br />
<br />
<br />
==Voting and Watching==<br />
<br />
You can '''vote''' for your favorite bugs. The number of votes indicates the developers how many people are impacted by the bug. However this functionality is considered useless by many communities and you might not care about voting for bugs. In reallity it does not help a lot solving the bug, does it ?<br />
<br />
'''Watching''' a bug is important : you will receive an email when new comments are added or the bug status changed. If you opened a bug verify that the '''watching attribute is set to yes'''. Otherwise you will not know when people ask you some more information or some fixes to try.<br />
<br />
<br />
==Answering additional information requests==<br />
<br />
Some people will take the time to look at your bug report and will try to help you.<br />
In addition of being very rude, not answering to their questions will make your bug unresolved.<br />
<br />
'''Please take the time to give people more information if requested and try the solutions proposed'''.<br />
<br />
'''Most developers or bug hunters will close your bug if you do not answer to questions after a month or two'''.<br />
<br />
<br />
==Updating the bug report when a new version of the related software is out==<br />
<br />
Sometimes a bug is related to a given package version and is '''fixed in a new version'''.<br />
If this is the case then indicate it in the bug report and '''request a closure'''.<br />
<br />
<br />
==Closing when solved==<br />
<br />
Sometimes people report bugs but do not notify when it is solved, leaving people searching for a solution that has already been found.<br />
<br />
Please '''request a closure if you found a solution''' and '''give the solution back''' in the bug report.<br />
<br />
<br />
==More about bug status==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Where to look at===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40880Bug reporting guidelines2008-05-07T14:21:09Z<p>Chicha: /* Bug Hunting */</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
<br />
<br />
==Reasons for not being a feature==<br />
==Gather usefull information==<br />
<br />
=Opening a Bug=<br />
<br />
==Creating an account==<br />
==Projects and Categories==<br />
==Severity==<br />
==Including Relevant Information==<br />
<br />
<br />
=Following a Bug=<br />
<br />
==Voting and Watching==<br />
==Answering additional information requests==<br />
==Closing when solved==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==How to help==<br />
<br />
===Candidates for closure===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40866Bug reporting guidelines2008-05-07T14:09:32Z<p>Chicha: New reasons for not being a bug</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug|Reasons for not being a bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
*A bug already reported upstream.<br />
*A bug already fixed upstream but not in Arch because the package is not up-to-date.<br />
*'''A package which is not-up-to-date'''. Use the '''Flag Package Out-of-Date''' feature on [http://archlinux.org/packages/ Arch's packages website].<br />
*A package which does not use Fedora, Ubuntu or any other community patch. '''Patches should be submitted ''upstream'''''.<br />
*A package where '''non essential function''' X or function Y is not activated. This is a feature request.<br />
<br />
<br />
==Reasons for not being a feature==<br />
==Gather usefull information==<br />
<br />
=Opening a Bug=<br />
<br />
==Creating an account==<br />
==Projects and Categories==<br />
==Severity==<br />
==Including Relevant Information==<br />
<br />
<br />
=Following a Bug=<br />
<br />
==Voting and Watching==<br />
==Answering additional information requests==<br />
==Closing when solved==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==Where to look ?==<br />
<br />
==How to help==<br />
<br />
===Candidates for closure===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=Bug_reporting_guidelines&diff=40865Bug reporting guidelines2008-05-07T13:58:45Z<p>Chicha: First Draft with the main chapters</p>
<hr />
<div>{{stub}}<br />
[[Category:Guidelines (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
=Introduction=<br />
<br />
Opening (and closing) bug reports on [http://bugs.archlinux.org/ Arch's Bug Tracking System] is one of the possible way to '''help the community'''. However if this is done badly it can turn out in being a pain instead of being usefull : When too much bugs are badly reported the community and the developers loose a lot of time asking for questions and closing invalid bug reports.<br />
<br />
This document will '''guide''' any body wanting to help efficiently the community by '''reporting''' or '''hunting bugs'''.<br />
<br />
<br />
<br />
=Before Reporting=<br />
<br />
The work done before reporting is probably '''the most usefull part of the job'''. Unfortunatly few people take the time to do this work, they prefere others to do it for them...<br />
<br />
However preparing a good bug report is not difficult and can be achieved by any body (beginner or developer).<br />
The following steps will help you preparing your bug report or feature request. They should be followed in the order they come.<br />
<br />
<br />
==Glossary==<br />
*'''Upstream''' : ''Upstream'' is usually refered to as the community who developed a software packaged by Archlinux. It is the team who is responsible for creating, publishing and documenting a software. Archlinux can be refered to as ''upstream'' for all the projects specific to Archlinux : pacman, AUR, initscripts, etc ...<br />
<br />
<br />
==Looking for duplicates==<br />
<br />
If you encounter a problem or would like a new feature, there is a high probability that someone else already had this problem or idea. If so he/she might have already opened a bug report. In this case you do not have much to do and see the [[Reporting_Bug_Guidelines#How_to_help|How to help]] section.<br />
<br />
<br />
Here are a list of places to search for duplicates :<br />
<br />
<br />
*[http://bbs.archlinux.org/ Arch's forum] : most of the time you will find your bug and the related solution here.<br />
<br />
*[http://bugs.archlinux.org/ Arch's Bug Tracking System] : It sounds obvious, but the "Reject as duplicate" feature in a bug tracker would not exists if people looked for duplicate before reporting a bug ...<br />
<br />
*[http://www.google.com Google] or your favorite search engine : Search using your software name, version and a relevant part of the error message that came out if any.<br />
<br />
*'''Upstream''' Forum, Mailing List and Bug Tracker : Look directly at the source of your problem ! Some bugs may have already been reported to the software developers, and even some bug may have been already fixed in the development version. That is why it is important to '''look for closed bugs''' as well as new bugs in ''upstream'' 's bug tracker.<br />
<br />
*'''Other distro forums''' : The Free Software community is wide, and other people than archers may have good idea too! You might have a look at [http://forums.gentoo.org/ Gentoo's forums] (my favorite), [http://forums.fedoraforum.org/ Fedora forums] and [http://ubuntuforums.org/ Ubuntu forums]. If you know some other source of usefull information feel free to add them here.<br />
<br />
<br />
==Bug or Feature ?==<br />
<br />
Once you know nobody reported the bug either at Arch or Upstream, you have to ask yourself whether your problem is '''a bug or a feature''' :<br />
<br />
*A '''bug''' is something that should work but does not.<br />
*A '''feature''' is something a software does or would does if somebody code it.<br />
<br />
<br />
==Upstream or Arch ?==<br />
<br />
This is an important question. '''If arch is not responsible for a bug, there is no point at reporting the bug to Arch'''. At most post something in the forum with a link to relevant information from ''upstream'', so that people can cope with the bug.<br />
<br />
By reporting bugs upstream not only you will help archers and Arch developers, but also you will '''help other people in the Free Software Community'''.<br />
<br />
<br />
So what is Archlinux responsible for ?<br />
<br />
*'''Arch own projects''' : Pacman, AUR, Initscripts, Arch Websites ... If you have a doubt about if the project belongs to Arch or not, display the package information (pacman -Qi foobar_package or using the website) and look at the '''URL'''.<br />
<br />
*'''Packaging''' : ''packaging'' basically consist on fetching the source code upstream, compiling it with relevant options, make sure the package will be installed correctly on an Arch system, make sure the main functionalities of a package work. ''Packaging'' at Arch does not consist on adding new functionalities or patches for existing bugs, it is ''upstream'' 's work.<br />
<br />
<br />
'''If a bug/feature is not under Arch's responsibility report it ''upstream'''''. See also [[Reporting_Bug_Guidelines#Reasons_for_not_being_a_bug]].<br />
<br />
<br />
==Reasons for not being a bug==<br />
<br />
*Something you would like a software to do, whereas it is said nowhere that it does. In short : '''a new feature'''.<br />
<br />
==Reasons for not being a feature==<br />
==Gather usefull information==<br />
<br />
=Opening a Bug=<br />
<br />
==Creating an account==<br />
==Projects and Categories==<br />
==Severity==<br />
==Including Relevant Information==<br />
<br />
<br />
=Following a Bug=<br />
<br />
==Voting and Watching==<br />
==Answering additional information requests==<br />
==Closing when solved==<br />
<br />
<br />
=Bug Hunting=<br />
<br />
==Where to look ?==<br />
<br />
==How to help==<br />
<br />
===Candidates for closure===<br />
===Duplicates===<br />
===Reproducing a bug===<br />
===Asking for more information===<br />
===Reporting upstream===<br />
<br />
==Bug Squashing Day==<br />
[[Bug_Squashing_Day|Bug Squashing Day]]</div>Chichahttps://wiki.archlinux.org/index.php?title=AUR_Cleanup_Day/2010&diff=40792AUR Cleanup Day/20102008-05-06T09:46:05Z<p>Chicha: Added flumotion</p>
<hr />
<div>The AUR has a large number of obsolete packages which could use cleaning up. Examples of packages that may be cleaned up are:<br />
*packages that have been renamed or replaced<br />
*old and unmaintained developmental (cvs/svn/etc) packages<br />
<br />
Post suggestions of packages on this pages. Trusted Users will get together and go though the list in a couple of weeks and confirm which packages should be removed. '''Please DO NOT REMOVE suggestions from the wiki page but add a comment on why it should be kept instead.''' TUs will not delete any useful package.<br />
<br />
==Package List==<br />
* [http://aur.archlinux.org/packages.php?ID=2787 9base-devel] - Hasn't been update since 25/12/2005. I think its not needed.<br />
* [http://aur.archlinux.org/packages.php?ID=12840 abraca-hg] - Replaced by abraca-git<br />
* [http://aur.archlinux.org/packages.php?ID=7086 alienarena2007] - Replaced by alienarena<br />
* [http://aur.archlinux.org/packages.php?ID=573 amavisd-new] - old version, won't compile, maintainer don't answare for e-mails (I have made new package [http://aur.archlinux.org/packages.php?ID=14650 amavisdnew])<br />
* [http://aur.archlinux.org/packages.php?ID=3194 azrael] - dead project, does not compile<br />
* [http://aur.archlinux.org/packages.php?ID=1308 dx9wine] - contains a patch not needed anymore<br />
* [http://aur.archlinux.org/packages.php?ID=7259 firefox2-ca] - firefox2 is depreciated.<br />
* [http://aur.archlinux.org/packages.php?ID=10229 flumotion] - removed from community a year ago, orphan and 1 year out of date without any complain.<br />
* [http://aur.archlinux.org/packages.php?ID=1790 fusesmb] or [http://aur.archlinux.org/packages.php?ID=14475 fusesmb2] - duplicate (and both outdated, version 8.7 is available)<br />
* [http://aur.archlinux.org/packages.php?ID=13063 fftw2single] - part of fftw2 from [extra]<br />
* [http://aur.archlinux.org/packages.php?ID=13589 gimp-freetype] - This plugin was developed for gimp 2.0 and is not needed according to the notes [http://ftp.gwdg.de/pub/misc/grafik/gimp/gimp/plug-ins/v2.0/freetype/ here.]<br />
* [http://aur.archlinux.org/packages.php?ID=6823 gimp-resynth] or [http://aur.archlinux.org/packages.php?ID=12273 gimp-plugin-resynthesizer] - duplicate (best to keep latter)<br />
* [http://aur.archlinux.org/packages.php?ID=3754 gnash-cvs] - Hasn't been update since 18/11/2006. gnash is in extra now too.<br />
* gmpc*-svn - replaced by git<br />
* [http://aur.archlinux.org/packages.php?ID=7488 ionice] - part of util-linux-ng<br />
* [http://aur.archlinux.org/packages.php?ID=8231 kdelibs-noarts] - out-of-date, modified official package<br />
* [http://aur.archlinux.org/packages.php?ID=12581 kdenlive 0.5_1-1] - out-of-date, doesn't compile<br />
** Latest stable version is 0.5, last updated in AUR on Sun, 09 Mar 2008 --[[User:Doc Angelo|Doc Angelo]]<br />
* [http://aur.archlinux.org/packages.php?ID=6296 kernel26thinkpad] - obsolete, out of date since 2006<br />
* [http://aur.archlinux.org/packages.php?ID=2700 mutt-cvs] - mutt switched to mercurial a while back; way outdated anyway.<br />
* [http://aur.archlinux.org/packages.php?ID=12051 netscape-navigator] - Not supported upstream anymore making it vulnerable to security issues.<br />
* [http://aur.archlinux.org/packages.php?ID=15312 openssh-snapshot] - Not needed anymore<br />
* [http://aur.archlinux.org/packages.php?ID=12193 pidgin-xfire] - Broke; Replaced by [http://aur.archlinux.org/packages.php?ID=16776 pidgin-gfire].<br />
* [http://aur.archlinux.org/packages.php?ID=10514 rt61-cvs] - This driver is included in linus's tree and is therefore obsolete<br />
* [http://aur.archlinux.org/packages.php?ID=494 sonic-rainbow] - dead project, does not compile<br />
* [http://aur.archlinux.org/packages.php?ID=2612 stepmania-bin] - orphan, replaced by [http://aur.archlinux.org/packages.php?ID=5453 stepmania]<br />
* [http://aur.archlinux.org/packages.php?ID=15910 tar-fixed] - This bug is verified fixed in tar 1.20<br />
* [http://aur.archlinux.org/packages.php?ID=647 ximian-openoffice] - Ximian port of OpenOffice 1.x. Users should use the more secure OpenOffice 2.x. Also Ximian openoffice is what is now known as ooo-build.<br />
<br />
==Remove from Filesystem==<br />
<br />
This is a list of files on the AUR filesystem that have been created when poorly formed packages were uploaded. <br />
<br />
<pre><br />
/packages/0verkill-0.16.tar.gz/<br />
/packages/2007.02.17-2/<br />
/packages/abakus-0.91-1/<br />
/packages/abakus-0.91.tar.gz/<br />
/packages/abakus-0.91/<br />
/packages/akgregator/<br />
/packages/akregator/<br />
/packages/akregator1.0.2/<br />
/packages/akregator_1.0.2/<br />
/packages/amsn-0.97ec1/<br />
/packages/amsn-0.97rc1/<br />
/packages/amsn-097rc1-1/<br />
/packages/amsn-097rc1/<br />
/packages/amsn-cvs/<br />
/packages/amsn-svn_update/<br />
/packages/amsn096/<br />
/packages/amsn096rc1/<br />
/packages/bashstyle-5.0<br />
/packages/bashstyle-5.0rc1.tar.gz/<br />
/packages/bashstyle-5.0rc1.tar.gz1/<br />
/packages/bashstyle-5.0rc1/<br />
/packages/bashstyle.tar.gz/<br />
/packages/bashstyle-ng/<br />
/packages/bashstyle1/<br />
/packages/braero-svn<br />
/packages/braser-cvs/<br />
/packages/brasero-cvs/<br />
/packages/brasero.svn/<br />
/packages/brlcad-cvs/<br />
/packages/ccd2iso-0.3/<br />
/packages/cdcollect-0.6.0/<br />
/packages/centerim-4.22.2/<br />
/packages/centerim/<br />
/packages/ploticus-test/<br />
/packages/test-louipc/<br />
/packages/test/<br />
/packages/test_pkg/<br />
/packages/yacas-1.1.17-2/<br />
/packages/yacas-1.2.2/<br />
/packages/yacas-1.17-2/<br />
/packages/yacas-new/<br />
/packages/yacasnew/<br />
/packages/zzztest/<br />
/packages/zzzztest/<br />
</pre></div>Chichahttps://wiki.archlinux.org/index.php?title=Talk:Compiz&diff=29811Talk:Compiz2007-09-24T11:18:12Z<p>Chicha: Typo</p>
<hr />
<div>I think that now it's ok. Your opinion?<br />
<br />
==Unified Compiz article==<br />
<br />
Please consider merging this article with the one on "Compiz fusion"<br />
<br />
== Compiz is not deprecated, and compiz-fusion is a compiz extension not a replacement ==<br />
<br />
Hello,<br />
<br />
I disagree with the Note at the very begining of the article :<br />
Compiz is not deprecated and compiz-fusion is an extension to compiz, not a replacement.<br />
Compiz-fusion uses compiz as a base. Please have a look at this document which explains the differences :<br />
<br />
http://wiki.compiz-fusion.org/CompizFusionVsCompiz<br />
<br />
I hope it helped !<br />
<br />
Cheers,<br />
<br />
[[User:Chicha|chicha]] 07:17, 24 September 2007 (EDT)</div>Chichahttps://wiki.archlinux.org/index.php?title=Talk:Compiz&diff=29810Talk:Compiz2007-09-24T11:17:34Z<p>Chicha: Compiz is not deprecated, and compiz-fusion is an compiz extension not a replacement</p>
<hr />
<div>I think that now it's ok. Your opinion?<br />
<br />
==Unified Compiz article==<br />
<br />
Please consider merging this article with the one on "Compiz fusion"<br />
<br />
== Compiz is not deprecated, and compiz-fusion is an compiz extension not a replacement ==<br />
<br />
Hello,<br />
<br />
I disagree with the Note at the very begining of the article :<br />
Compiz is not deprecated and compiz-fusion is an extension to compiz, not a replacement.<br />
Compiz-fusion uses compiz as a base. Please have a look at this document which explains the differences :<br />
<br />
http://wiki.compiz-fusion.org/CompizFusionVsCompiz<br />
<br />
I hope it helped !<br />
<br />
Cheers,<br />
<br />
[[User:Chicha|chicha]] 07:17, 24 September 2007 (EDT)</div>Chichahttps://wiki.archlinux.org/index.php?title=The_Arch_Way&diff=24377The Arch Way2007-05-18T14:40:32Z<p>Chicha: Adding link to french translation</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|The Arch Way}}<br />
{{i18n_entry|Polski|The Arch Way (Polski)}}<br />
{{i18n_entry|Português de Portugal|À Maneira do Arch}}<br />
{{i18n_entry|Русский|Путь_Arch}}<br />
{{i18n_entry|Česky|Principy a filozofie Arch Linuxu (Česky)}}<br />
{{i18n_entry|Italiano|The Arch Way (Italiano)}}<br />
{{i18n_entry|Français|The Arch Way (Français)}}<br />
{{i18n_links_end}}<br />
<br />
English<br />
= Arch Principles & Philosophy =<br />
This page attempts to describe the principles and philosophy of [[ArchLinux|Arch Linux]]. There once was no written document about the Arch Way; most likely that will never happen again. In short, the Arch Way stands for "<b>freedom of choice, keep it simple, learning, and user-control</b>".<br />
<br />
== Principles ==<br />
I, Judd Vinet, started building Arch for two reasons:<br />
<br />
# I didn't find any other distributions that met my ideals. Some came very close to what I wanted but there were annoying quirks or needless complexity that seemed to hurt more than help;<br />
# For fun - to give a little something back to the free software community, from which I've taken so much.<br />
<br />
<br />
By its basic nature, Arch is:<br />
<br />
* Lightweight and simple. Note that doesn't mean it's for everyone....<br />
<br />
* NOT designed as a newbie distro; it's intended for more experienced users. The aim is to develop Arch into as nearly a perfect base as is humanly possible. A base doesn't include fancy tools and auto configuration mechanisms, but rather contains manual configuration tools and few functions, for the users to further develop and/or learn on their own.<br />
<br />
* A free gift, again, "...to give a little something back to the free software community, from which I've taken so much." When you receive a gift from someone, it's usually expected to give something in return. As such, users are welcome to contribute their ideas, tools and suggestions.<br />
<br />
* Aware there are two sides which contribute to Arch Linux: Developers and Users. Don't expect the two sides to merge, but to have a mutual relationship whereby anyone can pick up what they want to add to their machine; our GOALs are to:<br />
<br />
* NOT let configure tools / GUIs control the system, but that they be controlled by the user. There is nothing wrong with GUIs as long as they follow this principle.<br />
<br />
* NOT be controlled by or dependent on what tools offer. When developing or selecting a utility tool, it should be written in a hackable/readable programming language (KISS) to enable users to modify it if they so choose.<br />
<br />
* The core development of Arch Linux will NOT be providing any "newbie-friendly" GUIs/utilities at any time in the near future.<br />
<br />
* We humble developers will continue to provide Arch as a solid base for everyone and anyone. If you guys want to make it pretty, give 'er a rip. Free speech, free beer, and all that.<br />
<br />
== Philosophy ==<br />
<br />
The System of values by which Arch develops:<br />
<br />
* KISS (Keep It Simple, ...) is the basis of Arch development.<br />
<br />
* In Arch, 'simple' doesn't always mean what it does in other distros. It's our philosophy that the learning is more important than getting something easily done.<br />
<br />
* Relying on GUIs to build and use your system is just going to hurt a user in the end. At some point in time a user will need to know all that some GUIs hide.<br />
<br />
* If you try to hide the complexity of the system, you'll end up with a more complex system. Instead, try to make the system simpler and more logical from the inside.<br />
<br />
* Sooner or later, you'll have to find the information on the web and usenet (if man is not enough). Learning how and where to find it on the net should be the first thing a newbie has to learn.<br />
<br />
* Where some users say "...such and such distro isn't like so and so distro," Arch allows the user to make all the contributions they want as long as it doesn't go against the ideals of the design or philosophy.<br />
<br />
* Arch Linux is different from the others: at Arch, the user isn't the only concern. Minimizing development of new tools and docs while maximizing understanding of Linux' inner workings, while keeping a watchful eye always on the "KISS" aim and philosophy of Arch Linux in general...is what makes the "Arch Way" truly different.<br />
<br />
* The great thing about contributions is that you don't need anyone's permission to make them. (See?) No one can physically stop you from writing something that you (personally) find useful, even if the "powers that be" don't see it as a blessing. Write it and put it up in the User Contributions forum. If other people like it, you'll receive feedback. If virtually everyone out there hates it but you, you'll receive feedback, for sure - but who cares? It took you 20 minutes to write, and you learned something along the way. It's a winning situation no matter what.<br />
<br />
* It is what you make it.<br />
<br />
== Comments ==<br />
<br />
What users have said about Arch:<br />
<br />
* "I did a distro taste test with zenwalk(slack based), debian, Redhat fedora, redhat Enterprise, T2, freebsd, netbsd, gobolinux, and SUSE. Arch won in a close one over FreeBSD. Why? It was simple to get up n running with X, packages were VERY current and simple to install, and I didn't have to wait all day for something to compile, but my apps are compiled i686 so they are fast. Updates of whole box did not squash apps as Redhat seemed to. To me as a linux admin I am looking to bring up box, and for home use X, and then be able to add apps and libraries as I see fit. Once the box is up, hand it off to developers, or develop on it myself. Other distros had a lame package system, out of date packages, and simply had no docs to config thier systems without a GUI. Arch provides the shortest step from A to B. To read more of why I stick with Arch read the section: Arch v other distros."<br />
<br />
<br />
* "After spending a lot of time with other distributions (debian, gentoo, mandrake, redhat, fedora, slackware) and even FreeBSD. I think that I finally found the distribution I was looking for."<br />
<br />
* Same thing with (k)ubuntu, Mandriva, and several others. Well, openSUSE is nice and easy (that's the one I would advice for my sister); but Arch is the One which really *rocks*.<br />
<br />
* "I have tried several distro's and even took (tired?) RHCE (took it BACK?), but there was always something I disliked about each."<br />
<br />
* "My dream distro was always the simplicity of Slackware with real dependency support like Debian's, and guess what - that's Arch."<br />
<br />
* "I also found Arch my final distro."<br />
<br />
* "After trying out almost all the available distributions, I have to agree that Arch is the best."<br />
<br />
* "Hi all. I just registered here so I could report all the problems I'm having, and ask for help. Funny thing is, I HAVE NO PROBLEMS!!! I really can't believe this, but everything is just working! I installed Arch today, had a little trouble with xorg and sound setup, but found all the answers I needed in the documentation and the forums!"<br />
<br />
* "I tried Mandrake, Yoper, FC3/4, Mepis and Ubuntu. I was looking for the perfect distro. I am glad that I found Arch."<br />
<br />
----<br />
<br />
= PROS and CONS =<br />
<br />
== PROS ==<br />
<br />
* i686-optimized<br />
* [[pacman]]: 'System Upgrade' is ONE command: "pacman -Suy"<br />
* [[pacman]]: Dependency-control, no X/GUI needed<br />
* [[ABS]]: the package-building function need only be done once - building another version of a package is extremely easy<br />
* [[ABS]]: you can build all the packages on your machine with one command<br />
* fully up-to-date packages at your request, and fully customizable<br />
* the people behind the scenes are gentle, motivated and able<br />
* less than 20 minutes to create a fully functional system<br />
* the perfect environment to learn Linux in<br />
* not really popular, because not known (still relevant?)<br />
<br />
== CONS ==<br />
<br />
* [[pacman]]: needs a fast internet connection to stay always up-to-date easily (less of a problem as time marches forward)<br />
* some conflicts from using the newest libs ("bleeding edge")<br />
* lack of newbie-friendly features<br />
* very little hardware detection (relevant?)<br />
* info files are almost always way more detailed than man-pages (gcc.info e.g.)<br />
* not really popular, because not known</div>Chichahttps://wiki.archlinux.org/index.php?title=User:Chicha&diff=23428User:Chicha2007-04-24T09:53:19Z<p>Chicha: New page: == Welcom to Chicha's wiki page :-) == === Who am I ? === Nick : Chicha<br> Firstname : Charles-Henri<br> Lastname : d'Adhémar<br> Location : Nice (France)<br> Birthdate : 23/11/19...</p>
<hr />
<div>== Welcom to Chicha's wiki page :-) ==<br />
=== Who am I ? ===<br />
Nick : Chicha<br><br />
Firstname : Charles-Henri<br><br />
Lastname : d'Adhémar<br><br />
Location : Nice (France)<br><br />
Birthdate : 23/11/1979<br><br />
<br />
I will tell you more about me when time permit...</div>Chichahttps://wiki.archlinux.org/index.php?title=Disable_root_password_and_gain_su_sudo_with_no_password&diff=23408Disable root password and gain su sudo with no password2007-04-23T21:29:31Z<p>Chicha: Add a short tip to make kdesu use sudo</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 />
===Why:===<br />
<br />
# User password strength is same as root's password, and one must 1st login in-order to use su/sudo.<br />
# Root password will be disabled - thus anyone who will try login using root user will get denied... this will require anyone who wants to login to be familiar with the user name prior, which gives further security strength.<br />
# Once local security is compromised, a root password is meaningless if a live-cd (etc) is in hands, or as a wise user added - a baseball bat...<br />
<br />
===Requirements:===<br />
You'll need "sudo" installed. You can grab it from pacman:<br />
# pacman -S sudo<br />
<br />
===How:===<br />
<b> 1. Allow user to sudo:</b><br />
<br />
<b>1.1</b> Add "<user> <machine_name/ALL>=(ALL) ALL" to /etc/sudoers. You should always use visudo to edit the sudoers file, since visudo performs some checks to ensure that the edited file is valid. (Type visudo at a root prompt and edit. The command <b>i</b> will start edit mode of vi, <b>Esc</b> will end it, <b>:wq</b> will save the file and quit, while <b>:q</b> will quit visudo).<br />
<br />
<pre> > visudo<br />
#allow user ziggy sudo from local machine only (my_machine_name = HOSTNAME in rc.conf and NOT localhost):<br />
ziggy my_machine_name=(ALL) ALL<br />
#allow user arch sudo from anywhere (local/net):<br />
arch ALL=(ALL) ALL </pre><br />
<br />
'''1.2''' If you didn't use visudo, you will need to CHMOD /etc/sudoers to 0440<br />
chmod 0440 /etc/sudoers<br />
<br />
<b>2. Disable root and gain su/sudo with no password:</b><br />
<br />
<b>2.1</b> add group 'wheel' to installed accounts:<br />
<br />
<pre><br />
gpasswd -a <username> wheel<br />
</pre><br />
<br />
<b>2.2</b> Allow members of 'wheel' group to use sudo (it will be passwordless since root will be disabled) by adding the following line to /etc/pam.d/sudo:<br />
<br />
<pre><br />
auth sufficient pam_wheel.so trust use_uid<br />
</pre><br />
<br />
<b>2.3</b> to allow wheel users login via local <b>only</b>, add the following line to /etc/security/access.conf :<br />
<br />
<pre><br />
-:wheel:ALL EXCEPT LOCAL<br />
</pre><br />
<br />
<b>2.4</b> Test it, then disable the root account by removing it's password.<br />
<br />
<pre><br />
passwd -l root<br />
</pre><br />
<br />
<b>3.</b> if you ever need to reacitvate root, just run<br />
<br />
<pre><br />
sudo passwd root<br />
</pre><br />
<br />
Thats it. Enjoy your new passwordless root. :)<br />
<br />
<br />
<b>3. For Kde users, make kdesu use sudo :</b><br />
<br />
<br />
<i>Tips extracted from http://bugs.kde.org/show_bug.cgi?id=20914#c24</i><br />
<br />
<br />
kdesu may be used under kde to launch GUI applications with root privileges.<br />
By default kdesu uses su. As the root password has been deactivated, su will fail.<br />
Fortunately we can tell kdesu to use sudo instead of su.<br />
There are two ways to do so :<br />
<br />
<br />
<b>3.1</b> Recompile kdebase with '--with-sudo-kdesu-backend' configure switch.<br />
<br />
<br />
<b>3.2</b> Create a kdesurc file in '/opt/kde/share/config/' with the following :<br />
<br />
<pre><br />
[super-user-command]<br />
super-user-command=sudo<br />
</pre></div>Chicha