https://wiki.archlinux.org/api.php?action=feedcontributions&user=Lord+Aro&feedformat=atomArchWiki - User contributions [en]2024-03-29T13:48:02ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Pacman/Package_signing&diff=475159Pacman/Package signing2017-04-26T13:54:04Z<p>Lord Aro: /* Adding unofficial keys */ rewrite to effectively what was there before. it might not be directly related to pacman, but this is the first result on google</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Package management]]<br />
[[es:Pacman/Package signing]]<br />
[[fr:pacman-key]]<br />
[[it:Pacman/Package signing]]<br />
[[ja:Pacman-key]]<br />
[[ru:Pacman/Package signing]]<br />
[[tr:pacman paket imzaları]]<br />
[[zh-hans:Pacman/Package signing]]<br />
{{Related articles start}}<br />
{{Related|GnuPG}}<br />
{{Related|DeveloperWiki:Package signing}}<br />
{{Related articles end}}<br />
To determine if packages are authentic, ''pacman'' uses [http://www.gnupg.org/ GnuPG keys] in a [http://www.gnupg.org/gph/en/manual.html#AEN385 web of trust] model. There are currently five [https://www.archlinux.org/master-keys/ Master Signing Keys]. At least three of these Master Signing Keys are used to sign each of the Developer's and Trusted User's own keys which then in turn are used to sign their packages. The user also has a unique PGP key which is generated when you set up ''pacman-key''. So the web of trust links the user's key to the five Master Keys.<br />
<br />
Examples of webs of trust:<br />
<br />
* '''Custom packages''': You made the package yourself and signed it with your own key.<br />
* '''Unofficial packages''': A developer made the package and signed it. You used your key to sign that developer's key.<br />
* '''Official packages''': A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.<br />
<br />
{{Note|The HKP protocol uses 11371/tcp for communication. In order to get the signed keys from the servers (using ''pacman-key''), this port is required for communication.}}<br />
<br />
== Setup ==<br />
<br />
=== Configuring pacman ===<br />
<br />
The {{ic|SigLevel}} option in {{ic|/etc/pacman.conf}} determines how much trust is required to install a package. For a detailed explanation of {{ic|SigLevel}} see the [https://www.archlinux.org/pacman/pacman.conf.5.html#_package_and_database_signature_checking pacman.conf man page] and the comments in the file itself. Signature checking may be set globally or per repository. If {{ic|SigLevel}} is set globally in the {{ic|[options]}} section to require all packages to be signed, then packages you build will also need to be signed using ''makepkg''.<br />
<br />
{{Note|Although all official packages are now signed, as of June 2012 signing of the databases is a work in progress. If {{ic|Required}} is set then {{ic|DatabaseOptional}} should also be set.}}<br />
<br />
A default configuration can be used to only install packages that are signed by trusted keys:<br />
<br />
{{hc|1=/etc/pacman.conf|<br />
output=SigLevel = Required DatabaseOptional<br />
}}<br />
<br />
This is because {{ic|TrustedOnly}} is a default compiled-in ''pacman'' parameter. So above leads to the same result as a global option of:<br />
<br />
SigLevel = Required DatabaseOptional TrustedOnly<br />
<br />
The above can be achieved too on a repository level further below in the configuration, e.g.:<br />
<br />
[core]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
explicitly adds signature checking for the packages of the repository, but does not require the database to be signed. {{ic|Optional}} here would turn off a global {{ic|Required}} for this repository<br />
<br />
{{warning|The SigLevel {{ic|TrustAll}} option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use {{ic|TrustedOnly}} for all official repositories.}}<br />
<br />
=== Initializing the keyring ===<br />
<br />
To set up the ''pacman'' keyring use:<br />
<br />
# pacman-key --init<br />
<br />
For this initialization, [[Wikipedia:Entropy_(computing)|entropy]] is required. Moving your mouse around, pressing random characters at the keyboard or running some disk-based activity (for example in another console running {{ic|ls -R /}} or {{ic|find / -name foo}} or {{ic|1=dd if=/dev/sda8 of=/dev/tty7}}) should generate entropy. If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.<br />
<br />
The randomness created is used to set up a keyring ({{ic|/etc/pacman.d/gnupg}}) and the GPG signing key of your system.<br />
<br />
{{Note|If you need to run {{ic|pacman-key --init}} on computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either [[haveged]] or [[rng-tools]] on the target machine and start the corresponding service before running {{ic|pacman-key --init}}.}}<br />
<br />
== Managing the keyring ==<br />
<br />
=== Verifying the five master keys ===<br />
<br />
The initial setup of keys is achieved using:<br />
# pacman-key --populate archlinux<br />
Take time to verify the [https://www.archlinux.org/master-keys/ Master Signing Keys] when prompted as these are used to co-sign (and therefore trust) all other packager's keys.<br />
<br />
PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last ''sixteen'' digits of the fingerprint would be the 'long key ID').<br />
<br />
=== Adding developer keys ===<br />
<br />
The official developer and TU keys are signed by the master keys, so you do not need to use ''pacman-key'' to sign them yourself. Whenever ''pacman'' encounters a key it does not recognize, it will prompt to download it from a {{ic|keyserver}} configured in {{ic|/etc/pacman.d/gnupg/gpg.conf}} (or by using the {{ic|--keyserver}} option on the command line). Wikipedia maintains a [[wikipedia:Key server (cryptographic)|list of keyservers]].<br />
<br />
Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.<br />
<br />
{{Note|The {{Pkg|archlinux-keyring}} package, which is a dependency of {{Pkg|pacman}}, contains the latest keys. However keys can also be updated manually using {{ic|pacman-key --refresh-keys}} (as root). While doing {{ic|--refresh-keys}}, your local key will also be looked up on the remote keyserver, and you will receive a message about it being not found. This is nothing to be concerned about.}}<br />
<br />
=== Adding unofficial keys ===<br />
<br />
{{Note| For packages requiring a build process, for example with the [[AUR]] it is recommended to add the unofficial keys to a user-keyring, because ''makepkg'' does not employ the pacman keyring. See [[Makepkg#Signature_checking]] & [[GnuPG#Import_a_public_key]].}}<br />
<br />
You can use this method, for example, to add your own key to the ''pacman'' keyring, or when enabling signed [[unofficial user repositories]].<br />
<br />
First get the key ID ({{ic|''keyid''}}) from the owner of the key. Then you need to add the key to the keyring:<br />
<br />
* If the key is found on a keyserver, import it with: {{bc|# pacman-key -r ''keyid''}}<br />
<br />
* If otherwise a link to a keyfile is provided, download it and then run: {{bc|# pacman-key --add ''/path/to/downloaded/keyfile''}}<br />
<br />
Always be sure to verify the fingerprint, as you would with a master key, or any other key which you are going to sign.<br />
$ pacman-key -f ''keyid''<br />
<br />
Finally, you need to locally sign the imported key:<br />
# pacman-key --lsign-key ''keyid''<br />
<br />
You now trust this key to sign packages.<br />
<br />
=== Debugging with gpg ===<br />
<br />
For debugging purposes, you can access ''pacman'''s keyring directly with ''gpg'', e.g.:<br />
<br />
# gpg --homedir /etc/pacman.d/gnupg --list-keys<br />
<br />
== Troubleshooting ==<br />
<br />
{{Style|Instructions could be clearer}}<br />
<br />
{{Warning|''pacman-key'' depends on [[time]]. If your system clock is wrong, you'll get:<br />
error: PackageName: signature from "User <email@archlinux.org>" is invalid<br />
error: failed to commit transaction (invalid or corrupted package (PGP signature))<br />
Errors occured, no packages were upgraded.<br />
}}<br />
<br />
=== Cannot import keys ===<br />
<br />
There are multiple possible sources of this problem:<br />
<br />
* An outdated {{Pkg|archlinux-keyring}} package.<br />
* Incorrect date.<br />
* Your ISP blocked the port used to import PGP keys.<br />
* Your ''pacman'' cache contains copy of unsigned packages from previous attempts.<br />
* {{ic|dirmngr}} is not correctly configured<br />
<br />
You might be stuck because of outdated {{Pkg|archlinux-keyring}} package when doing an upgrade synchronization. Try if [[Pacman#Upgrading_packages|upgrading the system]] can fix it first.<br />
<br />
If you are still having issues, make sure the following file exists {{ic|/root/.gnupg/dirmngr_ldapservers.conf}} and that you can successfully run {{ic|# dirmngr}}. Create an empty file if it doesn't and run {{ic|# dirmngr}} again.<br />
<br />
If it does not help and your date is correct, you could try to switch to the MIT keyserver, which provides an alternate port. To do this, edit {{ic|/etc/pacman.d/gnupg/gpg.conf}} and change the {{ic|keyserver}} line to:<br />
<br />
keyserver hkp://pgp.mit.edu:11371<br />
<br />
If this does not help either, change the keyserver to the kjsl keyserver, which provides this service through port 80 (the HTTP port), which should always remain unblocked:<br />
<br />
keyserver hkp://keyserver.kjsl.com:80<br />
<br />
If you have IPv6 disabled, ''gpg'' will fail when it found some IPv6 address. In this case try with an IPv4-only keyserver like:<br />
<br />
keyserver hkp://ipv4.pool.sks-keyservers.net:11371<br />
<br />
If you happen to forget to run {{ic|pacman-key --populate archlinux}} you might get some errors while importing keys.<br />
<br />
If none of this helps, your ''pacman'' cache, located at {{ic|/var/cache/pacman/pkg/}} might contain unsigned packages from previous attempts. Try cleaning the cache manually or run:<br />
<br />
# pacman -Sc<br />
<br />
which removes all cached packages that have not been installed.<br />
<br />
=== Disabling signature checking ===<br />
<br />
{{Warning|Use with caution. Disabling package signing will allow ''pacman'' to install untrusted packages automatically.}}<br />
<br />
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit {{ic|/etc/pacman.conf}} and uncomment the following line under {{ic|[options]}}:<br />
<br />
SigLevel = Never<br />
<br />
You need to comment out any repository-specific SigLevel settings too because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you decide to do this, you do not need to set up a keyring with ''pacman-key''. You can change this option later if you decide to enable package verification.<br />
<br />
=== Resetting all the keys ===<br />
<br />
If you want to remove or reset all the keys installed in your system, you can remove {{ic|/etc/pacman.d/gnupg}} folder as root and rerun {{ic|pacman-key --init}} and following that add the keys as preferred.<br />
<br />
=== Removing stale packages ===<br />
<br />
If the same packages keep failing and you are sure you did all the ''pacman-key'' stuff right, try removing them like so {{ic|rm /var/cache/pacman/pkg/''badpackage''*}} so that they are freshly downloaded.<br />
<br />
This might actually be the solution if you get a message like {{ic|error: linux: signature from "Some Person <Some.Person@example.com>" is invalid}} or similar when upgrading (i.e. you might not be the victim of a MITM attack after all, your downloaded file was simply corrupt).<br />
<br />
=== Updating keys via proxy ===<br />
<br />
In order to use a proxy when updating keys the {{ic|honor-http-proxy}} option must be set in both {{ic|/etc/gnupg/dirmngr.conf}} and {{ic|/etc/pacman.d/gnupg/dirmngr.conf}}. See [[GnuPG#Use a keyserver]] for more information.<br />
<br />
{{Note|If ''pacman-key'' is used without the {{ic|honor-http-proxy}} option and fails, a reboot may solve the issue.}}<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Package Signing Proposal for Pacman]]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-1-makepkg-and-repo-add/ Pacman Package Signing – 1: Makepkg and Repo-add]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-2-pacman-key/ Pacman Package Signing – 2: Pacman-key]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-3-pacman/ Pacman Package Signing – 3: Pacman]<br />
* [http://allanmcrae.com/2011/12/pacman-package-signing-4-arch-linux/ Pacman Package Signing – 4: Arch Linux]</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Pacman/Package_signing&diff=475158Pacman/Package signing2017-04-26T13:50:46Z<p>Lord Aro: /* Adding unofficial keys */ add note on adding keys to your own user, not using pacman-key</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Package management]]<br />
[[es:Pacman/Package signing]]<br />
[[fr:pacman-key]]<br />
[[it:Pacman/Package signing]]<br />
[[ja:Pacman-key]]<br />
[[ru:Pacman/Package signing]]<br />
[[tr:pacman paket imzaları]]<br />
[[zh-hans:Pacman/Package signing]]<br />
{{Related articles start}}<br />
{{Related|GnuPG}}<br />
{{Related|DeveloperWiki:Package signing}}<br />
{{Related articles end}}<br />
To determine if packages are authentic, ''pacman'' uses [http://www.gnupg.org/ GnuPG keys] in a [http://www.gnupg.org/gph/en/manual.html#AEN385 web of trust] model. There are currently five [https://www.archlinux.org/master-keys/ Master Signing Keys]. At least three of these Master Signing Keys are used to sign each of the Developer's and Trusted User's own keys which then in turn are used to sign their packages. The user also has a unique PGP key which is generated when you set up ''pacman-key''. So the web of trust links the user's key to the five Master Keys.<br />
<br />
Examples of webs of trust:<br />
<br />
* '''Custom packages''': You made the package yourself and signed it with your own key.<br />
* '''Unofficial packages''': A developer made the package and signed it. You used your key to sign that developer's key.<br />
* '''Official packages''': A developer made the package and signed it. The developer's key was signed by the Arch Linux master keys. You used your key to sign the master keys, and you trust them to vouch for developers.<br />
<br />
{{Note|The HKP protocol uses 11371/tcp for communication. In order to get the signed keys from the servers (using ''pacman-key''), this port is required for communication.}}<br />
<br />
== Setup ==<br />
<br />
=== Configuring pacman ===<br />
<br />
The {{ic|SigLevel}} option in {{ic|/etc/pacman.conf}} determines how much trust is required to install a package. For a detailed explanation of {{ic|SigLevel}} see the [https://www.archlinux.org/pacman/pacman.conf.5.html#_package_and_database_signature_checking pacman.conf man page] and the comments in the file itself. Signature checking may be set globally or per repository. If {{ic|SigLevel}} is set globally in the {{ic|[options]}} section to require all packages to be signed, then packages you build will also need to be signed using ''makepkg''.<br />
<br />
{{Note|Although all official packages are now signed, as of June 2012 signing of the databases is a work in progress. If {{ic|Required}} is set then {{ic|DatabaseOptional}} should also be set.}}<br />
<br />
A default configuration can be used to only install packages that are signed by trusted keys:<br />
<br />
{{hc|1=/etc/pacman.conf|<br />
output=SigLevel = Required DatabaseOptional<br />
}}<br />
<br />
This is because {{ic|TrustedOnly}} is a default compiled-in ''pacman'' parameter. So above leads to the same result as a global option of:<br />
<br />
SigLevel = Required DatabaseOptional TrustedOnly<br />
<br />
The above can be achieved too on a repository level further below in the configuration, e.g.:<br />
<br />
[core]<br />
SigLevel = PackageRequired<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
explicitly adds signature checking for the packages of the repository, but does not require the database to be signed. {{ic|Optional}} here would turn off a global {{ic|Required}} for this repository<br />
<br />
{{warning|The SigLevel {{ic|TrustAll}} option exists for debugging purposes and makes it very easy to trust keys that have not been verified. You should use {{ic|TrustedOnly}} for all official repositories.}}<br />
<br />
=== Initializing the keyring ===<br />
<br />
To set up the ''pacman'' keyring use:<br />
<br />
# pacman-key --init<br />
<br />
For this initialization, [[Wikipedia:Entropy_(computing)|entropy]] is required. Moving your mouse around, pressing random characters at the keyboard or running some disk-based activity (for example in another console running {{ic|ls -R /}} or {{ic|find / -name foo}} or {{ic|1=dd if=/dev/sda8 of=/dev/tty7}}) should generate entropy. If your system does not already have sufficient entropy, this step may take hours; if you actively generate entropy, it will complete much more quickly.<br />
<br />
The randomness created is used to set up a keyring ({{ic|/etc/pacman.d/gnupg}}) and the GPG signing key of your system.<br />
<br />
{{Note|If you need to run {{ic|pacman-key --init}} on computer that does not generate much entropy (e.g. a headless server), key generation may take a very long time. To generate pseudo-entropy, install either [[haveged]] or [[rng-tools]] on the target machine and start the corresponding service before running {{ic|pacman-key --init}}.}}<br />
<br />
== Managing the keyring ==<br />
<br />
=== Verifying the five master keys ===<br />
<br />
The initial setup of keys is achieved using:<br />
# pacman-key --populate archlinux<br />
Take time to verify the [https://www.archlinux.org/master-keys/ Master Signing Keys] when prompted as these are used to co-sign (and therefore trust) all other packager's keys.<br />
<br />
PGP keys are too large (2048 bits or more) for humans to work with, so they are usually hashed to create a 40-hex-digit fingerprint which can be used to check by hand that two keys are the same. The last eight digits of the fingerprint serve as a name for the key known as the '(short) key ID' (the last ''sixteen'' digits of the fingerprint would be the 'long key ID').<br />
<br />
=== Adding developer keys ===<br />
<br />
The official developer and TU keys are signed by the master keys, so you do not need to use ''pacman-key'' to sign them yourself. Whenever ''pacman'' encounters a key it does not recognize, it will prompt to download it from a {{ic|keyserver}} configured in {{ic|/etc/pacman.d/gnupg/gpg.conf}} (or by using the {{ic|--keyserver}} option on the command line). Wikipedia maintains a [[wikipedia:Key server (cryptographic)|list of keyservers]].<br />
<br />
Once you have downloaded a developer key, you will not have to download it again, and it can be used to verify any other packages signed by that developer.<br />
<br />
{{Note|The {{Pkg|archlinux-keyring}} package, which is a dependency of {{Pkg|pacman}}, contains the latest keys. However keys can also be updated manually using {{ic|pacman-key --refresh-keys}} (as root). While doing {{ic|--refresh-keys}}, your local key will also be looked up on the remote keyserver, and you will receive a message about it being not found. This is nothing to be concerned about.}}<br />
<br />
=== Adding unofficial keys ===<br />
<br />
You can use this method, for example, to add your own key to the ''pacman'' keyring, or when enabling signed [[unofficial user repositories]].<br />
<br />
First get the key ID ({{ic|''keyid''}}) from the owner of the key. Then you need to add the key to the keyring:<br />
<br />
* If the key is found on a keyserver, import it with: {{bc|# pacman-key -r ''keyid''}}<br />
<br />
* If otherwise a link to a keyfile is provided, download it and then run: {{bc|# pacman-key --add ''/path/to/downloaded/keyfile''}}<br />
<br />
Always be sure to verify the fingerprint, as you would with a master key, or any other key which you are going to sign.<br />
$ pacman-key -f ''keyid''<br />
<br />
Finally, you need to locally sign the imported key:<br />
# pacman-key --lsign-key ''keyid''<br />
<br />
You now trust this key to sign packages.<br />
<br />
The above adds keys to pacman's keychain. If you're using the [[AUR]] you likely want to add keys to your own user, for which you'll need to use {{ic|''gpg''}}). See [[GnuPG#Import_a_public_key]] for more details<br />
<br />
=== Debugging with gpg ===<br />
<br />
For debugging purposes, you can access ''pacman'''s keyring directly with ''gpg'', e.g.:<br />
<br />
# gpg --homedir /etc/pacman.d/gnupg --list-keys<br />
<br />
== Troubleshooting ==<br />
<br />
{{Style|Instructions could be clearer}}<br />
<br />
{{Warning|''pacman-key'' depends on [[time]]. If your system clock is wrong, you'll get:<br />
error: PackageName: signature from "User <email@archlinux.org>" is invalid<br />
error: failed to commit transaction (invalid or corrupted package (PGP signature))<br />
Errors occured, no packages were upgraded.<br />
}}<br />
<br />
=== Cannot import keys ===<br />
<br />
There are multiple possible sources of this problem:<br />
<br />
* An outdated {{Pkg|archlinux-keyring}} package.<br />
* Incorrect date.<br />
* Your ISP blocked the port used to import PGP keys.<br />
* Your ''pacman'' cache contains copy of unsigned packages from previous attempts.<br />
* {{ic|dirmngr}} is not correctly configured<br />
<br />
You might be stuck because of outdated {{Pkg|archlinux-keyring}} package when doing an upgrade synchronization. Try if [[Pacman#Upgrading_packages|upgrading the system]] can fix it first.<br />
<br />
If you are still having issues, make sure the following file exists {{ic|/root/.gnupg/dirmngr_ldapservers.conf}} and that you can successfully run {{ic|# dirmngr}}. Create an empty file if it doesn't and run {{ic|# dirmngr}} again.<br />
<br />
If it does not help and your date is correct, you could try to switch to the MIT keyserver, which provides an alternate port. To do this, edit {{ic|/etc/pacman.d/gnupg/gpg.conf}} and change the {{ic|keyserver}} line to:<br />
<br />
keyserver hkp://pgp.mit.edu:11371<br />
<br />
If this does not help either, change the keyserver to the kjsl keyserver, which provides this service through port 80 (the HTTP port), which should always remain unblocked:<br />
<br />
keyserver hkp://keyserver.kjsl.com:80<br />
<br />
If you have IPv6 disabled, ''gpg'' will fail when it found some IPv6 address. In this case try with an IPv4-only keyserver like:<br />
<br />
keyserver hkp://ipv4.pool.sks-keyservers.net:11371<br />
<br />
If you happen to forget to run {{ic|pacman-key --populate archlinux}} you might get some errors while importing keys.<br />
<br />
If none of this helps, your ''pacman'' cache, located at {{ic|/var/cache/pacman/pkg/}} might contain unsigned packages from previous attempts. Try cleaning the cache manually or run:<br />
<br />
# pacman -Sc<br />
<br />
which removes all cached packages that have not been installed.<br />
<br />
=== Disabling signature checking ===<br />
<br />
{{Warning|Use with caution. Disabling package signing will allow ''pacman'' to install untrusted packages automatically.}}<br />
<br />
If you are not concerned about package signing, you can disable PGP signature checking completely. Edit {{ic|/etc/pacman.conf}} and uncomment the following line under {{ic|[options]}}:<br />
<br />
SigLevel = Never<br />
<br />
You need to comment out any repository-specific SigLevel settings too because they override the global settings. This will result in no signature checking, which was the behavior before pacman 4. If you decide to do this, you do not need to set up a keyring with ''pacman-key''. You can change this option later if you decide to enable package verification.<br />
<br />
=== Resetting all the keys ===<br />
<br />
If you want to remove or reset all the keys installed in your system, you can remove {{ic|/etc/pacman.d/gnupg}} folder as root and rerun {{ic|pacman-key --init}} and following that add the keys as preferred.<br />
<br />
=== Removing stale packages ===<br />
<br />
If the same packages keep failing and you are sure you did all the ''pacman-key'' stuff right, try removing them like so {{ic|rm /var/cache/pacman/pkg/''badpackage''*}} so that they are freshly downloaded.<br />
<br />
This might actually be the solution if you get a message like {{ic|error: linux: signature from "Some Person <Some.Person@example.com>" is invalid}} or similar when upgrading (i.e. you might not be the victim of a MITM attack after all, your downloaded file was simply corrupt).<br />
<br />
=== Updating keys via proxy ===<br />
<br />
In order to use a proxy when updating keys the {{ic|honor-http-proxy}} option must be set in both {{ic|/etc/gnupg/dirmngr.conf}} and {{ic|/etc/pacman.d/gnupg/dirmngr.conf}}. See [[GnuPG#Use a keyserver]] for more information.<br />
<br />
{{Note|If ''pacman-key'' is used without the {{ic|honor-http-proxy}} option and fails, a reboot may solve the issue.}}<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Package Signing Proposal for Pacman]]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-1-makepkg-and-repo-add/ Pacman Package Signing – 1: Makepkg and Repo-add]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-2-pacman-key/ Pacman Package Signing – 2: Pacman-key]<br />
* [http://allanmcrae.com/2011/08/pacman-package-signing-3-pacman/ Pacman Package Signing – 3: Pacman]<br />
* [http://allanmcrae.com/2011/12/pacman-package-signing-4-arch-linux/ Pacman Package Signing – 4: Arch Linux]</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Patching_packages&diff=452235Patching packages2016-09-27T19:37:30Z<p>Lord Aro: /* Applying patches */ tweak example patch path</p>
<hr />
<div>[[Category:Package management]]<br />
[[ja:ABS でパッチを適用]]<br />
{{Related articles start}}<br />
{{Related|ABS}}<br />
{{Related|Getting PKGBUILDs from SVN}}<br />
{{Related articles end}}<br />
This document covers the steps to creating and/or applying patches to packages when using [[ABS]].<br />
<br />
== Creating patches ==<br />
<br />
If you are attempting to use a patch that you got from elsewhere (ie: you downloaded a patch to the Linux kernel), you can skip to the next section. However, if you need to edit source code, make files, configuration files, etc, you will need to be able to create a patch.<br />
<br />
{{Note|If you need only to change one or two lines in a file (e.g. a Makefile), you may be better off investigating the properties of {{ic|sed}} instead.}}<br />
<br />
Creating a patch for a package involves creating two copies of the package, editing the new copy, and creating a unified diff between the two files. When creating an Arch Linux package, this can be done as follows:<br />
<br />
# Add the download source of the file to the source array of the {{ic|PKGBUILD}} you are creating. Of course, if you are altering an existing PKGBUILD, this step is taken care of.<br />
# Create a dummy (empty, or containing a single {{ic|echo}} command is good) build() function. If you are altering an existing {{ic|PKGBUILD}}, you should comment out most of the lines of the build function, as you are likely going to be running {{ic|makepkg}} several times, and you will not want to spend a lot of time waiting for a broken package to build.<br />
# Run {{ic|makepkg -o}} This will download the source files you need to edit into the {{ic|src}} directory.<br />
# Change to the {{ic|src}} directory. In standard cases, there will be a directory containing a bunch of files that were unzipped or untarred from a downloaded archive there (Sometimes it's a single file, but diffs work on multiple files too!) You should make two copies of these directories. One is a pristine copy that makepkg will not be allowed to manipulate, and one will be the new copy that you will create a patch from. You can name the two copies {{ic|package.pristine}} and {{ic|package.new}} or something similar.<br />
# Change into the {{ic|package.new}} directory. Edit whichever files need to be edited. The changes needed depend on what the patch has to do; it might correct a Makefile paths, it may have to correct source errors (for example, to agree with {{ic|gcc 3.4}}), and so on. You can also edit files in subfolders of the {{ic|package.new}} directory, of course. '''Do not''' issue any commands that will inadvertently create a bunch of files in the {{ic|package.new}} directory; ie: do not try to compile the program to make sure your changes work. The problem is that all the new files will show up in the patch, and you do not want that. Instead, apply the patch to another copy of the directory ('''not''' the pristine directory), either manually with the {{ic|patch}} command, or in the {{ic|PKGBUILD}} (described below) and test the changes from there.<br />
# Change back to the {{ic|src}} directory.<br />
# Run {{ic|diff -aur package.pristine package.new}} This will output all the changes you made in unified diff format. You can scan these to make sure the patch is good.<br />
# Run {{ic|diff -aur package.pristine package.new > package.patch}} to capture all the changes in a file named {{ic|package.patch}}. This is the file that will be used by patch. You may now apply the changes to a copy of the original directory and make sure they are working properly. You should also check to ensure that the patch does not contain any extraneous details. For example, you do not want the patch to convert all tabs in the files you edited to spaces because your text editor did that behind your back. You can edit the patch either using a text editor, or to be safer (and not accidentally introduce errors into the diff file), edit the original files and create the patch afresh.<br />
<br />
{{Note|[[git]] is also able to generate patch via {{ic|git diff -p -u commit_hash > patchfile.diff}} inside a working tree.}}<br />
<br />
== Applying patches ==<br />
<br />
This section outlines how to apply patches you created or downloaded from the Internet from within a {{ic|PKGBUILD}}'s {{ic|prepare()}} function. Follow these steps:<br />
<br />
# Add an entry to the {{ic|source}} array of the {{ic|PKGBUILD}} for the patch file, separated from the original source url by a space. If the file is available online, you can provide the full URL and it will automatically be downloaded and placed in the {{ic|src}} directory. If it is a patch you created yourself, or is otherwise not available, you should place the patch file in the same directory as the {{ic|PKGBUILD}} file, and just add the name of the file to the source array so that it is copied into the {{ic|src}} directory. If you redistribute the {{ic|PKGBUILD}}, you should, of course, include the patch with the {{ic|PKGBUILD}}.<br />
# Then use {{ic|updpkgsums}} to update the {{ic|md5sums}} array. Or manually add an entry to the {{ic|md5sums}} array; you can generate sum of your patch using {{ic|md5sum}} tool.<br />
# Create the {{ic|prepare()}} function in the {{ic|PKGBUILD}} if one is not already present.<br />
# The first step is to change into the directory that needs to be patched (in the {{ic|prepare()}} function, not on your terminal! You want to automate the process of applying the patch). You can do this with something like {{ic|cd $srcdir/$pkgname-$pkgver}} or something similar. {{ic|$pkgname-$pkgver}} is often the name of a directory created by untarring a downloaded source file, but not in all cases.<br />
# Now you simply need to apply the patch from within this directory. This is very simply done by adding <br />
patch -p1 <pkgname.patch <br />
to your {{ic|prepare()}} function, changing {{ic|pkgname.patch}} to the name of the file containing the diff (the file that was automatically copied into your {{ic|src}} directory because it was in the {{ic|source}} array of the {{ic|PKGBUILD}} file).<br />
<br />
An example prepare-function:<br />
prepare() {<br />
cd $pkgname-$pkgver<br />
patch -Np1 -i ${srcdir}/eject.patch<br />
}<br />
<br />
Run {{ic|makepkg}} (from the terminal now). If all goes well, the patch will be automatically applied, and your new package will contain whatever changes were included in the patch. If not, you may have to experiment with the {{ic|-p}} option of patch. read {{ic|man patch}} for more information.<br />
Basically it works as follows. If the diff file was created to apply patches to files in {{ic|myversion/}}, the diff files will be applied to {{ic|myversion/file}}. You are running it from within the {{ic|yourversion/}} directory (because you cd would into that directory in the {{ic|PKGBUILD}}), so when patch applies the file, you want it to apply it to the file {{ic|file}}, taking off the {{ic|myversion/}} part. {{ic|-p1}} does this, by removing one directory from the path. However, if the developer patched in {{ic|myfiles/myversion}}, you need to remove two directories, so you use {{ic|-p2}}.<br />
<br />
If you do not apply a -p option, it will take off all directory structure. This is ok if all the files are in the base directory, but if the patch was created on {{ic|myversion/}} and one of the edited files was {{ic|myversion/src/file}}, and you run the patch without a {{ic|-p}} option from within {{ic|yourversion}}, it will try to patch a file named {{ic|yourversion/file}}.<br />
<br />
Most developers create patches from the parent directory of the directory that is being patched, so {{ic|-p1}} will usually be right.<br />
<br />
== Using quilt ==<br />
<br />
A simpler way to create patches is using {{Pkg|quilt}} which has better job to manage many patches, such as applying patches, refreshing patches, and reverting patched files to original state. {{Pkg|quilt}} is used on [https://wiki.debian.org/UsingQuilt Debian] to manage their patches. See [http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf Using Quilt] for basic information about basic quilt usage to generate, apply patches, and reverting patched files.<br />
<br />
== See also ==<br />
<br />
* http://www.kegel.com/academy/opensource.html — Useful information on patching files</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Guake&diff=275362Guake2013-09-13T16:01:30Z<p>Lord Aro: /* Window width */ better way of editing window alignment</p>
<hr />
<div>[[Category:Terminal emulators]]<br />
[[de:Guake]]<br />
[[ru:Guake]]<br />
{{Article summary start}}<br />
{{Article summary text|This article demonstrates the installation of Guake}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNOME}}<br />
{{Article summary end}}<br />
[http://guake.org Guake] is a top-down terminal for [[GNOME]] (in the style of Yakuake for [[KDE]], [[Tilda]] or the terminal used in Quake).<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] {{Pkg|guake}}, available in the [[official repositories]].<br />
<br />
== Usage ==<br />
<br />
Once installed, you can start Guake from the terminal with:<br />
<br />
$ guake<br />
<br />
After guake has started you can right click on the interface and select Preferences to change the hotkey to drop the terminal automatically, by default it is set to F12.<br />
<br />
== Autostartup ==<br />
<br />
You may want Guake to load on starting up Desktop Environment. To do this, you need to<br />
{{bc|# cp /usr/share/applications/guake.desktop /etc/xdg/autostart/}}<br />
<br />
See [[Autostarting]] for more info.<br />
<br />
== Window width ==<br />
<br />
Guake takes all the width of your display by default and there's no such option in "Preferences". To change width you can edit the program itself ({{ic|/usr/bin/guake}}) which is [[Python|python]] script.<br />
Find that string:<br />
<br />
width &#61; 100<br />
<br />
It is width value in percents, change it to whatever you like.<br />
<br />
If you want to align new "narrowed" window left or right find string (just below the 'width' line above).<br />
<br />
halignment &#61; self.client.get_int(KEY('/general/window_halignment'))<br />
<br />
and replace the part after the '&#61;' sign with "ALIGN_LEFT" or "ALIGN_RIGHT".<br />
<br />
To avoid overwrites on update, save it as /usr/local/bin/guake and remember to make it executable.<br />
<br />
== Dual monitor workaround ==<br />
<br />
The traditional patch for dual monitors is no longer available, but a workaround is to define the start points for the window.<br />
Edit {{ic|/usr/bin/guake}}.<br />
Find that string<br />
<br />
window_rect.y &#61; 0<br />
<br />
is the default point in Y coordinate if you need change for the width of top desktop bar (or the long from the top of the bar to below), if you use it, <br />
and add the default x coordinate in the line below, for positioned the window I use:<br />
<br />
window_rect.x &#61; total_width - window_rect.width<br />
window_rect.y &#61; 24 <br />
window_rect.x &#61; 1024 <br />
return window_rect<br />
<br />
My first window is 1024 pixels and my second window is 1280 pixels, so guake get size of the first window from left to right which is why I must increase the width by a percentage<br />
<br />
Find that string<br />
<br />
width &#61; 100<br />
<br />
Change de value 100 for a more greater, in my case 125 (1280 divided by 1024 and multiplicated by 100.<br />
<br />
If the window width identified wrong, try to change the display number in<br />
<br />
window_rect = screen.get_monitor_geometry(0)<br />
<br />
== 'Ctrl' Keybind Problem ==<br />
<br />
As of {{Pkg|guake}} 0.4.2-7, there has been a noted bug affecting multiple users concerning the use of the 'Ctrl' key on the Keyboard Shortcuts to toggle guake visibility in the "Keyboard shortcuts" tab of guake-prefs (i.e. Users that setup 'Ctrl+Shift+z' to open the guake console can open it by pressing 'Shift+z', hence having the Ctrl key-bind irrelevant.<br />
•••••••••••<br />
There is a bug in the program that stores the settings in Toggle Guake Visibility that places the Ctrl string as "<Primary>" instead of "<Control>".<br />
<br />
The workaround is to use the command-line gconftool-2 from {{Pkg|gconf}} package, get the current string shortcut string from {{ic|/apps/guake/keybindings/global/show_hide}}, and replace all instances of "<Primary>" to "<Control>".<br />
<br />
To get what the current keyboard shortcut string is:<br />
# gconftool-2 -g /apps/guake/keybindings/global/show_hide<br />
<br />
To activate the guake console with Ctrl+Shift+z for example:<br />
# gconftool-2 -t string -s /apps/guake/keybindings/global/show_hide "<Control><Shift>z"<br />
<br />
It would be easier to use the graphical gconftool equivalent {{Pkg|gconf-editor}} to browse for and edit the {{ic|/apps/guake/keybindings/global/show_hide}} string. Replace "<Primary>" in the string with "<Control>".<br />
<br />
Alternatively you can use this script to replace instances of <Primary> with <Control> in the {{ic|/apps/guake/keybindings/global/show_hide}} string:<br />
{{hc|~/replaceit.sh<br />
|#!/bin/bash<br />
|2=<nowiki>if which gconftool-2 &> /dev/null<br />
then<br />
val=$(printf "%s" $(gconftool-2 -g /apps/guake/keybindings/global/show_hide))<br />
newval=${val/"<Primary>"/"<Control>"}<br />
if [ "$newval" = "$val" ]<br />
then echo "No changes made. Could not find or replace <Primary> in your settings."<br />
else<br />
echo "Replacing old string $val with new string:$newval"<br />
gconftool-2 -t string -s /apps/guake/keybindings/global/show_hide "$newval"<br />
fi<br />
else<br />
echo "gconftool-2 not found. Please install gconf. Exiting..."<br />
fi</nowiki>}}</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Google_Earth&diff=275352Google Earth2013-09-13T15:26:25Z<p>Lord Aro: /* 3) Caught signal 11 */</p>
<hr />
<div>[[Category:Internet Applications]]<br />
[[it:Google Earth]]<br />
[[pl:Google Earth]]<br />
From the [http://support.google.com/earth/bin/answer.py?hl=en&answer=176145 project web page]:<br />
<br />
''"Google Earth allows you to travel the world through a virtual globe and view satellite imagery, maps, terrain, 3D buildings, and much more. With Google Earth's rich, geographical content, you are able to experience a more realistic view of the world. You can fly to your favorite place, search for businesses and even navigate through directions."''<br />
<br />
== Installation ==<br />
<br />
Google Earth is not presently available in the [[Official Repositories]], and will need to be installed from the [[AUR]].<br />
<br />
The latest version is called {{AUR|google-earth}} and the legacy one (intended for certain Intel users) {{AUR|google-earth6}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Excessive memory usage ===<br />
The application's memory usage can be controlled either by limiting the maximum cache size in {{ic|Tools}} -> {{ic|Options}} -> {{ic|Cache}} or by lowering the graphics settings in the {{ic|3D View}} tab.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Tip|The project has an [https://productforums.google.com/forum/#!categories/earth/linux official support forum] for anything not covered here.}}<br />
<br />
=== Google Earth crashes at startup ===<br />
==== 1) Startup tips are enabled ====<br />
The startup tips can be very useful but also known to cause crashes on certain Intel cards. To disable them use {{ic|1='''enableTips=false'''}} in {{ic|~/.config/Google/GoogleEarthPlus.conf}}:<br />
$ sed -i "s|enableTips=.*|enableTips=false|" ~/.config/Google/GoogleEarthPlus.conf<br />
<br />
==== 2) No new line at the end of {{ic|~/.drirc}} ====<br />
To prevent a crash with -dri drivers you may need to add a new line to {{ic|~/.drirc}} with:<br />
$ echo >> ~/.drirc<br />
<br />
==== 3) Caught signal 11 ====<br />
It seems that for fglrx/[[Catalyst]] users Google Earth is completely broken, with no known fix at this time. Use {{AUR|google-earth6}} until a fix can be found.<br />
<br />
=== Earth shows nothing but yellow borders ===<br />
Taken from the changelog of [https://support.google.com/earth/bin/answer.py?hl=en&answer=40901 7.0.3] this issue has improved to some extent but overall it's still there:<br />
<br />
Imagery now displays for Linux users running specific families of Intel GPUs.<br />
<br />
The solution is to just stick with the legacy version called {{AUR|google-earth6}}.</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Google_Earth&diff=273268Google Earth2013-08-30T21:58:52Z<p>Lord Aro: /* 3) Caught signal 11 */</p>
<hr />
<div>[[Category:Internet Applications]]<br />
[[it:Google Earth]]<br />
[[pl:Google Earth]]<br />
From the [http://support.google.com/earth/bin/answer.py?hl=en&answer=176145 project web page]:<br />
<br />
''"Google Earth allows you to travel the world through a virtual globe and view satellite imagery, maps, terrain, 3D buildings, and much more. With Google Earth's rich, geographical content, you are able to experience a more realistic view of the world. You can fly to your favorite place, search for businesses and even navigate through directions."''<br />
<br />
== Installation ==<br />
<br />
Google Earth is not presently available in the [[Official Repositories]], and will need to be installed from the [[AUR]].<br />
<br />
The latest version is called {{AUR|google-earth}} and the legacy one (intended for certain Intel users) {{AUR|google-earth6}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Excessive memory usage ===<br />
The application's memory usage can be controlled either by limiting the maximum cache size in {{ic|Tools}} -> {{ic|Options}} -> {{ic|Cache}} or by lowering the graphics settings in the {{ic|3D View}} tab.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Tip|The project has an [https://productforums.google.com/forum/#!categories/earth/linux official support forum] for anything not covered here.}}<br />
<br />
=== Google Earth crashes at startup ===<br />
==== 1) Startup tips are enabled ====<br />
The startup tips can be very useful but also known to cause crashes on certain Intel cards. To disable them use {{ic|1='''enableTips=false'''}} in {{ic|~/.config/Google/GoogleEarthPlus.conf}}:<br />
$ sed -i "s|enableTips=.*|enableTips=false|" ~/.config/Google/GoogleEarthPlus.conf<br />
<br />
==== 2) No new line at the end of {{ic|~/.drirc}} ====<br />
To prevent a crash with -dri drivers you may need to add a new line to {{ic|~/.drirc}} with:<br />
$ echo >> ~/.drirc<br />
<br />
==== 3) Caught signal 11 ====<br />
It seems that for fglrx/{{Catalyst}} users Google Earth is completely broken, with no known fix at this time. Use {{AUR|google-earth6}} until a fix can be found.<br />
<br />
=== Earth shows nothing but yellow borders ===<br />
Taken from the changelog of [https://support.google.com/earth/bin/answer.py?hl=en&answer=40901 7.0.3] this issue has improved to some extent but overall it's still there:<br />
<br />
Imagery now displays for Linux users running specific families of Intel GPUs.<br />
<br />
The solution is to just stick with the legacy version called {{AUR|google-earth6}}.</div>Lord Arohttps://wiki.archlinux.org/index.php?title=Google_Earth&diff=273267Google Earth2013-08-30T21:58:04Z<p>Lord Aro: </p>
<hr />
<div>[[Category:Internet Applications]]<br />
[[it:Google Earth]]<br />
[[pl:Google Earth]]<br />
From the [http://support.google.com/earth/bin/answer.py?hl=en&answer=176145 project web page]:<br />
<br />
''"Google Earth allows you to travel the world through a virtual globe and view satellite imagery, maps, terrain, 3D buildings, and much more. With Google Earth's rich, geographical content, you are able to experience a more realistic view of the world. You can fly to your favorite place, search for businesses and even navigate through directions."''<br />
<br />
== Installation ==<br />
<br />
Google Earth is not presently available in the [[Official Repositories]], and will need to be installed from the [[AUR]].<br />
<br />
The latest version is called {{AUR|google-earth}} and the legacy one (intended for certain Intel users) {{AUR|google-earth6}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Excessive memory usage ===<br />
The application's memory usage can be controlled either by limiting the maximum cache size in {{ic|Tools}} -> {{ic|Options}} -> {{ic|Cache}} or by lowering the graphics settings in the {{ic|3D View}} tab.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Tip|The project has an [https://productforums.google.com/forum/#!categories/earth/linux official support forum] for anything not covered here.}}<br />
<br />
=== Google Earth crashes at startup ===<br />
==== 1) Startup tips are enabled ====<br />
The startup tips can be very useful but also known to cause crashes on certain Intel cards. To disable them use {{ic|1='''enableTips=false'''}} in {{ic|~/.config/Google/GoogleEarthPlus.conf}}:<br />
$ sed -i "s|enableTips=.*|enableTips=false|" ~/.config/Google/GoogleEarthPlus.conf<br />
<br />
==== 2) No new line at the end of {{ic|~/.drirc}} ====<br />
To prevent a crash with -dri drivers you may need to add a new line to {{ic|~/.drirc}} with:<br />
$ echo >> ~/.drirc<br />
<br />
==== 3) Caught signal 11 ====<br />
It seems that for fglrx/{{Catalyst}} users Google Earth is completely broken, with no known fix at this time. Use {{AUR|googleearth6}} until a fix can be found.<br />
<br />
=== Earth shows nothing but yellow borders ===<br />
Taken from the changelog of [https://support.google.com/earth/bin/answer.py?hl=en&answer=40901 7.0.3] this issue has improved to some extent but overall it's still there:<br />
<br />
Imagery now displays for Linux users running specific families of Intel GPUs.<br />
<br />
The solution is to just stick with the legacy version called {{AUR|google-earth6}}.</div>Lord Aro